The Decision Contract: Intent to Proof Record

Canonical vocabulary

1. The lifecycle: Execution Intent to Proof Record

An agent or orchestrator proposes a consequential action by submitting an Execution Intent (dh.execution-intent.v1). The kernel normalizes it, evaluates it deterministically against the active policy version, and projects a Decision Object (dh.decision.v1) carrying one of six Resolutions: AUTHORIZED, MODIFIED, ESCROWED, REVIEW_REQUIRED, ROUTED, or DENIED. Only an AUTHORIZED resolution issues an Execution Grant. Every step — normalization, evaluation, grant issuance, review, revocation, outcome verification — is appended to the decision's hash-chained trace. The Decision Object, the grant when one exists, and the trace together form the Proof Record (dh.proof-record.v1).

The six-value Resolution set is closed: it is never reduced or renamed, so integrators can write exhaustive handlers.

2. What is signed

The Execution Grant is the only signed object. It is an Ed25519-signed JWT claims set (JWS compact serialization; header typ dh-grant+jwt, alg EdDSA) binding the action hash, target hash, tenant, environment, principal, requestor, policy and context hashes, a nonce, a validity window (nbf/exp), and max_uses — single-use by default. Target-side connectors verify the signature offline against the verification key identified by kid; no call home is required.

The Grant Token is the serialized JWS compact form of the Execution Grant — the same object in its wire encoding. Only the serialized Grant Token crosses the trust boundary to the target; the terms are not interchangeable.

Verification is refused with a typed error on malformed input, an unsupported algorithm, a bad signature, expiry, not-yet-valid, or any audience, action, target, tenant, or environment mismatch.

3. What is hash-linked

Every trace event carries an event_hash computed over its own content and the previous_hash of its predecessor; the first event's previous_hash is null, and the trace head_hash equals the final event_hash. Editing any recorded event breaks the chain from that point forward, which is detectable by re-computing it.

The Decision Object additionally carries integrity digests: canonical_digest (SHA-256 of the canonical JSON decision record) and schema_digest (SHA-256 of the schema the record was normalized against). Grant claims bind action, target, policy, and context hashes, so changing any facet of the authorized action invalidates verification.

Tamper evidence means modification is detectable on re-verification. It does not prevent modification of the underlying store — compare the chain head against a trusted copy.

4. What must be pinned for deterministic replay

Replay reproduces an evaluation from pinned inputs and versions. To replay a decision you must pin four things, all of which are carried on the Proof Record:

5. The enforcement boundary

The enforcement boundary is the interception point between an agent's proposed action and the target system that would execute it. Inside the boundary: intent normalization, deterministic evaluation, grant issuance, and trace recording. Outside the boundary: the agent, and the target-side connector that must present a valid Grant Token before executing.

The boundary holds end to end only when connectors actually gate execution on grant verification. DecisionHypervisor cannot stop a target system that ignores the gate — deployment reviews verify connector behavior for exactly this reason.

6. Fail-open and fail-closed assumptions

Within the enforcement boundary the system fails closed: when authority cannot be established — no matching allow, an expired grant, an unverifiable signature, a malformed intent — the proposed action does not proceed. Deny takes precedence: when a matching rule evaluates to DENY, the decision resolves DENIED regardless of any ALLOW rules that also match.

These properties are exercised by the kernel conformance suite across the six resolution states. They are statements about the kernel and the grant verifier, not about incorrectly authored policies or connectors that bypass the gate.

7. What the schemas do not guarantee

The published JSON Schemas validate the shape of the contract — required fields, types, formats, the closed Resolution set, and boundary rejection of unknown fields. They do not, and cannot, guarantee:

8. Current product and SDK status

DecisionHypervisor is in private preview. The SDK (Node.js first; Python and Go planned), preview endpoints, and API keys are issued to approved design partners — they are not publicly downloadable. The public schemas and synthetic fixtures referenced here are Available: downloadable and checkable without an account. Air-gapped deployment is Design-partner only; the managed SaaS control plane is Targeted and not currently offered. The full, machine-readable status matrix is published with the evidence index.

9. Versioning and deprecation policy

Schemas under /schemas/v1/ are immutable once published. schema-index.json records the SHA-256 of every file so consumers can pin a version URL and detect any silent change; our conformance suite fails if a published file's hash drifts from the manifest. Corrections and new fields ship only under a new version directory (/schemas/v2/) with a new schema_version marker — never by editing v1 in place.

When a v2 line ships, v1 remains available and supported for a published deprecation window before it is retired. The same rule applies inside payloads: schema_version constants (dh.execution-intent.v1, dh.decision.v1, dh.proof-record.v1) change only with a new contract version.

Public artifacts