EMILIA Protocol

EMILIA Protocol

---

KI-Agenten werden zu Arbeitskräften. Arbeitskräfte brauchen Autorität.

EMILIA ist die Authority-Kontrollebene für autonome Arbeit. Gate ist die Konsequenzgrenze, an der die berechtigte Absicht eines Agenten zu einer Änderung von Geld, Code, Berechtigungen, Aufzeichnungen oder Infrastruktur wird. Ein Mensch oder eine Institution definiert ein endliches Betriebsmandat; Gate prüft die exakte Arbeitseinheit dagegen, bevor der geschützte Provider-Pfad beginnen kann.

Gate ist die kommerzielle Konsequenz-Firewall an dieser Grenze. Es verifiziert die Autorität, die der Eigentümer für die exakte Aktion benötigt, reserviert diese Autorität vor dem Provider-Eintritt, erlaubt einen zugelassenen Provider-Versuch für die abgedeckte Autorisierungsinstanz innerhalb seiner dauerhaften Authority-Domäne und hinterlässt tragbare Beweise dafür, was der geschützte Pfad zugelassen und später beobachtet hat. Wenn das Ergebnis unbekannt ist, verlangt es Rekonziliation statt eines blinden Wiederholungsversuchs. Protocol beweist. Gate verhindert.

• Authority Brain bildet unterstützte deklarierte Aktionsflächen lokal ab. Kein Konto, Upload oder Callback erforderlich. Discovery erzeugt keine Autorität; der Eigentümer prüft die Karte.
• EMILIA Gate wandelt die genehmigte Karte und das Betriebsmandat in präventive Kontrolle auf einem vollständig vermittelten, berechtigungsbesitzenden Executor-Pfad um.
• EMILIA Protocol ist das offene Apache-2.0-Substrat für Exakt-Aktions-Identität, native Beweisverifikation, Beweiskomposition, dauerhaften Zulassungsstatus und tragbare Arbeitsaufzeichnungen.
• EMILIA Approver erfasst eine gerätegebundene Exakt-Aktions-Entscheidung eines Menschen, wenn das Mandat oder die lokale Richtlinie frische menschliche Autorität erfordert. Ein menschlicher Klick ist eine Autoritätsquelle, nicht das Standard-Ausführungsmodell.
• EMILIA Assurance Plane bietet bereichsbezogene Verifikation, Wiederholungsausführung, Konformitätsberichte und Bereitstellungsnachweise. Es unterstützt Wirtschaftsprüfer, Versicherer, Aufsichtsbehörden und Kunden; EMILIA ist kein Wirtschaftsprüfer oder akkreditierter Zertifizierer, und es läuft kein öffentliches EMILIA-Zertifizierungsprogramm.

Führen Sie die lokale Karte aus (npx @emilia-protocol/scan), wählen Sie einen konsequenzrelevanten Workflow und platzieren Sie Gate dort, wo die Provider-Berechtigung Absicht in Arbeit verwandelt.

Das erste reibungsarme Vertriebsprofil ist GitHub: Das Open Merge Gate bindet ein repository-eigenes Mandat und einen losgelösten Beleg an die exakten Basis- und Head-Commits, bevor ein geschützter Merge-Check besteht. Es ist nur dann präventiv, wenn das Repository den Check als erforderlich festlegt und alternative Merge-Pfade schließt. Dies ist ein Produkt- und Vertriebsexperiment, kein Beleg für externe Übernahme.

Der Agent darf weiterlaufen. Seine Autorität endet.

Kontinuierliche und selbstverbessernde Agenten erzeugen ein Kontrollproblem, das allein durch Prozessterminierung nicht gelöst werden kann: Der Eigentümer muss möglicherweise neue Konsequenzen stoppen, ohne zu behaupten, dass die Berechnung gestoppt wurde oder dass ein externer Effekt rückgängig gemacht wurde. Gates Emergency Authority Freeze macht daraus einen dauerhaften Autoritätsübergang. Innerhalb einer abgedeckten Gate-Kontrolldomäne blockiert Freeze neue Reservierungen und verhindert, dass eine ältere Reservierung nach einem Wechsel der Kontrollepoche eintritt. Wenn der Provider-Eintritt zuerst serialisiert wurde, bleibt die Operation verbraucht und muss rekonziliert werden; Restore erhöht die Epoche erneut und erweckt keine alte Autorität wieder.

Diese Garantie erfordert vollständige Vermittlung und autoritativen gemeinsamen Zustand. Sie stoppt den Agenten nicht, macht keinen eingetretenen Effekt rückgängig und bietet keinen sofortigen Freeze über eine getrennte Leasing-Domäne hinweg. Die aktuelle Referenzimplementierung deckt die lokale In-Memory- und PostgreSQL-Kontrolldomäne ab; Leased-Edge-Ausbreitung und tragbare signierte Freeze-Ereignisnachweise bleiben ausdrückliche Implementierungslücken.

Der benannte bezahlte Workflow bleibt die KI-gestützte nachteilige medizinische Notwendigkeitsentscheidung des Zahlers, unter einer Sicherheitsregel: kein gültiger Lizenzüberprüfungsnachweis, keine nachteilige Entscheidung. Fehlende Nachweise führen zu rechtmäßiger menschlicher Überprüfung oder einem patientenschützenden Fallback; es ist keine Autorität, medizinisch notwendige Versorgung vorzuenthalten.

KI-Systeme und Repository-Reviewer: Beginnen Sie mit AI_CONTEXT.md. Aktuelle maschinenlesbare Nachweise, Herkunft, Annahmen und Ausschlüsse sind unter EMILIA-REPO-CONTEXT-v1 veröffentlicht. Archivierte oder gestufte Dokumente begründen keinen aktuellen Implementierungs- oder IETF-Status. Öffentliche Due-Diligence-Nachweise und Anspruchsgrenzen: DUE_DILIGENCE.md.

Technische Nachweise, keine Architekturbehauptungen

EMILIA liefert einen Sicherheitsfall, den Reviewer ausführen können. Das aktuelle Repository löst 35 Sicherheitsansprüche über 259 gehashte Nachweisdateien, verifiziert 20 Tamarin-Lemmata über zwei komponierte Dolev-Yao-Modelle — 17 All-Traces-Verpflichtungen und 3 Exists-Trace-Erreichbarkeitszeugen — und bewahrt 8 absichtlich abgeschwächte Varianten, die konkrete Angriffsspuren erzeugen, wenn tragende Prüfungen entfernt werden. Das Live-Konformitätskorpus desselben Teams enthält 21 Suiten und 331 aktuelle Vektoren. Separativ ist ein extern verfasster Rust-Verifizierer auf das eingefrorene 16-Suiten/164-Vektor-Bündel und eine 359-Fälle-Hostilitätskampagne gepinnt. Die breitere Suite enthält 8.865 automatisierte Tests über 533 Dateien.

Produktions-JavaScript- und JSDoc-Oberflächen werden compilergeprüft mit TypeScript checkJs; die sichere App hat ein eigenes Kompatibilitäts-Compiler-Projekt, während Deklarationen und das öffentliche TypeScript-SDK im strikten Modus geprüft werden. Dies ist vollständige konfigurierte Produktions-Typabdeckung, keine Behauptung, dass das Repository vollständig von JavaScript auf TypeScript umgestellt wurde oder dass jedes JavaScript-Projekt die Option strict von TypeScript aktiviert hat.

Jeder Sicherheitsanspruch benennt den Durchsetzungspfad, positive und negative Vektoren, Sprachabdeckung, formellen Umfang oder ausdrückliche Lücke, Annahmen, Ausschlüsse und Nachweishash. Beginnen Sie mit der menschenlesbaren Nachweiskarte, prüfen Sie dann den aufgelösten Sicherheitsfall oder führen Sie npm run check:security-case aus.

AEB-1: Testen Sie die Nachweis-zu-Wirkung-Grenze

Das offene AEB-1 Consequence Admission Conformance Pack testet den letzten Kontrollpunkt vor einer konsequenzrelevanten Aktion: native Verifikation, akzeptierende Partei, exakter CAID/Aktions-Abgleich, Nachweiserfüllung, lokale Autorisierung, atomare Reservierung, INVOKING-Verwahrung, getrennte Provider-Ergebnis- und beobachtete-Wirkung-Wahrheit, kein-blindes-Wiederholen-Verhalten und authentifizierte Rekonziliation.

npx @emilia-protocol/verify aeb-conformance --reference

Es ist formatneutral und selbstausführend. Ein bestandener Bericht ist selbstbescheinigter Konformitätsnachweis — kein Audit, keine Zertifizierung, kein Produktionsbereitstellungsanspruch und keine Berechtigung zur Ausführung einer Aktion.

Für einen fokussierten ausführbaren Beweis des Gate-Pfads des Repositorys führen Sie aus:

npm run proof:gate:reference

Dieser Befehl übt lokale Beispiele und fokussierte Dienstgrenzen mit generierten Schlüsseln, In-Memory-Zustand und Mock-Provider-Verhalten. Er ist ein nützlicher lokaler Beweis, kein Nachweis eines echten Menschen, einer externen Bank, einer Produktionsbereitstellung oder einer End-to-End-Produktionsintegration.

Identität ist keine Stellenbeschreibung

Identität sagt, wer oder was aufruft. Richtlinie sagt, was allgemein erlaubt ist. Keines von beiden definiert die endliche Aufgabe, die ein autonomer Arbeiter jetzt ausführen darf: seine Mission, Materialaktionsgrenzen, Budget, erforderliche Nachweise, Ablauf, Delegationsregeln und Ausnahmepfad.

EMILIA hält diese Fragen getrennt:

Ebene	Frage
Identität	Wer oder was ist vorhanden?
Richtlinie	Was ist allgemein erlaubt?
Autorität	Welche exakte Arbeit darf dieser Agent unter diesem Mandat ausführen?

Berechtigungen gewähren Reichweite. Autorität definiert die Aufgabe. Nicht jede Aktion braucht einen Menschen; jede konsequenzrelevante Aktion braucht gültige Autorität.

An der Basis stellt EP Core weiterhin drei interoperable Objekte bereit: Eine Trust Receipt trägt zuschreibbare Nachweise, ein Trust Profile repräsentiert strukturierten Vertrauenszustand und eine Trust Decision hält das richtlinienbewertete Ergebnis der akzeptierenden Partei fest. Die Authority-Kontrollebenen fügen exakte Aktionsbindung, endliche Mandate, Zulassung, Verbrauch und Ergebnisnachweise hinzu, ohne diese Objekte in einen einzigen Anspruch zusammenzuführen.

---

Setzen Sie das Mandat einmal. Lassen Sie den Agenten arbeiten.

Der Kunde definiert Mission, Grenzen, Nachweisanforderungen, Ablauf und Ausnahmeregeln. Lokaler Code darf diese Autorität einschränken; er kann sie nicht erfinden oder erweitern. Gate bindet jede ausführbare Anfrage an das Mandat, reserviert die abgedeckte Autorität vor dem Provider-Eintritt, erlaubt einen zugelassenen Provider-Versuch für diese Autorisierungsinstanz innerhalb der gemeinsamen dauerhaften Authority-Domäne und eskaliert nur, wenn Autorität fehlt, veraltet, erschöpft oder zu eng ist.

Die gebündelten MCP-Beispiele demonstrieren ein Richtlinienprofil, in dem eine frische menschliche Entscheidung an der Kante erforderlich ist. Sie führen die vollständige lokale Schleife aus — fehlende Nachweise abgelehnt, exakte Aktion signiert, ein Provider-Versuch zugelassen, gefälschte Nachweise abgelehnt — ohne zu behaupten, dass jede autonome Aktion einen menschlichen Klick braucht:

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

Die tiefere Kompositionsdemo führt eine CAID-gebundene delegierte Zahlung durch Gates echten begrenzten-Fähigkeiten-Pfad aus und verifiziert dann das signierte Ausführungszertifikat offline:

npm run demo:receipt-program

Sie enthält bewusst keine Blockchain- oder simulierte Null-Wissen-Behauptung. Siehe die receipt-program architecture für die Produktionszustands- und Vertrauensanforderungen.

Beginnen Sie mit einem Probelauf gegen Ihre deklarierte Tool-Oberfläche und generieren Sie dann die prüfbaren Integrationsdateien:

npx @emilia-protocol/scan protect ./tools.json
npx @emilia-protocol/scan protect ./tools.json --apply
node emilia/verify-setup.mjs

Der generierte lokale Check verwendet ausdrücklich ephemeren Demo-Zustand und beweist nur, dass sein synthetischer Handler nicht aufgerufen wurde. Produktion erfordert ein dauerhaftes Provenance-Ledger, einen gemeinsamen atomaren Verbrauchsspeicher, gepinnte Schlüssel und den Wrapper auf jedem Pfad zur echten Provider-Berechtigung. Siehe examples/mcp/ und /mcp.

Probieren Sie es in 30 Sekunden

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

Echte Face-ID-Freigabe ausprobieren → Genehmigen Sie eine Überweisung über 82.000 $ mit Ihrem eigenen Passkey. Sehen Sie, wie VERIFIED aussieht. Fälschen Sie den Beleg. Sehen Sie, wie er fehlschlägt.

Beliebigen Beleg im Browser verifizieren — einfügen, nichts wird hochgeladen.

---

So funktioniert es — ein Autoritätslebenszyklus

Probieren Sie es selbst aus: node examples/crash-test.mjs — vollständig offline, kein API-Schlüssel.

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

Mandat. Die Autoritätsquelle definiert endliche Arbeit. Es kann ein kundensigniertes Betriebsprogramm, eine begrenzte Fähigkeit, eine erforderliche menschliche Entscheidung, ein Quorum oder eine Komposition nativer Nachweise durch die akzeptierende Partei sein.

Exakte Arbeit. Gate bindet Methode, Ursprung, Angerufenen, Ziel, Vorkommnis und jedes wesentliche Feld in das kanonische ausführbare Objekt. Absicht, ein Prompt oder Tickettext ist nicht dieses Objekt.

Verifizieren, reservieren und eintreten. Native Artefakte bleiben nativ. Die akzeptierende Partei pinnt Vertrauens- und Zuordnungsprofile, bewertet die vollständige Nachweisanforderung, trifft die separate lokale Autorisierungsentscheidung und reserviert die abgedeckte Autorität, bevor der berechtigungsbesitzende Adapter in den Provider eintritt.

Frische menschliche Autorität, wenn erforderlich. Eine Richtlinie kann eine WebAuthn/Passkey- Entscheidung verlangen, die an die exakte Aktion und den deterministischen Anzeige-Hash gebunden ist. Dies verengt die Lücke zwischen „was Sie gesehen haben, ist was Sie signiert haben"; es beweist kein Verständnis, keine Weisheit, keine Rechtmäßigkeit und kein Ergebnis.

Für Unternehmensbereitstellungen kann Gate zusätzlich eine unabhängig verifizierte Authorization-Server-Bestätigung verlangen, die an genau diese menschlichen Nachweise, dieselbe exakte Aktion, den Identitätssnapshot, den der AS tatsächlich beobachtet hat, und den vorgesehenen Resource-Server-Schlüssel gebunden ist. Der Snapshot-Zeitpunkt und das maximale Alter bei der akzeptierenden Partei sind explizit: Ein frisches Token kann veraltete Verzeichnisdaten nicht aktuell machen. Der AS-Zweig ist Nachweis unter kundengepinnter Vertrauensbasis; er autorisiert nie allein, beweist keinen unmittelbaren Beschäftigungsstatus und macht den Agent-Orchestrator nicht zu einer Autorität. Wahrheitsgetreues Ergebnis. Zulassung ist keine Ausführung, und Ausführung ist keine Wirkung. Ein signierter Datensatz kann offline verifiziert werden; Provider- und Beobachter-Nachweise bleiben getrennt. Eine verlorene Antwort wird zu INDETERMINATE, einem Zustand, der abzugleichen ist—keine Berechtigung zum erneuten Versuch. Ein Heilmittel ist eine neue autorisierte Aktion und überschreibt niemals das alte Ergebnis.

---

Warum Entwickler es nutzen

Beginnen Sie damit, die Arbeit lokal zu kartieren, und schützen Sie dann eine deklarierte Aktionsfläche mit dem MCP-Server oder dünnen SDK-Wrapper. Der Scanner schlägt eine überprüfbare Karte vor; der Eigentümer definiert das Mandat; Gate besitzt die Provider-Anmeldedaten und setzt die exakte Aktion auf dem abgedeckten Pfad durch. Kein Scan beweist vollständige Vermittlung, und Entdeckung allein verleiht keine Autorität.

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

Der Agent erhält die Fähigkeit, begrenzte Arbeit auszuführen, keine dauerhafte Anmeldedaten, die er neu interpretieren kann.

---

Warum Unternehmen es brauchen

Agentenprozesse werden neu gestartet und Modelle ändern sich. Das Mandat des Kunden, der Verbrauchszustand, der Widerruf, die Unsicherheit und der Arbeitsverlauf müssen außerhalb dieser überleben. EMILIA hält diesen dauerhaften Autoritätszustand an der Grenze des Kunden, während fremde Nachweise über festgepinnte Adapter akzeptiert werden.

Das verwaltete Gate und die Assurance-Ebene fügen Mandatsoperationen, Integrationen, Nachweisoperationen, Wiederausführung, Support und Service-Level rund um das offene Protokoll hinzu. Der Kunde behält die Kontrolle über Autorität, Vertrauenswurzeln, Anmeldedaten, Richtlinien und portable Nachweise.

---

Der Standard

Das EMILIA Protocol ist offen und Apache-2.0. Seine Standardisierungsarbeit wird als Portfolio einzelner Internet-Drafts veröffentlicht. Ein veröffentlichter Internet-Draft ist keine RFC, kein übernommenes Arbeitsgruppen-Objekt und keine IETF-Befürwortung; Datatracker ist maßgeblich für Revision und Status.

Kanonische Vier-Dokument-Präsentationsfläche

Für die Lesernavigation ist der kanonische Nachweispfad:

1. Authorization Receipts-11 definiert das aktionsgebundene Genehmigungs-Nachweisprofil. Die aktuelle veröffentlichte Revision ist -11, eingereicht als Kandidaten-Einzeleinreichung auf dem Standards Track.
2. Human Authorization Binding-00 bindet ein Autorisierungs-Artefakt eines benannten Menschen in einen angrenzenden Host-Datensatz ein.
3. Authority Introduction-03 etabliert festgepinnte Vertrauenswurzeln der vertrauenden Partei und abgegrenzte Autorität.
4. Authorization Evidence Chain-05 bewertet, ob nativ verifizierte, aktionsgekoppelte Nachweise die Anforderung der vertrauenden Partei erfüllen; es gibt SATISFIED oder UNSATISFIED zurück, niemals AUTHORIZED.

Diese Vier-Dokument-Fläche dient nur der Präsentation. Sie führt keinen Entwurf im aktiven Portfolio zusammen, zieht keinen zurück, ersetzt, aktualisiert, obsoletisiert, unterordnet oder herabstuft keinen.

Getrennte Laufzeit-Ausführungssäule

Der Laufzeitpfad ist Architecture-02 → CAID-02 → AEC-05 → AEB-03: Systemgrenzen, exaktes Abgleichen materieller Aktionen, Nachweiserfüllung, dann ausführungsseitige Zulassung und dauerhafte Verwahrung von Konsequenzen. AEC erscheint in beiden Ansichten, weil die Nachweiserfüllung die Laufzeitzulassung speist, nicht weil die Ansichten gleichwertig sind.

Das vollständige aktive Portfolio umfasst weiterhin 23 Datatracker-Einträge: 20 aktive draft-schrock-*-Einträge und drei gemeinsam verfasste Einträge, jeweils mit eigenem Umfang und eigener Revisionshistorie. Siehe den Standards-Leitfaden, das Portfolio und das maschinenlesbare Statusinventar.

IETF-Internet-Drafts	Aktuelle lokale Schnappschüsse: veröffentlichtes Inventar · maßgeblicher Live-Status: IETF Datatracker
Sprachübergreifende Verifizierer	JavaScript · Python · Go — alle drei nachweislich übereinstimmend bei adversarischen Konformitätsvektoren, bei jedem Push (npm run conformance). Eine Konsistenzprüfung über die Portierungen eines Teams, keine Clean-Room-unabhängigen Implementierungen. Zusätzlich besteht eine extern verfasste Rust-Implementierung aus der Spezifikation (Quelle öffentlich) das festgepinnte 16-Suite/164-Vektor-Bündel und die festgepinnte 359-Fälle-Hostilitätskampagne unter einem evaluator-kontrollierten Neuaufbau aus einem unveränderlichen Quellbaum. Ihr eingechecktes Konstruktionsnachweismaterial bleibt implementierer-signiert, nicht dritter-bestätigt (signierte Erklärung); die strenge Clean-Room-Abnahme wartet auf das korrigierte dritter-bestätigte Manifest und den unabhängig festgepinnten Bestätigerschlüssel.
Formales Modell-Nachweismaterial	26 begrenzte TLA+-Sicherheitseigenschaften, gehalten in ihren konfigurierten Zustandsräumen; dies ist keine Implementierungsverfeinerung oder ein unbeschränkter Beweis · 35 Alloy-Fakten, 32 Behauptungen über vier Modelle · zwei zusammengesetzte symbolische Dolev-Yao-Modelle, die Challenge, CAID, zwei Genehmigungen, Aussteller- und Autoritäts-Pins, Registeransicht, Widerruf, Verbrauch, Ausführung und sechs dedizierte Anspruchsgrenzen abdecken. Zwanzig Tamarin-Lemmata verifizieren — 17 All-Traces-Verpflichtungen und 3 Exists-Trace-Zeugen; acht bewusst abgeschwächte Varianten erzeugen konkrete Angriffsspuren, wenn tragende Prüfungen entfernt werden (formal/tamarin/).
MCP-Registries	Offizielle MCP-Registry · Glama (Grade A, Official-Badge) · Smithery
Lizenz	Apache-2.0

Drei Referenz-Portierungen desselben Teams (JS / Python / Go) stimmen über alle 21 Suiten und 331 Vektoren überein. Zusätzlich besteht eine extern verfasste Rust-Implementierung, neu aufgebaut aus einem festgepinnten öffentlichen Quellbaum, das festgepinnte 16-Suite/164-Vektor-Clean-Room-Bündel und eine 359-Fälle-Hostilitätskampagne, die bei jeder Änderung in ihrer eigenen CI-Spur erneut ausgeführt wird. Die neueren AEC-Abnahme- und Vier-Ergebnis-Auflösungssuiten werden Rust nicht zugeschrieben. Das ist externes Interoperabilitäts-Nachweismaterial, keine strenge Clean-Room-Konstruktionsabnahme; der aggregierte CI-Fall führt die strenge Abnahmezahl als null, bis eine unabhängige Bestätigung vorliegt. Siehe CONFORMANCE.md, oder verifizieren Sie selbst eine Quittung unter emiliaprotocol.ai/verify.

---

Der Autoritätsstapel

Ebene	Was sie tut
Mandat	Definiert Auftrag, Grenzen, Nachweise, Ablauf, Delegation und Ausnahmeregeln.
CAID / exakte Aktion	Friert das materielle ausführbare Objekt ein, sodass Nachweise nicht auf andere Arbeit übertragen werden können.
AEC	Bewertet, ob unabhängig verifizierte und abgeglichene Nachweise die Anforderung der vertrauenden Partei erfüllen; es autorisiert nicht.
AEB / Gate	Trifft die lokale Autorisierungsentscheidung, reserviert die abgedeckte Autorität und kontrolliert den Provider-Zugang.
Ergebnis-Nachweise	Hält Aufruf, Provider-Antwort, beobachtete Wirkung und Unsicherheit getrennt.

---

Belegpunkte

Metrik	Wert
Automatisierte Testfälle	8.865 über 533 Dateien; alle plattformrelevanten Fälle müssen bestehen
TLA+-Sicherheitseigenschaften	26 begrenzte Invarianten, gehalten im konfigurierten Zustandsraum; kein Implementierungs-Verfeinerungs- oder unbeschränkter Beweis — siehe PROOF_STATUS.md
Alloy-relationale Behauptungen	35 Fakten + 32 Behauptungen über vier Modelle — in CI verifiziert
Katalogisierte Red-Team-Fälle	85 — RED_TEAM_CASES.md
Sicherheitsstatus der Version	Repository-Sicherheitsprüfungen bestehen; jeder Strix-Befund zu den geprüften Änderungen ist mit Regressionsabdeckung behoben und sein Review-Thread abgeschlossen
Konformität (7/7)	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
Sprachübergreifende Konformität	331 Vektoren · 21 Suiten: Quittungen · Geräte-Freigaben · Vier-Ergebnis-Auflösung · Mehrparteien-Quorum · Widerruf · Outcome Binding (semantisch + echte Krypto) · Authority Document/Proof-Ausstellerverbund · Zeitbescheinigung · Trust-Receipt (x2-Profile) · Herkunft · Nachweisdatensatz · Kanonisierung · Grenze · AEC-Abnahme · Währung · Initiator-Bescheinigung · Verbrauchsnachweis · Zeuge · Zeitstempelnachweis (RFC 3161). JS / Python / Go-Verifizierer stimmen überein (node conformance/run.mjs). Die externe Rust-Baseline bleibt bei 164 Vektoren / 16 Suiten. Siehe CONFORMANCE.md.
Handshake-Erstellen p95	575 ms bei 50 VUs — PERFORMANCE_PROOF.md

---

Kernprotokollobjekte

Objekt	Was es ist
Autoritätsprogramm / begrenzte Fähigkeit	Ein endliches Mandat mit explizitem Umfang, Budget oder Einheiten, Ablauf, Delegation und Verbrauchsregeln.
CAID	Ein kanonischer Bezeichner für eine materielle Aktion unter einem benannten Zuordnungsprofil; Abgleichen ist keine Autorisierung.
Nachweisanforderung und AEC-Ergebnis	Die festgepinnte Regel der vertrauenden Partei und ihre SATISFIED-, UNSATISFIED- oder INDETERMINATE-Bewertung.
AEB-Zulassungs- und Verwahrungsdatensatz	Der ausführungsseitige Datensatz von Autorisierung, Reservierung, Provider-Zugang und Abgleichzustand.
Autorisierungs- und Ergebnis-Nachweise	Portable native oder EP-Artefakte, die ihren exakten Aussteller, Umfang und Anspruchsgrenze behalten.

---

Schnellstart

1. Führen Sie npx @emilia-protocol/scan protect ./tools.json aus, um unterstützte deklarierte Oberflächen zu kartieren.
2. Prüfen Sie das generierte Aktionsmanifest, materielle Felder, Anmeldedaten und benannte blinde Flecken.
3. Installieren Sie Gate auf dem Pfad, der die Provider-Anmeldedaten und den dauerhaften Verbrauchszustand besitzt.
4. Definieren Sie das Betriebsmandat und etwaige Frisch-Mensch- oder Quorum-Ausnahmeregeln.
5. Führen Sie die Fälle für Verweigerung, exakte Aktion, Wiedergabe, Zeitüberschreitung und Abgleich aus, bevor Sie die Durchsetzung aktivieren.

90-Sekunden-Demo · Schnellstart · Agenten-Durchlauf · IETF-Entwurf · Discord

---

Was EP ist — und was nicht

EMILIA ist Autoritätsinfrastruktur für autonome Arbeit, kein Identitätssystem, keine Wallet, kein Reputationswert, keine Abwicklungsschiene und keine universelle Richtlinien-Engine.

• Ist: eine Kontrollebene für endliche Betriebsmandate, Exakt-Aktions-Verifikation, dauerhaften Zulassungszustand, wahrheitsgetreue Unsicherheit und portable Nachweise auf abgedeckten Ausführungspfaden.
• Ist nicht: ein Ersatz für OAuth/OIDC, Workload-Identität oder Richtlinien-Engines. Diese bleiben native Eingaben unter den Pins der vertrauenden Partei.
• Ist nicht: eine Anforderung, dass ein Mensch jede Aktion genehmigt. Ein Mandat kann automatische Arbeit innerhalb endlicher Grenzen erlauben und erst an der Grenze frische Autorität verlangen.
• Ist nicht: ein Beweis, dass eine zugelassene Aktion erfolgreich ausgeführt wurde oder die beabsichtigte Wirkung erzielt hat.
• Ist nicht: proprietäre Protokollkontrolle. Der Kern ist Apache-2.0 und die Internet-Drafts sind Einzeleinreichungen, keine RFCs oder IETF-Befürwortungen.

Siehe CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · Neutralitäts-Pakt