Skip to content
Brutor AI Docs

Contracts

A contract is a hash-pinned, versioned snapshot of every control that applies to an AI System — generated from the resolved live configuration, never hand-authored. A policy document that can disagree with reality is worse than none.

Because an AI System is a resource group, the contract is the resolved closure of that group: resources compose additively up the parent chain gated by inherit_from_parent; limits and policies compose restrictively, min-wins. Both are rules the platform already implements, so a contract is a rendering of an existing computation rather than a second opinion about it.

contract_hash = SHA256(canonical_json(resolved_closure))

It covers composition (models, MCP servers, skills, agent identities), resolved limits and governance, guardrail and argument-policy bindings, autonomy level, risk tier and intended use. Secrets are never included — a contract names which key binding applies, never the key.

Every finished run is stamped with the contract it ran under, so “what governed this run?” has a provable answer. If you have run change management, this is your change-approval process — made executable.

Versions are append-only

Section titled “Versions are append-only”

Minting is idempotent: if live configuration still hashes to the latest contract, nothing new is created. A superseded contract is kept, because it is the only record of what the rules were while historical runs executed.

Exactly one contract per system is active, enforced by a database constraint rather than by application logic.

The diff answers one question

Section titled “The diff answers one question”

Not “what changed” — a change list is easy and nearly useless. The diff separates widened from narrowed:

Direction Examples
Widened A new MCP server or skill; a raised cap; a removed cap; autonomy relaxed
Narrowed A removed resource; a lowered or newly added cap; autonomy tightened
Changed Owner, intended use, risk tier — documentation, not permission

A version that adds three MCP servers and tightens a token cap is not “four changes”; it is one thing that needs scrutiny and one that does not.

The diff shown to an approver is stored on the contract, not recomputed later. Recomputing it against today’s configuration would show a reviewer something they never approved.

The operating envelope

Section titled “The operating envelope”

The closure pins what a system may do. The envelope adds what it should achieve — declared bounds, signed off with the rest of the contract and evaluated continuously against the run ledger:

Term Bound
max_cost_per_run_usd Cost per completed task
max_monthly_cost_usd Spend over the trailing 30 days
min_completion_rate Share of finished tasks that completed
max_error_rate / max_abandoned_rate Shares that errored / went quiet unfinished
max_approval_escalation_rate Share escalated for human approval

Baselines learn what normal is; the envelope declares what acceptable was agreed to be. A system can drift without breaching its envelope, and breach it without drifting — the two questions are scored separately, and only the envelope produces contract violations: findings that response policies can act on, and that force the report’s verdict to violations.

Three honesty rules carry over from everywhere else:

  • There is deliberately no correctness term. “≥95% correct decisions” is not something a proxy can verify — no ground truth — and an envelope that mixes verifiable terms with unverifiable ones poisons trust in the verifiable ones.
  • Rates need evidence. Below 20 finished runs in the window a rate term reads insufficient_evidence — a different verdict from met, and never rolled up as assured. Spend caps are the exception: spend is a sum, not an estimate.
  • The envelope counts once signed. Declaring or editing terms drifts live config from the active contract; the terms are evaluated from the version an approver actually signed. In the diff, loosening a bound (or removing a term) is a widening the approver must read; tightening is not.

Conformance

Section titled “Conformance”

Because contracts are generated, “is this system running configuration nobody approved?” is computable. The Contracts panel states it plainly when live config no longer matches the active contract.

A document standard, not an API response

Section titled “A document standard, not an API response”

An exported contract is a specified, portable document — spec: ai.brutor/ai-system-contract, semantic spec_version, validated by a published JSON Schema (GET /v1/admin/standards/ai-system-contract/schema). It is self-contained: closure, hash, approval trail — so a third party can check that the closure hashes to what the approval names without an API call back to the platform. Download it per version from the Contract panel, or GET /v1/admin/ai-systems/{id}/contracts/{version}/export. Within 1.x the format only gains optional fields; anything breaking moves the major version.

Section titled “Related”