Core concepts

Ordered by dependency rather than alphabetically, because the terms build on each other: an action is the unit a bound judges, a bound produces a decision, and a decision is what a trace records. Read straight through the first time.

AI system

Anything that can propose an action and was not deterministically programmed to propose exactly that action. That definition is deliberately broader than “agent”, because the things an organization actually needs to govern are broader: a framework-built agent, a copilot embedded in a vendor SaaS product, a scheduled job that gained a model call, an application with a model behind it.

The test is not how it was built. It is whether it can change something and whether its next output is fully predictable from its inputs. If the answer is “can” and “no”, it is in scope, and the taxonomy covers the categories.

Action

A proposed change to a system of record, named as a dotted verb and carrying a subject. issue.refund on ORD-40122 is one. An action is the unit of governance here — not a request, not a prompt, not a session. Everything OpsAI decides, records and replays is scoped to a single action.

Reads are not actions. A retrieval agent that only reads has a different exposure profile and is governed at the data boundary rather than at the action boundary, which is why data access is its own mechanism.

Bound

The rule an action is judged against. A policy is what a team writes; a bound is what it compiles to. Four properties define one:

• Owned by the team that carries the risk, not by a platform team. The 8 bounds in the sample estate have 6 different owners.
• Versioned, so an action can be replayed against the version in force when it happened rather than the version in force now.
• Evaluated with no model call. A bound is not a prompt. This is the property that makes a decision reproducible.
• Expressed in business terms. refund.ceiling reads as a refund ceiling because that is what the team that owns it would say out loud, not as a resource ACL.

Decision

The outcome of evaluating an action against the bounds that apply to it. Three values, and the middle one is the one people get wrong.

• authorized — every check passed. A scoped grant is issued with the decision.
• held — a person has to decide. A hold expires; it does not queue. If nobody responds, the answer is no, which is the correct default for inattention.
• denied — a check failed, and the response names which one. A denial that does not say what failed is not actionable.

Risk and decision are separate axes and conflating them causes confusion later. The canonical refund is high risk — money leaves the business — and authorized, because it was within its ceiling. Risk describes the stakes; the decision describes the outcome.

Identity and grants

An AI system has a workload identity, attested rather than asserted. It never holds a system credential. When an action is authorized, OpsAI issues a grant derived from the centrally held credential, scoped to that action and expiring with it.

The distinction matters because it changes what a leak costs. A leaked API key is a standing capability; a leaked grant is a single action that has already happened and whose window has closed.

Autonomy and delegation

Autonomy is a rung on a ladder, not a switch. The 4 rungs run from proposing through to acting unsupervised inside bounds, and an AI system moves down a rung automatically when it breaks one — coming back up is a decision a person makes.

Delegation is one AI system granting authority to another. It is capped at 3 levels, and the cap exists because authority that can be passed on indefinitely cannot be reasoned about: at depth four, nobody can say which human’s authority is being exercised.

Trace and evidence

A trace is the six stages of one attempt: request, identity, authority, policy evaluation, decision, result. It exists for refusals as well as successes.

An evidence record is the sealed, chained entry a trace produces. Sealed means it cannot be edited afterwards, and chained means each record carries the digest of the one before, so a missing record is detectable rather than merely absent.

{
  "id": "EV-7512",
  "action": "ACT-7512",
  "decision": "authorized",
  "bound": "refund.ceiling",
  "bound_version": "v7",
  "sealed_at": "2026-09-15T09:41:02Z",
  "previous_digest": "…",
  "digest": "…"
}

Two vocabularies

The product surface and this documentation sometimes use different words for the same thing. That is deliberate rather than sloppy: the public term is the one a reader arrives knowing, and the console term is the one the mechanism is actually called. Both appear here so neither surprises you.

Policy→Bound

A policy is authored in the language of the business and compiles to a bound: owned by the team that carries the risk, versioned, replayable against past actions, and evaluated as code rather than asked of a model.

Audit→Evidence ledger

Audit is what you do; the evidence ledger is what you read. Each record is sealed before the response returns and chained to the one before it, and it names the bound version the decision was made against.

Approval→Held, then co-signed

An action that needs a person is held rather than queued. A named co-signer has thirty minutes; after that it expires rather than proceeding.

Execution control→The bound travels with the call

Authorization is not a gate the action passes through and leaves behind. The bound is attached to the outbound call, so the action cannot widen in flight.

Accountability · RACI→The person who answers for it

Every chain of authority starts at a named human and narrows at every hop — a child may only ever hold a subset of its parent. An agent can be responsible for a task without becoming accountable for the outcome.