10.3 The approval context

Included from Basic tier

After this you can: read, as an approver, why a change was raised — its provenance, its rationale and the one chain per unit of agent work — before you decide.

Before you start — tick each one:

• Lesson 10.1 — Approval policies and the change funnel (opschain learn 10.1)

In the GUI: Governance → Reviews & approvals — each inbox row opens its checklist with the approval context (requester, rationale, recommendation, chain) above the approve and reject controls; the Decided tab is the history.

An approver who cannot see why a change was raised is being asked to rubber-stamp it. Lesson 10.1 held a change and decided it; this lesson is about the minute before the decision. Every held change or workflow run carries an approval context — the platform explaining itself — and the inbox, opschain approvals show and the GUI all read the same block. The resource reference is opschain docs resources/approval (ApprovalContext); the model reference is opschain docs change-governance.

Who sees it. The context is served to the checklist's approvers (any line, group membership resolved), to its requester, and to holders of the agent-governance reviewer determination. Every other reader sees the checklist alone. You need no extra role to read the context of what you are asked to decide.

1. What the context carries

The create lane stamps the provenance under the run's server-owned opschain metadata namespace — never client-settable — and the inbox reads it back set-based, one read per page:

• The requester's kind. A person, or an agent with its trust tier at creation and its owner.
• The rationale. The requester's stated reason, verbatim: the create request's rationale attribute (opschain runs create change … --rationale "…", lesson 3.1). Optional for a person; mandatory for an agent — the server refuses an agent-originated create without one, by name.
• The recommendation the subject implements, when it does.
• The correlation chain the subject belongs to — the incident or operator request that invoked the agent, each governed read, the recommendation, the sealed adapter transcript, this subject.

The inbox's WHY column carries the rationale's first line; approvals show prints the whole block.

2. Read a person's change

As sarah, open the change jessica raised in lesson 10.1:

opschain approvals show <run-id>

workflow 01a2f4c1-1e9b-7f10-8a6d-0b1c2d3e4f50 — quarterly-security-patch on /projects/limebank
status: pending · requested by jessica at 2026-10-27T09:04:11Z
quorum deadline: 2026-11-03T09:04:11Z

lines:
  Production change control — 0/1 · waiting on you
    waiting on sarah, priya

requested by: jessica (user)
rationale:
  Quarterly patch cycle, CHG-1042: 3 CVEs open on core_banking
chain: 01a2f4c1-1e9b-7f10-8a6d-0b1c2d3e4f50 (opschain chains show 01a2f4c1-1e9b-7f10-8a6d-0b1c2d3e4f50)
  2026-10-27T09:04:11Z  workflow quarterly-security-patch

A person who stated no rationale shows (none stated) — the context is still there, it is just thin. The chain of a change a person raised directly is one hop: the subject itself.

3. Read an agent's change

The context earns its keep when the requester is an agent. In the demo, Felix (lesson 12.0) raises patch_preflight under a SUPERVISED grant; sarah is an approver on the line:

opschain approvals show <run-id>

change 01a2f6b0-4e2a-7c13-9d5e-2a3b4c5d6e7f — patch_preflight on /projects/limebank/environments/prod/assets/core_banking
status: pending · requested by svc-agent-limebank-felix at 2026-11-06T01:00:05Z
quorum deadline: 2026-11-13T01:00:05Z

lines:
  Production change control — 0/2 · waiting on you
    waiting on sarah, priya

requested by: felix (agent, SUPERVISED, owner release_managers) · agent 01a2f6a0-… · trust review /api/agents/01a2f6a0-…/trust_review
rationale:
  Incident INC-2041: patch level drift on core_banking.
  Observed 3 pending CVEs under the tiered read; patch_preflight is the standing remediation.
recommendation: 01a2f6ae-… — Apply the quarterly patch (open, 2026-11-06T00:59:00Z)
transcript: /api/projects/limebank/agents/felix/adapter_transcripts/exch-42
chain: 01a2f69f-… (opschain chains show 01a2f69f-…)
  2026-11-06T01:00:00Z  event info:agent:invoked
  2026-11-06T01:00:01Z  event info:agent:request
  2026-11-06T01:00:02Z  event info:recommendation:filed
  2026-11-06T01:00:03Z  event info:agent:adapter_transcript
  2026-11-06T01:00:05Z  change patch_preflight

Read it top to bottom, as the approver should:

• requested by names the agent, the tier it held when it raised the change, and who owns it; the trust-review link opens its evidence (lesson 12.3). Because you are an approver on this checklist you may open that one agent's sheet without the agents reviewer role.
• rationale is what the agent said, verbatim — what the incident said, what it observed under its tiered reads, why this action on this target.
• recommendation is the recommendation this change implements, with its status.
• transcript is the redacted adapter transcript the agent's reasoning left on the chain, when one was sealed and its agent path is readable to you.
• chain is the lineage: invocation, request, recommendation, transcript, change. Hops outside your read grant render as (redacted); … earlier hops omitted marks a longer chain.

4. One chain per unit of agent work

The chain is not something the agent's developer assembled. When the runtime dispatches a unit of work to an agent — a sweep, a chat turn, a recommendation cycle — it opens one correlation scope: it inherits the id the platform stamped on the inbound exchange when a caller supplied one (an incident relay, a trigger, an operator passing a chain on), so the chain starts at the incident or operator request rather than at the agent; with no caller-supplied id it mints one and lands the info:agent:invoked root hop. Every governed read, recommendation, transcript and run creation inside that scope carries the id, and the server records it on the created run (correlation_id, initiated_by_type agent). The approver reads the same chain the operator would triage:

opschain chains show <correlation-id>

The chain page renders the whole lineage oldest first — invocation, each read, the recommendation, the transcript, the created change and, once you decide, the approval decision — with the informative events kept and hops you cannot read shown as redacted stubs. Lesson 5.1 reads chains in general; the agent-side mechanics are on opschain docs ai-agents ("One chain per unit of work").

5. The history and the oversight view

Once decided, the context stays on the record: opschain approvals history --mine -o json carries each decided checklist in full, context included, and the governance administrator's opschain approvals history (the oversight determination — readable on /governance/change) lists every decision in the estate with the same detail. In the GUI the Decided tab's rows expand to the checklist, its approval rows and the context the approver saw.

A trust raise's context is shaped differently: it names the agent whose trust is being raised, the granter as requester and the grant's note as rationale, with no chain. A transport grant or release promotion carries no context block.

Check yourself

• What must an agent-raised change carry that a human-raised one need not, where does the approver read it, and what is the first hop of the chain when an incident relay invoked the agent?

What you learned

• A held change or workflow run carries an approval context — requester kind, rationale, recommendation, chain — stamped by the server, never by the client.
• A person's rationale is optional; an agent's is mandatory, and the create is refused without it.
• One unit of agent work is one correlation chain, inherited from the caller or minted at invocation, and approvals show and chains show read the same lineage.
• The context is served to the checklist's approvers and requester, and stays on the decided row for the history and the oversight view.

Next: lesson 10.4 — Waivers — the exceptions register (opschain learn 10.4), or back to your track (opschain learn).