Decision Table

Decision Table ist ein deterministisches Entscheidungs- und Constraint-Primitiv für KI-Agenten. Es verlagert begrenzte Geschäftsentscheidungen aus der Modelllogik in eine strikte, versionierte, ausführbare IR.

Der Produktname und die stabilen Paket-, CLI-, Plugin-, Skill- und MCP-Identifikatoren sind in docs/PRODUCT_IDENTITY.md festgehalten.

Die erste Version bietet:

• decision.evaluate: Fakten mit first, unique, collect oder priority-Trefferrichtlinie auswerten;

• decision.validate: das Modell validieren und konservativ Duplikate, Überlappungen oder überlagerte Regeln nachweisen, wo unterstützt;

• constraint.check: einen vorgeschlagenen Kandidaten prüfen und Verstöße, fehlende Eingaben und konfigurierte Reparaturhinweise zurückgeben;

• constraint.check_approved: wenn vom Host konfiguriert, eine schreibgeschützte Prüfung gegen eine exakte genehmigte Regelsatz durchführen, den der Aufrufer nicht ersetzen oder zurückdatieren kann;

• einen gemeinsamen TypeScript-Kern, eine JSON-CLI und einen MCP-Server sowie ein Codex-Plugin.

Installation in Codex

codex plugin marketplace add tetracoralla/decision-table --ref main
codex plugin add decision-table@decision-table

Starten Sie nach der Installation eine neue Codex-Aufgabe, damit die Skill- und MCP-Tools aus dem installierten Plugin geladen werden. Es ist kein npm-Konto, npm-Paket oder Quellcode-Build erforderlich; das Plugin enthält einen vorgebauten MCP-Server und benötigt nur Node.js 20.19 oder höher auf PATH.

Das Repository-Root ist der Marktplatz und plugins/decision-table ist das installierbare Plugin. Siehe docs/INSTALLATION.md für Updates, Entfernung und Verifizierung.

Verwenden Sie gewöhnliche Anfragen wie:

• „Validieren Sie diesen Entscheidungsregelsatz, bevor ich ihn verwende.“

• „Bewerten Sie diesen Regelsatz mit diesen Fakten.“

• „Prüfen Sie, ob diese vorgeschlagene Aktion diese Einschränkungen erfüllt.“

Decision Table wird von GitHub als Codex-Plugin verteilt. Das Node-Paket in diesem Repository ist privat und dient nur zum Erstellen, Testen und zur lokalen Bibliotheksentwicklung; es wird nicht auf npm veröffentlicht.

Aus dem Quellcode entwickeln

npm install
npm run check

Für die lokale Plugin-Entwicklung fügen Sie dieses Repository-Verzeichnis selbst als Marktplatz hinzu und validieren Sie das Quell-Plugin mit npm run check:plugin.

CLI

npm run cli -- validate examples/payment-approval.decision.json
npm run cli -- evaluate examples/payment-approval.decision.json \
  --facts examples/payment-approval.facts.json \
  --expected-version 1.0.0
npm run cli -- check examples/email-marketing.constraint.json \
  --candidate examples/email-marketing.candidate.json \
  --facts examples/email-marketing.facts.json

Die gesamte Ausgabe ist JSON. Verwenden Sie - anstelle eines Eingabepfads, um dieses eine Dokument von stdin zu lesen. Optionen, die für den ausgewählten Befehl nicht definiert sind, werden abgelehnt. Der Regelsatz, die Fakten und die Kandidatendokumente teilen sich ein kumulatives Limit von 256 KiB.

Für exaktes Content-Pinning übergeben Sie sowohl --expected-version als auch --expected-fingerprint <sha256>.

Genehmigte Prüfungen und Host-Durchsetzung

Inline-constraint.check ist beratend, da der Aufrufer den Regelsatz liefert. Für eine schreibgeschützte Analyse mit einer vom Host genehmigten Richtlinie binden Sie den Regelsatz, bevor Sie den MCP-Server starten:

import {
  createApprovedConstraintChecker,
  createConstraintExecutionGuard,
  fingerprintRuleset,
} from "@openadam/decision-table";

const expected = {
  id: approvedRuleset.id,
  version: approvedRuleset.version,
  fingerprint: fingerprintRuleset(approvedRuleset),
};
const checker = createApprovedConstraintChecker({ ruleset: approvedRuleset, expected });

Der gebündelte stdio-Server stellt constraint.check_approved bereit, wenn sein Host DECISION_TABLE_APPROVED_CONSTRAINT_JSON auf dasselbe strikte Bindungsobjekt setzt. Der Agent kann die Richtlinie nicht ersetzen oder die Prüfung zurückdatieren, aber er liefert weiterhin Kandidat und Fakten, daher ist dieses schreibgeschützte MCP-Tool keine Ausführungsgrenze.

Für einen kontrollierten Nebeneffekt halten Sie die Kandidatenkonstruktion, das Laden vertrauenswürdiger Fakten, die Prüfung und die Ausführung in einem vom Host verwalteten Kontext:

const guard = createConstraintExecutionGuard(checker, async (action, run) =>
  database.transaction(async (transaction) =>
    run({
      candidate: candidateFromActualAction(action),
      facts: await loadTrustedFacts(transaction, action),
      execute: (sameActionSnapshot) =>
        executeActualAction(transaction, sameActionSnapshot),
    }),
  ),
);

const outcome = await guard.execute(actualToolArguments);

Der Guard erstellt einen Snapshot der tatsächlichen Aktion, blockiert den Executor, sofern die Einschränkungen nicht gültig zurückgeben, und übergibt denselben eingefrorenen Snapshot an die Ausführung. Der vom Host verwaltete Kontext ist der Ort, an dem eine Transaktion oder Sperre flüchtige Fakten während des Nebeneffekts gültig halten muss. Der Guard ist eine Bibliotheksgrenze und ist absichtlich kein von Agenten aufrufbares MCP-Tool.

Regelsatzform

Bedingungen sind getaggte Daten, niemals ausführbare Zeichenfolgen:

{
  "op": "compare",
  "left": { "kind": "fact", "path": "amount" },
  "comparator": "gte",
  "right": { "kind": "literal", "value": "10000" }
}

Dezimalwerte sind Zeichenfolgen. Fehlende Pfade erzeugen UNKNOWN; sie werden nicht zu false gezwungen. Datumszeiten erfordern einen echten ISO-Kalenderwert, expliziten Offset, Sekunden und höchstens Millisekundengenauigkeit. Siehe examples/ und docs/PRODUCT_MODEL.md für die vollständige Produktgrenze.