Platform documentation

How the pieces behave in operation. This assumes the quickstart and the vocabulary from core concepts.

Connections

A connection is the credential-holding relationship between OpsAI and one system of record. The sample estate has 11 of them. Three things are true of every connection and worth being precise about:

• The credential never leaves. Not to an AI system, and not to an enforcement point. Both receive derived grants instead.
• The connection declares what it permits at all. An action not in that list cannot be authorized by any policy, which makes the connection a ceiling rather than a channel.
• A connection is not an integration. It does not add capabilities to your AI system. It gives OpsAI the ability to carry out an action that has already been authorized.

const connection = await opsai.connections.get('conn_razorpay_live');

connection.allows;        // ['issue.refund', 'payment.read']
connection.credential;    // { kind: 'api_key', held: true, value: undefined }
connection.rotation;      // { policy_days: 90, age_days: 12, due: false }

What the inventory records

The inventory is the register of AI systems under governance. Per system it holds the accountable human, the autonomy rung, the actions it may attempt, the model it calls, the framework it was built in, and the date it came under governance.

Two of those are more load-bearing than they look. The accountable human is required, because every question asked after an incident is a question about a person. The framework is descriptive and nothing branches on it — it is recorded so that the spread is visible, not so behaviour can vary by it.

The action lifecycle

An action moves through a fixed sequence, and the ordering is the design. Identity is established before authority is resolved, authority before the policy is evaluated, and the policy before anything reaches a system of record.

The consequence: an AI system cannot widen its own authority mid-flight. The grant it receives is derived after the decision, scoped to the action that was authorized, and expires with it. Nothing is re-negotiated at the boundary.

The six trace stages

Every attempt produces all six, whether it was authorized, held or denied. A denied action does not stop producing a trace at the point of refusal; it records where it stopped, which is the information a review needs.

1. The agent asked 0 ms — refund-resolver asked to run issue.refund against Razorpay for ₹18,400 on ORD-40122. Nothing has run yet.
2. Authority traced to a person 1 ms — Every hop holds a subset of the hop before it. A sub-agent cannot be talked into authority it was never issued.
3. Bounds matched 2 ms — Two bounds apply. Both were written by the team that owns the risk — not by the agent, and not by a prompt.
4. Bounds evaluated 6 ms — Every bound held. The action is cleared to run exactly as asked — no wider.
5. Decision 11 ms — Authorized. The call went out with the bound attached, so it cannot widen in flight.
6. Record sealed 13 ms — The decision, its inputs and the bound version were written to the ledger before the response returned. Nothing here can be edited afterwards.

The elapsed times are from the canonical refund in the sample estate, which resolved in 11ms. That figure is worth internalising: a control in the path of an action has to be fast enough that nobody is tempted to route around it.

The evidence ledger

Each decision produces one ledger record, sealed before the response returns. Sealed means no endpoint can edit it. Chained means each record carries the digest of its predecessor, so a removed record is detectable rather than merely absent — the chain fails to verify.

{
  "id": "EV-7512",
  "action": "ACT-7512",
  "bound_version": "v7",
  "bound_since": "30 Jun 2026",
  "previous_digest": "d5bdfde76116b2a5cf853ad280bb989659848df5e0ab78af500ef78f968fb61d",
  "digest": "d7ffd0b3bab589c9f5e902bddacf4f875e6f108129d6fb13e0e5eea8b1f6b278"
}

Verification is available to you rather than being something OpsAI asserts. Walk the chain, recompute each digest, and the ledger either verifies or names the record where it stops. How an auditor reads this.

Credential rotation

Rotation is 4 stages rather than one, and the second stage is why it is boring rather than an outage.

1. Issue — A second credential is created alongside the first.
2. Dual accept — Both are valid. Every enforcement point takes either one.
3. Cut over — New grants derive from the new credential only.
4. Revoke — The old credential is destroyed at the source.

Dual accept is the stage most rotation procedures omit. Revoking before every enforcement point has accepted the replacement is what turns a routine rotation into an incident, and no code change is required at any stage because the AI systems never held the credential in the first place.