Kapitel 6: Designprinzipien

TPs Design dreht sich um fünf Kernprinzipien. Diese Prinzipien leiten nicht nur das technische Design des Protokolls selbst, sondern definieren auch die Verhaltensstandards, denen alle Teilnehmer im TP-Ökosystem folgen sollten.

6.1 Geteilte Kognition vor Nachrichtenübermittlung

TPs primäres Designprinzip lautet: Wann immer möglich, die Etablierung eines geteilten kognitiven Raums gegenüber serialisierter Nachrichtenübertragung priorisieren. Das Nachrichtenübermittlungsmodell führt bei jeder Interaktionsrunde Kodierungsverluste, Übertragungslatenz und semantische Mehrdeutigkeit ein; das Modell der geteilten Kognition lässt zusammenarbeitende Parteien direkt auf dieselben kognitiven Ressourcen zugreifen und eliminiert grundlegend die Reibung des Informationstransfers. Dieses Prinzip leugnet nicht den Wert der Nachrichtenübermittlung — die Etablierung des geteilten Raums selbst erfordert Nachrichtenverhandlung — aber es definiert klar TPs Designrichtung: unnötige Serialisierung und Deserialisierung minimieren.

Praxisbeispiel: Zwei Fays arbeiten gemeinsam an der Bearbeitung eines Verkehrsunfall-Versicherungsanspruchs. Unter dem Nachrichtenübermittlungsmodell muss der Versicherungs-Fay den vollständigen Unfallbericht, Fotos, Fahrzeuginformationen und Policendetails an den Bewertungs-Fay senden... jede Kommunikationsrunde beinhaltet das Verpacken und Übertragen großer Datenmengen. Unter dem Modell der geteilten Kognition etablieren beide Parteien einen geteilten Kontext, in dem der Unfallbericht, Fotos und Policeninformationen im geteilten Raum eingebunden sind. Der Bewertungs-Fay betrachtet und annotiert direkt im geteilten Raum, und der Versicherungs-Fay sieht die Annotationsergebnisse in Echtzeit — der gesamte Prozess ist wie zwei Schadensregulierer, die am selben Schreibtisch dieselbe Fallakte überprüfen.

6.2 Transportagnostik

TP konzentriert sich auf die semantische Schicht, nicht auf die Transportschicht. TP-Nachrichten können über A2As JSON-RPC, MCPs Tool Call, traditionelle REST APIs oder sogar natürlichsprachliche Prompts zugestellt werden. Dieses Prinzip stellt sicher, dass TP nicht an ein einzelnes zugrunde liegendes Protokoll gebunden ist; wenn neue Transportmethoden entstehen, muss TP nur einen Transportadapter hinzufügen, ohne die eigenen semantischen Definitionen des Protokolls zu ändern. Transportagnostik bedeutet auch, dass TP inhärent Vorwärtskompatibilität besitzt — es kann sich an Transportprotokolle anpassen, die noch nicht erfunden wurden.

Praxisbeispiel: Ein Unternehmens-Fay, der in der Cloud läuft, muss mit einem Fay kommunizieren, der auf einem Edge-Gerät läuft (wie einem Fabriksensor-Gateway). Der Cloud-Fay unterstützt nativ A2A, aber das Edge-Gerät hat nur eine einfache REST API. TPs Transportagnostik lässt beide Parteien kommunizieren, ohne sich um die Transportfähigkeiten des anderen zu sorgen — TP passt sich automatisch an, und der vom Cloud-Fay via A2A gesendete Intent wird transparent in einen REST-API-Aufruf übersetzt und an das Edge-Gerät geliefert.

6.3 Adaptive Protokollverhandlung

In einem heterogenen AI-Ökosystem können verschiedene Fays unterschiedliche Protokollsprachen „sprechen". TP verlangt nicht, dass alle Teilnehmer ein einheitliches Transportprotokoll verwenden; stattdessen ermöglicht es durch einen adaptiven Verhandlungs- und Übersetzungsmechanismus Fays mit unterschiedlichen „Muttersprachen" nahtlose Kommunikation. Der Verhandlungsprozess umfasst drei Schritte — Fähigkeitserkundung, Vertragsverhandlung und semantisches Mapping — und stellt sicher, dass Absichten bei der protokollübergreifenden Übersetzung nicht verloren gehen. Dieses Prinzip senkt die Eintrittsbarriere zum TP-Ökosystem — jeder Fay, der mindestens eine Transportmethode unterstützt, kann an der TP-Kommunikation teilnehmen.

Praxisbeispiel: Der HR-Fay eines multinationalen Unternehmens muss mit Sozialversicherungs-coFays in verschiedenen Ländern kommunizieren. Der US-Sozialversicherungs-coFay verwendet A2A, Japans verwendet MCP Tool Call, und der der EU verwendet REST API. Der HR-Fay muss keinen unterschiedlichen Integrationscode für jedes Land schreiben — TP erkundet automatisch die Protokollfähigkeiten der Gegenseite während der Sitzungsetablierung, verhandelt eine Transportmethode, die beide Seiten unterstützen, und alle nachfolgende Kommunikation ist vollständig transparent.

6.4 Host-souveräner Datenschutz

In der iFay-Weltanschauung handelt jeder Fay im Namen eines Hosts. Daher hat der Host absolute Souveränität über seine Daten. Ein Fay kann nicht einseitig entscheiden, welche kognitiven Ressourcen geteilt werden — jede Datenoffenlegung muss innerhalb der vom Host vorab autorisierten Grenzen erfolgen. TP stellt durch einen dreifachen Mechanismus aus Ende-zu-Ende-Verschlüsselung, selektiver Offenlegung (SelectiveDisclosure) und zeitlich begrenzten Callback-Credentials (CallbackCredential) sicher, dass die Privatsphäre-Daten des Hosts während der Übertragung und des Zugriffs stets geschützt sind. Der Host kann die Autorisierung jederzeit widerrufen und die Datenteilung beenden.

Praxisbeispiel: Der iFay eines Benutzers beantragt in seinem Namen einen Kredit bei einem Bank-coFay. Die Bank muss den Einkommensnachweis und die Kredithistorie des Benutzers prüfen, aber der Benutzer möchte nicht, dass die Bank seine Ausgabendetails und sein Anlageportfolio sieht. Der Benutzer spezifiziert bei der Autorisierung ausdrücklich, dass „nur die Gehaltsabrechnungen der letzten 12 Monate und der Kredit-Score offengelegt werden dürfen", und der iFay legt über den Mechanismus der selektiven Offenlegung nur diese beiden Posten offen. Nach Abschluss der Kreditgenehmigung läuft das Callback-Credential automatisch ab, und der Bank-coFay kann nicht mehr auf Benutzerdaten zugreifen. Wenn der Benutzer es sich zwischendurch anders überlegt, kann er die Autorisierung jederzeit widerrufen und die Datenteilung sofort beenden.

6.5 Auditierbare Vertrauensgrenzen

Vertrauen ist nicht blind — es muss auf einer überprüfbaren Grundlage aufgebaut werden. TP verlangt, dass alle Operationen, die den Zugriff auf Privatsphäre-Daten, die Nutzung von Credentials und die Inter-Fay-Kommunikation betreffen, auditierbar sind. Audit-Aufzeichnungen enthalten den Operationstyp, die Identitäten der Teilnehmer, Zeitstempel und den Zugriffsumfang, aber nicht den tatsächlichen Dateninhalt oder Credential-Token im Klartext. Der Host kann das Audit-Log jederzeit überprüfen, um zu verstehen, wer auf seine Daten zugegriffen hat, zu welchem Zeitpunkt und zu welchem Zweck. Dieses Prinzip stellt sicher, dass Vertrauen innerhalb des TP-Ökosystems transparent und nachverfolgbar ist.

Praxisbeispiel: Der iFay eines Patienten hat im vergangenen Monat mehrfach mit einem medizinischen coFay, einem Versicherungs-coFay und einem Apotheken-coFay interagiert. Der Patient kann das Audit-Log öffnen und Aufzeichnungen sehen wie: „3. April, 14:23 — Medizinischer coFay hat auf Ihre Allergiehistorie zugegriffen (autorisierter Umfang: diagnosebezogene Daten)", „5. April, 09:15 — Versicherungs-coFay hat über Callback-Credential auf Diagnosecodes und Kostenaufschlüsselung zugegriffen (Credential abgelaufen am 5. April, 17:00)." Das ist wie die Überprüfung der Transaktionshistorie eines Bankkontos — jede „Datentransaktion" ist dokumentiert.