Why contracts exist
A coordination contract defines the declared meaning, allowed structure, and governing artefacts for the bounded signal before any reasoning occurs. The vault enforces the agreed structure and referenced governance mechanically. Models cannot expand the channel beyond those constraints. This is the distinction between a schema (which constrains structure) and a contract (which binds governance).
An API schema tells you what shape the data has. A coordination contract tells you what both participants agreed to, what enforcement policy governs the session, what prompt template will be used, and what declared information budget and schema constraints govern the output channel. The contract is a bilateral agreement — not a unilateral definition imposed by one party. Both participants must agree to the contract before any private context is exchanged.
Three-part structure
Every coordination contract is composed of three distinct elements, each serving a different function in the bounded-disclosure guarantee.
Consent boundary. The contract defines who participates (participants), what the session is for (purpose_code), and what execution constraints apply (enforcement_policy_hash, model_profile_id, and related execution parameters). This establishes the consent boundary — what both parties have agreed to before any context is exchanged. The consent boundary is locked at session creation and cannot be modified mid-session.
Information compression. The output_schema field is a JSON Schema that defines exactly which fields exist, what values are permitted, and what structure is required. This is the mechanism that narrows the communication channel. An all-enum schema with four fields carrying 2 bits each has a channel capacity of 8 bits — structurally, regardless of what the model attempts to produce. The schema is not advisory. It is the structural constraint that bounds what can be disclosed.
Mechanical constraint. The enforcement_policy_hash references a content-addressed guardian policy that applies additional enforcement rules on top of schema validation. The guardian enforces constraints — it rejects invalid outputs. It never evaluates whether a signal is correct. It only verifies that the signal is allowed. Policy is referenced by hash, not embedded in the contract, so the same policy can govern multiple contracts.
Contract fields
The following fields comprise a coordination contract. All fields must be present in the serialised JSON (including null-valued optional fields) when computing the contract hash. This ensures cross-party hash parity.
{
"purpose_code": "COMPATIBILITY",
"output_schema_id": "agentvault_compatibility_signal_v2",
"output_schema": {
"type": "object",
"properties": {
"compatibility_signal": {
"type": "string",
"enum": ["STRONG_MATCH", "PARTIAL_MATCH", "WEAK_MATCH", "NO_MATCH"]
},
"confidence": {
"type": "string",
"enum": ["HIGH", "MEDIUM", "LOW"]
}
},
"required": ["compatibility_signal", "confidence"],
"additionalProperties": false
},
"participants": ["agent-alice", "agent-bob"],
"prompt_template_hash": "18b1b459...64hex",
"entropy_budget_bits": 32,
"enforcement_policy_hash": "b977379e...64hex",
"output_schema_hash": "0d25ea01...64hex",
"relay_verifying_key_hex": "a1b2c3d4...64hex",
"model_profile_id": "api-claude-sonnet-v1",
"timing_class": null,
"metadata": { "scenario": "scheduling-compatibility", "version": "2" }
} How contract_hash binds governance into receipts
When a session is created, the relay computes the contract hash: SHA-256(JCS(contract)) where JCS is RFC 8785 JSON Canonicalization Scheme. This hash is bound into the signed receipt as commitments.contract_hash. A verifier who holds the original contract can independently recompute the hash and confirm it matches the receipt.
The contract hash is the root of the verification chain. From the contract, a verifier can derive the expected hashes of the schema, enforcement policy, prompt template, and model profile reference. If any of these artefacts were substituted after the contract was agreed, the hash chain breaks and verification fails.
This is why null fields must be present: JCS canonical form of {"timing_class":null} differs from {}. An implementation that omits null fields will compute a different hash, and cross-party verification will fail.
Contracts vs API schemas
An API schema is a unilateral definition: the server declares the response shape, and clients consume it. The server can change the schema at any time. There is no bilateral agreement, no enforcement policy, and no cryptographic proof of what governed the interaction.
A coordination contract is a bilateral agreement. Both participants agree to the same contract before submitting private context. The contract is content-addressed and immutable for the session duration. Neither party can change the terms mid-session. The contract binds not just the output structure but the referenced governance artefacts and execution parameters that were agreed for the session. The receipt proves — after the fact — that this specific contract governed the session.
The distinction matters because bounded disclosure requires bilateral consent. A unilateral schema constrains structure but not governance. A contract constrains both: the output is bounded by the schema, and the session is governed by the full set of content-addressed artefacts referenced from the contract.
Contract-level fields that matter for security
enforcement_policy_hash binds the guardian policy into the contract. If the contract specifies this field, the receipt's guardian_policy_hash must match. A relay that loaded a different policy would produce a receipt with a mismatched hash — detectable by any verifier.
entropy_budget_bits declares the advisory upper bound on output information content. Where supported by the active receipt version and runtime, the relay computes the actual channel capacity from the schema structure and records it in the receipt. A verifier can compare the declared budget against the computed capacity to check whether the schema is consistent with the claimed bound.
output_schema_hash allows the schema to be referenced by hash rather than embedded inline. The relay performs a registry lookup by hash if the inline output_schema is a stub. This enables schema reuse across contracts without duplicating the full schema in every contract.
The contract can constrain the permitted model class or profile for the session via model_profile_id. The relay selects a model satisfying the profile requirements. The receipt records which model was actually used (as a claim at SELF_ASSERTED level, as an attestation at PROVIDER_ATTESTED level).
relay_verifying_key_hex pins the relay's Ed25519 public key into the contract. If present, the verifier checks that the receipt was signed by the pinned key — not just any valid key. This prevents relay substitution: a participant who agreed to coordinate through a specific relay operator can detect if a different relay signed the receipt.
Key takeaway
A coordination contract is the root governance object for an AgentVault session. Everything that governs the session is either in the contract or referenced by content hash from the contract. The receipt proves, cryptographically, that this specific contract governed this specific session. Schema design is a security decision. Contract design is a governance decision. They are distinct concerns, bound together by content addressing.