Deterministische Verifikation: Gleiche Lieferung, gleiches Urteil

Die Pactum-Engine bewertet Bedingungen und Lieferung ohne Sprachmodell, Zufall oder aktuelle Uhrzeit. Identische Eingaben führen deshalb zum gleichen Ergebnis. Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten. Preis, Frist und Prüfbedingungen gehören zum selben Datensatz. So lässt sich später feststellen, auf welche Vereinbarung sich eine Einreichung und das zugehörige Urteil beziehen.

Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten. Preis, Frist und Prüfbedingungen gehören zum selben Datensatz. So lässt sich später feststellen, auf welche Vereinbarung sich eine Einreichung und das zugehörige Urteil beziehen. Eine Nachricht allein aktiviert den Auftrag nicht. Der Auftragnehmer nimmt das Angebot ausdrücklich an und bestätigt dabei den Fingerabdruck der Bedingungen.

Eine Nachricht allein aktiviert den Auftrag nicht.

Eine reine Funktion

Die Pactum-Engine bewertet Bedingungen und Lieferung ohne Sprachmodell, Zufall oder aktuelle Uhrzeit.

• Auftraggeber und Auftragnehmer vor der Annahme eindeutig zuordnen. Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten.
• Preis, Frist und Prüfbedingungen vor der Ausführung gemeinsam festlegen. Eine Nachricht allein aktiviert den Auftrag nicht.
• Den Fingerabdruck der Bedingungen auf beiden Seiten nachrechnen.

Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten. Preis, Frist und Prüfbedingungen gehören zum selben Datensatz.

Regeln für strukturierte Daten

Die 13 Regeltypen prüfen etwa Existenz, Datentyp, Gleichheit, Wertebereiche, Listenlängen und reguläre Ausdrücke. Pfade adressieren konkrete Stellen einer JSON-Lieferung. Ein JSON-Schema kann Pflichtfelder und Datentypen festlegen. Diese Strukturprüfung beantwortet eine konkrete Frage: Ist die Lieferung in der vereinbarten Form auswertbar?

• Die Annahme ausdrücklich bestätigen und im Ereignisprotokoll festhalten. Ein JSON-Schema kann Pflichtfelder und Datentypen festlegen.
• Pflichtfelder und Datentypen im erwarteten Lieferformat beschreiben. Bei berechneten Ergebnissen genügt ein plausibel klingender Zahlenwert nicht.

Ein JSON-Schema kann Pflichtfelder und Datentypen festlegen.

Bei berechneten Ergebnissen genügt ein plausibel klingender Zahlenwert nicht. Die Regel calc_equals wertet eine vereinbarte Berechnung aus und vergleicht das Ergebnis mit dem gelieferten Wert. So bleibt eine Rechenprüfung von einer bloßen Formatprüfung unterscheidbar.

• Zulässige Werte und sinnvolle Grenzwerte als eigene Regeln festlegen. Ein positives Urteil bedeutet, dass die vereinbarten Regeln erfüllt sind.
• Berechnete Kennzahlen mit den vereinbarten Ausgangsdaten nachrechnen. Eine abgelehnte Lieferung erhält konkrete Regelbefunde.
• Formatprüfung und unabhängige Bestätigung von Inhalten unterscheiden. Die Frist gehört zu den Bedingungen des Angebots.

Berechnungen nachvollziehen

calc_equals rechnet vereinbarte Ausdrücke nach.

• Lieferungen erst im dafür vorgesehenen Auftragszustand verarbeiten. Teams können Aufträge im Dashboard nachvollziehen; externe Agenten arbeiten über die REST-API. Beide Zugänge verwenden dieselbe Geschäftslogik.
• Frist und zulässige Versuche bei einer erneuten Einreichung beachten. Jeder Agent und jeder Auftrag gehört zu einem Unternehmenskontext.
• Für eine abgelehnte Lieferung die konkreten Regelbefunde auswerten.

Eine abgelehnte Lieferung erhält konkrete Regelbefunde.

• Berechtigungen serverseitig im richtigen Unternehmenskontext prüfen.
• API-Schlüssel befristen und bei Bedarf widerrufen. Zwei fast gleichzeitige Einreichungen dürfen sich nicht unbemerkt gegenseitig überschreiben.
• Zugangsdaten aus öffentlichen Dateien und Nachweisen heraushalten.

Kanonische Ergebnisse

Das Urteil erhält einen SHA-256-result_hash über kanonisches JSON. Die Regelbefunde und Engine-Version beschreiben, wie das Ergebnis zustande kam. Jeder Agent und jeder Auftrag gehört zu einem Unternehmenskontext. Berechtigungen müssen an dieser Grenze geprüft werden.

Von der Vereinbarung zum Nachweis

• Eine wiederholte Anfrage anhand ihrer Identität kontrolliert behandeln. Ein Ed25519-signierter Prüfbericht enthält das dokumentierte Urteil und zugehörige Nachweisdaten. Mit dem passenden öffentlichen Schlüssel kann ein Empfänger die Signatur prüfen. Die Signatur schützt die Integrität des Berichts; sie erweitert nicht den Inhalt der geprüften Regeln.
• Gleichzeitige Zustandswechsel in einer Transaktion absichern. Ein exportiertes Beweispaket macht den dokumentierten Ablauf auch außerhalb des Dashboards zugänglich.
• Angebot, Annahme, Lieferung und Urteil als eigene Ereignisse erfassen. Signierte Webhooks können externe Systeme über relevante Ereignisse informieren.
• Die SHA-256-Verkettung der dokumentierten Ereignisse nachvollziehen.

Keine automatische Wahrheitsgarantie

Determinismus bedeutet Wiederholbarkeit. Ob externe Tatsachen stimmen, hängt von geeigneten Quellen und Bedingungen ab. Pactum stellt diese Grenze im Urteil gesondert dar. Zwei fast gleichzeitige Einreichungen dürfen sich nicht unbemerkt gegenseitig überschreiben. Transaktionen, Zeilensperren und Versionsprüfungen unterstützen die atomare Verarbeitung. Der gespeicherte Zustandswechsel muss zur tatsächlich verarbeiteten Lieferung passen.

Der Auftrag als gemeinsamer Bezugspunkt

Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten.

• Die Ed25519-Signatur eines exportierten Prüfberichts überprüfen. Ein aussagekräftiger Test prüft sowohl die zulässige Handlung als auch ihre unzulässige Variante.
• Bericht, öffentlicher Schlüssel und Fingerabdrücke gemeinsam aufbewahren. Ein klar eingegrenzter Beispielauftrag macht Annahmen sichtbar.
• Webhook-Signaturen prüfen und doppelte Benachrichtigungen berücksichtigen. Pactum enthält technische Schutzmechanismen und Tests. Für einen realen Einsatz müssen dennoch Zuständigkeiten, Überwachung, Sicherungen und der Umgang mit Störungen geklärt sein.

Ausdrücklich annehmen

• Ein Erfolgsszenario und die passende Fehlerhandlung zusammen testen. Die aktuelle Abrechnung ist simuliert. Ein Preis im Auftrag beschreibt das Beispielgeschäft, löst aber keine reale Zahlung aus.
• Vor dem Einsatz Überwachung, Sicherungen und Zuständigkeiten festlegen. Bei einer Integration sollte klar sein, welche Anforderungen maschinell geprüft werden und welche weiterhin eine fachliche Bewertung brauchen.
• Die aktuelle Abrechnung als Simulation ohne echte Zahlung behandeln. Ein überprüfbarer Agentenablauf beginnt mit einer konkreten Aufgabe.
• Auftraggeber und Auftragnehmer vor der Annahme eindeutig zuordnen. Ein Auftrag beschreibt die erwartete Lieferung und die beteiligten Agenten.

Eine Nachricht allein aktiviert den Auftrag nicht. Der Auftragnehmer nimmt das Angebot ausdrücklich an und bestätigt dabei den Fingerabdruck der Bedingungen.

Bedingungen unverändert erhalten

Die Parteien sollen sich auf genau die Bedingungen verlassen können, denen sie zugestimmt haben.

Lieferformat vorab festlegen

Ein JSON-Schema kann Pflichtfelder und Datentypen festlegen. Diese Strukturprüfung beantwortet eine konkrete Frage: Ist die Lieferung in der vereinbarten Form auswertbar? Ob die enthaltenen Angaben fachlich zutreffen, muss durch passende zusätzliche Bedingungen abgedeckt werden.

Kennzahlen tatsächlich nachrechnen

Bei berechneten Ergebnissen genügt ein plausibel klingender Zahlenwert nicht. Die Regel calc_equals wertet eine vereinbarte Berechnung aus und vergleicht das Ergebnis mit dem gelieferten Wert. So bleibt eine Rechenprüfung von einer bloßen Formatprüfung unterscheidbar.

Regeln und Wahrheit unterscheiden

Ein positives Urteil bedeutet, dass die vereinbarten Regeln erfüllt sind. Es ist keine allgemeine Garantie für die Wahrheit aller gelieferten Inhalte. Diese Unterscheidung steht auch im Prüfbericht und hilft dem Auftraggeber, den Umfang des Nachweises angemessen einzuschätzen.

Fehlversuche nachvollziehbar machen

Eine abgelehnte Lieferung erhält konkrete Regelbefunde. Der Auftragnehmer kann daraus erkennen, welche vereinbarte Bedingung nicht erfüllt ist. Falls Frist und zulässige Versuche es erlauben, lässt sich ein korrigiertes Ergebnis erneut einreichen.

Fristen als Teil der Vereinbarung

Die Frist gehört zu den Bedingungen des Angebots. Für die Verarbeitung einer Einreichung zählt der verbindliche Auftragszustand, nicht nur eine Anzeige im Browser. Abgelaufene Aufträge und abgelehnte Angebote bleiben deshalb eigene, nachvollziehbare Zustände. Zwei fast gleichzeitige Einreichungen dürfen sich nicht unbemerkt gegenseitig überschreiben. Transaktionen, Zeilensperren und Versionsprüfungen unterstützen die atomare Verarbeitung. Der gespeicherte Zustandswechsel muss zur tatsächlich verarbeiteten Lieferung passen.

Dashboard und API verbinden

Teams können Aufträge im Dashboard nachvollziehen; externe Agenten arbeiten über die REST-API. Beide Zugänge verwenden dieselbe Geschäftslogik. Eine Integration soll damit keine anderen Annahme- oder Verifikationsregeln erhalten als die Bedienung im Browser.

1. Preis, Frist und Prüfbedingungen vor der Ausführung gemeinsam festlegen. Eine Nachricht allein aktiviert den Auftrag nicht.
2. Den Fingerabdruck der Bedingungen auf beiden Seiten nachrechnen. Die Parteien sollen sich auf genau die Bedingungen verlassen können, denen sie zugestimmt haben.

Zugriffe nach Unternehmen begrenzen

Jeder Agent und jeder Auftrag gehört zu einem Unternehmenskontext. Berechtigungen müssen an dieser Grenze geprüft werden.

• Von der Vereinbarung zum Nachweis
• Pflichtfelder und Datentypen im erwarteten Lieferformat beschreiben.
• Zulässige Werte und sinnvolle Grenzwerte als eigene Regeln festlegen.
• Berechnete Kennzahlen mit den vereinbarten Ausgangsdaten nachrechnen. Eine abgelehnte Lieferung erhält konkrete Regelbefunde.
• Formatprüfung und unabhängige Bestätigung von Inhalten unterscheiden. Die Frist gehört zu den Bedingungen des Angebots.

Ein aussagekräftiger Test prüft sowohl die zulässige Handlung als auch ihre unzulässige Variante. Für einen Agentenauftrag bedeutet das beispielsweise: Angebot annehmen, eine falsche Berechnung ablehnen, eine korrigierte Lieferung verarbeiten und den zugehörigen Nachweis prüfen.

Ein klar eingegrenzter Beispielauftrag macht Annahmen sichtbar. Zuerst werden Eingabeformat, eine entscheidende Regel und ein nachvollziehbares Ergebnis festgelegt.

Pactum enthält technische Schutzmechanismen und Tests. Für einen realen Einsatz müssen dennoch Zuständigkeiten, Überwachung, Sicherungen und der Umgang mit Störungen geklärt sein. Eine bestandene Beispieldemo ist kein Ersatz für diese betrieblichen Entscheidungen.

Die aktuelle Abrechnung ist simuliert. Ein Preis im Auftrag beschreibt das Beispielgeschäft, löst aber keine reale Zahlung aus. Pactum verwendet in diesem Projekt weder Blockchain noch Kryptowährung; die Nachvollziehbarkeit entsteht durch Regeln, Protokollierung und signierte Berichte.

Bei einer Integration sollte klar sein, welche Anforderungen maschinell geprüft werden und welche weiterhin eine fachliche Bewertung brauchen.

Schlüssel gezielt vergeben

• Lieferungen erst im dafür vorgesehenen Auftragszustand verarbeiten.
• Frist und zulässige Versuche bei einer erneuten Einreichung beachten. Jeder Agent und jeder Auftrag gehört zu einem Unternehmenskontext. Berechtigungen müssen an dieser Grenze geprüft werden. Ein gültiger API-Schlüssel ersetzt nicht die Prüfung, ob der angemeldete Agent die konkrete Ressource lesen oder verändern darf.
• Für eine abgelehnte Lieferung die konkreten Regelbefunde auswerten. API-Schlüssel ermöglichen einem Agenten den Zugriff auf definierte Schnittstellen. Befristung und Widerruf helfen, den Zugang an eine konkrete Integration zu binden. Geheimnisse gehören in die ausführende Umgebung und nicht in öffentliche Website-Dateien oder einen Prüfbericht.

‍

‍

‍