Mission Lifecycle and Change

Overview

The Mission Is the Missing Abstraction defined the Mission as a durable governance object and gave it a deliberately small lifecycle: active, revoked, expired, with the rule that only active permits new derivation. That issuance profile is complete on its own. But it observes Mission state only through one channel: the lifetime of the tokens it already issued, plus optional token introspection. A consumer that holds a Mission-bound token and nothing else has no way to ask “is this Mission still good,” and no way to be told that it stopped being good. An authorized operator who wants to pause a Mission has no standardized verb for it. A task that finishes keeps deriving its authority until a clock or a revoke stops it.

This part closes those gaps with the lifecycle suite: optional capabilities layering on the issuance profile without changing it, with Status as the suite’s root (it carries the status surface and the lifecycle endpoint) and the Status List, Signals, Entry Discharge, and Management as its satellites. All of them are proposed individual drafts, and they sit at different points in the handbook’s adoption guidance. Status carries the Runtime-Enforced label: it is that level’s state surface. Signals, its push complement, is OPTIONAL and Advanced, aligned with the Shared Signals transmitter and receiver model. Expansion and Entry Discharge are Advanced, to adopt when the use case arrives, and each has a newer companion noted where it attaches (Progressive Authorization and fleet Management). They answer four questions a long-running task forces:

• Observe: how does a consumer holding only a mission_id learn the current state, and learn it promptly when it changes?
• Revoke: how does an authorized party change the state (terminate, pause, resume)?
• Grow: what happens when the task legitimately needs more authority than was approved?
• Complete: how does authority retire itself safely as the work it was granted for finishes?

The unifying move is the one the handbook framing names as a recurring rule. Only active permits reliance. Every state these profiles add (suspended, completed, superseded) is treated as non-active by any consumer, including one that has never heard of it. That is what lets the lifecycle grow new states without breaking the consumers that predate them. We return to it at the end, because it is the property that makes all four verbs safe.

Observe and revoke: pull and push

The canonical statement first, because every mechanism in this part serves it. Revocation changes the Mission’s authoritative state immediately. Enforcement latency is path-dependent: runtime-gated actions stop within the published freshness bound, new derivation stops when the issuer observes state, and outstanding offline-valid tokens run to expiry unless the path checks Mission state.

The kill switch from The Mission Is the Missing Abstraction is possession-independent. Revoke the Mission at the Authorization Server and no new authority derives for the task. But “no new derivation” only bites at the next derivation event. A Resource Server holding a live access token does not consult the Authorization Server on every call by default. It trusts the token until it expires. So the kill switch is only as fast as the slowest token’s remaining lifetime, unless consumers can learn the current state out of band.

There are exactly two ways to learn current state: ask for it, or be told. The suite provides both.

Status: the pull side

Mission Status and Lifecycle defines the canonical state surface the issuance profile deferred: an operation keyed by mission_id alone. Token introspection answers “is this token’s authorization still good.” The Status operation answers a different question, “what is the state of this Mission,” and answers it for any consumer holding a mission_id, including an auditor or a cross-domain Resource Server that holds no token the Authorization Server issued. The consumer resolves the endpoint from the credential’s mission.issuer and asks.

The answer is signed. A Status response is a JWS, with its own media type (application/mission-status-response+jwt), carrying the mission object (id, issuer, state, the Mission’s expires_at, and a REQUIRED state version, with authority_hash disclosed only to a caller the issuer authorizes for audit or correlation) plus, when the requester names an audience, the audience-scoped Authority Set entries relevant to it. An auditor may omit the audience and get a state-only response with no authorization_details. It is bound to the request by an echoed nonce, to the requester by aud and sub, and to a freshness window by fresh_until, which tells the consumer how long it may cache the reported state before re-checking. The signing matters because the response often outlives the call. An auditor must be able to verify, later, that the issuer really reported revoked at a given moment.

Two design choices in Status are worth pulling out because they are easy to get wrong:

• A mission_id is never a bearer capability. The endpoint authenticates the requester and authorizes it for the specific mission_id and audience. An unknown Mission and a known-but-unauthorized one return indistinguishable responses, so the Status surface cannot be turned into an enumeration oracle for the Mission space.
• The dedicated operation is not RFC 9701. Signed token introspection (RFC 9701) is scoped to token introspection and does not apply to a lookup keyed by mission_id. There is a separate, thinner story for the token-scoped case. The issuance profile’s introspection projection carries the mission state, and this Status profile adds the option of returning that projection as an RFC 9701-signed response. Two surfaces, two signing stories, deliberately not conflated.

Status is also where the explicit lifecycle endpoint lives (the verbs that change state). A management endpoint, distinct from RFC 7009 token revocation, accepts authenticated revoke, suspend, resume, and complete operations and introduces two states the issuance profile did not have:

• suspended: a non-terminal pause. A suspended Mission derives no tokens, but it can be resumed to active. This is the “stop, but don’t tear down” state an operator wants when something looks wrong but is not yet known to be malicious. A suspend may carry a deadline, suspend_until, with an on_expiry of resume or revoke that the issuer applies when the deadline passes, without a further request.
• completed: a terminal state recording that the task finished successfully.

The legal transitions are narrow on purpose: suspend only from active, resume only from suspended, revoke from either, complete from active or suspended (completion is a monotonic narrowing to a terminal state and needs no derivation window, so a suspended Mission need not be resumed first). One rule adjudicates every request: an operation whose resulting state equals the Mission’s current state is an idempotent success, terminal or not, and any other operation against a state it is not legal from is a conflict, not a silent no-op. The endpoint refuses it rather than pretending it worked. resume is the one exception to the idempotent arm: active is also the state a never-suspended Mission holds, so resume against an active Mission is a conflict. A caller deciding over state it may not have refreshed can also send expected_version, the state version it last observed, and the endpoint refuses with stale_version when the Mission has moved on, so a console that has not yet seen a newer resume cannot re-suspend the Mission. The endpoint authorizes operations against deployment policy (typically revoke to the Subject, Approver, or an administrator, and suspend/resume to administrators), and a caller that authenticates with an access token presents a sender-constrained (DPoP- or mTLS-bound) token carrying the mission_lifecycle scope. An unauthorized request gets the same not-found response shape as an unknown Mission, so the management surface is no more of an enumeration oracle than the read surface. Fleet-scale operations are deliberately out of this profile: authenticated Mission enumeration (by subject, client, state, or expiry window) and bulk lifecycle operations with a dry-run-first discipline live in Mission Management, an advanced companion.

Suspension is also priced as an actuator, not only defined as a state. It parks work rather than canceling it, resume re-verifies the facts that admitted the work, and a suspend that destroys days of queued work is a lever responders hesitate to pull and a damage multiplier for whoever games the risk signals into pulling it.

Signals: the push side

Status answers when the consumer asks. But a high-assurance consumer that wants revocation to bite in seconds cannot afford to poll the Status endpoint on every action. That puts the Authorization Server on the hot path of every credential validation. The complement is to be told.

Mission Lifecycle Signals is a profile of the OpenID Shared Signals Framework. When the Mission Issuer commits a lifecycle transition (a revocation, expiry, suspension, completion, or the approval event that activates the Mission), it emits a signed Security Event Token, a mission.lifecycle-change event, delivered either by push (the Issuer pushes the SET to the consumer’s receiver) or by poll (the consumer fetches available SETs). A partner Resource Server subscribed to the stream learns of a cancellation seconds after it happens, well inside the remaining lifetime of any token it holds, and stops honoring the Mission.

Scale is its own consumer. A fleet of enforcement points watching thousands of Missions cannot poll them one by one, and the Mission Status List, its own Advanced companion, is the swarm answer: the Issuer publishes one signed, TTL-bounded bit array covering many Missions, riding the OAuth Status List work now in the RFC Editor queue. Each Mission holds a two-bit value. VALID (0x00) reports active and is the only value that permits reliance; SUSPENDED (0x02) and INVALID (0x01, every terminal state) are non-active, as is any other value, and a consumer that reads anything but VALID re-establishes state at Status before relying again. The list’s TTL is the published staleness bound, and index assignment preserves the anti-oracle property, so holding the list does not let a consumer enumerate the estate’s Missions. One fetch refreshes a fleet.

One maturity note. Signals is a proposed OPTIONAL profile requesting the Standards Track, aligned with the Shared Signals transmitter and receiver model, and its Security Event Token and delivery dependencies are published RFCs. The handbook labels it Advanced, which means adopt it when the use case arrives. Push is a latency optimization over correctly sized status polling, so the default path remains Status sized to the risk, with Signals adopted where a revocation must bite in seconds.

The event carries the new state, the prior_state (except on the initial approval emission, where there is none), the Mission’s own expires_at (so an event-only consumer can fail safe on expiry), and a strictly monotonic per-Mission version counter, the same state version Status reports. An event can also report a narrowing that changes no state: authority_changed is true when an entry discharge or a containment shrinks the Mission’s Effective Authority Set while it stays active, and because the event says nothing about what changed, the consumer re-reads Status. The counter is the part that makes event delivery safe against the network. Events can arrive out of order or be replayed, so the consumer applies a transition only if its version is greater than the last it applied. A stale active event for an older version cannot revive a Mission a newer revoked event already retired. And because delivery is best-effort, a consumer that cannot verify its stream, or that was down and may have missed events, treats its cached state as stale once it exceeds the Issuer’s advertised staleness bound and falls back to polling Status. A missed event is a freshness failure, never “still active.” Signals make revocation prompt. They never make it fail open.

Pull and push are not alternatives so much as two sizes of the same answer. A consumer that checks state occasionally polls Status. A consumer that needs prompt revocation subscribes to Signals and falls back to Status when the stream goes quiet. Both read the same fact, the current state, from the same authoritative issuer.

Both surfaces assume the issuer’s own record is consistent. Mission Control-Plane Consistency, an Advanced companion that defines no endpoint or wire member, makes that testable across replication, partition, and recovery: one serialization order per Mission, no freshness manufactured by re-signing an older observation, no lower state version after a restore, and every committed transition published through durable, repairable fan-out.

The running example. Take the handbook’s running example, the Prepare the Q3 board packet Mission, msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p at as.example.com. At 23:00 the board meeting is cancelled while the agent’s final pass on the packet is still queued, so an admin revokes the Mission at the lifecycle endpoint. A consumer holding only the mission_id (the docs Resource Server, an auditor) learns the new state without holding any token the Issuer can age out. It either asks Mission Status (pull) or receives a mission.lifecycle-change Signal carrying state: revoked (push). Either way the result is the same. query_financials, create_doc, and notify_reviewer all stop deriving at once.

This is the kill switch at the moment of use, everything this section defines on one surface, stated as maximum bounds rather than guarantees: seconds for mediated paths, token lifetime for issuance-gated ones:

Two details worth noticing because they are the spec, not decoration: completed effects are flagged for unwind rather than rolled back, and the test button is the acceptance test made one click: revoke, then watch the next consequential action fail closed.

Between suspension and revocation the family now defines a third, experimental channel: Mission Containment, narrowing a live Mission without ending it. When a declared protected event fires (a tainted read, an anomaly signal, or, from open-world discovery, a routed_to_approval outcome or a tainted Discovery Evidence record), the issuer commits a versioned, removal-only overlay that subtracts capability from the Mission’s Effective Authority Set (the approved set after every issuer-held narrowing, as the Status profile defines it) while the Mission stays active and the approved anchors stay immutable. A derivation that asks only for contained capability fails closed as authority_contained, and removed authority returns only as a fresh approval, a successor under Expansion. Suspension pauses everything and containment removes something: the undertaking keeps running on the authority that was never in question.

Grow: expansion creates a successor

The first recurring rule of the handbook is that authority can only narrow. A derived or delegated token never carries more than the Mission. The subset rule enforces it at every derivation. That is a foundational safety property, but it raises an obvious question. What happens when the task legitimately needs to do something the approved Authority Set does not cover? Mid-task, the Prepare the Q3 board packet agent decides it could enrich the packet by reading CRM customer data, an authority the Approver never granted, outside the Mission’s query_financials/create_doc/notify_reviewer set entirely.

The answer is not to widen the Mission in place. A Mission’s authority is committed at one approval event by authority_hash. Widening it in place would mean the thing the user approved is no longer the thing in force, and authority_hash would no longer commit what is being used. Mission Expansion instead routes growth through a new approval that creates a successor Mission.

An expansion is an RFC 8693 token exchange at the token endpoint that carries the successor’s Mission Intent in mission_intent and leads to a fresh approval event. The subject_token is the predecessor’s own sender-constrained Mission-bound access token, and the client proves possession of that token’s confirmation key, so the Issuer adjudicates a successor of a specific predecessor rather than an unrelated new Mission, and no client can put an expansion in front of an Approver merely by naming another Mission’s identifier. A refresh token is never accepted as the subject_token. The possession proof is an eligibility rule, not an authority path. A deployment that issues only bearer tokens for a Mission forgoes this expansion and reaches succession through a fresh approval that references the continued work, and the management plane’s standing over the predecessor never depends on the possession proof: the proof gates the proposal channel and the supersession trigger, never the authority. The fresh consent is what supplies the broader authority. The successor’s authority comes only from its own approval. Its authority_hash commits exactly the set the Approver saw, never the predecessor’s plus a computed delta. On the successor’s activation, the predecessor transitions atomically to a terminal superseded state and derives nothing further, because two active records for one undertaking are a widening wearing a lifecycle. Supersession is a terminal exit, so it cascades to the predecessor’s live Child Missions: the expansion’s consent disclosure should show how many it will end, and a child still needed is re-created under the successor. The successor carries a predecessor lineage member linking it back, but that member is audit context only. Like every other extra member on the mission claim, it MUST NOT grant or widen authority.

The ask, as the user meets it:

One note on the mock’s compression: in the family’s semantics, approving this ask does not edit the running Mission. It lands as a fresh approval over a successor’s full derived authority, with the predecessor superseded and lineage kept.

Two distinctions keep expansion honest:

• Expansion is not step-up. A request denied because authentication is too weak (an acr/amr shortfall) is satisfied by re-authentication. The Authority Set does not change. A request denied because the authority is not in the active Mission is what expansion addresses. Routing an authentication shortfall through an approval event would surface irrelevant consent and breed approval fatigue. Treating an authority shortfall as a mere re-auth would silently widen nothing. The two are not interchangeable.
• Expansion is a governance operation, not a runtime escalation. It does not undo the subset rule. It is a deliberately heavier, consent-backed path that produces a new governed object the kill switch and audit chain still cover.

For open-ended tasks where stopping the user at every step is impractical, a newer, experimental companion, Mission Progressive Authorization, builds on expansion. At the initial approval the Approver may also consent to an authority ceiling and a drawdown policy, so in-ceiling expansions can be adjudicated by policy rather than a fresh human prompt. The ceiling is broad by construction (it has to cover the open-ended task), but what stays narrow is the active authority any single Mission in the chain yields. Each successor is derived for what is actually needed at that step, independently gated and revocable. The guard is explicit. A drawdown that would grant an irreversible action, an external commitment, privileged administration, external communication (the exfiltration leg), or cross-domain authority always requires fresh human approval, even within the ceiling. So does any drawdown while the predecessor has live Child Missions, because only a human approval can witness the cascade, and any drawdown that overlaps authority an entry discharge or a containment removed from the chain: policy never restores removed authority. Progressive authorization bounds standing-authority exposure. It does not eliminate it, and it is meant to be paired with short successor lifetimes and runtime enforcement.

The running example. The Prepare the Q3 board packet Mission, msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p at as.example.com, cannot read CRM customer data. That authority is outside its Authority Set, and the agent cannot widen the Mission in place. So it requests an expansion: a token exchange that presents the predecessor’s sender-constrained access token and asks for a fresh approval of a successor Mission. The Approver declines. CRM access is out of policy for board-packet preparation. The result is the failsafe one. No CRM access, no successor activates, and the predecessor is untouched and still active, deriving exactly its original three entries. Had the expansion instead been approved, the successor would have activated and the predecessor would have transitioned atomically to superseded, and supersession need not cost the runtime: a harness may rebind running sessions to the successor under freshly derived credentials, so the work continues under the new authority without a restart. Because it was declined, nothing supersedes anything.

Complete: discharge narrows one entry at a time

Expansion is governed growth. Completion is its narrowing counterpart. It is the more important of the two for everyday safety, because the common case is not a task that needs more authority but a task that is done with some of the authority it has. Like Expansion, it is Advanced in the handbook’s adoption guidance, to adopt when the use case arrives, with expires_at, revocation, and the complete verb as the simpler path until then. Its draft also says it is less exercised than issuance and runtime enforcement and that its details may change.

The issuance profile’s Mission Intent can carry success_criteria: a description of when the task is complete. In the issuance profile those criteria are inert (rendered to the Approver, committed to the record, carrying no machine effect). A Mission granted authority to post journal entries “until the Q3 close is finalized” keeps deriving that authority after the close, until a clock or a revoke intervenes. Mission Entry Discharge supplies the enforceable counterpart. It registers terminal_when, an entry-level completion condition carried in a mission_resource_access entry’s constraints, and a discharge operation on the Status lifecycle endpoint that commits a condition’s firing. When the Authorization Server commits a discharge, the entry is discharged: the AS stops deriving any token carrying it, exactly as it refuses derivation for a non-active Mission. The firing is asserted by a resource or event authority, not by whoever may revoke the Mission. A discharge call needs its own mission_discharge scope or an equivalent grant, the AS checks the caller against the authority published for that event type or named by the condition’s discharge_authority, and neither the mission_lifecycle scope nor being the Subject, Approver, or an administrator implies that authority.

The crucial scope detail is that discharge gates at the entry, not the Mission. A multi-resource Mission completes one entry at a time. In the running example, suppose the board meeting is not cancelled and the work finishes instead. The Prepare the Q3 board packet Mission has a query_financials read entry, a create_doc write entry, and a notify_reviewer send entry, the write and send entries each bounded terminal_when their step is done (create_doc once the packet is published, notify_reviewer once the audit committee is told). As each condition fires and the system that observed it (the document system for the publication, the workflow system for the notice) commits it through discharge, the Authorization Server stops deriving that entry (a refresh returns a token carrying only what remains) while the Mission stays active so any remaining entry keeps working. Each authority retired itself once its task completed and the event was reported. No revoke, no clock.

This is distinct from the complete lifecycle verb of the Status profile, and the two should not be blurred. complete is a Mission-level terminal transition to the completed state, driven by an authorized party at the lifecycle endpoint. terminal_when discharge is entry-level. The Mission stays active and keeps deriving its other entries. A deployment that tracks Mission-level completion may move a Mission to completed through that complete operation once all its entries are discharged, but Entry Discharge does not require it. One is “the whole task is finished.” The other is “this part of the authority is spent.”

What makes entry-level discharge safe to expose to an adversarial agent is that it is monotonic. Discharge can only remove an entry’s authority. It can never widen the entry or the Mission, and a committed discharge never reverts: the restriction carries to every successor in the expansion chain, and the retired authority returns only through a fresh human approval that discloses the discharged entry and its condition. So a prompt-injected agent has nothing to gain from it. The worst a forced discharge does is retire authority sooner, which is not an escalation but is a denial of service on the task, and discharge authority is what limits who can force one. Monotonicity is also why discharge composes cleanly with the subset rule: a derived entry carries its parent’s conditions unchanged and may only add more, making it discharge sooner.

Discharge is not fail-closed on the event itself. A discharge takes effect when the Authorization Server commits it, and until then the AS keeps issuing against the entry. A lost or delayed notification is therefore a temporary widening relative to the real-world event, bounded by authenticated at-least-once delivery to an idempotent acknowledgement, by monitoring and reconciliation, and by the Mission’s and its tokens’ own lifetimes. A deployment that needs no issuance while it cannot determine whether a condition fired runs a synchronous status or policy check outside the draft’s baseline. A token issued before the commit stays valid until it expires, unless the consumer checks Mission Status or introspection, which omit the discharged entry, or the runtime layer refuses it at the point of use as authority_discharged.

When the agent changes, not the Mission

One more change surface sits beside the Mission’s own lifecycle, because three objects govern an agent estate and this part’s verbs cover only one of them. The agent’s Agent Deployment, its approved behavioral version (code, model, system prompt, tool allowlist, data scope, runtime configuration), changes on its own cadence and is owned by change governance rather than by the Mission Issuer. Two rules keep the seam honest.

First, which changes require re-approving standing Missions is policy, and it is policy that change governance records rather than a default the platform assumes. A prompt hotfix may be routine. A new model or a widened tool allowlist changes what the Approver actually approved, and a standing Mission whose agent has materially changed is running on an approval that was given to different behavior.

Second, a Mission can be pinned to a specific approved Agent Deployment without that deployment becoming the Mission. The pin is an architectural pattern today, not a wire member: the OAuth binding defines no mechanism that pins a Mission to a deployment class or version and reserves no Intent member for one (the former controls seam is retired). A future Agent Deployment Binding profile would own it, with a committed approval-context pin and presenter-instance evidence checked at every derivation, and would define its own request carriage, record extension, rendering, and fail-closed behavior. The Agent Deployment stays owned by change governance either way.

The standing agent at scale

One shape of agent looks like a counterexample to this whole part: the agent that never finishes. A support-triage agent works four hundred tickets an hour. A SOC agent watches alerts around the clock. There is no board packet that ends, so what do expiry, completion, and successors even mean for it? A sharper version follows: if the Mission just gets renewed forever, is this not the blank check with a renewal ritual? The card chapter already toured this room: the standing arrangement that keeps billing is the expense world’s version, and its lesson was that continuity machinery must be taught to check whether the arrangement still stands.

The answer is the distinction the machinery in this part exists to make. The agent stands. The authority cycles. The standing thing is a charter, consented once as an authority ceiling with a drawdown policy (Progressive Authorization, experimental for exactly this shape of work). The experimental Mission Template companion is the sibling shape for independent dispatches: where progressive draws successors within one chain, a template instantiates independent Missions from one consented template. The working thing is the Mission each unit of work draws under that ceiling: a ticket, a batch of fifty, an investigation, each adjudicated by policy inside the pre-consented bounds, each carrying its own expiry and entries, each discharging what it used as the unit completes. And nothing high-consequence rides the policy path: the drawdown guard routes the class-guard classes, external communication, and cross-domain authority to a fresh human approval even inside the ceiling.

Run the numbers. Four hundred tickets an hour is four hundred small Missions, or forty batch Missions, whose approvals are policy decisions at machine speed. What humans decide is the handful of exceptions a day where the guard fires, and the one decision that matters: the ceiling itself, set and renewed on a governance cadence with the previous cycle’s evidence in front of the reviewer. The human approval load is not four hundred an hour. It is the ceiling review plus the exceptions, which is the fatigue budget spent where it buys safety. The machine load scales the same way: four hundred Missions an hour is also four hundred freshness checks, and the Status List answers them in one fetch. The records have their own bill: four hundred Missions an hour is also four hundred evidence trails, so the ceiling review sets a retention class beside the authority, with completed Missions’ evidence aggregated or aged out on a stated horizon and the minimization rules deciding what each trail carried in the first place.

And the failure mode is named, because a standing charter can decay into exactly what this handbook exists to retire. The tells are checkable: renewals that never narrow, ceilings that only grow, exception approvals trending toward zero because the guard was quietly widened, and discharge that never fires because nothing is scoped tightly enough to complete. The mechanism that forces narrowing is the renewal default: a ceiling renews at the envelope its evidence shows was used, not at its prior breadth, and anything wider is a new approval, not a rollover. A ceiling whose renewals carry no evidence review is a blank check with a calendar. The machinery makes the standing agent governable. Only the governance cadence makes it governed.

The accountable principal has a lifecycle too, and it arrives from the identity provider rather than being assumed. Authority that outlives its approver is one of the oldest failures in the stack, and this layer must not recreate that orphan debt in its own system of record. A leaver event moves the person’s ceilings into a state that admits no new Missions and starts an ownership-transfer clock, running Missions transfer or run out under policy, and a ceiling whose accountable principal no longer exists is a finding, not a curiosity. Signals carry Mission state out to consumers. The same rail carries principal state in.

The rule that makes it safe

The four verbs add three new states to the lifecycle The Mission Is the Missing Abstraction began with. The state diagram now looks like this:

A growing state machine is a liability if every consumer must be upgraded in lockstep to recognize each new state. The Mission lifecycle avoids that with the rule the handbook framing states as one of its two invariants, and which the Reference’s lifecycle-states section records for the issuance profile:

Only active permits reliance. A consumer treats every other value, recognized or not, as non-active.

This is why the new states fail safe. A Resource Server that predates the Status profile has never heard of suspended. When it sees one (in a Status response, in an introspection projection, in a Signals event), it does not need to understand it. It only needs to observe that the value is not active, and refuse. A consumer that predates Expansion treats superseded the same way. The forward-compatibility rule turns “I don’t recognize this state” into “this Mission is not live,” which is precisely the safe interpretation. New lifecycle states therefore extend the system without a flag day.

The one place this “ignore what you don’t recognize” instinct flips is Entry Discharge’s terminal_when, and the difference is worth being precise about. A new state value is safe to ignore because an unrecognized state is treated as non-active. Ignoring it fails closed. But terminal_when is a member, not a state, and it is mandatory to understand. It is essential narrowing a consumer cannot infer from the rest of the entry, so ignoring it would let a discharged entry keep being narrowed, projected, or enforced, failing open. A consumer that does not recognize terminal_when therefore MUST fail closed for that entry. It MUST NOT narrow, delegate, audience-project, or rely on it. Unknown state value, treat as non-active. Unknown terminal_when, refuse the entry. Both resolve toward less authority, by opposite handling.

The same instinct runs through Status, the Status List, Signals, Expansion, and Containment: uncertainty resolves toward less authority. That is the through-line. Entry Discharge keeps it for an unrecognized terminal_when but not for the event itself, because a discharge the Authorization Server has not yet committed leaves the entry live, as the complete section prices. The Mission Is the Missing Abstraction made revocation possession-independent. This part makes the current state itself a first-class surface (observable by pull and push, changeable by authorized parties, growable only through fresh approval, and shrinkable safely as work finishes) without ever giving a consumer a way to read uncertain state as permission.

Where this sits in the handbook

Lifecycle and change is the layer that keeps the Mission true over time. It does not enforce actions. That is Mission-Bound Runtime Enforcement, which consumes the state these profiles expose. Every PDP decision takes current Mission state and the current Effective Authority Set as its own inputs, beside the authority the credential carries, and Status is how the PDP learns them promptly, with Signals accelerating and Entry Discharge and Containment narrowing what there is to learn. It does not handle fan-out. Mission-Bound Authority covers Child Missions and the cascaded state that Status and Signals forward-reference but do not define. And it does not record the transitions for audit. The Agent Runtime and Audit makes every lifecycle change tamper-evident.

The approval event of The Mission Is the Missing Abstraction and the approval-time integrity of From a Request to an Approved Mission establish what was approved. This part keeps that approval honest as the task runs. A Mission that is revoked stops being relied on, a Mission that grows does so under a fresh approval, and a Mission whose work is done retires its own authority. Observe, revoke, grow, complete. Four verbs that turn a one-time approval into a governed lifecycle.