From a Request to an Approved Mission

Overview

The Mission Is the Missing Abstraction drew the boundary between Mission Intent (a proposal) and an approved Mission (the governance object). The approval event is the single moment of transition, where the Authorization Server validates the Intent, derives an Authority Set, the Approver consents, and the Mission record is committed by intent_hash and authority_hash.

This part is about the integrity of that transition. A request arrives as natural language, or as an upstream trigger, and has to become something the Authorization Server can validate and an Approver can meaningfully consent to. Three things have to hold for the resulting Mission to be trustworthy, and each maps to its own drafts in the suite:

1. The proposal must be honest about what it is. A shaper turns the request into a candidate Mission Intent, and that candidate has to fail closed on ambiguity rather than invent authority. (Shaping, Informational.) Client claims about the Intent, including its originator or presenter, travel as typed evidence the Authorization Server verifies or refuses. (Intent Submission Evidence, requesting Standards Track.)
2. The approval must commit what the Approver was actually shown. Otherwise a faulty rendering layer can display a narrow task while the Mission records a broad one. (Consent Evidence, requesting Standards Track.)
3. The approval must survive a real human review. Reviews are asynchronous, and reviewers approve a narrowed subset far more often than they accept all-or-nothing. (Deferred Approval, requesting Standards Track, and its narrowing companion Approval Revision, Experimental.)

The unifying claim, hammered through every section below, is the one from The Mission Is the Missing Abstraction. None of these three grants authority. Authority is created only by the Authorization Server’s validation and approval. The shaper proposes. Consent evidence records. Deferred approval narrows. They make the approval that does grant authority trustworthy, without ever becoming it.

The boundary, restated

The trust boundary is the whole reason this layer exists. The Mission versus Intent section of the architecture chapter is the canonical treatment. The short version:

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The user’s raw prompt, the shaper, the model behind the shaper, and the candidate Mission Intent are all on the untrusted side. The Authorization Server’s admission decision is the boundary. Before it, only Intent exists. After it, only the Mission is authoritative.

Each of the three drafts in this part strengthens a different edge of this picture. Shaping makes the left box honest and auditable. Consent Evidence makes the middle box reconstructable after the fact. Deferred Approval makes the middle box tolerate a slow, picky human reviewer without losing state. The boundary itself never moves.

Who may approve

The Approver is a role, not a species. On the record it is the consent_principal of the Mission’s approval_basis, an {iss, sub} principal (the record’s approver member is a compatibility alias carrying the same value), and the litmus test has never named a person as the decider. What the approval event requires is an accountable principal deciding against committed inputs before any authority exists. Three roles divide that work: derivation fixes the authority, an adjudicator (the human Approver, or a deterministic, versioned policy acting within a ceiling a human consented to) decides whether this instance activates, and a human stays accountable as the Approver. Two invariants hold whoever adjudicates:

• The proposer is never the approver. The agent, the shaper, and the requesting client sit on the untrusted side of the boundary above, whoever sits on the deciding side. A request that approves itself is not a request.
• Non-human adjudication traces to a human decision at some grain. An adjudicating policy is legitimate because a human consented to the ceiling it enforces or approved the policy it executes, exactly as a manager’s sign-off is legitimate because finance approved the delegation-of-authority matrix behind it. The record can name the policy in approval_basis.adjudication by id and version, so re-running that version over the recorded inputs re-checks the decision.

Within those invariants, the adjudicator is a spectrum the deployment chooses per class. A human approves directly, with Consent Evidence committing the disclosure they saw. A policy adjudicates the activation at machine speed, with the committed inputs and the policy’s recorded version standing where the disclosure stood, which is how a standing agent’s ceiling turns four hundred approvals an hour into policy decisions. Risk and fraud engines compose as decision inputs that inform or narrow either kind of adjudicator, the same way content-aware controls compose at the runtime layer: signals, not authorities. A model’s judgment enters adjudication only as a recorded input to the policy, with the model’s identifier and version: it can refuse an activation or narrow the authority it activates, and it never grants or widens, because a generated approver reading attacker-influenced proposals is itself an injection surface. Neither the policy nor a model input to it gates on the Intent’s prose members, which stay the human Approver’s check. And the floor is the class guard: irreversible actions, external commitments, and privileged administration keep a human in the decision by deployment policy, whatever approves everything else. The runtime part prices these same classes as high-consequence.

That floor names one accountable human, and the singular is a modeling choice worth defending, because four-eyes controls exist precisely so that no principal decides alone. The record commits one accountable Approver for attribution’s sake: a decision everyone signed is a decision no one answers for, and Law 2 needs a name. Joint approval is not lost, it is relocated. An adjudicating policy can require two human sign-offs before the Mission activates, and the quorum is enforced at admission. Every co-signer lands as an assertion in the issuer-signed Approval Governance Record, under the approval_policy (its id, version, and a digest of the retained policy snapshot) that demanded them, joined to the Mission by its approval_event_id. Consent Evidence can present the co-signers’ decisions beside the disclosure as co_approvals, and the governance record stays authoritative. What the model refuses is only the opposite flattening, a record where accountability diffuses across the quorum until it vanishes.

The enemy this section guards is not machine approval. It is agent-inferred authority: the agent granting itself scope mid-flight because no admission decision was required at all. Policy adjudication is still an admission decision, committed and attributable. An agent that widens its own authority is not.

The role, on a screen. The routing is risk-based (production impact and sensitive data pull a manager into the loop), the requester is not the approver, and the panel says why the decision landed here:

Shaping: proposes only

The issuance profile defines the Mission Intent object and how the Authorization Server derives an Authority Set from it. It does not define how a deployment turns “reconcile our Q3 invoices and post any adjustments under $500” into that structured object. That step is the Mission Shaper, and the Shaping draft describes it.

The draft is Informational by deliberate choice. Client-side prompt processing is shaped by deployment policy, model choice, and product ergonomics. No two deployments agree on the transformation, and the interoperable surface is not the transformation but its result, the Mission Intent, which the issuance profile already validates on the wire. So the draft specifies the shaper’s role and trust posture and the behaviors a sound implementation follows, not a portable shaping protocol.

A shaper can be an LLM-assisted function, a deterministic rules engine, a form, or a workflow. Whatever it is, its single rule is propose only:

• It MUST NOT issue, derive, or certify authority. Its output is untrusted client input until the Authorization Server validates and narrows it.
• It MUST NOT emit members that mimic Authorization Server outputs. No mission.id, no intent_hash, no authority_hash, no Authority Set, no lifecycle state. Those are produced by the Authorization Server at and after approval. The issuance profile rejects a Mission Intent carrying any such member with invalid_request rather than silently stripping it.
• A model-based shaper is no exception. The model can draft a proposal. It is never the thing that grants or widens access.

What a sound shaper builds is a Mission Intent with goal, an optional goal_lang, target_resources (each an absolute URI, no wider than what the request referenced), optional free-text task_bounds and success_criteria (disclosure and audit material only, carrying no machine semantics), an optional registered purpose, and expires_at, plus any member a companion the Authorization Server implements defines, such as requested_derivation_limit or a metering bound. The Intent’s top level is closed: the Authorization Server refuses an unknown member with invalid_request. The client submits the Intent through PAR as the intent member of a Submission envelope, and intent_hash commits the intent alone. The Intent carries no authority members. Any concrete candidate authority the shaper has resolved (actions, structured constraints, delegation facts) rides beside the Intent as standard top-level authorization_details: an untrusted carrier, committed by the conditional proposal_hash, that the Authorization Server only narrows when it derives the Authority Set (narrowing mode). Without a proposal, the Authorization Server looks the candidate entries up in a mapping it has configured for the Intent’s purpose or target_resources, then narrows those to policy (configured-mapping mode). Every handbook example uses the mission_resource_access entry type, which the Mission Resource Access Profile defines: a resource matched exactly or by path prefix, its actions, machine-checkable constraints including the registered Common Constraints, a per-entry delegation policy, and the subset algebra that narrows one entry against another. The OAuth binding itself is type-agnostic. Either way, the Authority Set is the Authorization Server’s product, never the shaper’s input taken at its word.

The Submission envelope’s other member, evidence, is where the client backs claims about the Intent: typed Intent Submission Evidence entries naming its originator, an admission or consent decision that applies to it, or the presenter authorized to submit it. The Authorization Server refuses the whole submission with invalid_mission_intent_evidence if an evidence entry has an unsupported type or fails verification. A verified entry is policy input, never authority. Intent-bound evidence must name this exact Intent’s intent_hash, evidence that names a presenter must match the one the exchange authenticated, and the Mission records the verified facts as submission_evidence.

One evidence type the family defines for the originator is Mission Request Provenance. A request intake, isolated from the shaper so the shaper cannot write to it, authenticates the person, captures the instruction before shaping, and signs an assertion binding the originator, the authenticated channel, and the capture time to this Authorization Server, the exact provisional intent_hash, and the presenter. The assertion carries only a keyed digest of the instruction, under a secret that never leaves the intake, so the Mission records where the request came from as submission_evidence without the Authorization Server learning what it said. Verification establishes the request’s origin. It does not establish that the Intent interprets the request faithfully, and it is never approval or authority.

Fail closed, not open. An ambiguity in the request is material when resolving it one way rather than another would change the Authority Set, the action class, the actor, the expiry, or the risk posture. For a material ambiguity, a sound shaper does one of three things: request clarification, emit a narrower proposal that excludes the ambiguous authority, or refuse with a reason. What it must not do is silently default a vague goal into a wide proposal. Because the shaper’s internal reasoning is unobservable to the Authorization Server, the draft expresses this through the audit artifact. When a shaper resolves an ambiguity in the broadening direction, Shaping Evidence MUST record the resolution, together with the deployment-policy rule that permitted that default where one did.

Shaping Evidence is that artifact: a record of the inputs, inferences, policy decisions, capability resolutions, ambiguities, and any model trace that produced the proposal. It is audit material, not authority, and never an input the derivation consumes. A Resource Server or PDP MUST NOT use it to permit an action. A client that wants the approval to cite how its proposal was produced can send a shaping_evidence_hash, computed over the suite’s domain-separated {typ, iss, value} envelope exactly as intent_hash and authority_hash are, as the mission_shaping_evidence_hash parameter of the PAR request. An Authorization Server that implements Consent Evidence records the value unchanged in the Consent Disclosure, where consent_rendering_hash commits it. The parameter carries only the hash, not the Shaping Evidence, so the Authorization Server cannot check the value against it, and the hash is a client-supplied audit commitment, not verified provenance. It confers no authority and proves nothing about the proposal’s correctness.

The threat this contains is silent broadening: a vague request quietly becoming a broad Authority Set, or prompt-injected content in the request expanding target_resources, choosing the wrong purpose, pushing out expires_at, or suppressing a stated bound. The shaper’s defenses (treat all prompt content as data not instructions, use resolved capabilities as a hard allowlist, refuse on injection patterns, record everything) reduce but cannot eliminate the risk. The real defense in depth is downstream. The Approver sees the validated Intent in a disclosure rendered by the Authorization Server, not by the shaper, before authority is bound. Which is exactly what the next section makes verifiable.

Both shaping modes have a natural surface, and neither grants a thing. Generated shaping takes the plain-language request and proposes policy-shaped options with cost, duration, and risk visible:

Authored shaping is the same proposal built by hand: objective, success criteria, allowed and forbidden capabilities, budgets and limits, then submission for approval:

Illustrations of the experience, not normative renderings. On the wire both are the same thing, a Mission Intent submitted for validation, and the compliance both surfaces advertise is a pre-check: the Authorization Server’s derivation and the Approver’s decision still create all the authority there is.

Consent Evidence: the recorded disclosure

The issuance profile commits what was approved, the Mission Intent and the Authority Set, through intent_hash and authority_hash. It deliberately leaves one gap open. It does not commit the consent disclosure the Approver actually saw. A faulty or malicious rendering layer could show a narrower task than the Authority Set really records, and nothing in the issuance profile would catch it. The Consent Evidence draft (requesting Standards Track) narrows that gap.

It adds two artifacts at each human approval, including the consent to a template or ceiling that later instances run under. An instance a policy activates under that standing consent has no disclosure of its own:

• A structured Consent Disclosure object: the task summary (including the rendered expires_at), the rendered authority summary (resources, actions, constraints, delegation, consumption bounds), the material notices for high-risk authority, the Approver and Subject identities, the requesting_client that will wield the authority (the party the Approver most needs to identify to resist consent phishing), and the intent_hash / authority_hash the disclosure corresponds to. When the submission carried Intent Submission Evidence, a submission_provenance_hash commits the verified provenance as part of the disclosure. It is constructed after Authority Set derivation and before approval. If the Authority Set changes afterward, the disclosure is discarded and rebuilt.
• A consent_rendering_hash over that disclosure object (again in the {typ, iss, value} envelope), and a signed Consent Evidence object that records the decision (approved, declined, or narrowed, the last for a review that sent the proposal back for revision), the authentication context, and an integrity envelope (a JWS) over the whole record, bound to the same Mission anchors used for authority.

The precise scope claim matters, and the draft is careful about it:

This profile commits the structured disclosure that the Authorization Server says it rendered, and binds it to the same Mission anchors used for authority.

What no server-side commitment can prove is that the pixels presented to the Approver matched the committed object, that the Approver read or understood it, or that the rendering layer was honest. The draft names that residual rather than hiding it.

What it buys you is a durable, integrity-protected record tying a specific structured disclosure to a specific approval decision and Authority Set, so that any divergence between the recorded disclosure and the authority later enforced becomes detectable in audit. An auditor can re-render the committed disclosure and check it against the Authority Set the agent actually used.

The “what a human perceived” problem is not all-or-nothing, so the draft defines a rendering-assurance ladder of rungs a deployment adopts as far as its threat model needs. Rung 0 commits the disclosure. Rung 1 makes rendering a deterministic function of the disclosure and its template, so an auditor can re-render the intended form. In practice that means the disclosure identifies its template, the template’s version, and the locale it rendered, and commits the template bytes with a rendering_template_digest, because a re-render an auditor cannot reproduce exactly is not deterministic. Rung 2 adds an attestation that an identified, attested renderer produced it. Rung 3 is the what-you-see-is-what-you-sign rung. The Approver’s own authenticator signs the consent_rendering_hash, moving trust from the rendering layer to the Approver’s authenticator. (Rung 4, out-of-band confirmation at execution time, belongs to Mission-Bound Runtime Enforcement.) Rung 0 is the profile’s only conforming floor. Every rung above it is an optional named claim, and Rungs 2 through 4 are additionally experimental, since each imports a trust infrastructure (attestation, transaction-confirming authenticators) the profile cannot supply. A deployment that needs assurance that the Approver’s authenticator confirmed a specific disclosure SHOULD evaluate Rung 3 for its high-risk notice classes: the class-guard classes plus consumption bounds.

Two details are easy to miss and worth keeping. First, declines are recorded too. A declined approval creates no Mission, token, or authority, but Consent Evidence is still recorded, so that coercion, decline-then-reshape fatigue attacks, and rendering confusion cannot be made invisible to audit. Second, the disclosure renders the derived authority, not just the friendly summary. A disclosure that shows a mission_summary without a faithful authority_summary does not conform. The Approver consents to the authority, with the summary as context.

Translation and interrogation: the disclosure as a dialogue

The same draft sets a translation floor, because coverage alone does not make a disclosure readable. A deployment can satisfy every coverage rule and still present the Authority Set as serialized structure that trains the Approver to stop reading, which is the consent-fatigue residual arriving through the rendering layer. So the rendered forms must be natural-language statements of what the agent may do, with each constraint and consumption bound rendered as the bound on a statement (“may not exceed 500 USD in total”), a serialized Authority Set never the primary rendering, and a constraint key the template cannot translate rendered and identified as untranslated rather than omitted. An Approver shown an untranslated bound can decline. One shown nothing cannot. Disclosure is a language problem before it is a rendering problem, and the floor is template-testable: the same template fixtures that catch downgrades should prove the template translates every constraint key and notice class the deployment uses.

The floor is also where ontology ownership becomes visible, because the disclosure renders meaning the issuer does not own. A Common Constraint has registered semantics the template can translate, but a resource-local action means what the resource says it means, and where a substrate lets the resource declare its own operations and consequences (AAuth’s exploratory Rich Resource Requests is this shape), consent composes the resource’s own words and commits them, so the record carries what the resource declared beside what the client asked and what the Approver accepted.

And the disclosure is not take-it-or-leave-it. A faithful disclosure answers what the Mission may do, but the question an Approver actually weighs is often why. Why does a support-ticket task need write access to a finance folder? An Approver who cannot ask guesses, and a guessing Approver decides on the wrong fact. Disclosure Interrogation gives the Approver a question channel before the decision, and the draft is precise about what may answer it. Anything the consent surface presents in its own voice must be drawn from recorded material: Shaping Evidence for why the task motivated an entry, constraint provenance for whose rule a bound is, and identified deployment policy for the Issuer’s own bounds. Where the answer is instead relayed from the requesting agent (AAuth’s clarification chat is exactly this channel), the relayed text is attacker-influenceable, so it is rendered inert and visibly the agent’s, because the same channel that lets an Approver ask why lets a compromised agent argue. An answer grants nothing and amends nothing. An Approver satisfied by an answer approves the same committed authority, and one convinced the authority is wrong declines or requires narrowing through a fresh derivation. The interrogation itself is recorded in Consent Evidence, and the question asked before a decline is the record’s most valuable entry: it preserves which authority the Approver probed and could not accept.

The dialogue, drawn. The question channel with its trust boundary visible: the requester’s answer arrives quarantined as relayed agent text, the grounded answer comes from Shaping Evidence with its citations, and the footer records the whole exchange into Consent Evidence:

The mock keeps the section’s rule: an answer grants nothing and amends nothing, and the Approver who accepts one approves the same committed authority.

Deferred and revisable approval

The issuance profile’s direct approval treats the approval event as immediate. Real human review of an agent’s proposed Mission is not. Two facts go unspecified, and two companion drafts supply them: the Deferred Approval draft makes the approval asynchronous, and the Approval Revision draft lets the reviewer narrow it in place. Deferred Approval depends normatively on OAuth Deferred Token Response, which the OAuth working group adopted in September 2026 and which is still a draft, and Approval Revision rides the same substrate and is labeled Evaluate only. Synchronous approval is the path to start with until that substrate settles.

Reviews are asynchronous. The agent submits a proposed Mission and may wait a long time for a decision. This is deliberately the shape of the request-and-approval workflows an enterprise already runs, so an IGA or ticketing system can drive the decision without new human ritual, and for approval volume the ceiling-and-drawdown model of progressive authorization is the companion answer (Mission Lifecycle and Change). The draft profiles OAuth Deferred Token Response so a Mission approval can be deferred and polled. The client includes deferred among its completion_mode values, the Authorization Server returns authorization_pending with a deferral_code instead of a token, and the client polls until the approval resolves. Deferral changes only the timing of the approval event. The Authority Set, its authority_hash, and the recorded consent are exactly as in a synchronous approval. An agent with no person at hand still runs the authorization code step: no Approver need be present at the authorization endpoint, which may issue the code without user interaction because the code stands for a pending authorization, bound by PKCE or DPoP. The agent redeems it with completion_mode=deferred and polls on the deferral_code until it receives a token, access_denied, or expired_token. The Mission becomes active atomically with the approval, and the client treats every pending response as unapproved. The drafts do not specify how a headless agent drives that front-channel step.

Reviewers narrow. A reviewer commonly approves a subset of the proposed Mission, not the whole thing. Without a way to revise in place, the agent has to abandon the proposal and start over, losing the approval state and any preceding work. The experimental Approval Revision companion adds a revisable mode. The client offers mission_revisable alongside deferred (completion_mode=deferred mission_revisable), and when the Authorization Server can grant only a narrowed version, it extends the authorization_pending response with mission_revision_required, a single-use sender-constrained mission_revision_handle, and (optionally) the mission_rejected_scope and mission_rejected_authorization_details that tell the agent which dimensions were refused. The client pushes a narrowed submission to PAR with the handle, and keeps polling the same deferral_code. A revision whose re-derived Authority Set does not narrow every refused dimension fails with mission_revision_not_narrowing. The approval resolves over the narrowed proposal. The client never lost its place, and without this companion the path is deny-and-resubmit under Deferred Approval alone.

The hard invariant, and the boundary to keep straight, is that this is narrowing only:

A revision can reduce the proposed Mission. It can never broaden it. The Authorization Server verifies the revised Authority Set is a subset of the proposed one under the issuance profile’s subset rule before it re-reviews.

Widening an already approved Mission is a different operation with its own fresh approval, Mission Expansion, which lives in Mission Lifecycle and Change. Deferred Approval and its revision companion govern only how the initial approval is reached over time. A client MUST treat mission_revision_required and the refused dimensions as evidence of nothing approved yet, never as a grant.

The mission_rejected_scope and mission_rejected_authorization_details are also the machine-readable input a shaper consumes to plan the narrowing. Shaping narrows a proposal before submission. Deferred approval narrows it during review. And because a narrowed proposal is a different disclosure, a deployment recording Consent Evidence records the review as a narrowed decision with the refused dimensions, and MUST compute a fresh consent_rendering_hash for the re-reviewed revision. Prior consent does not transfer to a different Authority Set.

The approver’s side of a deferred review, riding their own queue on their own schedule:

Request Changes is the revision channel: the reviewer narrows, the agent keeps polling the same deferral code, and nothing restarts. And the mock’s approve-and-run button compresses two events the wire keeps distinct: approval activates the Mission, and the waiting agent’s poll is what resumes the run.

The fatigue budget

Approval fatigue is not a UX complaint in this architecture. It is a security budget, because the card chapter’s version of this room said the quiet part: any adversary who can generate requests can farm a tired approver, and for agents the requests generate themselves. The handbook’s design answer is grain plus who may approve: machines approve actions, authorized policy adjudicates the Mission activations a consented ceiling already covers, and humans decide what is left, the ceilings, the class-guard classes, and the exceptions. But grain alone just moves the pile. A reviewer rubber-stamping forty Mission disclosures a day is the same failure one level up, and every approval a policy can legitimately take is one the human budget never pays. So the profiles in this part are also the fatigue controls, and they are worth reading that way:

• Shaping is the first control. A disclosure a reviewer can actually read (goal, resources, bounds, expiry, rendered small) is the difference between a decision and a reflex, and a shaper that fails closed on ambiguity keeps the padded, over-broad proposal from ever reaching the queue.
• Deferred approval routes decisions where attention already lives. The review rides the IGA or ticketing workflow the organization already staffs, with its own escalation and its own SLAs, instead of a new interrupt channel nobody owns.
• Revision narrows without restarting. The common case (right task, wrong bounds) costs the reviewer one trim instead of a resubmission cycle that trains requesters to ask broad and approvers to stop reading.
• Ceilings spend one good decision on many small ones. For high-volume and standing work, a pre-consented authority ceiling moves the human decision to the ceiling and its renewal, with the drawdown guard reserving fresh human approval for the classes where fatigue is most dangerous (the standing agent at scale).
• Action-bound approval is rationed by class, not sprinkled. Runtime enforcement reserves the second human decision for the class-guard classes: the friction budget spent at the point of maximum consequence.

And measure it, because a fatigue budget nobody measures is already overspent. Approval latency, deny and revision rates, exception volume, and time-to-decision are governance health metrics, and a queue where every approval lands in four seconds is telling you the disclosures are unreadable, the grain is wrong, or the reviewer has stopped reviewing.

Repeated work can justify a coarser human decision when its bounds are stable and its evidence is reviewable. Revision and deny rates inform that review alongside authority used, exceptions, incidents, and outcomes, and falling rates alone do not show the work is safe: broad permissions or a tired reviewer lower them too. A human decides whether the work belongs under a standing consent:

Both standing consents hold back more than the class guard does. Authority in the high-consequence classes, authority with the external-communication property, and cross-domain authority never activate on policy alone: a drawdown that grants such authority needs a fresh human approval, and a template cannot dispatch a Mission that carries it, so that work takes direct approval. Approving a Mission is separate from approving an action: where a deployment claims agent-compromise resistance, each high-consequence action also needs its own action-bound approval. Templates and progressive drawdown are experimental and Evaluate only in the catalog. They reduce the number of approvals, and the security benefit holds while a human still reviews each standing consent and its exceptions at renewal.

Spent well, the budget looks like this pair. Most work runs at the one-click end, read-only and least-privilege, previewed rather than interrogated:

And the heavy end is reserved for the one percent, where simulation results, blast radius, policy evaluation, and a chain of named approvers spend the friction where the consequence lives:

The tiers printed on these mocks are approval routing, not the Mission Assurance Levels: one is per-Mission friction under one deployment’s policy, the other is how much of the architecture a deployment runs.

How they compose

The three concerns are easiest to see threaded through one task. This is the handbook’s canonical running example. Alice asks her agent, in free text, “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission Is the Missing Abstraction picked up this task at the issuance profile. Here we watch the approval-time integrity around it.

Walking it:

1. Shaping proposes. The shaper turns the open-ended prompt into a bounded candidate Intent. It proposes three target_resources URIs (the finance, docs, and workflow services), matches the request to the registered board-packet purpose (urn:example:mission:board-packet), and states the bounds the request implies as human-readable task_bounds: Q3 2026, Example Corp, confidential. It bounds the work in time with an expires_at of 2026-10-15T18:00:00Z. What it does not do is author the actions: it submits no authorization_details proposal. Had no registered purpose matched, the shaper would have asked alice rather than choose the nearest one. It records Shaping Evidence and proposes.

2. The approval defers. Because the agent offered deferred mission_revisable, the review need not be synchronous. The Authorization Server validates the Intent and returns authorization_pending with a deferral_code, and the agent polls while the review waits for alice.

3. The Authorization Server derives at the approval event. No authority was proposed, so the AS derives the set in configured-mapping mode. The board-packet purpose mapping supplies the current reporting period, template, and reviewer group within the Intent’s target_resources. The AS shows alice the task_bounds beside the result but does not read them. The result is a query_financials action (finance, scoped to Q3 2026), a create_doc action (docs, bound to the board-packet template), and a notify_reviewer action (workflow, targeting the audit-committee group), each a mission_resource_access entry. The shaper’s structured members informed that derivation, as lookup key and bound. The Authorization Server authored every action in it. And derivation is mechanical, happening once at the approval event over the policy and capability catalog in force when alice decides, so a proposal that waits for days is never rendered to her under superseded policy. The rendered disclosure routes to alice, who approves on her own schedule. Had she instead refused the notify_reviewer action (a common reviewer instinct, holding back the external-facing step), the revisable mode would let the agent drop the workflow service from target_resources, push the narrowed submission, and keep polling the same deferral_code. Here she approves the proposal as derived.

4. Consent Evidence commits the surface. The structured disclosure the Authorization Server recorded as rendered (the task summary plus the faithful authority_summary over all three actions) was committed by consent_rendering_hash before approval, and her approval produces a signed Consent Evidence record bound to it. The committed intent_hash and authority_hash are over exactly the Intent and Authority Set she approved. The Authorization Server commits the Mission as msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p, state=active, with a direct approval_basis naming alice as its consent_principal, and issues the Mission-bound token that runtime enforcement will police. Its mission claim names the Mission by id and issuer, and the anchors stay on the record.

The same composition, rendered as an approval surface: the mock walks the identical spine as a reviewer experience, and its printed design principles are this part’s arguments as pixels.

An illustration of the experience, not a normative rendering. The wire truth for the claims and anchors lives in the exhibits, and a conforming disclosure renders the faithful authority_summary this part requires, whatever the pixels around it look like.

The result is an approved Mission whose integrity anchors commit a proposal that was honestly shaped, a disclosure that was faithfully recorded, and an approval that reflected a real human decision, without any of those three steps ever having granted authority. That is the whole job of this layer.

Where this sits in the handbook

This is the Intent step and the integrity of the Mission approval event on the spine. It sits between The Mission Is the Missing Abstraction, which defines the Mission and the issuance profile this layer feeds, and Mission-Bound Runtime Enforcement, which is where a Mission-bound token becomes a Mission-bound action, checked one action at a time against the current Mission.

Everything here happens before any token exists. By the time Mission-Bound Runtime Enforcement is evaluating an action against the current Mission, the questions this part answers, was the proposal honest, was the disclosure faithful, did the approval reflect a real human decision, have already been settled and committed. The later parts carry the approved Mission forward: Mission-Bound Authority, Mission Lifecycle and Change (including Mission Expansion, the widening counterpart to this part’s narrowing-only revisions), and The Agent Runtime and Audit.

The laws this part proves are the quiet ones. An approval binds only what it can replay (Attribution), and enforcement can only hold a boundary the approval actually drew (Containment). This is the one place in the loop where safety is still cheap. Spend the friction here.