Agent Passport System

signal@aeoess.com https://agent-passport.org

Security Individual Submission AI agent identity delegation capability attenuation governance Ed25519 signed receipts This document specifies the Agent Passport System (APS), a protocol for representing and evaluating authority exercised by AI agents. APS separates agent identity, represented principal, delegated authority, policy approval, admission to dispatch, observed results, and external effects. It defines cryptographic identity and principal records, monotonic delegation, revocation and authority-lifecycle semantics, deterministic action and decision references, signed governed-action records, verifier outcomes, evidence resolution, profiles, and protocol bindings. APS defines how an enforcement boundary rechecks current authority before admitting an action to dispatch, and how a verifier distinguishes what a signed record establishes from claims that remain unresolved or external to the protocol. Requirements are split into APS Core, which every conforming implementation carries, and Candidate features, which an implementation opts into by naming them in its claim, and most of the lifecycle and decision-to-effect material in this document is Candidate rather than Core. Candidate features specify additional lifecycle and decision-to-effect behavior without making those features requirements of APS Core conformance. Implementation and conformance sections identify which requirements have exact conformance-vector coverage and which are implemented by the reference implementations. APS does not treat a valid signature, receipt, or delegation chain as proof of external truth or of the absence of an out-of-band execution path.

Introduction This document specifies the Agent Passport System (APS), a protocol for identifying AI agents, narrowing delegated authority at each transfer point, deciding and admitting individual actions at an enforcement boundary, and recording signed evidence of what was decided and what was observed. APS defines an authority and verification model that keeps identity, authority, approval, admission, execution and external effect apart. It defines Ed25519 agent passports and separately signed principal bindings. It defines delegation chains that a verifier rejects when authority widens across scope, spend, depth, time, reputation, values, or reversibility. It defines the lifecycle states an authority artifact can hold and the verdicts a verifier may report about them. It defines deterministic action and decision references, a common envelope for the signed records of a governed action, and bindings for Model Context Protocol tool calls and imported OAuth identity-assertion authorization grants. A verification result keeps cryptographic integrity, signer authority, referenced-artifact resolution, policy semantics, and external truth on separate axes. Sections labelled Candidate are specified in this document rather than against a prior published rule. Their status blocks name related fixture families, and is the sole authority for which requirements an exact vector exercises. An Implementation Status section states the coverage of the available open-source implementations. APS fills this gap by providing (1) Ed25519 agent passports and separately signed principal bindings, (2) scoped delegation chains where authority narrows monotonically across seven constraint dimensions, (3) revocation that invalidates every chain depending on a revoked delegation, with revocation records, where produced, and optional cascade evidence carried as evidence of processing rather than as the cause of that invalidity, (4) a three-record policy chain binding intent, decision, and observed result, (5) a common signed-receipt envelope for those records, (6) a componentwise composition rule for institutional governance structures specified in companion work, and (7) an enforcement-gateway model that can serve as an external reference monitor. Agentic work raises several distinct attribution questions: under whose authority an action was taken, what sources contributed to a deliverable, on whose behalf the agent acted, and who receives the value the work creates. This document specifies the authority core and the signed receipt layer through which principal resolution is recorded and other attribution axes may be referenced; it does not define contribution-attribution or beneficiary-attribution models. The protocol's formal invariants and design rationale are published in the informative references. At the time of writing no IETF working group is chartered for AI agent identity or agentic authorization: WIMSE is chartered for workload identity, where a workload is a running instance of software executing for a specific purpose , and carries one agent-specific document , the proposed DAWN charter places identity management of AI agents, tools and skills out of scope , and the proposed agentproto charter commits its reference architecture to reusing existing identity, authentication and authorization building blocks rather than defining new ones . This individual submission specifies APS and identifies current implementation coverage and deviations in Appendix A. Its requirement keywords constrain implementations claiming conformance to this revision.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Authority and Verification Model This section names the parties this document talks about, the distinctions the rest of the document enforces, and what a verifier is allowed to say. It is placed before any wire format because every later section is written against it. Two labels appear throughout. Core marks a requirement of APS Core conformance. It is mandatory for an implementation claiming the conformance class to which the requirement applies, and maps each identifier area to its classes. Candidate marks an opt-in feature. A Candidate requirement is normative for an implementation that claims the feature and is not a requirement of APS Core conformance. A conformance claim names the classes it claims and the Candidate features it claims, in the form "APS Core in the named classes, plus named features", as states. A Candidate label is not a claim that any deployment uses the rule. Normative requirements introduced outside the closed core carry stable semantic identifiers of the form APS-AREA-NAME, listed with each subsection and mapped in . An identifier never changes because a section moves and is never reused.

Actors Nine roles appear in this document. A deployment can put several of them in one component or split one across several.

Principal

The person, office, or organization on whose behalf authority exists. A principal binding record names the principal an agent acts for, signed by the principal and scoped to named audiences and authority profiles rather than asserted for every purpose ().

Authority issuer

The party that signs a delegation, creating or narrowing authority for the party below it. In a chain each issuer holds the parent grant (). The issuer and the principal can be different parties.

Acting agent

The agent that declares an intended action and, once admitted, executes it. It is identified by an Agent Passport () and named as subject_agent on the records of a governed action ().

Delegate

An agent holding authority received from another agent rather than from the principal directly. What a delegate can hold is bounded facet by facet by the grant above it ().

Policy decision point

The component that evaluates one action against the selected authority chain and the applicable policy and returns permit, deny, or narrow. In this document it is the deterministic gate plus the advisory evaluation path (). It may be a separate component from the enforcement boundary.

Enforcement boundary

The component that issues the policy-decision record () and the action-result record (), consumes the approval at the next authorization boundary, applies the state current at that moment, and completes any spend reservation (). Only the enforcement boundary admits an action to dispatch. A policy decision point may compute the decision, and the boundary is the issuer of the record that carries it. Approval consumption, reservation, dispatch and the external effect are not one atomic transaction in this revision, and records what that leaves open.

Target system

The system the action operates on. It appears in the action input object hashed into action_ref (). This document specifies no interface to it and no obligation on it.

Evidence issuer

A party outside the delegation chain that signs an artifact a verifier may resolve, for example an attesting service or a counterparty system. Keys for such signers resolve under a model separate from an agent's own key (), and what resolution reports is its own axis ().

Verifier

Any party that reads these artifacts and reports what it can establish from them. Its obligations are stated for chains in and for records in .

This subsection defines terms and states no requirement, so it carries no status block. It does not establish that any deployment has all nine roles, does not require any two of them to be distinct components, and does not say which party operates which.

Seven Distinctions Each distinction below is enforced by the section named with it. This subsection adds no requirement of its own. It exists because the seven collapses it names are the ones that make a verifier report more than it established. Identity is not authority. An Agent Passport is a self-signed record, and checking its signature establishes that the holder controlled the key at signing time. What the agent may do comes from somewhere else: a delegation chain whose facets narrow at every hop () and a principal binding scoped to named audiences and authority profiles (). A passport that resolves and a signature that checks leave the authority question untouched. This does not establish that an agent holding no APS chain has no authority under some other system, only that this document gives it none. Cryptographic validity is not signer authority. A valid signature establishes that an authorized signing key attested to the canonical record body. It does not establish that an external event occurred or that a signed claim is true (). Whether the signer held authority is resolved separately, at the artifact's own issuance time, and for parties outside the chain under a separate model (). A record can be internally consistent and correctly signed while the decision it names is not the decision a verifier is holding. The receipt-decision-relation family makes that gap executable as a rejection with a named reason rather than leaving it to inference. Authority is not approval. Authority is standing held over an interval. An approval is one decision about one action, bound to the action_ref it approves, single use, and time bounded (). A valid chain does not carry an approval and an approval does not extend a chain. This does not establish an ordering between the two: a chain can be valid with no approval ever issued, and an approval can be stale while the chain under it still stands. Approval is not admission. A permit or narrow policy-decision record exists from the moment the boundary issues it and admits nothing until the next authorization boundary consumes it. At that boundary the enforcement boundary rechecks temporal validity and revocation state, consumes the approval identity atomically, and completes any spend reservation (). An approval that has expired, has already been consumed, or fails the recheck admits nothing. Whether a given approval was in fact consumed is boundary state keyed by its identity and is not content of any record, so a verifier without access to that state reports the approval-state axis as not established (). Admission is not execution. Admission is the boundary's act. Execution is what the target system then does. They are separate states, and in this revision admission is enforcement-boundary state with no durable record, per and . The action-result record carries its own issued_at, which can fall after the consumed decision's validity window closes, because execution and observation take time (). A decision record held on its own says nothing about whether the action ran. The accountability-record family carries the boundary decision and the executed flag as independent fields and keeps a vector in which the decision is deny and the action executed anyway. Observed outcome is not external effect. An action-result record attests to what the enforcement boundary observed after dispatch, and external occurrence or settlement requires separately resolved evidence (). A status of unknown is a real outcome rather than a missing one. Agreement between an APS record and a record produced outside the deployment is evidence of correlation between records, not of the authenticity, authority, or integrity of either record (). Evidence of a claim is not its truth. An evidence reference is a commitment, not evidence availability (). Resolving it establishes that the bytes the artifact's own rules select hash to the committed digest. Whether the artifact's content is true is outside what resolution reports, and a verifier does not report a record fully valid for a claim that depends on evidence it never resolved. The read-fidelity-receipt family is the plainest case in the corpus: the record commits to sampled readback at a stated n, carries no pass threshold, and leaves the consumer to judge k of n. What this subsection does not establish. It states no requirement, adds nothing to the sections it points at, and does not establish that the seven are exhaustive. It is a reading guide over text that is normative elsewhere.

Admissibility A record defined in this document describes what a verifier may conclude from the artifacts it holds. It does not describe what happened. Two verifiers holding different artifacts about one action can reach different conclusions without either being wrong, and neither conclusion is a statement about the world. An artifact verdict is what a verifier says about one authority artifact at one moment. The set is closed and has six members.

valid

The verifier establishes that the artifact currently confers the authority claimed.

invalid

The verifier establishes that it does not, or no longer does. Revoked, expired, exhausted, void from issuance, and dependent on an invalid ancestor all land here, separated by reason code.

not established

The verifier cannot reach a conclusion. This is ignorance. It is never a finding about the world and never the negation of the claim.

not yet effective

The verifier establishes that the artifact was validly issued and that an enabling condition has not occurred yet. The remedy is to wait, not to find a better source. The activation conditions of are the only route to this verdict in this revision. A wait carried by the time facet instead returns invalid with a not-yet-valid reason from , and that subsection records the two verdicts side by side rather than resolving them.

suspended

Use is paused by one or more live causes, each separately releasable.

restricted

Authority continues in reduced form under a live constraint that does not pause it.

A verifier MUST report a verdict from that set and MUST NOT report a verdict outside it. Every verdict MUST carry a reason code. Two findings that share a verdict name and differ in substance MUST carry different reason codes, because a result that reports only verdict names cannot be read. A verifier MUST NOT report not established for a conclusion it has reached. Where the conclusion is negative, the shape of the negative decides the output. An enabling condition established not to have occurred yet is the verdict not yet effective, reason code ENABLING_CONDITION_NOT_YET_OCCURRED. A composition rule established not to be satisfied denies the action at the boundary, reason code COMPOSITION_NOT_SATISFIED. A pinned referent established to have changed denies the action at the boundary, reason code PINNED_REFERENT_MISMATCH. Neither of the last two makes any artifact invalid. Unexecutable is not a seventh verdict. An artifact whose target, executor, or named capability no longer exists keeps its verdict and fails at execution, with the unresolvable referent recorded. The rest of this subsection is informative. What an enforcement point decides about one action at one authorization boundary is a boundary outcome, a different subject with its own three values: authorized, denied with a stated reason, or not established. No conformance family in the Agent Authority Conformance suite decides an outcome by these names, so this document states them as vocabulary and places no requirement on them. A third axis is the chain-verification result of , whose closed set is valid, invalid, indeterminate and unsupported. It is a finding about one selected root-to-leaf chain rather than about one artifact or one action, and the three axes are never mixed. A chain result of valid supports the artifact verdict valid for the artifacts on that chain and supports no boundary outcome on its own. A chain result of invalid supports the artifact verdict invalid. A chain result of indeterminate is carried as indeterminate on its own axis. Where a verifier also reports an artifact verdict for the artifacts on such a chain, that verdict is not established, naming the source limb where no accepted answer was available and the freshness limb where the answer was past its declared bound. Neither value is collapsed into valid, and the chain result is not replaced by the artifact verdict. A chain result of unsupported is carried as unsupported and is neither erased nor folded into any other value on any axis. Also informative: a not established verdict is unreadable unless it says which limb was missing. Three limbs are proposed. Source means no source the authority model accepts produced a usable answer, or the answer came from a source the model does not accept for that state, or two accepted sources are in unresolved conflict. Freshness means an answer existed but was older than the bound the model declares for its source. Coverage means the claim does not state that it covers what the verdict needed. The verdict set of this subsection places no requirement on the limbs. The Candidate features that name limbs do place one on an implementation claiming them, at , and . No conformance family names a limb on a verdict. The reference SDK modules enforce the rule at construction, which is an implementation choice and not a conformance obligation. What this subsection does not establish. The verdict set says what a verifier may report, not what is true of the authority. A valid verdict means the verifier establishes that the artifact currently confers the authority claimed, against the checks that verifier ran, and which checks those were is a separate question this subsection does not answer. Two of the six members, suspended and not yet effective, are not decided by any family cited in this section. The distinction between a finding that something is false and a finding that it is not established is carried by the verdict name and by nothing else here. Requirements. APS-EVID-VERDICT-SET-CLOSED, a verifier reports a verdict from the closed six-member set and reports none outside it, exercised. APS-EVID-REASON-CODE-REQUIRED, every verdict carries a reason code and two findings sharing a verdict name carry different codes, specified, not exercised. APS-EVID-NOT-ESTABLISHED, a verifier does not report not established for a conclusion it has reached, and an established negative takes the shape its own subject gives it, specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-evidence-and-record, whose runners fail any vector returning a verdict outside the closed set, across its 12 cases. revocation-resolution-forward-compat, 14 cases. Exercised requirements: APS-EVID-VERDICT-SET-CLOSED. Implemented requirements: APS-EVID-VERDICT-SET-CLOSED, APS-EVID-REASON-CODE-REQUIRED, APS-EVID-NOT-ESTABLISHED. Related implementation surfaces: lifecycle-state module in agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental and opt-in.

Evidence Linkage and correlation each establish one narrow thing. A prev reference cryptographically links one record body to a claimed predecessor. It does not establish wall-clock ordering, completeness, or the absence of omitted records without an external log or sequencing mechanism (). A matching external action reference is evidence of correlation between records, not of the authenticity, authority, or integrity of either record, and correlation strength is bounded by the external ecosystem's own field discipline (). An action reference is a correlation key rather than an integrity seal, and tamper evidence against a record's writer comes from a signature over the record or from an independently held copy. Later findings do not rewrite earlier records. A record of a decision states what its issuer decided on the record available at that instant. A verifier MUST NOT change what such a record states because of anything learned afterwards, including a finding that an ancestor of the chain was never validly issued. Whether the authority stands now is a separate question with its own answer, reported as its own finding. A digest mismatch has two subjects and two results. Where a record's bytes do not match the digest under which it was recorded, the presented bytes do not establish the evidence claim, and a verifier MUST NOT read their content as a finding. The containing record's required-evidence axis is invalid, because the commitment that record carries mismatched, as states. Evidence strength is a verifier appraisal. This document defines no assurance level, no strength score, and no threshold at which evidence becomes sufficient. The read-fidelity-receipt family is built that way on purpose: the record carries the sampled result and no pass threshold, and the consumer judges it. An evidence attestor is whoever produced or signed a piece of evidence, and in what role. A boundary attesting an execution makes a different claim from an issuer signing a grant, and the attestor's key has its own lifecycle, resolved outside the record (). In the accountability-record family a record carries the signer's identifier and not a key, and the signature says nothing until a resolver binds that identifier to a key. Three further requirements on what a verdict record carries are proposed in the authority lifecycle work and are stated here as informative prose, because no conformance family exercises any of them.

• Verdict coverage. Where the authority model publishes a class list of authority-changing events, a verdict would record, for each class on that list, whether it was checked and against which source. Where the model publishes no such list, the verdict would record that no event-class coverage was claimed. Tested by nothing.
• Chain validity against relying party knowledge. Whether a chain is currently valid and whether a particular party had notice of a change are separate findings, and a verdict record would carry a notice finding with its own timestamp or record that it has none. Tested by nothing.
• Declared scope against the enforcing boundary. A declared scope is only as effective as the boundary that enforces it. A verifier that cannot establish that the enforcement boundary implements a grant's declared scope would not report the narrower scope as established, because documented scope and reachable scope are separate facts needing separate evidence. Tested by nothing. The accountability-record family records the matching limitation on itself as a non-goal: it does not check that an action's scope is covered by the delegation it names.

What this subsection does not establish. It does not establish that available evidence is complete, and showing that individual records are authentic is weaker than establishing that every relevant event was observed. It does not establish that an attestor's claim is true, only which party made it and under which key. It places no requirement on the three proposed carriage rules above, and it does not establish that a record's silence on a claim is a denial of that claim. Requirements. APS-EVID-NO-RETROACTIVE-REWRITE, a verifier does not change what a decision record states because of anything learned afterwards, exercised by lifecycle-evidence-and-record LC-G-006-b, LC-G-006-c, LC-G-006-d and LC-G-006-e. APS-EVID-DIGEST-MISMATCH-NOT-ESTABLISHED, bytes that do not match the digest under which they were recorded do not establish the evidence claim and their content is not read as a finding, while the containing record's required-evidence axis is invalid per , exercised by lifecycle-evidence-and-record LC-G-006-f. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-evidence-and-record, accountability-record, read-fidelity-receipt, receipt-decision-relation. Exercised requirements: APS-EVID-NO-RETROACTIVE-REWRITE, APS-EVID-DIGEST-MISMATCH-NOT-ESTABLISHED. Implemented requirements: none. Related implementation surfaces: lifecycle-state module in agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental and opt-in, for the verdict vocabulary these findings are reported in. No released package implements the later-finding rule as a check.

The Mediation Assumption Everything this document specifies rests on one assumption about the deployment around it. APS establishes that a governed path was valid. It does not establish that no ambient credential reached the target system outside that path. The assumption is load bearing and it is not self-checking. Where the target system accepts a credential that never passes the enforcement boundary, the records defined here describe the governed path and are silent about the rest. Silence is not a denial. A verifier MUST NOT read the absence of a record of an ungoverned path as evidence that no ungoverned path was used. The accountability-record family holds the format to that: the boundary decision and the executed flag are independent fields, a record in which the decision is deny and the action executed anyway is a well-formed record of a boundary violation, and the family states that absence of a claim in the record is not a denial of that claim. An observation scope is itself a finding with its own limits. Where a verifier has watched a named scope and seen no alternate use, it has established something about that scope and nothing about paths outside it. One observed bypass settles the question. The absence of an observed bypass leaves it not established rather than settled negative. The corresponding deployment obligations are in the security considerations, and the reference architecture for a boundary that can carry them is informative. What this subsection does not establish. It does not establish that the target system is reachable only through the boundary. It does not establish that a credential issued outside APS was unused. It does not establish that any observation scope covered every path, and it does not turn an unobserved path into an absent one. Requirement. APS-ENF-NO-ABSENCE-INFERENCE, a verifier does not read the absence of a record of an ungoverned path as evidence that no ungoverned path was used, exercised by accountability-record vector 9, positive-deny-executed, a well-formed record in which the boundary decision is deny and the executed flag is true. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: accountability-record, 12 vectors. Exercised requirements: APS-ENF-NO-ABSENCE-INFERENCE. Implemented requirements: none. Related implementation surfaces: no released package.

Transition Contract This subsection is informative. It is the spine the rest of this document describes. Each row names one transition in the life of an authority and separates three questions about it: where its semantics are specified, what a verifier can establish about it in this revision, and which durable artifact it leaves behind. The three answers differ for several rows, which is why they are three columns rather than one. The table is the set of protocol-stage and major lifecycle transitions selected for this revision. It is not exhaustive. Three rows are the open transition and evidence gaps this revision carries, the principal-to-authority association, admission to dispatch, and dispatch attempted, and each is carried in rather than left silent. Other rows record no dedicated durable artifact without being open questions: expiry leaves none because the bound is inside the signed record, and key compromise, approval withdrawal before consumption and renunciation by the agent have no transition of their own in this revision. Transitions, where each is specified, what a verifier can establish now, and the durable artifact each leaves

Transition	Specified in	What a verifier can establish now	Durable artifact
Principal relationship		the binding exists and verifies	PrincipalBindingV1
Principal relationship ended		the revocation verifies	signed principal-binding-revocation record
Principal-to-authority association	no section of this revision, recorded at	not established in this revision	none
Root authority basis accepted	,	that the verifier's own trust policy accepts the root, and not which principal it represents	root delegation plus trust policy, or an importing profile's evidence
Activation		valid, not yet effective, or not established	condition and attestation records, in the proposed: namespace
Delegation	,	the child is no wider than the parent under every component order	AuthorityDelegationV1
Revocation	, with as one record format	every chain containing the revoked delegation is invalid once the verifier establishes the revocation	revocation record, status observation
Suspension and release		suspended or restricted, naming the causes that remain	suspension and release records
Restriction imposed or released	, and informatively	restricted, or a denial at the boundary, with the chain unchanged	none in this revision
Pinned-referent mismatch		a denial under a mismatch reason, or continuity not established	none in this revision
Purpose exhaustion		exhausted, which is an ending of the expiry kind	an exhaustion record, which MAY be recorded
Expiry		authority ceased at its signed bound	none, the bound is in the signed record
Key rotation	,	the key authorized at the artifact's issued_at, or an ambiguous signing instant	published key material with windows
Key compromise	no dedicated transition, see and	nothing of its own	none
Approval withdrawal before consumption	no dedicated transition, named at	nothing of its own, and no record defines it	none
Renunciation by the agent	no dedicated transition, see	nothing of its own	none
Succession and reauthorization		new authority exists and the predecessor tree is neither revived nor inherited	new root or delegation records
Status source report		knowledge inside the source's declared coverage	status observation with time and coverage
Intent		the declaration verifies, and nothing about authority	action-intent receipt
Decision		an approval exists, or a denial is recorded	policy-decision receipt issued by the enforcement boundary
Admission to dispatch	,	the approval-state axis is not established without boundary state	none, open in
Dispatch attempted		nothing until a result	none
Result observed		succeeded, failed or unknown, as the boundary observed it	action-result receipt
Settlement or cancellation		reserved moved to committed, or released	boundary ledger state, settlement evidence where a profile requires it
External effect established	,	established only for the claim the resolved evidence supports	separately resolved evidence
Compensation		a new action chain that refers to the prior action	a new intent, decision and result

Each row is stated in full below. The closing sentence of each entry is what the establishing section does not establish.

Principal relationship

The principal signs and the agent is the subject. The authority needed is the principal's own signing authority. What changes is that a binding exists. A failure confers no authority. A binding is not a grant, and the binding alone does not establish that the agent holds any authority for that principal.

Principal relationship ended

A principal-binding revocation under is signed by the key its verification_method names. The authority needed is that key's signing authority over the binding, which the reference implementation constrains to the principal's own identifier. What changes is that the binding is revoked. The agent's key and unrelated delegations are not revoked by it, and an enforcement profile defines which authority records depended on that binding. The artifact is the signed principal-binding-revocation record. Where the revocation does not verify, the binding stands and nothing about the agent's other authority is established either way.

Principal-to-authority association

A verifier associates the principal axis with the accepted authority lineage, using the applicable authority source and the principal evidence, under whatever standing the applicable profile or trust policy requires. This revision defines no dedicated artifact for it. The association is profile and trust-policy dependent over the binding, the accepted root basis and the authority-state material. Where it cannot be made, the association is not established, and it is not inferred from agent identity or from root selection alone. carries what this document requires until the arrow is settled, and states the requirement there in the keyword form this subsection does not use. No section of this revision establishes the arrow.

Root authority basis accepted

An issuer acts and the verifier's trust policy decides. The basis is one of three forms: an APS root delegation with a null parent, imported external authority under the importing profile's missing-facet basis and audience check, or a trust anchor the verifier accepts. What changes is that a root is selected for this action. A failure is invalid where the failure is established, unsupported for a reference to a non-delegation authority basis, and indeterminate otherwise. It is never valid. Acceptance does not establish which principal the authority represents.

Activation

Either time acts, for a date condition, or an attestor with a role the condition accepts acts, for a recorded-event condition. Already issued authority becomes exercisable. The verdict is valid, not yet effective, or not established, and an unmet condition does not make the grant invalid. The records are the condition and attestation records of , which stay in the proposed: namespace. The establishing subsection does not settle which clock governs an instant comparison, and a boundary that does not claim the feature does not apply the gate at all.

Delegation

An issuer holding a valid parent acts. The issuer equals the parent's subject, the parent is valid at issuance, depth remains, and the child is no wider than the parent under every component order. What changes is that a new leaf exists. On failure a conforming issuer refuses to mint. A minted invalid child is rejected by verification, and the sections that establish this arrow do not establish that such a child was never minted.

Revocation

The delegation's issuer acts, holding issuer standing over that delegation. Every chain containing the revoked delegation becomes invalid once the revocation is established, irreversibly. establishes the transition and specifies one format for the record. Evidence is a revocation record, which is a SHOULD in a format the applicable profile defines, and a status observation. On failure, unknown is not active and the chain is indeterminate. The evidence cascade state never feeds the authority result, and neither the presence nor the absence of a revocation record is an input to it.

Suspension and release

A party with standing over a suspension cause acts. Authority is inactive while any cause remains and is active again only when every cause is released. Release creates no new authority. An unreleased cause keeps authority inactive, and an unknown cause state is indeterminate. The establishing section defines no precedence order among causes and does not establish that a release restores the shape authority had before the cause was imposed.

Restriction imposed or released

A party outside the grant chain acts, or a policy the deployment holds tightens. The artifact stays in force and some of what it covers is blocked, which is the verdict restricted, or the action is denied at the boundary. Nothing in the chain changes and no revocation occurs. No record defined here carries the restriction, and , which is informative, states that block and release are not always symmetric.

Pinned-referent mismatch

Nobody acts inside the delegation graph. What the grant pinned and what a verifier observes have come apart. An established mismatch denies the action under a mismatch reason, and a mismatch the verifier cannot establish either way leaves continuity not established with a missing limb named. Neither outcome makes the delegation invalid, and no record defined here carries the observation.

Purpose exhaustion

The enforcement boundary finds, from the evidence it names, that a declared non-time bound was reached. Authority ends, which is an ending of the expiry kind and not a revocation. An exhaustion record MAY be recorded, in the proposed: namespace. It attests what the boundary found and not that the purpose was met in the world, and a verifier with no access to the boundary's ledger reaches no exhaustion verdict for a use_count or budget bound from signed records alone.

Expiry

Time acts and no party does. Authority ceases at its signed temporal bound and no revocation event occurred. Issuance under an expired parent fails at the issuer. The establishing rule does not establish that a replacement grant is owed.

Key rotation

The identifier's controller acts, holding control of the identifier. The acceptable signing-key state changes and delegated authority does not. A signing time relative to a boundary the verifier cannot establish is ambiguous and is never a signature failure. The establishing sections do not establish which evidence fixes the signing instant.

Key compromise

This revision defines no transition for it. The identifier's controller rotates the key under , and a party with standing revokes the records that depended on the compromised key. Neither step reaches artifacts already signed under that key, and states that a model needing that reach has no rule here. records the same gap.

Succession and reauthorization

A currently authorized principal or authority issuer acts, holding current standing to grant. New authority exists and the predecessor tree is neither revived nor inherited. The old chain stays invalid and there is no silent resurrection. The establishing section does not establish what happens while an office is vacant.

Status source report

A status source acts, holding accepted standing to report rather than authority to mutate a grant. Verifier knowledge changes within the source's coverage. Conflicting or uncovered sources leave the state not established. A coverage block does not establish that the declared source set was every source that mattered.

Intent

The acting agent signs as itself and holds no permission to execute. Nothing about authority changes. Intent is not admission and the action-intent receipt does not establish that any decision followed.

Decision

A policy decision point or the boundary evaluates, and the boundary issues the record. A permit or narrow needs a valid selected chain and the applicable policy. A denial is evaluated and recorded regardless. What changes is that an approval exists or a denial is recorded, and spend is reserved at approval. A deny record is terminal and is never consumed. The record does not establish that the approval was consumed.

Admission to dispatch

Only the enforcement boundary acts. The approval must be unexpired and unconsumed, authority must still be valid at this moment, and the reservation must complete. and state those consumption semantics. No durable record of this transition exists in this revision, which is open at , so a verifier without access to boundary state reports the approval-state axis as not established. Evaluation alone never consumes. A refusal before admission leaves the approval unconsumed. Failure after a boundary-local commit but before dispatch is durably established has no portable recovery semantics in this revision.

Dispatch attempted

The enforcement boundary acts under an admission. The effect adapter is handed the exact bound input. Holding the input does not establish that dispatch was attempted, and no evidence exists until a result. Missing result evidence is not evidence that no record exists elsewhere.

Result observed

The enforcement boundary acts under an admission. Reservation or settlement state changes only so far as the observed result and any required settlement evidence justify. The action-result receipt carries succeeded, failed or unknown, and its prev is the consumed decision. Unknown does not establish failure, does not establish absence of effect, does not by itself permit release of a reservation, and does not by itself authorize a retry.

Settlement or cancellation

The enforcement boundary acts under an admission. Release requires trusted evidence that dispatch did not occur, or a pre-dispatch cancellation. Reserved moves to committed, or is released. An unjustified release is a conformance failure. The ledger state is boundary state and a signature over a delegation does not establish the current cumulative total.

External effect established

An evidence issuer acts and verifier policy decides. Separately resolved evidence moves the external-effect axis, and only for the claim that evidence supports. Where it does not resolve, the effect is not established, and it is never inferred from the result record.

Compensation

A party with its own authority for the compensating action acts, under its own chain, decision and admission. A new action chain exists that refers to the prior action, carried by a new intent, decision and result rather than by a rewrite of the original. Where compensation fails the original result stands, and the compensation is not established.

What this subsection does not establish. It does not establish that the transitions listed are every transition an authority passes through, that a deployment performs them in this order, or that a verifier can observe any of them without the artifact or state named. Three transitions leave no artifact a verifier can read in this revision, and naming them here is not a claim that this revision covers them.

Identity Scheme

Agent Passport An APS Agent Passport is a self-signed cryptographic identity record. The version specified here has record_type "aps.agent-passport" and version "2.0". Its wire object contains exactly the following members: passport_id, agent_id, verification_method, public_key_multibase, issued_at, expires_at, nonce, self_asserted, record_type, version, and signature. The self_asserted object contains a required, UTF-8-byte-sorted unique capabilities array and an optional display_name. A principal or owner identifier is not a passport member; the principal relationship is carried by the separate record in . The public key is a multibase base58btc encoding of the multicodec Ed25519 public key prefix 0xed01 followed by the 32-byte public key. issued_at and expires_at use the exact UTC millisecond form YYYY-MM-DDTHH:MM:SS.sssZ, where SS is 00 through 59, and the validity interval is issued_at <= now < expires_at. nonce is 16 bytes encoded as 32 lowercase hexadecimal characters. The passport identifier and signature are computed as follows, where JCS is RFC 8785 over validated I-JSON, UTF8 converts the resulting string to bytes, and || denotes byte concatenation: A valid self-signature establishes possession of the private key corresponding to public_key_multibase and protects the signed fields. It does not establish that verification_method was authorized for agent_id, or that any self-asserted claim is true. A verifier MUST report proof of possession separately from key authority. For an identifier that is not self-certifying, key authority is verified by resolving verification_method at issued_at under the identifier's own method and trust policy.

Agent Identifiers APS is DID-method-agnostic. agent_id and verification_method use the syntax and resolution rules of the selected DID method . New self-certifying passports SHOULD use an existing generative DID method whose identifier commits to the signing key, such as did:key . Rotation of a self-certifying key changes that identifier. Deployments that require one stable agent identifier across key rotation MUST use an update-capable DID method and resolve the verification method at the artifact's signing time, for example by a method-defined versionId or versionTime. A successor statement between two self-certifying identifiers documents a claimed migration; it does not transfer delegations or establish that the identifiers are equivalent. Earlier APS implementations emitted the experimental identifier did:aps:z<base58btc-multicodec-key>. A compatibility verifier MAY read that exact immutable form. It MUST treat the embedded key as the complete identifier state, MUST reject the earlier raw-hex alias, and MUST treat rotation as a new identifier. Conforming new-write paths in this revision do not emit did:aps identifiers.

Principal Binding A passport does not identify the person or organization on whose behalf an agent acts. That relationship is expressed by a PrincipalBindingV1 record with record_type "aps.principal-binding" and version "1.0". The record contains binding_id, agent_id, principal_id, verification_method, audiences, authority_profiles, status_uri, issued_at, expires_at, nonce, and signature. audiences and authority_profiles are non-empty, UTF-8-byte-sorted unique arrays. The principal signs the record with the key named by verification_method. The record is therefore scoped rather than a global assertion that the agent represents the principal for every purpose. binding_id uses the tag "APS-PRINCIPAL-BINDING-ID-V1" and the same construction as passport_id, with binding_id and signature absent. signature uses the tag "APS-PRINCIPAL-BINDING-SIG-V1" and covers the binding with signature absent. Both tags are followed by one zero byte before the JCS bytes. Claim levels are verifier results, not labels selected by the issuer. A principal string found only in a self-signed or legacy passport is self_asserted. A binding whose principal signature and signing-key authority verify is principal_attested. A verifier reports externally_verified_principal only when its own trust policy has also verified the principal identity. A verifier MUST NOT infer a higher level from the presence of a field. Binding revocation is a separate signed record with record_type "aps.principal-binding-revocation", version "1.0", revocation_id, binding_id, principal_id, verification_method, revoked_at, reason_code, nonce, and signature. Its identifier and signature use the tags "APS-PRINCIPAL-BINDING-REVOCATION-ID-V1" and "APS-PRINCIPAL-BINDING-REVOCATION-SIG-V1", respectively. Revoking a principal binding does not revoke the agent's key or unrelated delegations; an enforcement profile defines which authority records depended on that binding.

Key Rotation and Historical Verification An update-capable identifier MAY rotate its signing key. A retired key is eligible only for artifacts whose signing time falls within the key's method-defined validity interval. A resolver MUST select the key version authorized at the artifact's issued_at; selecting the key that is current at verification time is insufficient. The artifact timestamp is an issuer claim. This document does not define a trusted timestamping service. When key retirement makes the result depend on whether an artifact was signed before a boundary, a profile MUST identify an acceptable timestamp, transparency-log, or equivalent evidence source. Without that evidence the key-authority result is indeterminate, even when the artifact signature is cryptographically valid. This requirement extends to any historical key-selection boundary, including a relying party's trust-policy pin used as a key-selection input. Without acceptable evidence that the artifact was signed on one side of such a boundary, the pin result is the ambiguous outcome of . A verifier MUST report that indeterminate result through the ambiguous resolution outcome of , whose outcome name is KEY_AMBIGUOUS, and MUST NOT report it as a key that was not found, as structurally malformed key material, or as a signature failure. An issuer's unverified issued_at claim MUST NOT on its own satisfy the evidence requirement above. This document defines no outcome specific to a signing time that cannot be established. A profile that needs that distinction carries it alongside the ambiguous outcome, not instead of it.

Key Resolution for External and Evidence Signers , and govern an agent's own signing key and its historical resolution. A verifier also encounters signatures from parties outside the delegation chain: evidence issuers, counterparty systems, and attesting services. For these external signers this document specifies a resolution model rather than a registry. An external signer identifier MAY be hash-bound to its subject: the identifier carries a digest of the subject identity (for example, a DID whose method-specific identifier is the SHA-256 of a server identity), and the resolver checks the presented subject against that digest before any key material is trusted. A hash-bound identifier is a binding, not a locator: key material located through the subject's own endpoint is accepted only when the subject hashes to the identifier, which excludes the case in which one tenant's key material is resolved under another tenant's identifier. A hash-bound locator presented without the subject it binds MUST be rejected. Published key material MAY carry per-key validity windows. Key selection is gated on the artifact's own signed issuance time, evaluated against each key's window; a verifier MUST NOT select whichever key is current at verification time. A key set in which a key identifier is duplicated is malformed. The duplication makes the set unusable as a whole rather than key by key, and is reported as the ambiguous outcome. A relying party's trust-policy pin, where it is used as a key-selection input, is evaluated at the artifact's issued_at under the same rule. A verification-time cutoff a deployment applies for its own reasons is reported on its own axis and MUST NOT be folded into the key-selection result. Resolution outcomes preserve failure structure. At minimum a resolver distinguishes: resolved; subject or key not found; ambiguous (including duplicate key identifiers); structurally malformed key material; transport unreachability; and an unsupported identifier scheme. Resolution is fail-closed by default. A deployment MAY adopt a fail-open policy for transport unreachability only; malformed key material that loads but is wrong is not a transient transport condition and MUST fail closed even under such a policy. A resolution outcome degraded by a fail-open policy MUST NOT be treated as a positive verification, consistent with . Each failure outcome carries a stable outcome name. The five failure outcomes above are named KEY_NOT_FOUND, KEY_AMBIGUOUS, KEY_MATERIAL_MALFORMED, KEY_UNREACHABLE and KEY_SCHEME_UNSUPPORTED. The resolved outcome carries no failure name. This document defines no further key-resolution outcome. Outcomes map to verification states as follows. An unsupported identifier scheme is unsupported. Subject or key not found, ambiguous, structurally malformed key material, and transport unreachability are each indeterminate, and a verifier MUST report them under distinct outcome names rather than collapse them into one. Structurally malformed key material MUST NOT be reported as a signature failure, because no signature check ran. The key-authority case of , in which the artifact's signing time relative to a key-validity boundary cannot be established from acceptable evidence, is reported as ambiguous.

Attestation Provenance and Composition Identity claims about an agent arrive with different evidentiary weight, and a protocol that flattens them invites over-trust. APS distinguishes four provenance tiers for attested signals: observed (the receiving infrastructure itself recorded the signal, such as transport characteristics at connection termination); infrastructure-attested (a runtime or sandbox gateway signed a claim about the agent's execution environment); provider-attested (a third-party provider confirmed a claim, such as an account or tenant relationship); and self-declared (the agent asserts the claim, unverified). In the reference implementation an attested signal carries: a signal key; a digest of the signal value rather than the raw value; its provenance tier; a verification status distinguishing cryptographically verified, observed without cryptographic proof, declared and unverified, and verification attempted but failed; a stability class indicating how long the signal remains constant; the attesting party; and issuance and expiry times. A signal's provenance tier and its verification status are independent axes: a provider-attested signal whose signature was never checked remains at declared, and a verifier MUST NOT infer verification from tier. Two attestation record shapes are published with the reference implementation. A runtime attestation is a signed claim by an attesting infrastructure party about the agent's execution environment, bound by challenge-response: it carries a nonce supplied by the requesting issuer and a digest of the subject public key, so that the attestation cannot be replayed for a different request or a different key. A provider attestation is a signed or verifiable confirmation by a third-party provider of a subject relationship, carrying a digest of the subject identifier and the verification method used. This section defines the tier and status terminology that profiles import; it does not define a general attested-signal wire format and imposes no verifier behavior beyond the tier-independence rule above. The record shapes are illustrated by the reference implementation. How a deployment weighs, combines, or scores composed attestations is deployment policy and is not specified by this document.

Delegation and Authority Attenuation

Faceted Authority Attenuation AuthorityDelegationV1 is the signed authority record specified by this revision. It has record_type "aps:authority-delegation:v1", version "1.0", delegation_id, parent_delegation_id, issuer, subject, verification_method, issued_at, nonce, authority, and signature. parent_delegation_id is null only for a root selected by verifier trust policy. authority contains exactly seven required facets: scope, spend, depth, time, reputation, values, and reversibility. A missing facet is invalid rather than an implicit unconstrained value. ", "parent_delegation_id": null, "issuer": "did:example:principal", "subject": "did:example:agent", "verification_method": "did:example:principal#key-1", "issued_at": "2026-07-18T22:00:00.000Z", "nonce": "<32-lowercase-hex>", "authority": { "scope": {"profile":"aps-hierarchical-v1", "grants":["commerce:checkout"]}, "spend": {"mode":"bounded","unit":"iso4217:USD:minor", "per_action":"5000","cumulative":"10000"}, "depth": {"remaining":2}, "time": {"not_before":"2026-07-18T22:00:00.000Z", "not_after":"2026-07-19T22:00:00.000Z"}, "reputation": {"profile":"aps-score-0-100-v1","ceiling":80}, "values": {"profile":"aps-values-identifiers-v1", "required":["F-001","F-003"]}, "reversibility": {"profile":"aps-tci-v1", "ceiling":"compensable"} }, "signature": "<128-lowercase-hex>" } ]]> The spend unit in that example is one deployment's choice. A unit is an opaque string compared by its UTF-8 bytes, as states, and the iso4217:USD:minor form carries no meaning this document defines. The object schema is closed. All timestamps use exact UTC milliseconds with a second value from 00 through 59. nonce is 16 random bytes. delegation_id and signature are computed as follows: A verifier resolves verification_method for issuer at issued_at. A valid self-issued root is not trusted automatically; acceptance of a root is verifier policy.

Component Orders Let child be directly delegated from parent. child is no wider than parent only when every comparison below succeeds. Profiles on a facet MUST match; a profile change is unsupported rather than narrower.

Scope

Scope grants use ASCII colon-separated segments. "*" covers all grants; a wildcard is otherwise permitted only as the terminal segment ":*". An exact grant covers itself. A terminal wildcard p:* covers p and every grant beginning p:. Every child grant MUST be covered by a parent grant. Arrays are UTF-8-byte-sorted, unique, and irredundant.

Spend

Spend is either {"mode":"unbounded"} or a bounded object with unit, per_action, and cumulative. Amounts are canonical unsigned decimal integers from 0 through 9223372036854775807; per_action MUST NOT exceed cumulative. A bounded child under a bounded parent uses the same unit and no greater limit. A bounded child under an unbounded parent is narrower. An unbounded child under a bounded parent is invalid. APS performs no unit conversion.

Depth

remaining is an integer from 0 through 255. A parent with zero remaining cannot issue a child. Otherwise child.remaining MUST be no greater than parent.remaining minus one.

Time

The half-open child interval [not_before, not_after) MUST be contained in the parent interval. A child's not_before MUST NOT predate its issued_at, and a child MUST be issued while the parent is valid. Relative durations are converted to absolute instants before signing and do not appear in the wire record.

Reputation

ceiling is an integer from 0 through 100. A child ceiling MUST NOT exceed its parent. Runtime authorization uses the lesser of the resolved subject score and the signed ceiling. Missing, stale, or profile-incompatible reputation evidence yields indeterminate when that evidence is required.

Values

required is a sorted unique array of profile-defined identifiers. A child MUST contain every parent-required identifier and MAY add identifiers. This comparison preserves requirements; it does not establish that the subject complies with them.

Reversibility

The order from narrowest to widest is tentative, compensable, irreversible. A child ceiling MUST NOT move to the right. An unknown or unresolved action classification is treated as irreversible. This ceiling constrains authority; the realized reversibility of an action is determined by its effects and need not compose across a chain.

These comparisons define a componentwise partial order over the seven-facet vector. Scope narrows by coverage, Values narrows by adding requirements, and every other facet follows its rule above. A valid child is less than or equal to its parent in every component. The fuller formalization appears in and .

Chain Verification A verifier processes a root-to-leaf chain in this order: closed schema and canonical values; delegation_id; historical signing-key resolution and signature; duplicate identifiers; root trust; parent_delegation_id; issuer-to-subject continuity; child issuance time; the seven facet comparisons in ; current validity; and revocation state for every member. A cycle, repeated identifier, broken parent link, or issuer discontinuity invalidates the chain. That order is phase-major over the whole root-to-leaf chain. A verifier applies each listed phase to every member before it applies the next phase. The first phase in which any member fails determines the returned state and failure reason, and within that phase the lowest member index determines which failure is reported. Where two faults fall inside one phase, this document states no order between them and a verifier MAY report either. Inside the closed schema and canonical values phase, recognition of record_type and version precedes evaluation against the v1 schema, and a record whose record_type or version is not recognized is unsupported and is not additionally judged against that schema. A root member's null parent_delegation_id is checked in the parent_delegation_id phase and not earlier. Verification returns one of valid, invalid, indeterminate, or unsupported with a failure reason the verifier reports. This document defines no failure-code vocabulary for chain verification. An unavailable or stale revocation result is indeterminate. An unsupported facet profile is unsupported. Cryptographic or attenuation failure is invalid. A root the verifier's trust policy does not accept is invalid, with a root-trust reason at the root's index, and a trust policy that is unavailable or cannot decide is indeterminate under the same rule as an unavailable revocation result. A caller MUST NOT collapse indeterminate or unsupported into valid. A revocation-resolution outcome that a verifier does not recognize MUST NOT be treated as active. The revocation state is not established, and the chain result is indeterminate under the same rule as an unavailable or stale result. This applies to any answer outside the set a verifier recognizes, including a value a later revision of this document may define, and to a resolver that does not answer at all. Two phase-scope rules follow from the phases above. In the closed schema and canonical values phase, a timestamp MUST carry a second value from 00 through 59. A verifier MUST reject the second value 60 wherever it appears, and MUST NOT consult a leap-second table. This is narrower than , which admits the second value 60 at the end of a month in which a leap second occurs. In the child issuance time phase, the rule that a record's not_before MUST NOT predate its issued_at applies only to a member whose parent_delegation_id is not null. A root MAY take effect before its own issued_at, and a verifier MUST NOT report a schema or attenuation failure on that basis alone. Each action selects one root-to-leaf authority chain. A verifier MUST NOT union scopes or budgets from multiple chains. Cross-principal composition requires a separate profile.

Cumulative Spend Across a Delegation Subtree The signed cumulative value is a ceiling for the entire delegation subtree, not an entitlement reserved for each child. Before an action with amount q is dispatched, an enforcement boundary performs one atomic transaction over every bounded delegation in the selected root-to-leaf chain. It verifies the common unit and each per_action limit, verifies committed plus reserved plus q is no greater than each cumulative limit, and reserves q against every bounded ancestor or against none. The reservation is keyed by action_ref. A request whose footprint matches an unsettled and uncancelled reservation is an idempotent retry. A request under the same action_ref whose unit, amount or bounded ancestor set differs is conflicting reuse and MUST be rejected. states the same rule in full. Successful settlement moves every ancestor counter atomically from reserved to committed. Cancellation releases a reservation only before dispatch or after trusted evidence that dispatch did not occur. This prevents two siblings from each consuming a parent's complete cumulative budget. A distributed deployment needs one linearizable accounting ledger for the authority tree. Without it, live spend status is indeterminate. Signatures establish static limits; they do not establish the current cumulative total.

Revocation and Cascade Any delegation MAY be revoked by its issuer. Revocation is irreversible. The enforcement gateway MUST recheck revocation status at the moment the approval is consumed to admit dispatch, not only at the moment the policy decision is issued. , and use the same phrase for that moment. A revocation takes effect for a verifier at the point that verifier establishes it under the revocation and freshness rules of . From that point the verifier MUST NOT accept as valid any chain that contains the revoked delegation. This holds whether or not any further record exists for a descendant of the revoked delegation, and whether or not that descendant was ever enumerated. A descendant delegation does not remain valid pending descendant-specific cascade evidence. This document does not state that a revocation takes effect for every verifier at the same instant. Until a verifier has established the revocation, its result follows the freshness and staleness rules of . A revoking party MAY additionally produce the cascade evidence described in . That evidence records how a revocation was processed. It is not what makes a descendant chain invalid, and its absence MUST NOT be read as leaving a descendant chain valid. An implementation reports two results, and MUST NOT collapse them into one field. The authority result for a chain is valid, invalid, indeterminate, or unsupported, as specified in . The evidence cascade state for a revocation is complete, incomplete, or indeterminate, as specified in . An evidence cascade state MUST NOT be reported as an authority result.

Revocation Evidence specifies revocation behavior. Behavior alone leaves a verifier dependent on the revoking system's current state. This section specifies the evidence through which revocation history is verifiable from records where a profile defines that evidence. The model separates two questions that MUST NOT collapse into one mutable lookup: whether a delegation is currently valid, answerable from state, and whether and why a revocation occurred, verifiable from signed records. The records defined in this section are evidence about how a revocation was recorded and processed. A verifier MUST NOT treat the presence or the absence of a record defined in this section as an input to the authority result of . A revocation SHOULD be evidenced by a signed revocation record, in a format defined by the applicable profile, carrying at minimum the revoked delegation's identity, the revocation time inside the signed content, a reference to the revoking authority, and a machine-readable reason code with optional free-text detail. This document defines no wire encoding, identifier construction, signature construction, reason-code vocabulary or signer rule for that record. Where no such record is available, current revocation state remains governed by the resolution and freshness rules of . A record derived from a cascade is evidence about a descendant delegation. It carries no authority, it is not a revocation of that descendant, and it MUST NOT change an authority result. Where such a record is produced, it MUST carry a reference to the originating revocation and the cascade transaction identity of that originating revocation. A cascade-derived record is produced only where the originating revocation record exists. That transaction identity is bound to the content of the originating revocation and is shared by every record the cascade produces. This document does not define a wire format for a cascade-derived record and does not state who signs one. A verifier that holds the originating revocation record and a profile for its format establishes why a descendant chain is invalid from that record and the signed chain. It does not need a record naming the descendant, and the absence of one is not a defect in the chain. A verifier that does not hold both the originating revocation record and a profile for its format reports the evidence cascade state of as indeterminate, which does not change the authority result. Cascade completeness (INV-4, ) is a claim about evidence processing. It is not verifiable from individual revocation records, because a partially processed subtree is indistinguishable, record by record, from a completely processed one. A cascade-completion record, where a profile defines one, carries the cascade transaction identity of the originating revocation and states that every descendant in a defined set was processed. A party MUST NOT emit a cascade-completion record unless it can state the basis on which that set was complete when the originating revocation took effect, and what prevented a further descendant from entering that set afterwards. This document does not define such a basis. A party without one reports the evidence cascade state of as incomplete or indeterminate, which does not weaken the verifier obligation in . A verifier MUST NOT read an incomplete record set as a completely processed subtree. An incomplete or indeterminate evidence cascade state does not make any chain valid.

Revocation Record Format states what a revocation record carries at minimum and defines no wire encoding, identifier construction, signature construction, reason-code vocabulary or signer rule for it. This section specifies one format that carries those members. A profile MAY define others. The record type is "aps:authority-revocation:v1" at version "1.0". The schema is closed. The members below are all a record carries, and detail is the only OPTIONAL one. This name is in the aps: namespace rather than the proposed: namespace other features of this revision use, because its semantics are fixed for this record_type and version, its wire shape is specified below, a fixture family exercises it against distinct negative cases, and both reference implementations map to it. The record type is inside the signed content, so the name is part of every preimage in this subsection. Wire compatibility: the released packages emit and verify records under this exact record_type and version, so a record minted by either of them is a record under this subsection. ", "delegation_id": "sha256:<64-lowercase-hex>", "revoker": "did:example:principal", "verification_method": "did:example:principal#key-1", "revoked_at": "2026-03-15T12:00:00.000Z", "reason_code": "issuer-key-compromise", "detail": "Issuer key retired after hardware replacement.", "cascade_transaction_id": "sha256:<64-lowercase-hex>", "nonce": "<32-lowercase-hex>", "signature": "<128-lowercase-hex>" } ]]> delegation_id names the revoked delegation. revoker is that delegation's issuer, and names no other party for a direct revocation, so this format covers issuer revocation and no other. A record whose revoker member differs from the named delegation's issuer is invalid under a revoker-not-issuer reason code, and a conforming issuer does not issue one. Both reference implementations decide such a record invalid under that reason code and both refuse to issue one, which is the behavior records. verification_method names the key that signed. All timestamps use exact UTC milliseconds with a second value from 00 through 59. nonce is 16 random bytes. A record carrying a record_type other than "aps:authority-revocation:v1", or a version other than "1.0", is unsupported rather than invalid. A record under this format MUST carry revoked_at. revoked_at is a member, so the revocation time is inside every preimage below, and the closed schema leaves no member that could carry a revocation time outside the signed content. The three identifiers and the signature are constructed as follows, following the pattern of . Each domain tag is followed by one zero byte. revocation_id is inside the signature preimage, so the identifier is signed rather than carried as a label beside the signature. A verifier MUST recompute cascade_transaction_id and revocation_id from the record's own content before it checks the signature. A verifier resolves verification_method for the revoked delegation's issuer at revoked_at, not for the revoker member the record carries, so no field inside a revocation selects the key that authorizes it. revoked_at is the signing instant for key selection, so the key version that has to be authorized is the one authorized at revoked_at and not the one current at verification time, which is the historical selection rule of . cascade_transaction_id is derived from the record's own originating content rather than chosen by the party that issues it, so a verifier recomputes it instead of accepting the value written there. It is the transaction identity that says every record one cascade produces shares. This section defines the direct revocation only. It defines no cascade-derived record and no cascade-completion record. A revocation evidenced by a record under this format satisfies the SHOULD in . Revocation is irreversible (INV-5, ). A party that records one of these MUST NOT replace a record it already holds for the same delegation_id. A later valid record naming that delegation leaves the earlier one in place. reason_code is a non-empty string. This document defines no vocabulary for its value and no rule relating a value to an authority result. No family named in the status block below varies a reason-code value, so nothing here is a statement about which values an implementation uses. This section does not establish that this is the format requires, and does not establish that a record under this format is an input to the authority result of . The record is evidence in the sense of , and the prohibition stated there applies to it unchanged: neither the presence nor the absence of the record is an input to that result. It does not establish that a cascade was processed, that a subtree was completely processed, or that any descendant chain is invalid, which follows instead from and the signed chain. It does not establish that a recorded record is persistent, and it states nothing about how a party keeps the first-wins property above under concurrent writers. It states nothing about the recheck at the next authorization boundary required by . Requirements. APS-REC-REVOCATION-TIME-SIGNED, a record carries revoked_at, exercised by ARR-04. APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED, a record_type or version other than the ones named is unsupported rather than invalid, exercised by ARR-05. APS-REC-REVOCATION-RECOMPUTE-IDS, a verifier recomputes cascade_transaction_id and revocation_id from the record's own content before checking the signature, exercised by ARR-02 and ARR-06, with ARR-03 covering the signature preimage. APS-REC-REVOCATION-FIRST-WINS, a party does not replace a record it already holds for the same delegation_id, exercised by ARR-07 and ARR-08. APS-REC-REVOCATION-REVOKER-IS-ISSUER, a record whose revoker member differs from the named delegation's issuer is invalid under a revoker-not-issuer reason code and a conforming issuer does not issue one, specified, not exercised: no vector in the family presents a revoker other than the issuer. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: authority-revocation-record, 8 vectors, 6 under record verification and 2 under store first-wins. Both reference runners reported 8 pass, 0 fail, 0 not_supported, asserting the state, the valid flag and the full failure list including message strings: TypeScript against agent-passport-system 7.2.0 from npm, and Python against agent-passport-system 4.2.0 from PyPI. The family is merged into the conformance suite at commit 5829e2ff00d75f49ce21e9d87e756658deb1ef33. This subsection is a Candidate feature because the format is one format under the SHOULD of the previous subsection, and supporting it is not a requirement of APS Core. Exercised requirements: APS-REC-REVOCATION-TIME-SIGNED, APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED, APS-REC-REVOCATION-RECOMPUTE-IDS, APS-REC-REVOCATION-FIRST-WINS. Implemented requirements: APS-REC-REVOCATION-TIME-SIGNED, APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED, APS-REC-REVOCATION-RECOMPUTE-IDS, APS-REC-REVOCATION-FIRST-WINS, APS-REC-REVOCATION-REVOKER-IS-ISSUER. Related implementation surfaces: agent-passport-system 7.2.0 (npm), agent-passport-system 4.2.0 (PyPI).

Core Invariants The protocol specifies eight invariants: INV-1 (Identity Verifiability), INV-2 (Scope Monotonic Narrowing), INV-3 (Spend Limit Narrowing), INV-4 (Cascade Completeness), INV-5 (Revocation Irreversibility), INV-6 (Intent-Receipt Binding), INV-7 (Authority Attribution Completeness), and INV-8 (Signature Integrity). INV-4 is a claim about evidence processing, reported as the evidence cascade state of , and is not an input to the authority result. It is verifiable only from a completion record whose basis leaves undefined. The signed receipt layer in elaborates INV-6. INV-7 requires every governed action to identify an acting agent, an authority path, and a receipt context. It does not concern contribution-attribution or beneficiary-attribution, which are outside the scope of this document as described in . INV-2, INV-3, and INV-8 are enforced at issuance, not only at verification. An issuer minting a child delegation MUST verify the parent delegation's signature and temporal validity before signing the child, and MUST refuse to issue under an expired, not-yet-valid, or revoked parent. Issuance from an expired parent MUST fail at the issuer; it MUST NOT produce a delegation whose invalidity is left for a later verifier to discover. Verification-time checking remains required (), but a conforming issuer does not rely on it as the sole enforcement point: a delegation that was invalid at issuance never becomes valid later.

Policy Chain APS defines a three-record policy chain: an action-intent record in which the agent declares the intended action; a policy-decision record in which the policy engine returns permit, deny, or narrow, with narrow carrying the reduced authority and applied constraints; and an action-result record in which the enforcement boundary records the observed execution result. The policy engine splits into a deterministic gate (scope, signature, revocation, authority path, spend) and an advisory evaluation path (deception, proportionality). The structure and verification of each signed record are specified in . The spend check in the deterministic gate compares amounts only within a declared unit. When the action's declared unit and the governing delegation's declared unit differ, the gate MUST deny; it MUST NOT compare raw numeric amounts across units, and it MUST NOT apply a conversion. When the action does not declare a unit, the amount is evaluated under the delegation's resolved unit (); this is a defined interpretation rule, not a verifier assumption. Deployments handling monetary spend SHOULD require actions to declare their unit, and a profile MAY require the gate to deny when it is undeclared. A unit is an opaque non-empty string. This document defines no grammar for unit values. Two units are the same unit when their UTF-8 byte sequences are equal, and are different units otherwise. An implementation MUST NOT reject a unit for failing a grammar this document does not state, and MUST NOT treat two unequal unit strings as one unit because they appear related. A delegation's spend value is a limit fixed at issuance. A signed delegation is immutable and cannot carry mutable state; live spend is enforcement-boundary state. A cumulative limit applies to the complete delegation subtree, not independently to each descendant. Before dispatch, the boundary MUST atomically reserve the proposed amount against every bounded ancestor in the selected root-to-leaf chain. It MUST dispatch only if the reservation succeeds for all of them. After settlement, the boundary atomically moves the reservation to committed spend for every affected ancestor. This all-or-none operation prevents sibling delegations and concurrent requests from overspending a shared ancestor. Signatures establish the static limits; the accounting ledger establishes the live totals. A reservation is keyed by action_ref. Its footprint is the action_ref, the unit, the amount, and the set of bounded ancestor delegation_id values in the selected chain. Unbounded ancestors do not contribute to that footprint. A request presenting a footprint already reserved and not yet settled or cancelled is a retry of the same reservation, and the boundary MUST NOT reserve a second amount for it. A request under the same action_ref whose unit, amount or bounded ancestor set differs is conflicting reuse, and the boundary MUST reject it. After a reservation is cancelled, a later request carrying the same footprint MUST reserve again.

Action Reference Computation Each governed action is identified by an action_ref under the profile "aps-action-ref-v2". The reference commits to who is acting, what operation is requested, where it will occur, the exact payload, the authority scopes needed, when the intent was issued, and a replay-resistant nonce. The input object has exactly these members: ", "scope_required": ["commerce:read", "commerce:write"], "issued_at": "2026-04-08T12:00:00.000Z", "nonce": "<32 lowercase hexadecimal characters>" } ]]> profile MUST equal "aps-action-ref-v2". agent_id is the acting agent's identifier. action_type is the operation identifier. target is the exact resource, tool, or endpoint against which the action will be dispatched; a profile MUST define its target string construction. payload_ref is the lowercase hexadecimal SHA-256 digest defined below. scope_required is a duplicate-free array of NFC strings sorted by the lexicographic order of their UTF-8 encodings. issued_at is an RFC 3339 UTC timestamp with exactly three fractional digits, a second value from 00 through 59, and the literal "Z" suffix. nonce is 16 random bytes encoded as 32 lowercase hexadecimal characters. All string fields MUST be non-empty except that a profile MAY permit an empty scope_required array. Each scope_required value is a scope string under . This document states no grammar for it beyond what that section states, and an implementation MUST NOT reject a scope value against a pattern this document does not state. Because profile is fixed to "aps-action-ref-v2", the input object cannot name the profile that permits an empty scope_required array. The permission is therefore supplied to the implementation as profile context, alongside the object and outside it, by the caller that holds the applicable profile. An implementation given no such context MUST reject an empty scope_required array. An implementation MUST NOT infer the permission from any member of the object. The payload reference and action reference are computed as: JCS is RFC 8785 and SHA-256 is defined in . The payload is the exact JSON value presented for authorization and dispatch. The input_object includes payload_ref and excludes the payload itself. A verifier MUST reject an object with an unknown or duplicate member, a non-I-JSON value, a non-canonical scope array, an invalid timestamp, or an invalid hexadecimal field. A parser MUST detect duplicate names before conversion to an ordinary map; it MUST NOT accept the last occurrence silently. A number MAY appear in any spelling I-JSON admits. JCS serializes a number to one canonical form, so two admissible spellings of the same value produce the same digest, and an implementation MUST NOT reject a value on the ground that its spelling is not the canonical one. This governs spelling only. A value I-JSON does not admit is rejected as before. A string containing an unpaired UTF-16 surrogate has no UTF-8 encoding and MUST be rejected. An implementation MUST NOT substitute U+FFFD, delete the code unit, or otherwise repair the string. Scope normalization occurs when the intent is created; a verifier accepts only the resulting NFC, sorted, duplicate-free form and does not normalize an untrusted wire object before verification. The enforcement boundary MUST recompute payload_ref from the payload it will dispatch and action_ref from the received input object. It MUST reject either mismatch before policy evaluation. It MUST also reject reuse of nonce by the same agent within the deployment's replay window. The nonce prevents two otherwise identical requests from sharing an approval or receipt identity; it does not replace an enforcement-boundary replay ledger.

Legacy External Correlation Form For correlating APS-governed actions with records produced by systems outside an APS deployment, this document defines a second deterministic reference, the external action reference, identified by the label "action-ref-v1-jcs-sha256": where canonicalize is RFC 8785 , the hash is computed over the UTF-8 encoding of the canonicalized JSON, and input_object is a JSON object with exactly four fields, named in snake_case:

action_type

The action identifier string.

agent_id

The acting agent's identifier string, in the form the correlating ecosystem uses.

scope

A single scope string.

timestamp

An RFC 3339 UTC timestamp at exactly millisecond precision, with three fractional-second digits, a second value from 00 through 59, and the literal "Z" designator (e.g., "2026-04-08T12:00:00.000Z"). The timestamp is hashed as the byte sequence supplied. An implementation MUST reject a timestamp that does not match this shape; it MUST NOT coerce, truncate, extend, or renormalize a non-conforming value.

Field values in the external form are hashed as supplied. The external form applies none of the native form's field transformations: no Unicode normalization and no array sorting, since the scope field is a single string. This form predates aps-action-ref-v2 and remains only for correlation with records that already use it. It omits the target, payload digest, and nonce, and therefore MUST NOT identify an APS policy decision, approval, dispatch, spend reservation, or receipt. An implementation MUST label it "action-ref-v1-jcs-sha256" and MUST NOT present its digest as an action_ref under . A digest produced by any construction other than the one specified in this section MUST NOT carry that label. The external form exists for cross-ecosystem byte parity: independent implementations outside an APS deployment compute this key from their own records, and agreement with the value carried in or derived from an APS receipt correlates the two without prior coordination. The aps-action-ref-v2 form of is the only action identity within the APS policy chain. The two forms differ in field naming, field forms, scope arity, and timestamp precision, and produce unrelated digest values for the same underlying action.

Two-Phase Execution requires revocation to be rechecked at the moment the approval is consumed to admit dispatch, and the action-result record of records the observed outcome after a policy decision is consumed. These requirements place enforcement at two distinct moments; this section names that model. In two-phase execution, the enforcement boundary first evaluates the policy chain and, on a permit or narrow verdict, issues an approval bound to the authority the verdict grants: a first-class consumable artifact, bound to the action_ref it approves, single-use, and carrying a bounded lifetime. The permit or narrow policy-decision record of is that artifact. Its receipt_id is the consumable identity, its action_ref is the binding, and its valid_until is the bounded lifetime. Execution then presents and consumes the approval. At the moment the approval is consumed to admit dispatch, the boundary MUST re-validate what can have changed since issuance, including revocation status and temporal validity, as required by . An approval that has expired, has already been consumed, or fails re-validation MUST NOT admit execution. For actions carrying a spend dimension, the two phases align with reserve-then-settle: the amount is reserved against the boundary-held cumulative total () at approval, and settled at completion. This document specifies the gate model and its obligations; the internal mechanics of an enforcement boundary implementing it are out of scope.

Profile Model This document leaves several constructions to a profile. A profile is a separate document that fixes those constructions for a deployment or for a community of deployments, under a name that records can carry. This document does not register profiles, does not define a profile document format, and does not name any profile other than the facet, action-reference and receipt profile identifiers it already fixes. Two things a profile is not. It is not a policy. Policy decides whether a particular action is allowed under authority that is already established, and is carried in the policy chain. A profile decides how the records are constructed and read before any policy runs. It is also not an extension point for new authority. The dimensions a verifier compares are the ones the delegation section fixes, and a profile supplies the construction inside a dimension rather than adding one.

What a Profile Identifies The requirements in this subsection bind a profile document. They are requirements on what a profile has to say, not runtime checks a verifier performs on a record, so no fixture exists for them. This is the only normative content of , and it is marked as such because the rest of this section reports behavior that fixture families do exercise. A profile MUST identify all of the following.

Identifier.

The exact string that appears in records claiming the profile, in the member that names a profile at the extension point the profile serves.

Version.

A version distinct from the identifier, or a statement that the identifier carries the version. Two profiles that differ in any requirement below MUST NOT share an identifier and version.

Canonicalization.

The canonical byte form of every structure the profile defines, and whether it is the RFC 8785 form this document uses or another form. A profile that defines a signed structure and does not fix its canonical bytes has defined nothing verifiable.

Authority dimensions and their orders.

For each dimension the profile constructs, the set of values, the order relation over them, and which direction of that order is narrowing. A verifier compares a child against its parent under that order, so a profile that states the values and omits the order leaves the comparison undefined.

Target construction.

The target string construction that the action-reference computation of the policy chain section requires a profile to define, including how the string is derived from the resource, tool or endpoint the action will reach, and which differences in that resource produce different strings.

Required decision context.

The members a decision under the profile commits to beyond those the DecisionRefV1 construction of already names, and whether a verifier that cannot resolve one of them reports the decision as not established or proceeds without it.

Evidence types and resolution rules.

Each evidence type the profile accepts, how a verifier resolves it, what a resolved value establishes, and what the verifier reports when resolution fails or returns an answer the profile does not recognize. Where the profile supplies evidence this document requires but does not define, such as the acceptable timestamp or transparency-log evidence at a historical key-selection boundary, the profile MUST state the acceptance rule and not only the record shape.

Freshness policy.

For each answer the profile reads from live state rather than from a signed record, the age past which the answer is no longer usable, and what a verifier reports past that age. An answer with no stated freshness bound is unbounded, and a profile MUST say so explicitly rather than leave it unstated.

Unknown-profile behavior.

What an implementation that does not hold this profile reports when it meets a record naming it. A profile MUST NOT require that such an implementation treat the record as valid.

Admission requirements.

What the next authorization boundary checks again before the action takes effect, and what it consumes or reserves when it admits. A profile that adds a construction which a boundary has to re-evaluate MUST say so, because a construction checked only at issuance is not an admission control.

Semantic preservation.

For each semantic this document defines that the profile touches, which of six values applies to it: preserved exactly, transformed with equivalent semantics, narrowed, omitted and irrelevant to the operation, not representable, or externally resolved. This is the loss model states, and a profile fills it for its own constructions rather than only for external protocols. A profile MUST state the verifier result for a semantic it cannot represent that an operation under the profile requires, and that result MUST NOT be valid.

External protocol mapping.

For each external protocol the profile carries APS concepts over, the concept-by-concept mapping, and, for every concept that does not survive the mapping, whether the result is unsupported or not established. A profile MUST NOT map a concept onto a weaker external construct without recording the loss.

A profile MUST NOT widen authority. A profile defines constructions, and a construction that admits a grant, an action or an effect which the same records would not admit without the profile is a widening. This constraint is on the profile document, in the same way as the requirements above, and this document states no runtime test by which a verifier detects a widening construction. The following is informative. Where an implementation does recognize such a construction, reporting the record unsupported rather than valid is the disposition consistent with the rest of this document. What recognizing a widening construction consists of is not defined here, so this disposition is not stated as a requirement. What this subsection does not establish. It does not establish that any profile exists, that a profile satisfying this list produces interoperability with another profile that also satisfies it, or that a verifier can tell a conforming profile from a widening one by inspecting records. It states what a profile document has to contain and stops there. Requirements. APS-PROF-REQUIRED-CONTENT, a profile identifies every item in the list above. APS-PROF-SEMANTIC-PRESERVATION, a profile states which of the six loss values applies to each APS semantic it touches and states the verifier result for a semantic it cannot represent, which is never valid. APS-PROF-NO-WIDENING, a profile does not widen authority. APS-PROF-UNKNOWN-NOT-VALID, a profile does not require an implementation that does not hold it to treat a record naming it as valid. All four are specified, not exercised, and no fixture exists for a requirement on a profile document. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: none. Implemented requirements: none. Related implementation surfaces: no released package.

Profiles at the Extension Points This subsection is informative. It collects every point at which this document defers a construction to a profile, states what an implementation that does not hold the profile reports there, and names the fixture families that exercise the point. The obligations themselves are stated in the sections listed, not here.

Facet profiles in the delegation record.

The scope, reputation, values and reversibility facets of each carry a profile identifier. The component orders subsection requires the profiles on a facet to match between parent and child, and states that a profile change is unsupported rather than narrower. Chain verification returns unsupported for an unsupported facet profile. Both reference SDKs report this as UNSUPPORTED_PROFILE and return the chain state unsupported rather than invalid. No fixture family changes a facet profile between parent and child. The requirement inventory records this as not exercised, and the behavior described here is read from the SDK sources rather than from a vector.

Cross-principal composition.

The chain verification subsection requires one root-to-leaf chain per action, forbids a verifier from taking the union of scopes or budgets across chains, and leaves cross-principal composition to a separate profile. No such profile exists. Without one, a record set carrying several chains over one leaf supports the grants of whichever single chain is selected and nothing more. Related fixture families: chain-selection-no-union and single-chain-selection, both of which state in their own READMEs that they neither define nor approximate that profile.

Historical key-selection evidence.

The key rotation subsection requires a profile to identify an acceptable timestamp, transparency-log or equivalent evidence source wherever key retirement makes the result depend on which side of a boundary an artifact was signed. Without that evidence the key-authority result is indeterminate even when the signature is cryptographically valid, and it is reported through the ambiguous resolution outcome KEY_AMBIGUOUS rather than as a key that was not found, as malformed key material, or as a signature failure. Related fixture families: key-rotation-historical, which supplies its own test evidence record and records that the record is a fixture stand-in and not a proposal.

Target string construction.

The action-reference computation requires a profile to define how the target string is built. The implementation status appendix records this as a construction the released packages leave to a profile. Exercised indirectly by capability-binding-drift, which shows that a target naming a tool or endpoint does not distinguish two revisions of that tool, and which returns not established rather than invalid when the grant carries no construction that would.

Empty scope_required.

The action-reference object fixes its own profile member, so the object cannot name the profile that permits an empty scope_required array. That permission reaches the implementation as profile context supplied alongside the object by the caller holding the profile. An implementation given no such context rejects an empty array and does not infer the permission from any member of the object. This is the one extension point at which the absence of a profile is a rejection rather than an unsupported result. No family supplies or withholds profile context.

Revocation record format and cascade completion.

The revocation evidence subsection leaves the wire format of the signed revocation record, and of any cascade-completion record, to the applicable profile. A verifier that holds the originating revocation record and a profile for its format establishes why a descendant chain is invalid from the records. A verifier holding one and not the other reports the evidence cascade state as indeterminate, which does not change the authority result. Related fixture families: ancestor-revocation-chain, for the per-member revocation path. The record format itself is exercised by no family in this corpus at this commit.

Undeclared spend unit.

The policy chain section lets a profile require the gate to deny when an action does not declare its unit, and otherwise evaluates the amount under the delegation's resolved unit. No family presents an action and a delegation whose units differ, and none omits the unit.

Receipt envelope and stage result profiles.

A receipt whose envelope profile is not aps-receipt-v1 is unsupported and is not judged against the aps-receipt-v1 schema, which is not its schema. A result object whose profile is not the one its named stage defines is invalid rather than unsupported, because those objects are closed. Both reference SDKs implement the envelope case as UNSUPPORTED_PROFILE returning unsupported. Exercised for the positive envelope profile by the receipts families under cross-stack and by accountability-record. No family presents an unknown envelope profile.

Signatures the profile requires.

The receipt verification subsection () makes the required signature set the issuer signature plus any signature the applicable profile or the verifier's own input requires. Failure or non-resolution of a signature outside that set does not change the record's aggregate state and is reported on its own axis. Related fixture families: receipts-aeoess, in its two-signature vectors.

Imported grants.

The OAuth identity-assertion grant binding states that an external grant carrying no spend semantics cannot be projected into a conforming chain root unless an importing profile supplies an explicit spend basis that verifier policy accepts, and that the projection is otherwise unsupported. No family presents such a projection.

Principal binding revocation.

Revoking a principal binding does not revoke the agent's key or unrelated delegations, and an enforcement profile defines which authority records depended on that binding. No family carries a principal-binding revocation.

Attestation tiers.

The attestation provenance subsection defines the tier and status terminology that profiles import, defines no general attested-signal wire format, and imposes no verifier behavior beyond keeping tier and verification status independent. Exercised in part by instruction-provenance, whose tier mutation is rejected under that document's own tier lock rather than under the independence rule.

Identifier scope.

The privacy considerations recommend that profiles use context-specific agent and principal identifiers where global correlation is unnecessary. Every family reuses stable identifiers across its vectors, so nothing exercises this.

External protocol carriage.

A profile that carries APS concepts over another protocol states the mapping and the losses. Related fixture families: arap-binding, which models one external approval profile against a pinned source, and by the cross-stack families, which carry artifacts produced by other systems.

Across the points above, the pattern this document holds to is that an unknown or unheld profile yields unsupported or not established, and never valid and never a narrower reading. The text states that outcome directly at the facet, receipt-envelope, imported-grant and cascade-evidence points. At the empty scope_required point the outcome is rejection instead, for the reason given above. The nearest exercised evidence for the general pattern is revocation-resolution-forward-compat, which shows both reference SDKs failing closed on a revocation answer they do not recognize rather than reading it as active. That family is about a resolver answer and not about a profile, so it supports the pattern by analogy and does not establish it. What this subsection does not establish. It does not establish that the extension points listed are the complete set for future revisions, that any implementation behaves as described at a point no family covers, or that the SDK behavior read from source at the facet-profile point would survive a vector. Where a point has no family, that is recorded above rather than argued past. This subsection states no requirement of its own and carries no requirement identifier. The obligations are in the sections it names. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: chain-selection-no-union, single-chain-selection, key-rotation-historical, capability-binding-drift, ancestor-revocation-chain, revocation-resolution-forward-compat, instruction-provenance, arap-binding. Implemented requirements: none. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI) for the UNSUPPORTED_PROFILE and KEY_AMBIGUOUS outcomes only. No released package implements a profile document, a profile registry, or profile-context passing.

Governed Action Records APS represents a governed action as three signed records: an agent's intent, the enforcement boundary's policy decision, and, when dispatch occurs, the boundary's observed execution result. All three use the ReceiptV1 envelope. The common envelope permits one verification algorithm while receipt_type and result state the record's stage and bounded semantics.

ReceiptV1 Envelope A ReceiptV1 is a closed JSON object. The example below is an action-intent record and therefore omits the conditional decision_ref and prev members described after the example: ", "receipt_type": "aps:action-intent:v1", "issuer": "did:key:z6Mk...", "subject_agent": "did:key:z6Mk...", "action_ref": "<64 lowercase hexadecimal characters>", "delegation_ref": "sha256:<64 lowercase hexadecimal characters>", "issued_at": "2026-04-08T12:00:00.000Z", "evidence_refs": [], "result": { "profile": "aps-action-intent-result-v1", "status": "declared" }, "signatures": [{ "signer": "did:key:z6Mk...", "key_id": "did:key:z6Mk...#z6Mk...", "alg": "Ed25519", "value": "<128 lowercase hexadecimal characters>" }] } ]]> profile MUST equal "aps-receipt-v1". receipt_type identifies a stage defined in . issuer is the party responsible for that record. subject_agent is the acting agent. action_ref is the aps-action-ref-v2 digest from . delegation_ref identifies the selected AuthorityDelegationV1 leaf, or the authority basis when no delegation exists. decision_ref is REQUIRED for policy-decision and action-result records and MUST be absent from an action-intent record. issued_at uses exact UTC milliseconds with a second value from 00 through 59. prev is REQUIRED for policy-decision and action-result records and MUST be absent from an action-intent record. A member that is not applicable is absent, not null. evidence_refs is a duplicate-free array of objects containing exactly artifact_type and sha256. sha256 is the lowercase hexadecimal SHA-256 digest of the artifact bytes defined by artifact_type. References are sorted first by the UTF-8 bytes of artifact_type and then by the ASCII bytes of sha256. result is the closed, typed object defined by receipt_type. signatures is a non-empty array sorted first by the UTF-8 bytes of signer and then by the UTF-8 bytes of key_id. Each signer and key_id pair occurs at most once, alg MUST equal "Ed25519", and one signature MUST be from issuer.

Receipt Identifiers and Signatures The receipt identifier is computed over the validated envelope with receipt_id and signatures absent: Each signature descriptor contains signer, key_id, and alg. Its value is computed over a form that contains the receipt with signatures absent and the descriptor as a separate signer member: The signature form includes receipt_id. It therefore binds the complete content-addressed body and the signer's own identifier, verification method, and algorithm. A verifier MUST recompute receipt_id before signature verification, resolve each key as authorized for signer at issued_at, and verify every required signature. A valid signature establishes that an authorized signing key attested to the canonical receipt body. It does not establish that an external event occurred or that a signed claim is true. A prev reference cryptographically links one receipt body to a claimed predecessor. It does not establish wall-clock ordering, completeness, or absence of omitted receipts without an external log or sequencing mechanism.

Core Receipt Types This section defines three stages and their receipt_type values: "aps:action-intent:v1", "aps:policy-decision:v1", and "aps:action-result:v1". A verifier selects the rules to apply from the receipt_type the record carries, never from the stage a caller expects. A record whose receipt_type names no stage defined here is unsupported. A verifier MUST NOT report such a record valid, and MUST NOT judge its result object against a stage schema the record does not name. Each result object defined below is closed, so a result whose profile is not the one its named stage defines is invalid. These rules bind the issuer as well as the verifier. A conforming issuer MUST NOT emit a receipt whose receipt_type names a stage defined here and whose content breaks that stage's rules. This is the obligation states for delegations, applied to receipts. It does not require a general-purpose record-building function to apply the stage rules itself, but a record that breaks them is not a conforming receipt whatever produced it. Where a stage below names the enforcement boundary as issuer, the expected boundary identity is a trust input the verifier supplies. A verifier given an expected identity MUST report a record whose issuer differs from it as invalid on that axis. A verifier given none MUST report that axis as not established, which is indeterminate and is never valid. This document states no rule that issuer differs from subject_agent at those stages, and no separate rule that an action-result issuer equals the issuer of the policy decision it follows. The latter follows only where both are checked against the same supplied boundary identity.

Action Intent An action-intent record has receipt_type "aps:action-intent:v1". issuer and subject_agent MUST be the acting agent, prev and decision_ref MUST be absent, and result MUST contain exactly profile "aps-action-intent-result-v1" and status "declared". The agent signature binds the action_ref and selected delegation_ref before policy evaluation. It attests to the declared request; it does not establish that dispatch occurred.

Policy Decision A policy-decision record has receipt_type "aps:policy-decision:v1". issuer is the enforcement boundary, prev is the receipt_id of the action-intent record, and decision_ref is computed as specified in . result is a CoreDecisionOutputV1 object with exactly these members: ", "constraints": [], "valid_until": "2026-04-08T12:00:05.000Z" } ]]> verdict is permit, deny, or narrow. constraints is a duplicate-free array of NFC strings sorted by UTF-8 bytes. effective_authority_ref identifies the exact effective authority admitted by the decision. It is null for deny and a lowercase hexadecimal SHA-256 digest for permit or narrow. valid_until is null for deny and an exact UTC-millisecond timestamp later than issued_at for permit or narrow. valid_until and issued_at are compared as instants, not as strings. The issuer puts constraints into that canonical form when it builds the decision output, before the output is hashed for , so that two byte-different encodings of one decision cannot produce different decision_ref values. A verifier takes the array as received. It MUST NOT normalize, deduplicate or sort a received array before evaluating it, and a received array that is not already duplicate-free, in NFC and sorted by UTF-8 bytes makes the record invalid. This is the rule states for the other canonical array in this document. A permit or narrow policy-decision record is a bounded, single-use approval for its action_ref. At the moment the approval is consumed to admit dispatch, the enforcement boundary MUST verify that it has not expired, atomically consume its receipt_id, recheck time and revocation state, and complete any spend reservation. An already consumed, expired, or stale approval MUST NOT admit dispatch. A deny record is terminal and MUST NOT be consumed as an approval.

Action Result An action-result record has receipt_type "aps:action-result:v1". issuer is the enforcement boundary, prev is the consumed policy-decision receipt_id, and decision_ref MUST equal that decision's decision_ref. result contains exactly profile, status, effect_ref, and error_code: ", "error_code": null } ]]> status is succeeded, failed, or unknown. For succeeded, effect_ref is REQUIRED and error_code is null. For failed, error_code is a non-empty stable identifier and effect_ref is either a digest of a returned error artifact or null. For unknown, both are null. A failure the boundary cannot characterize is reported unknown, because failed carries a stable failure identifier the boundary does not hold in that case. A non-null effect_ref is computed as lowercase-hex(SHA-256( ASCII("APS-ACTION-EFFECT-V1") || 0x00 || JCS(effect))). An action-result record attests to what the enforcement boundary observed after dispatch. External occurrence or settlement requires separately resolved evidence. The validity window belongs to the policy decision. valid_until bounds the moment at which that decision may be consumed to admit dispatch, as requires. It does not bound the issued_at of the action-result record that follows, because execution and observation can complete after the decision is consumed. A verifier MUST NOT treat an action-result record as invalid on the sole ground that its issued_at is later than the consumed decision's valid_until, and MUST NOT report a temporal relation between the two that it did not check.

DecisionRefV1 DecisionRefV1 commits the policy decision to the action, evaluated authority state, policy input, decision context, and decision output without requiring those potentially sensitive objects to be embedded in every receipt. Each component reference is computed over the exact JSON value evaluated by the enforcement boundary: The DecisionRefV1 input is a closed object: ", "authority_state_ref": "<64 lowercase hexadecimal characters>", "policy_ref": "<64 lowercase hexadecimal characters>", "context_ref": "<64 lowercase hexadecimal characters>", "decision_output_ref": "<64 lowercase hexadecimal characters>" } ]]> authority_state MUST include the selected authority chain, authority-basis resolution, revocation observations, and the spend state used by the decision. policy_input MUST identify the policy and version actually evaluated and include its decision-relevant input. decision_context contains decision-relevant environmental state. decision_output is the exact CoreDecisionOutputV1 carried in the policy-decision receipt. A deployment MAY keep component values private, but a verifier cannot independently recompute a component whose value is unavailable. Matching decision_ref values establish that the same component digests were named. They do not establish that the policy was correct, the inputs were complete, or the underlying claims were true.

Evidence Resolution An evidence reference is a commitment, not evidence availability. When a verification policy depends on referenced evidence, the verifier resolves the artifact under the rules named by artifact_type, hashes the exact bytes those rules select, and compares the digest. Resolution reports at least resolved, not_found, unreachable, malformed, digest_mismatch, or unsupported. A not_found, digest_mismatch, or malformed result is invalid for a required artifact; unreachable is indeterminate; unsupported is unsupported. A verifier MUST NOT report the containing receipt fully valid for a claim that depends on unresolved evidence. A verifier that does not resolve evidence at all reports the evidence-resolution axis as not_attempted, which is indeterminate. Declining to resolve evidence is a permitted verifier scope. Omitting the axis, or reporting a receipt valid for a claim that depends on evidence the verifier never resolved, is not. Retrieval code MUST apply scheme allowlists, size limits, redirect limits, timeouts, and private-network restrictions appropriate to its environment. A receipt signature does not make an evidence locator safe to fetch.

Receipt Verification A verifier performs these checks in order:

1. parse bounded I-JSON while preserving duplicate names
2. enforce the closed ReceiptV1 envelope schema and the schema of the stage named by receipt_type
3. recompute receipt_id
4. resolve signer authority at issued_at, and, for a stage that names the enforcement boundary as issuer, compare issuer with the expected boundary identity where one is supplied
5. verify the required signatures
6. recompute action_ref from the independently supplied action input object, and compare that object's agent_id with the record's subject_agent
7. verify delegation_ref against the selected authority chain, and verify that chain
8. recompute decision_ref where required, over the decision output in the canonical form of , using the construction of
9. validate prev and stage transitions
10. enforce freshness and single-use state for an approval
11. resolve evidence required by the verifier's policy

On step 5, the required signature set is the signature from issuer that requires, plus any signature the applicable profile or the verifier's own input explicitly requires. Failure or non-resolution of a signature outside that set MUST NOT change the record's aggregate state and is reported on its own axis. A structurally malformed signature descriptor still makes the envelope invalid, because the envelope schema is closed and the descriptor is part of it. On step 6, the action binding is established only against an independently supplied action input object. Where the verifier holds none, the action-binding axis is not established, which is indeterminate. Where it holds one, the object's agent_id of and the record's subject_agent of MUST be equal, and a verifier MUST report a mismatch as invalid on that axis. The two name the acting agent from the two sides of one action, and a record binding an action declared by one agent to a different subject_agent is not a conforming receipt. On step 7, where an authority chain is supplied, delegation_ref MUST equal the delegation_id of the selected leaf byte for byte, and a verifier MUST report a mismatch as invalid. Where no chain is supplied, a verifier checks the form of delegation_ref only and MUST NOT report the delegation-validity axis as valid. Where delegation_ref names an authority basis rather than a delegation leaf, this document defines no encoding for that basis, and a verifier MUST report that axis as unsupported. On step 10, the policy-decision record identifies the approval. Whether that approval has been consumed is enforcement-boundary state keyed by its receipt_id and is not content of the record. A verifier without access to that state reports the approval-state axis as not established, which is indeterminate. The result keeps artifact integrity, signer authority, action binding, delegation validity, decision binding, stage continuity, enforcement-boundary identity, approval state, and evidence resolution separate. An invalid cryptographic or structural check is invalid. Missing live state is indeterminate. An unknown required profile is unsupported, as is a receipt_type that names no stage of . A result object whose profile is not the one its named stage defines is invalid, because those objects are closed. A caller MUST NOT collapse indeterminate or unsupported into valid, and a verifier MUST NOT let an axis it did not establish contribute to a valid result. A ceiling an implementation reaches while parsing or verifying, such as a nesting depth, a wire size, or a chain length limit, is a property of that verifier and not of the record: the same bytes verify under a verifier with a higher ceiling. A verifier that reaches such a ceiling MUST report indeterminate with a reason naming the limit, and MUST NOT report the record invalid on that ground. A parse failure, a duplicate member, or any other schema violation remains invalid. Where a bounded parser both reaches a ceiling and observes a syntax violation, a ceiling reached before any syntax violation is observed is indeterminate, and a syntax violation observed first is invalid.

Authority Lifecycle An agent can outlive the session that started it, the person who sponsored it, the key it first signed with, the approval that let it act, and the workflow it was built for. This section states what happens to its authority across those changes: what stays continuous, what must stop, what may be transferred, who can establish replacement authority, when current authority is checked again, and what evidence supports each transition. This section has four parts. Concepts names the findings the rest of it keeps apart. Authority Continuity Rules states what authority means across change, as twelve rules L1 to L12. Lifecycle Mechanisms specifies the machinery a deployment uses to make those rules checkable: activation, purpose exhaustion, capability and policy binding, authority epoch, suspension cause sets, status sources, succession and handover, and what changes when a person leaves. Candidate Lifecycle Extensions lists statements written against this text that no requirement here depends on. Lifecycle Core is an enumerated set of propositions, not a reading of this section, and it is an informative grouping name rather than a claimable base. A proposition is in it only where it restates a requirement the closed core of this document already states, which is the only ground on which anything in this section is Core. Six of the twelve continuity rules contribute to it, one requirement identifier each. L1 is in it whole, restating the per-member revocation check of applied to a dependent chain. From L3, that revocation is irreversible for the authority object it names, which states as INV-5. From L5, that an action is decided against one root-to-leaf chain with no union across chains, per . From L6, that the boundary rechecks revocation state and temporal validity at the moment the approval is consumed to admit dispatch, per , and . From L7, that an unknown revocation state is not active. From L9, historical key selection at the artifact's issued_at together with the issuer-claim timestamp and the indeterminate result where the signing instant is not established, all three per . Every other rule, every remaining part of L3, L5, L6, L7 and L9, and every mechanism in this section is a Candidate feature, normative for an implementation claiming it and not a requirement of APS Core conformance. Every normative subsection here ends with its requirement identifiers and a status block naming the fixture families that exercise it and the released packages that implement it. A requirement is marked exercised only where a named vector carries an assertion that fails when the requirement is violated. Everything else is marked specified, not exercised. Record types this section names are in the proposed: namespace. They are the names the reference packages ship. No fixture family in the conformance suite mints a record under any of them, so none of them graduates to the aps: namespace in this revision, and none of them is a frozen wire name.

Concepts Authority is the bounded set of actions an agent may perform on behalf of a principal under currently valid grants and constraints. It is not one record and not one status flag. It depends on parties, on authority artifacts, on lifecycle state, on action state, and on what a verifier can establish about each of them. These change independently. A transition in one does not imply a transition in another unless the authority model in force binds them. Not every concept named below is a separate protocol object. The names exist so that two findings a deployment tends to run together can be reported apart. Parties and standing:

Agent identity

Which agent is acting. Identity continuity does not establish authority continuity.

Principal

The person, office, organization or other body on whose behalf authority exists.

Issuer

Whoever issues or signs an authority artifact. The issuer and the principal can be different parties.

Issuer standing

Why the issuer was allowed to create, narrow, suspend, revoke or replace authority for the principal at the moment of issuance.

Lifecycle standing

Who may suspend, revoke, replace or reaffirm an authority artifact now. This is not always the issuer. An organization, a quorum, a successor or a security function can hold standing over authority it never issued. In this revision a party with lifecycle standing that is not the delegation's issuer ends dependent authority by revoking its own ancestor grant, or through a suspension cause under , because names only the issuer for a direct revocation. Direct revocation by a party other than the issuer is open at .

Principal binding

Which principal an agent acts for. It can exist before any grant and outlive one.

Sponsor

Who is responsible for an agent's continued operation, where a deployment has that role. Changing a sponsor does not on its own transfer or replace existing authority.

A signature that verifies establishes which key signed, and, where an identifier-to-key binding is established, which party signed. A verifier MUST NOT read it as establishing that the signer held standing to make the statement the record carries. Standing MUST be resolved from a source the authority model accepts for that statement, and MUST NOT be read from the record asserting it. A record's own claim about the role its signer holds is the signer's claim about itself, and where that claim conflicts with the accepted source the conflict MUST be reported under its own reason code rather than folded into a plain role mismatch. A standing answer has three values, not two: the party holds the role, the party does not hold the role, and the source cannot say. Where the source cannot say, the verifier MUST report the state as not established and MUST NOT report it as a finding that the party lacks standing. Issuer standing and lifecycle standing are separate findings. Issuer standing is about the issuer at the moment of issuance and does not change with later events. Lifecycle standing is about who may change the artifact now. A verifier MUST NOT derive one from the other. Whether an artifact was validly issued and whether it still confers authority are likewise two findings, established separately. A grant can be validly issued and stay dependent on an authority path that later ends. Authority and dependencies:

Delegated authority

That a subject may take an action because a principal granted it, under which constraints, for which targets, for what period, through a specific chain.

Authority path and current dependency

Which other authority a grant depends on now. Historical provenance and current dependency are two findings.

Presented credential or session

A session or derived token used to exercise authority in one request. Ending a grant does not on its own invalidate every session or derived token already issued, and ending a session does not on its own end the grant.

Activation condition

When already issued authority becomes exercisable. A grant can be validly issued and still wait on a date or a recorded event. See .

Target binding

Which resource, counterparty or object the authority applies to. Continuity of a name does not on its own establish continuity of the thing named.

Capability binding

Which operation, implementation or declared schema a grant refers to, where that distinction matters. See .

Lifecycle state:

Issuance

The event that creates an authority artifact.

Suspension

Pauses or narrows the use of authority without permanently ending it.

Expiry or exhaustion

Ends authority because a declared time, use count, budget, purpose or other bound has been reached.

Revocation

Permanently ends a named authority artifact.

External restriction

A block from outside the grant chain. It can stop some effects while the grant itself stays valid.

Authority epoch

Separates current authority from stale authority surviving in sessions, queues, replicas, snapshots or restored state. See .

Decisions and effects:

Approval

A principal or approver allows a proposed action. It is an input to authorization, with its own scope, expiry and use count, and it can be withdrawn before the next authorization boundary consumes it.

Policy version

Which policy an approval or decision was evaluated against. The same action can be allowed under one version and denied under the next.

Authorization decision

The record an enforcement point makes that an action was allowed or denied, against the authority, policy and inputs it evaluated. The signed form is the policy-decision record of .

Invocation and execution

The exact action submitted for execution, and the attempt to carry it out.

Effect

The externally observable result, if any.

In-flight state

Where an action sits between authorization and a known outcome. Authority can change inside that interval.

This section is written against three enumerations, and they are never mixed. An artifact verdict is what a verifier says about an authority artifact at a moment: valid, invalid, not established, not yet effective, suspended, or restricted. A boundary outcome is what an enforcement point decides about one action at one authorization boundary: authorized, denied with a stated reason, or not established. A chain-verification result is what returns for one selected root-to-leaf chain: valid, invalid, indeterminate, or unsupported. Two findings that share a name across the artifact-verdict and boundary-outcome enumerations MUST carry different reason codes. The chain-verification result relates to the other two without being converted into either. A chain result of valid supports the artifact verdict valid for the artifacts on that chain and supports no boundary outcome on its own. A chain result of invalid supports the artifact verdict invalid. A chain result of indeterminate is carried as indeterminate on its own axis, and where a verifier also reports an artifact verdict for the artifacts on that chain, that verdict is not established with the source or freshness limb named, as states. The chain result is not replaced by the artifact verdict. A chain result of unsupported is carried as unsupported and is neither erased nor folded into another value, as already requires of a caller. Not established keeps one meaning, which is the evidential one. The verifier cannot reach a conclusion because a source is missing, unrecognized, stale past its declared bound, silent, self-attested with nothing to check it against, or in unresolved conflict with another accepted source. It is ignorance and it is not the negation of the claim. Where a verifier has reached a conclusion and the conclusion is negative, the finding MUST be reported under the shape it has. An enabling condition established not to have occurred yet is the artifact verdict not yet effective. A composition rule established not to be satisfied denies the action at that boundary. A pinned referent established to have changed denies the action at that boundary. A verdict of not established MUST name at least one missing limb from source, freshness and coverage. What this subsection does not establish. It does not say which party holds any of these roles in a deployment, and it does not define a registry or a protocol for resolving standing. It does not give an authority epoch, an activation condition or a non-time bound a place inside a signed delegation, because the authority vector of is closed at seven facets and a missing facet is invalid rather than an implicit unconstrained value. Human agency law draws related distinctions between actual authority, notice and apparent authority. Those doctrines are a source of cases for this work. This document does not assume that any of them applies to AI agents. Requirements. APS-LC-STANDING-NOT-FROM-RECORD, standing is resolved from a source the authority model accepts and is not read from the record asserting it. APS-LC-STANDING-THREE-VALUED, a source that cannot say gives not established rather than a finding that the party lacks standing. APS-LC-ISSUER-VS-LIFECYCLE-STANDING, a verifier derives neither issuer standing nor lifecycle standing from the other. APS-LC-VERDICT-ENUMERATIONS-DISTINCT, artifact verdicts and boundary outcomes are two enumerations and two findings sharing a name across them carry different reason codes. APS-LC-NOT-ESTABLISHED-LIMB, a verdict of not established names at least one missing limb from source, freshness and coverage. All five are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: activation-not-established, lifecycle-purpose-exhaustion, authority-epoch-rollback, sponsor-handover, conflicting-status-sources. Implemented requirements: APS-LC-STANDING-NOT-FROM-RECORD, APS-LC-STANDING-THREE-VALUED, APS-LC-VERDICT-ENUMERATIONS-DISTINCT, APS-LC-NOT-ESTABLISHED-LIMB. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental lifecycle-state module.

Authority Continuity Rules Twelve rules, L1 through L12, about what authority means when the records stay the same and the surroundings move. They are separate from the eight protocol invariants of and do not extend that numbering. Each subsection states the rule, states what the rule does not claim, and carries its own identifiers and status block. Six of the twelve are Lifecycle Core. The rest are Candidate.

L1. Revoking an Ancestor Invalidates the Authority That Depends on It Once a verifier establishes, under the status and freshness rules its authority model declares, that a delegation is revoked, every chain that depends on that delegation is invalid. This holds where the dependent delegation carries no revocation record of its own and appears on no enumeration of descendants. Enumerating descendants is a cleanup and reporting mechanism. It MUST NOT be what makes a chain-verifiable descendant invalid. What it does not claim. It does not claim a teardown report is useless. It does not reach a credential that carries no chain a verifier can check, such as an opaque bearer token, where an issuer-side revocation mechanism is still needed. It does not claim a verifier can always establish the revocation: an unavailable or stale answer is governed by , not by this invariant. Requirement. APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS, an established revocation invalidates every chain that depends on the revoked delegation, and enumeration of descendants is not what makes a chain-verifiable descendant invalid. Specified, not exercised: no vector in either family named below carries an assertion that fails when enumeration is treated as the operative mechanism. Status: Lifecycle Core. This rule restates the per-member revocation check of applied to a dependent chain, which is a requirement of the closed core. Related fixture families: ancestor-revocation-chain (4 vectors), authority-epoch-rollback (12 vectors). Implemented requirements: APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI).

L2. Identity Continuity Does Not Imply Authority Continuity The same agent identity MAY appear as the subject of a revoked chain and of an independent replacement chain. A verifier MUST decide each chain on its own members and MUST NOT carry a result from one chain to the other. Revoking the first chain's ancestor invalidates the first chain and says nothing about the second. What it does not claim. It does not claim the agent must stop running. It does not claim the replacement chain is narrower or wider than the one it replaces. It does not state when replacement authority must exist, and it does not decide whether a handover accepts an overlap or accepts a gap. Requirement. APS-LC-IDENTITY-NOT-AUTHORITY, a verifier decides each chain on its own members and carries no result from one chain to another. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: sponsor-handover (6 vectors). Implemented requirements: APS-LC-IDENTITY-NOT-AUTHORITY. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI).

L3. Reauthorization Creates New Authority Continuity after revocation is a new grant from a principal that currently holds the authority being granted. A verifier MUST NOT treat a revocation as reversed and MUST NOT re-parent a revoked chain under a new ancestor. A record stating that a revocation was published in error is a new record that references the revocation. It does not remove the revocation, the revocation still verifies, and the record does not on its own change any chain result. Recording that a revocation was made in error is permitted only as an explicit, attributable record from a source with lifecycle standing. Such a record is a new record and not a reversal of the old one. Revocation is irreversible, as states, and a record withdrawing a recorded revocation does not remove it. A proposed:revocation-withdrawal:v0 record references the revocation by identifier, carries the delegation that revocation named, the party stating the withdrawal, the instant, a machine-readable reason code and optional free-text detail. After an accepted withdrawal the revocation is still held, still verifies byte for byte, and the chain result does not change. The resulting position is not that the revocation never happened. It is that the revocation was withdrawn by a named record, which is this document's rule that a later finding is a new record rather than an edit of an earlier one. Whether a party may withdraw a revocation is a lifecycle-standing question the authority model answers, and it MUST NOT be read from the withdrawal record itself. WITHDRAWAL_ACCEPTED states that the store accepted the record and states nothing about authority. The revocation stands, the chain result is unchanged, and no authority returns. The outcome codes are WITHDRAWAL_ACCEPTED, WITHDRAWAL_SCHEMA_INVALID, WITHDRAWAL_NAMES_NO_HELD_REVOCATION, WITHDRAWAL_TARGET_MISMATCH, WITHDRAWAL_SIGNER_WITHOUT_STANDING and WITHDRAWAL_STANDING_NOT_ESTABLISHED. The last two are different findings and MUST NOT be collapsed: one says the party may not, the other says nobody has told the verifier either way. A withdrawal that changes nothing in silence is indistinguishable from one that was never submitted, so a refusal MUST be reported with its code. What it does not claim. It does not claim a correction is forbidden. The word doing the work is silently. It does not state who may withdraw a recorded revocation, which is a lifecycle-standing question the authority model answers. It does not state what a verifier reports after an accepted withdrawal beyond keeping the revocation and its result. Requirements. APS-LC-NO-REVOCATION-REVERSAL, a verifier does not treat a revocation as reversed, which restates the irreversibility INV-5 states in the closed core. APS-LC-NO-REPARENTING, a verifier does not re-parent a revoked chain under a new ancestor, which the closed core does not state. APS-LC-WITHDRAWAL-NOT-REMOVAL, a record withdrawing a recorded revocation is a new record, the revocation is still held and still verifies, and the chain result does not change. All three are specified, not exercised. Status: Lifecycle Core for one proposition, carried by APS-LC-NO-REVOCATION-REVERSAL, that revocation is irreversible for the authority object it names, which states as INV-5 and which is a requirement of the closed core. Everything else in this subsection is a Candidate feature under the lifecycle continuity rules named in , normative for an implementation claiming it and not a requirement of APS Core conformance: the rule against re-parenting a revoked chain under a new ancestor, carried by APS-LC-NO-REPARENTING, the treatment of a record stating that a revocation was published in error, and the withdrawal record and its outcome codes above. Related fixture families: sponsor-handover (6 vectors), authority-epoch-rollback (12 vectors). Implemented requirements: APS-LC-NO-REVOCATION-REVERSAL, APS-LC-NO-REPARENTING, APS-LC-WITHDRAWAL-NOT-REMOVAL. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental authority-state module.

L4. A Successor Does Not Inherit the Predecessor's Delegation Tree A successor's authority covers what the successor issues. A descendant whose ancestor artifact was revoked is invalid, and it stays invalid until a party that currently holds the authority issues it a new grant. The departure is not the event that invalidated it. A departure with no revocation anywhere on the path leaves the descendant's result to chain verification, as states. What it does not claim. It does not decide whether office-based authority continues, suspends or needs reaffirmation when no current holder can exercise or revoke it. It does not settle how to treat long-lived grants an issuer signs shortly before leaving. Both remain open. Requirement. APS-LC-SUCCESSOR-NO-INHERITANCE, a successor's authority covers what the successor issues, and descendants whose selected chain contains the revoked predecessor delegation stay invalid until a party that currently holds the authority issues new grants. Departure is never the invalidating event. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: sponsor-handover (6 vectors). Implemented requirements: none. Related implementation surfaces: no released package.

L5. Independent Chains Are Not Combined Each action selects one root-to-leaf authority chain. A verifier MUST NOT union scope grants or spend ceilings from more than one chain. An agent that holds two valid chains MUST NOT use them together to obtain authority broader than either chain allows on its own. An implementation that judges an action against a held set MUST report the single chain the action was decided against, and that report MUST name one chain rather than a set. A presentation that concatenates two root-to-leaf chains into one array is not a selection of one chain, and an implementation MUST NOT decide an action against it. An implementation MAY refuse such a presentation before chain verification runs, on the ground that the fault is the presentation rather than the records, or it MAY let chain verification report the broken parent link. Both paths refuse the action. What it does not claim. It does not forbid independently rooted chains from coordinating on a shared objective while each keeps its own scope. It does not define how an action selects its chain, which is an implementation choice. It does not define cross-principal composition, which requires a separate profile. It does not decide what an implementation does next when the chain an action selected turns out to be unusable, which is . Requirements. APS-AUTH-CHAIN-NO-UNION, an action is decided against one root-to-leaf chain and no verifier unions scope grants or spend ceilings across chains, which restates the two propositions states in the closed core, exercised by single-chain-selection SCS-06, whose assertion expects the chain verifier's PARENT_MISMATCH at index 1 when a concatenated presentation is offered as one chain, and by the eleven cases of chain-selection-no-union. APS-AUTH-CHAIN-SET-NOT-A-SELECTION, a concatenated presentation is not a selection of one chain and no action is decided against it, exercised by the same vector. APS-AUTH-CHAIN-REPORT-ONE-CHAIN, an implementation that judges an action against a held set reports the single chain the action was decided against and names one chain rather than a set, specified and not exercised. Neither of the last two is stated in the closed core. Status: Lifecycle Core for one proposition, carried by APS-AUTH-CHAIN-NO-UNION, that an action is decided against one root-to-leaf chain with no union across chains, which states. The reporting rule of APS-AUTH-CHAIN-REPORT-ONE-CHAIN and the concatenated-presentation rule of APS-AUTH-CHAIN-SET-NOT-A-SELECTION are a Candidate feature under the lifecycle continuity rules named in , normative for an implementation claiming it and not a requirement of APS Core conformance. Related fixture families: single-chain-selection (6 vectors), chain-selection-no-union (11 vectors). Exercised requirements: APS-AUTH-CHAIN-NO-UNION, APS-AUTH-CHAIN-SET-NOT-A-SELECTION. Implemented requirements: APS-AUTH-CHAIN-NO-UNION, APS-AUTH-CHAIN-SET-NOT-A-SELECTION, APS-AUTH-CHAIN-REPORT-ONE-CHAIN. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), chain-selection module, stable.

L6. An Earlier Approval Is Not Current Authority An approval issued earlier does not establish that the authority it rested on is still current. The enforcement boundary MUST recheck revocation state and temporal validity at the next authorization boundary, meaning the moment the approval is consumed to admit the action, and not only at the moment the decision was issued. A cached authorization decision MUST NOT be used past the freshness bound the authority model declares for it. What it does not claim. It does not state that every input of the earlier decision is re-evaluated at that boundary. The recheck of temporal validity sits in the closed core beside the revocation recheck, at . Revalidation broader than those two is exercised only as a candidate. It does not state what happens to an operation already in flight when the recheck fails, which stays open. Requirements. APS-LC-RECHECK-AT-ADMISSION, the enforcement boundary rechecks revocation state and temporal validity at the moment the approval is consumed to admit dispatch and not only at the moment the decision was issued. This obligation is stated normatively in the closed core, at , and , and this rule restates it rather than adding to it. APS-LC-CACHED-DECISION-FRESHNESS, a cached authorization decision is not used past the freshness bound the authority model declares for it, which the closed core does not state. Both are specified, not exercised: no vector named below asserts a failure keyed to the recheck moment itself. Status: Lifecycle Core for one proposition, carried by APS-LC-RECHECK-AT-ADMISSION, that the boundary rechecks revocation state and temporal validity at the moment the approval is consumed to admit dispatch, which the closed core states at , and . The cached-decision freshness bound, carried by APS-LC-CACHED-DECISION-FRESHNESS, is a Candidate feature, normative for an implementation claiming it and not a requirement of APS Core conformance. Related fixture families: cached-authorization-revocation (9 vectors), approval-single-use (9 vectors), runtime-authority-denial-continuity (9 vectors). Implemented requirements: none. Related implementation surfaces: no released package.

L7. Unknown Revocation State Is Not Active A revocation answer that is unavailable or stale is indeterminate. A verifier MUST NOT read it as active, and the record MUST NOT claim a revocation that no source stated. An enforcement point MAY deny on an indeterminate answer. Where it does, the denial MUST say that the state was not established rather than say that a revocation occurred. A resolver answer the implementation does not recognize, including a status value added after the implementation was written, MUST be treated as not established rather than as active. What it does not claim. It does not decide between denying and waiting. It does not define freshness bounds, which the authority model declares per source. It does not on its own extend to every current lifecycle state claim, which is a candidate broadening rather than this invariant. Requirements. APS-LC-UNKNOWN-NOT-ACTIVE, an unavailable, stale or unrecognized revocation state is not active. Specified, not exercised: the families below decide the normalization, and neither names a vector whose assertion fails when an unavailable answer is read as active. APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED, an enforcement point may deny on an indeterminate answer, and a denial on it says the state was not established rather than that a revocation occurred. Specified, not exercised: neither family names a vector whose assertion turns on the wording of the denial. Status: Lifecycle Core for one proposition, that an unknown revocation state is not active, which states for an unavailable, stale or unrecognized revocation-resolution outcome and which is a requirement of the closed core. Everything else in this subsection is a Candidate feature under the lifecycle continuity rules named in , normative for an implementation claiming it and not a requirement of APS Core conformance: the permission to deny on an indeterminate answer, and the obligation that such a denial say the state was not established rather than say a revocation occurred, which APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED carries. Related fixture families: revocation-resolution-forward-compat (14 vectors), conflicting-status-sources (14 vectors). Implemented requirements: APS-LC-UNKNOWN-NOT-ACTIVE. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI).

L8. Suspension Is Not Revocation Suspension pauses the use of an authority artifact and of the authority that depends on it, and it can be released. Revocation is terminal for the artifact it names. A verifier MUST report the two under different verdicts and MUST NOT report one as the other. A restricted state is a third finding: authority continues in reduced form under a live constraint that does not pause it, and a restriction is not required to pause descendants. What it does not claim. It does not define who may release a suspension. It does not define a precedence order among concurrent causes. It does not state what happens to an action queued before a suspension that is still queued after the release. Requirement. APS-LC-SUSPENSION-NOT-REVOCATION, a verifier reports suspension and revocation under different verdicts and reports neither as the other, and a restricted state is a third finding. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: suspension-cause-composition (16 vectors). Implemented requirements: APS-LC-SUSPENSION-NOT-REVOCATION. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental suspension module.

L9. Key Rotation Is Not Delegation Revocation An identity MAY rotate its signing key and continue. A verifier MUST select the key version authorized at the artifact's issued_at rather than the key current at verification time, so a rotation does not on its own invalidate artifacts signed before it. The artifact timestamp is an issuer claim. Where the result depends on whether an artifact was signed before a key was retired, the verifier needs timestamp or log evidence its authority model accepts, and without it the result is indeterminate. Revoking a delegation is a statement about that delegation and not about the key that signed it. What it does not claim. It does not state which evidence establishes the signing instant. It does not cover key compromise, where an authority model may need to reach artifacts signed before the rotation, and this document states no rule for that case. Requirements. APS-LC-ROTATION-NOT-REVOCATION, a verifier selects the key version authorized at the artifact's issued_at rather than the key current at verification time, the artifact timestamp is an issuer claim, and the key-authority result is indeterminate where the signing instant is not established. All three are stated in the closed core at and this rule restates them. APS-LC-REVOCATION-NOT-ABOUT-KEY, revoking a delegation says nothing about the key that signed it, which the closed core does not state. Both are specified, not exercised: the family below supplies its own stand-in evidence record and records that it is a fixture stand-in. Status: Lifecycle Core for the three propositions the closed core states, carried by APS-LC-ROTATION-NOT-REVOCATION: historical key selection at the artifact's issued_at, the artifact timestamp as an issuer claim, and the indeterminate key-authority result where the signing instant is not established. states all three. One proposition is a Candidate feature under the lifecycle continuity rules named in , normative for an implementation claiming it and not a requirement of APS Core conformance, carried by APS-LC-REVOCATION-NOT-ABOUT-KEY: that revoking a delegation says nothing about the key that signed it. Related fixture families: key-rotation-historical (5 vectors). Implemented requirements: APS-LC-ROTATION-NOT-REVOCATION, APS-LC-REVOCATION-NOT-ABOUT-KEY. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI).

L10. Expiry Is Not Revocation Expiry ends authority because a declared bound was reached. Revocation ends it because a party with lifecycle standing ended it early. Both stop use. A verifier MUST report which of the two occurred and MUST NOT collapse them into a single state. Exhaustion of a non-time bound is an ending of the expiry kind and is not a revocation. A grant MAY be expired and exhausted at the same instant, and a verifier MUST report both rather than letting one overwrite the other. What it does not claim. It does not state that an ending must produce a signed record, although defines one for exhaustion. It does not state that a replacement grant is owed after either ending. Requirement. APS-LC-EXPIRY-NOT-REVOCATION, a verifier reports which of expiry and revocation occurred and does not collapse them, and reports a grant expired and exhausted at one instant as both. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-purpose-exhaustion (21 vectors), lifecycle-expiry-and-renewal (15 vectors). Implemented requirements: APS-LC-EXPIRY-NOT-REVOCATION. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental bounds module.

L11. No Silent Authority Resurrection Where the authority path an implementation selected becomes invalid, the implementation MUST NOT decide the action against another held grant unless that switch was itself authorized. A switch MUST be reported as a decision that names the path switched away from and the authorization relied on for the switch. An implementation that refuses to switch MUST NOT read any held chain other than the one the action selected, so that a refusal cannot conceal a switch. What it does not claim. The backup-restore and rollback case, where a restore presents authority state from before a change as current, is carried by and rather than here. It does not define what makes a switch authorized. It does not forbid an agent from holding more than one chain. It does not state what happens to the operation after the refusal. It does not make an implementation that has never observed the newer authority state at fault for not detecting a regression it could not see. Requirement. APS-LC-NO-RESURRECTION, an implementation does not decide an action against another held grant when the selected authority path becomes invalid unless the switch was itself authorized, and a switch is reported as a decision naming the path switched away from. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: chain-selection-no-union (11 vectors), authority-epoch-rollback (12 vectors). Implemented requirements: APS-LC-NO-RESURRECTION. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), the fallback surface of the chain-selection module.

L12. Completeness Is a Separate and Stronger Claim A record stating that a teardown processed a set of descendants establishes that its signer made that statement. It does not establish that the set was every descendant at the relevant boundary, that every write persisted, or that nothing was issued concurrently. A claim that a set is complete MUST state the basis on which it is complete, and a verifier that cannot establish that basis MUST report not established with the coverage limb named, rather than reading the claim as covering the whole set. A query whose interval is still inside a declared delivery lag does not cover that interval, and an empty result over it is delivery lag rather than absence. What it does not claim. It does not define what basis is sufficient for a completeness claim. That is open: what set a boundary claims to have accepted at a moment, what prevents an addition afterwards that still counts as earlier authority, and what public commitment can establish closure over that set without exposing private state are all unsettled. It does not turn an incomplete teardown into a finding that the descendants the record does not name are valid. Requirement. APS-LC-COMPLETENESS-BASIS, a claim that a set is complete states the basis on which it is complete, and a verifier that cannot establish that basis reports not established with the coverage limb named. This requirement is exercised by lifecycle-infrastructure-failure LC-F-016-b, LC-F-026-a, LC-F-027-a, LC-F-027-b and LC-F-029-a, the five cases in which the family names this rule. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-infrastructure-failure (30 vectors), lifecycle-evidence-and-record (12 vectors). Exercised requirements: APS-LC-COMPLETENESS-BASIS. Implemented requirements: none. Related implementation surfaces: no released package.

Lifecycle Mechanisms Eight mechanisms, each its own Candidate feature. An implementation claims them one at a time, and claiming one implies none of the others. They are the machinery the continuity rules above are checked with: activation conditions, purpose bounds and exhaustion, capability and policy binding, the authority epoch, suspension cause sets, status sources, succession and handover, and what changes when a person leaves.

Activation Conditions Authority subject to an activation condition is not exercisable until that condition is established by evidence the authority model accepts, from a source the model accepts for that condition. An activation condition is a separate signed record that references a delegation by its identifier. It is not a facet, because the authority vector of is closed at seven facets. Two record types carry this surface. A proposed:activation-condition:v0 record declares the condition and names the delegation it gates. A proposed:activation-attestation:v0 record is one party's statement about the condition. An authority model MAY accept condition evidence in a record shape this document does not define, and where it does, the model MUST declare which record types it accepts for that condition. A condition is of kind date or of kind recorded_event. A date condition carries an activation_date and needs no evidence. The verifier compares the action instant with the date, so an unreached date is a known negative and never an unknown one. A recorded_event condition carries an event_type, an event_id, at least one required attestor role, a threshold of at least one, and an instant_basis. Required attestor roles are roles and never principals. Who holds a role at an instant is resolved outside the record, and a condition that names no accepted source has not stated what it accepts and MUST be refused rather than treated as accepting anything. A record from a party holding any named role is acceptable, which is a union and not a conjunction. The threshold states how many acceptable attestations establish a finding and has no default value. The instant_basis states which instant a positive attestation is measured against, and it has no default value. Under condition_occurrence the governing instant is the instant the condition is asserted to have occurred. Under attestation_written it is the instant the record was written. The two give opposite answers for an occurrence before an action attested after it, so the condition MUST state which one governs. An attestation asserts either condition_occurred, carrying the occurrence instant, or condition_not_occurred_through, carrying the instant through which the attestor states the condition had not occurred. The second is a negative that is evidence rather than an absence of evidence, and that is what separates not yet effective from not established. A verifier checks each presented attestation in this order, and the first failing check is that record's reason:

1. the record type is one the model declared it accepts for this condition, else ATTESTATION_RECORD_TYPE_NOT_ACCEPTED
2. a key resolves for the record's verification method at the record's own written instant, and the signature verifies over the canonical bytes of the body, else ATTESTATION_SIGNATURE_UNVERIFIED
3. the verification method belongs to the attestor the body names, else ATTESTATION_ATTESTOR_BINDING_MISMATCH
4. the accepted source can say whether the attestor holds the role, else ATTESTATION_ATTESTOR_ROLE_UNKNOWN
5. the role the record claims for itself agrees with the accepted source, else ATTESTATION_ROLE_CLAIM_CONFLICT
6. the attestor holds a role the condition requires, else ATTESTATION_ATTESTOR_ROLE_MISMATCH
7. the condition identifier, event type and event identifier are the condition's own, else ATTESTATION_CONDITION_MISMATCH
8. the assertion is one of the two defined above and carries the member that assertion needs, else ATTESTATION_UNKNOWN_ASSERTION
9. every instant on the record is one the verifier will compare, else ATTESTATION_INSTANT_MALFORMED
10. a condition_not_occurred_through record reaches the action instant, else ATTESTATION_DOES_NOT_REACH_ACTION

A record that fails any of these checks is not evidence in either direction. It cannot establish the condition and it equally cannot establish that the condition was unmet. A negative statement from a source the model does not accept for this condition therefore gives not established and MUST NOT give not yet effective. Each accepted record yields one finding, measured on the condition's own instants: occurred_by_action, occurred_after_action, or not_occurred_through_action. The verdict follows in this order. Where both occurred_by_action and not_occurred_through_action are present, two accepted records disagree, the verdict is not established with reason CONDITION_EVIDENCE_CONFLICT, and neither record is discarded in favour of the other. Where occurred_by_action alone is present and the threshold is met, the verdict is valid with reason ACTIVATION_ESTABLISHED. Where not_occurred_through_action is present, the verdict is not yet effective with reason CONDITION_ESTABLISHED_NOT_YET_OCCURRED. Where occurred_after_action is present, the verdict is not yet effective with reason CONDITION_FIRST_OCCURRED_AFTER_ACTION. Where no finding is present, the verdict is not established, with ACTIVATION_THRESHOLD_NOT_MET where accepted records exist but fall short of the threshold, with NO_ATTESTATION_PRESENTED where nothing was presented, and otherwise with the reason of the record that got furthest through the checks. A condition presented against a different delegation gives not established with reason CONDITION_DELEGATION_MISMATCH and the coverage limb named. The claim does not state that it covers what the verdict needed. Only three verdicts are reachable here: valid, not yet effective and not established. An unmet activation condition MUST NOT make a grant invalid. Whether the grant is valid at all is chain verification's answer and not this surface's. A record written after an action MAY establish a condition that obtained before it, which is the ordinary case for any model built around a determination recorded after the fact. A condition whose first occurrence is after the action does not reach back to that action, and the same record establishes the condition for a later action. What it does not establish. An activation condition is enforced only at a boundary that claims this feature. A delegation gated by a recorded_event condition verifies as valid at a boundary that does not claim it, because the condition is a separate record the chain does not carry and chain verification never reads. An issuer that needs a gate enforced at every boundary has only the time facet of , whose not_before every chain verifier applies. It does not settle which clock governs an instant comparison, and a single time source or a declared smear window can both produce readings a verifier has no basis to accept. It has no vocabulary for a condition whose trigger is that something did not happen within a declared window, and the unresolved standing answer is what keeps that case reachable rather than silently answered. It does not state whether a condition, once established, stays established. It does not decide whether a wait carried by the time facet is reported as invalid or as not yet effective: chain verification returns invalid with NOT_YET_VALID for a not_before that has not been reached, this surface returns not yet effective for an activation date at the same instant, and the difference is recorded here rather than resolved. Requirements. APS-LC-ACTIVATION-SOURCE-DECLARED, an authority model accepting condition evidence in a record shape this document does not define declares which record types it accepts for that condition, and a condition naming no accepted source is refused rather than read as accepting anything. APS-LC-ACTIVATION-EVIDENCE-ORDER, each presented attestation is checked in the stated order and the first failing check is that record's reason. APS-LC-ACTIVATION-NOT-INVALID, an unmet activation condition does not make a grant invalid, and only valid, not yet effective and not established are reachable on this surface. All three are specified, not exercised: the family below decides the verdicts and does not carry an assertion keyed to the order of the checks. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: activation-not-established (19 vectors). Implemented requirements: APS-LC-ACTIVATION-SOURCE-DECLARED, APS-LC-ACTIVATION-EVIDENCE-ORDER, APS-LC-ACTIVATION-NOT-INVALID. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental activation module.

Purpose Bounds and Exhaustion A grant can end because a declared non-time bound was reached. Three bound kinds are defined: purpose, use_count and budget. A proposed:authority-bound:v0 record declares one bound on one delegation, carrying a bound identifier, the delegation's identifier, the kind, the bound value, and the attestor roles that may state the bound was reached. Like an activation condition, a bound is a separate record rather than a facet. The three kinds are reached by different means and MUST NOT be conflated. A purpose bound is reached when a fulfilment record from a party with standing establishes that the stated reason was met. Exercising the grant does not reach it. A use_count bound is reached by the admission itself, and no fulfilment record is involved. A budget bound is reached when committed plus reserved spend reaches the cumulative ceiling, under the cumulative spend rules this document states for a delegation subtree, where signatures establish static limits and do not establish the current cumulative total. A budget bound is never wider than the facet's cumulative limit. Reaching the facet's limit is the reservation refusal the closed core already states at , not exhaustion under this feature, and a boundary reports the two separately. Purpose membership is not purpose exhaustion. Whether a requested purpose falls inside a grant's allowed purposes answers the same way for the second action as for the first. An implementation that checks the chain, the time facet, revocation state and purpose membership, and stops there, admits an action under a grant that has already done its one job. A conforming enforcement boundary MUST evaluate the bound separately from membership. A fulfilment record has record type proposed:authority-bound-fulfilment:v0 and carries the bound identifier, the delegation identifier, the attestor, the verification method, the instant the record was written inside the signed content, a machine-readable outcome of fulfilled or not_fulfilled, a machine-readable reason code, and optional free-text detail. It is shaped after what this document requires of a revocation record, which is the nearest case of a party with standing recording that an authority artifact's state changed. A record that says not_fulfilled is a statement about the world, so that a fulfilment record existing and the record saying the purpose was met stay two facts. A bound evaluation reports one of three states. The bound is not reached, with reason BOUND_NOT_REACHED. The bound is exhausted, with reason PURPOSE_EXHAUSTED, USE_COUNT_EXHAUSTED or BUDGET_EXHAUSTED according to the kind. Or the state is not established, with reason BOUND_STATE_NOT_ESTABLISHED. A fulfilment claim the boundary cannot establish MUST give not established and MUST NOT give exhausted. That covers a record whose signature does not verify and a record authenticated by a party without standing, and the two MUST be reported under different per-record codes: FULFILMENT_SIGNATURE_INVALID and FULFILMENT_ATTESTOR_WITHOUT_STANDING. Where no key resolves for the attestor's method the code is FULFILMENT_KEY_UNRESOLVED, which is a source gap and not a signature failure. Where the accepted source cannot say whether the attestor holds a role the code is FULFILMENT_ATTESTOR_ROLE_UNKNOWN, which is not the same finding as the party lacking standing. The remaining per-record codes are FULFILMENT_ACCEPTED, FULFILMENT_SCHEMA_INVALID, FULFILMENT_NOT_BOUND_TO_BOUND, FULFILMENT_OUTCOME_NOT_FULFILLED, FULFILMENT_NOT_YET_ATTESTED and FULFILMENT_NOT_APPLICABLE_TO_KIND. A verifier asked about one instant MUST NOT read a record written after it. An exhaustion is not reversible. A record asking to void an exhaustion MUST be refused, and it MUST be refused whether or not its signer holds standing to revoke the grant, because standing to revoke is not standing to undo an ending that already occurred. A refusal for want of standing and a refusal because the ending is terminal are two findings and are reported apart. This document fixes no reason code for either refusal, and no released package ships one. An exhaustion MAY be recorded. A proposed:authority-exhaustion:v0 record carries the bound identifier, the delegation identifier, the kind, the enforcement boundary making the finding, the verification method, the instant the finding was made inside the signed content, the reason code that reached exhausted, and the evidence the finding rests on. For a purpose bound the evidence names the attestor and written instant of every accepted fulfilment record. For a use_count or budget bound the evidence is empty, because the basis is the boundary's own ledger. The record attests that the named boundary found, from the evidence it names, that the bound had been reached. It does not attest that the purpose was met in the world, which is the same separation draws for an action-result record. Expiry and exhaustion are separate endings and can hold at the same instant. A verifier MUST report the chain result and the bound state side by side, and neither overwrites the other. Neither is a revocation. What it does not establish. This document does not authenticate a bound declaration. Because the facet set is closed, a bound cannot ride inside the signed delegation, and the declaration is an input the authority model establishes by its own means, whether a principal signature over the body, an entry in a registry the verifier accepts, or a term outside the wire format. It does not state who holds standing to attest a fulfilment. It does not let a verifier with no access to the boundary's ledgers reach an exhaustion verdict for a use_count or budget bound from signed records alone, and the empty evidence array on the record says so rather than hiding it. It does not settle how far a detected reuse of a single-use artifact reaches into artifacts already issued under that grant. Requirements. APS-LC-BOUND-KINDS-DISTINCT, the three bound kinds are reached by different means and are not conflated. APS-LC-PURPOSE-MEMBERSHIP-NOT-EXHAUSTION, a conforming enforcement boundary evaluates the bound separately from purpose membership. APS-LC-FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED, a fulfilment claim the boundary cannot establish gives not established rather than exhausted, and a signature failure and an attestor without standing carry different codes. APS-LC-EXHAUSTION-IRREVERSIBLE, a record asking to void an exhaustion is refused whether or not its signer holds standing to revoke the grant. All four are specified, not exercised: the family below carries the events and no vector named in the handoff asserts a failure keyed to one of these rules alone. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-purpose-exhaustion (21 vectors). Implemented requirements: APS-LC-BOUND-KINDS-DISTINCT, APS-LC-PURPOSE-MEMBERSHIP-NOT-EXHAUSTION, APS-LC-FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED, APS-LC-EXHAUSTION-IRREVERSIBLE. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental bounds module.

Capability Binding and Policy Version A stable identifier, name or identity does not establish that what it refers to is unchanged. A tool can keep its name while its implementation or its declared schema, description and permissions change, which widens effective authority with no change to the grant. Where the authority model declares a class of referent change capability-relevant, continuity of the referent across such a change MUST be established by something the grant, the model or an attesting party pins. A verifier MUST NOT treat an unchanged name as evidence of an unchanged controller, an unchanged implementation or an unchanged declared schema. A pin is carried in one of two encodings, and an implementation states which it used. Under scope_grant_v0 the pin is further colon-separated segments under the tool grant, which keeps it inside the scope grammar of . That encoding has one consequence worth stating: a pin then narrows across a chain by the ordinary covering rule, so a child carrying a different pin fails as scope widening rather than as a binding failure. Under bound_record_v0 the pin is a separate signed record referencing the delegation identifier. This document reserves the name and does not define that record's wire format. Two axes are pinned separately, and each is a set rather than a single value, so that a grant may pin more than one acceptable revision. The implementation axis pins digests of acceptable implementations. The declared-metadata axis pins digests of acceptable declared metadata blocks. They are distinct because a tool can keep its name and its implementation bytes while its declared schema, description or permissions change, which is a different evidence problem. An empty set on an axis means that axis is not pinned. Continuity of the referent has three values. Established means the referent the grant pinned is the referent observed. Mismatch means the verifier reached a conclusion and the conclusion is that the referent changed. Not established means the verifier could not reach a conclusion either way, because nothing was pinned or because no accepted attestation covered what the answer needed. An established mismatch MUST deny the action at that boundary under a mismatch reason and MUST NOT be reported as not established. A not-established continuity MUST name at least one missing limb from source, freshness and coverage. Neither outcome makes the delegation invalid. The grant is intact, and what is not established is that the action now attempted is within it. The reason codes for this surface are CAPABILITY_CONTINUITY_ESTABLISHED for an authorized outcome, TOOL_NOT_IN_GRANT_SCOPE, SCOPE_NOT_GRANTED, PINNED_IMPLEMENTATION_DIGEST_MISMATCH and PINNED_METADATA_DIGEST_MISMATCH for a denial, and TOOL_ATTESTOR_KEY_UNRESOLVED, TOOL_ATTESTATION_SIGNATURE_INVALID, TOOL_ATTESTATION_ABSENT, REGISTRY_ENTRY_TOOL_NAME_MISMATCH, REGISTRY_ENTRY_IMPLEMENTATION_MISMATCH, NO_CAPABILITY_PIN_IN_GRANT, IMPLEMENTATION_NOT_PINNED_IN_GRANT, METADATA_NOT_PINNED_IN_GRANT and OBSERVATION_ABSENT for a not-established outcome. A metadata pin does not cover an implementation and an implementation pin does not cover a declared schema, which is what the two partial-pin codes record. An axis the verifier did not observe MUST NOT be reported as matching. The identifier limb is the same rule applied to who controls a name. A grant that does not declare an identifier the action in fact relies on gives not established, because a verifier that never modelled the identifier has no record to invalidate when control of it moves. A single accepted holder at the instant that is not a pinned controller denies the action under IDENTIFIER_CONTROLLER_CHANGED, and the result names the party that holds the identifier now. Two accepted custodian records naming different holders at one instant give not established under IDENTIFIER_BINDING_CONFLICT rather than a winner. An interval between issuance and the instant that is neither bound to the holder nor covered by an accepted retention record gives not established under IDENTIFIER_CONTINUITY_GAP_UNCOVERED, and a retention record whose issuer is not the custodian the verifier resolves for that identifier kind gives RETENTION_CUSTODIAN_WITHOUT_STANDING. The remaining codes are IDENTIFIER_CONTINUITY_ESTABLISHED, IDENTIFIER_DEPENDENCY_NOT_DECLARED, IDENTIFIER_CONTROLLER_NOT_PINNED and IDENTIFIER_BINDING_LAPSED. The released capability-binding module evaluates custodian binding and retention records it does not itself produce. Its entry point takes the binding and retention records as inputs together with two caller-supplied resolvers, one for which custodian the caller resolves for an identifier kind and one for that custodian's key, and its contract states that standing is resolved "by KIND and never from the custodian member the record asserts about itself: a valid signature establishes who signed, not that they had standing". The module issues no custodian record and signs none. It exports the signed-byte construction a custodian signs over and nothing that mints or signs a record. A policy version is a dependency of a decision that the grant does not carry. The same action can be allowed under one version and denied under the next. A decision record MUST identify the policy version it was evaluated against. already requires the policy input a decision commits to through policy_ref to identify the policy and version actually evaluated, so a decision whose policy_ref commits to such an input satisfies this rule even where the deployment keeps the value private and no reader can recompute the component. Not established applies where no such commitment exists, because a reader then cannot tell which rules produced the decision. A pin that resolves to no version is likewise not established. A pinned decision renders under its own version whatever version is operative at the moment it is read, which is this document's rule that later findings never rewrite earlier records applied to a policy change. Which version is operative at an instant is resolved from pointers, not from write order. The operative version at an instant is the target of the acceptable pointer with the greatest effective instant at or before it. Two acceptable pointers sharing that instant and naming different targets give not established rather than a winner. A pointer from an issuer that does not hold standing over the policy is not established. A pointer's own claim to be a rollback does not make it one: a rollback is established only where the version it names was already operative under an earlier acceptable pointer, and a newly authored version that reproduces an older version's rules is a new version whatever the pointer calls it. A policy that tightens after a grant was issued restricts the action at the authorization boundary. The chain is unchanged and the grant stays valid. A verifier MUST report that case as restricted and MUST NOT report it as invalid. Invalid is what an actual revocation produces, and keeping the two apart is what lets a reader tell a policy change from an authority change. A tightened policy does not reach backward on its own, and the earlier grant does not need to be revoked for the new rule to bind future actions. What it does not establish. It does not claim every referent must be pinned, because pinning has real cost and many grants do not need it. The claim is that where nothing pins it, continuity is not established and the verdict says so. It does not claim a verifier can always detect a referent change, and often a verifier cannot. It does not cover narrowing: a referent that loses a capability has not widened or redirected what the authority permits, and denying there would be a false denial. It does not claim a capability change invalidates the grant. It does not claim re-consent is the only remedy. It does not resolve semantic drift generally, and when a change in meaning should invalidate an earlier grant or approval stays open. It does not define how a policy version is published, who holds standing over a policy, or how a verifier learns which pointers are acceptable. This document fixes no reason codes for the policy-version limb, and no released package ships any. One divergence is recorded rather than resolved. The candidate families named below were authored against an earlier reading and label an established pinned-referent mismatch as not established, in a verdict set that has no denial member. This document specifies the denial. A family run that reproduces the earlier labelling is reproducing the family's vocabulary and is not deciding the rule. Requirements. APS-LC-REFERENT-CONTINUITY-PINNED, continuity of a referent across a change the authority model declares capability-relevant is established by something the grant, the model or an attesting party pins, and an unchanged name is not evidence of an unchanged controller, implementation or declared schema. APS-LC-PINNED-MISMATCH-DENIES, an established mismatch denies the action under a mismatch reason and is not reported as not established, and a not-established continuity names at least one missing limb. APS-LC-POLICY-VERSION-IDENTIFIED, a decision record identifies the policy version it was evaluated against, and one that does not is not established when read afterwards. That identifier restates and adds nothing to it, and carries it as a Core restatement. APS-LC-POLICY-TIGHTENING-RESTRICTS, a policy that tightens after issuance is reported as restricted and not as invalid. All four are specified, not exercised, and the divergence recorded below is why: the families label the mismatch outcome differently from the rule this subsection states. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-policy-change (13 vectors). Diverging families, not evidence: capability-binding-drift (8 vectors) and lifecycle-identifier-reuse-and-rename (13 vectors), whose vectors label an established pinned-referent mismatch as not established, so a run of either counts neither for nor against the rule this subsection states, and records the same divergence. Implemented requirements: APS-LC-REFERENT-CONTINUITY-PINNED, APS-LC-PINNED-MISMATCH-DENIES. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental capability-binding module, for the capability and identifier limbs, and no released package for the policy-version limb.

Authority Epoch and Fencing An authority epoch detects regression of a monotonic value the deployment supplies, where a stale value can survive in sessions, queues, replicas, snapshots or restored state. The feature specified here is a regression rule and a fencing comparison over that value, and nothing more. A value that has not regressed establishes nothing about whether the authority behind it is current. No record defined by this document carries an epoch value, and no decision commits to one. An approval's usability is decided by the rules in and not by an epoch comparison. This document names the concept and the comparison and defines no wire field for either. A deployment that uses generations supplies the value, and what is specified here is what a verifier does with it. The design is incomplete, and the gaps are stated rather than filled. The value the reference packages carry is an in-memory marker. It is not signed, it is not a wire field, and the module that holds it supports neither durability nor concurrency. Five questions follow from that and none of them is answered here. Which authority the epoch is counted for, which this document leaves to the deployment or its profile and for which the root authority basis and its delegation lineage is the recommended answer. Who is authorized to advance it. How an advance is authenticated, given that an unsigned marker can be presented by any party that can reach the comparison. What a verifier does on a first observation, where there is no high-water mark to compare against. And what a verifier does when its own remembered high-water mark is itself restored from stale state. An implementation claiming the authority-epoch feature MUST define its epoch domain, its authorized updater, the authenticated representation of an advance, its first-observation trust rule and its handling of stale verifier state. An implementation that leaves any of the five undefined MUST report the feature as unsupported rather than applying the comparisons below to a value whose meaning it cannot state. An epoch value is a canonical unsigned decimal integer with no sign, no leading zero and no separators, compared as an integer and never lexically. It is counted within an epoch domain, which the deployment or the applicable profile defines and declares. A declared domain names what the value is counted within. A verifier MUST compare two values only where both are carried in the same declared domain, and two values from different domains order nothing. Placing a presented value against what a verifier has already established gives one of three results. Forward means the value advanced or held equal, and the presented state is read normally. Regressed means the value went backwards against an established high-water mark. Unplaceable means there is nothing to compare against, or the two values are counted in different declared domains. For each authority subject, an enforcement point MUST NOT act on a state older than the newest state it has established for that subject under the scheme in force. Where the value regresses, the operation MUST be refused rather than resolved by recency of write. Monotonicity is per subject and is measured against what the verifier has established, not against global truth, so a verifier legitimately holds a current epoch for one artifact and an older snapshot for another. Unplaceable is not a verdict. A high-water mark has to start somewhere, and this document does not state whether a first observation is read or refused. Both are defensible and the outcomes differ, so the authority model MUST declare which disposition applies and an implementation MUST NOT supply a default. This is the first-observation trust rule the feature definition above requires, and declaring it is not the same as establishing that the first value observed was current. A regressed view never answers active. Two verifiers holding the same high-water mark can give different answers about the same restored state, and the difference is what each retained. A verifier that retained the revocation records it observed can establish the revocation from those records and answers revoked. A verifier that retained only the epoch value cannot, and answers unknown, which chain verification reports as indeterminate under a revocation-unknown failure code. Both answers are correct for the verifier that gives them, and neither is active. Fencing applies between the components of one enforcement boundary. Where the component that evaluates authority is not the component that performs the effect, the value MUST be carried to the performing component inside the boundary and checked there. A write to an authority state source inside the boundary MUST carry the value of whoever claims to be the current publisher, and that source MUST refuse a write whose value went backwards against the highest it has already seen. An equal value has not gone backwards, so an equal value is accepted and the retry is idempotent. The three refusal codes are STALE_FENCING_TOKEN, FENCING_SCOPE_MISMATCH and FENCING_TOKEN_UNREADABLE. A write path that cannot order a value is not fenced, so the second and third refuse rather than guess. This document places no obligation on a party outside the deployment's enforcement boundary, here or anywhere else. What it does not establish. It does not require a deployment to run an epoch scheme. It claims that where a deployment has one, a regression is a refusal rather than an input to a merge. It does not make a verifier that has never seen the newer state at fault, because that verifier cannot detect the regression at all. It does not say who advances an epoch, whether the value is signed, or what evidence carries it, and the feature definition above turns those into obligations on an implementation rather than answers from this document. It does not state that last-writer-wins storage is misconfigured, only that such a store is the wrong place to resolve a revocation. It does not bind any decision or approval to an epoch. It does not close authority rollback, which stays open at , and it does not establish that a verifier whose own remembered high-water mark was restored from stale state can detect that it was. Requirements. APS-LC-EPOCH-FEATURE-DEFINITION, an implementation claiming this feature defines the five items above or reports the feature unsupported. APS-LC-EPOCH-NO-REGRESSION, an enforcement point does not act on a state older than the newest it has established for that subject, and refuses rather than resolving by recency of write. APS-LC-EPOCH-SCOPE-DECLARED, an epoch value is counted within a declared epoch domain that names what it is counted within, a verifier compares two values only within the same declared domain, and two values from different domains order nothing. APS-LC-EPOCH-NO-REGRESSION is exercised by authority-epoch-rollback for the rejection of stale authority. The other two are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: authority-epoch-rollback (12 vectors), for the rejection of stale authority only. That family is not cited here for recovery from stale verifier memory, which no family exercises. chain-selection-no-union (11 vectors). Exercised requirements: APS-LC-EPOCH-NO-REGRESSION. Implemented requirements: APS-LC-EPOCH-NO-REGRESSION, APS-LC-EPOCH-SCOPE-DECLARED. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), experimental authority-state module, whose marker is unsigned, is not a wire field, and supports neither durability nor concurrency.

Suspension, Cause Sets and Release Suspension pauses the use of an authority artifact without ending it. Restriction leaves the artifact in force and blocks some of what it covers. The two are separate states and neither is revocation. Revocation is terminal for the artifact it names, and a release record never reverses one. A lifecycle cause is a separate signed record that references a delegation_id. It is not a facet. The authority vector is closed at seven facets and a missing facet is invalid, so a cause cannot ride inside a signed delegation. A cause record carries record_type proposed:suspension-cause:v0, a cause_id unique within one evaluation, the delegation_id it stands against, a kind of either suspension or restriction, the party that imposed it, the instant it was imposed, a stable reason code, a verification method prefixed by the imposing party, and a signature over the RFC 8785 canonical bytes of the record with record_id and signature removed. A verifier MUST represent the causes standing against one artifact as a set, and MUST NOT collapse them into a single flag. Where any cause remains unreleased, the verdict is suspended if at least one remaining cause is of kind suspension, and restricted if every remaining cause is of kind restriction. The result MUST name the remaining causes, each with its kind and its reason code. A count or a boolean does not satisfy this. A release record carries record_type proposed:cause-release:v0, a release_id, the delegation_id, the list of cause_ids it claims to clear, the releasing party, the instant it was recorded, a verification method prefixed by the releasing party, and a signature over the same preimage rule. One release record MAY name several causes. A verifier MUST decide each named cause independently, so a record from a party holding standing over two of the three causes it names clears exactly those two. Releasing one cause MUST NOT clear another as a side effect. Standing over a cause is resolved outside the record. A verifier MUST NOT read standing from the record asserting it, and MUST NOT treat a cause's own statement of who may release it as deciding the question. Standing is not authorship. A party that holds standing over a cause it did not impose can release it, and a party that imposed a cause does not thereby hold standing over a different one. A record that fails a record-level check releases nothing and is never applied to any cause. The record-level checks are the signature under the key the verification method names, the binding of that verification method to the party the body names, and that the record was recorded at or before the instant being evaluated. An unverified claim does not become a lifecycle state. Reporting suspended on a cause whose signature does not verify converts an unauthenticated assertion into a pause the artifact never carried. Three time rules apply. A cause is not in evidence at an instant before it was imposed, and the same record is in evidence at a later instant. A release is not in evidence at an instant before it was recorded. A release recorded before the cause it names was imposed clears nothing. Where a standing resolver cannot establish whether a releasing party holds standing over a cause, the state is not established, with reason code RELEASE_STANDING_NOT_ESTABLISHED and the source limb missing. Failing to establish that a cause was released is not establishing that it still holds, and it is not a finding that the release was ineffective. A release never clears a revocation recorded while the artifact was suspended. Where chain verification returns anything other than valid, a verifier MUST report that result and MUST NOT report the pause state as if it answered the chain question. A fully released cause set on a revoked chain is invalid. A fully released cause set with an unresolvable revocation answer is not established. Neither is exercisable. The reason codes for this subsection are NO_CAUSE_PRESENTED, NO_CAUSE_IN_EVIDENCE, ALL_CAUSES_RELEASED, CAUSES_OUTSTANDING and RELEASE_STANDING_NOT_ESTABLISHED on a verdict, and CAUSE_IN_EVIDENCE, CAUSE_NOT_ON_DELEGATION, CAUSE_RECORD_TYPE_UNRECOGNISED, CAUSE_NOT_YET_IN_EVIDENCE, CAUSE_SIGNATURE_UNVERIFIED, CAUSE_IMPOSER_BINDING_MISMATCH, CAUSE_RELEASED, RELEASE_IN_EVIDENCE, RELEASE_NOT_ON_DELEGATION, RELEASE_RECORD_TYPE_UNRECOGNISED, RELEASE_SIGNATURE_UNVERIFIED, RELEASE_ISSUER_BINDING_MISMATCH, RELEASE_AFTER_EVALUATION_INSTANT, CAUSE_NOT_PRESENTED, RELEASE_PRECEDES_IMPOSITION and RELEASER_WITHOUT_STANDING on a per-record or per-cause disposition. What this subsection does not establish. It defines no precedence order among causes, so a deployment holding two causes whose releases point in opposite directions has no rule here to apply. It says nothing about whether a cause propagates to descendants of the artifact it names, and it decides the state of that one artifact only. It does not claim that a release returns authority to its shape before the cause was imposed, because something else may have ended in the interval. It does not say where a standing registry comes from or who publishes one. It does not say what a verifier should report first when a chain is revoked and causes are still outstanding. Informative. The open question this subsection was written against asks that lifting one suspension not clear another, not bypass a revocation that happened while the agent was suspended, and not recreate rights that changed in the meantime. The composition rule above answers the first two. The third is the same question as the pre-suspension shape, and it stays open. Requirements. APS-LC-CAUSE-SET-NOT-FLAG, a verifier represents the causes standing against one artifact as a set, names the remaining causes with kind and reason code, and does not collapse them into a flag or a count. APS-LC-RELEASE-PER-CAUSE, each named cause is decided independently and releasing one clears no other. APS-LC-RELEASE-STANDING-EXTERNAL, standing over a cause is resolved outside the record and is not read from the record asserting it or from the cause's own statement of who may release it. APS-LC-CHAIN-RESULT-PRECEDES-PAUSE, where chain verification returns anything other than valid the verifier reports that result and does not report the pause state as if it answered the chain question. All four are specified, not exercised: the family below carries sixteen composition cases and the handoff names no single vector whose assertion fails on one of these rules alone. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: suspension-cause-composition, 16 cases and 5 gates. Implemented requirements: APS-LC-CAUSE-SET-NOT-FLAG, APS-LC-RELEASE-PER-CAUSE, APS-LC-RELEASE-STANDING-EXTERNAL, APS-LC-CHAIN-RESULT-PRECEDES-PAUSE. Related implementation surfaces: agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python), suspension module, experimental and opt-in.

Status Sources, Freshness and Coverage A claim about the current lifecycle state of an authority artifact, meaning its revocation, suspension, restriction, expiry or exhaustion state, is established only from a source the deployment profile accepts for that state, within a freshness bound that profile declares for that source, and only over the set the claim itself states it covers. An answer from a source the profile does not accept for the state does not establish it, whatever the answer says. A status answer is active, revoked or unavailable. The first two are determinate. unavailable is a source that was consulted and produced no usable answer, and a verifier MUST NOT use it as a third determinate state. A source that produced no observation at all is silent, which is a different input, and a profile MUST declare whether silence from a required source is a coverage gap or is read as that source answering unavailable. Freshness is declared per source, not globally. Each accepted source carries its own bound in whole seconds, and the comparison is inclusive, so an age exactly equal to the bound is within it. A profile MUST declare whether an answer past its own bound still counts, separately for a revoked answer and for an active answer. The two readings differ and this document does not choose between them. An answer dated after the boundary instant has no measurable age and MUST NOT be read as fresh. A verifier records that answer as skew, distinctly from staleness, and does not use it. Where the used answers carry more than one determinate state, that is an unresolved conflict. A verifier MUST NOT admit on a conflict, whatever coverage says. The record MUST name both states and the sources that carried them, because a conflict a record does not attribute cannot be acted on. A profile declares whether a conflict denies the action with a conflict reason or returns not established. Under either reading the artifact verdict is not established and never invalid. The verifier refused the action. It reached no conclusion about the authority, and it does not claim that either answer is false. Unknown is not active. A revocation answer that is unavailable, stale past its declared bound, silent or in unresolved conflict leaves the state not established. It does not become active, and the record MUST NOT claim a revocation that was never observed. An enforcement boundary MAY deny on not established, and the denial records which of source, freshness or coverage was missing. Chain verification already requires that a revocation-resolution outcome a verifier does not recognise is not treated as active, leaving the revocation state not established and the chain result indeterminate. That rule covers more shapes than an implementation tends to anticipate. A casing or whitespace variant of a recognised answer, a value of the wrong type, a null, an empty object or array, and a resolver that raises rather than answering all land in the same place. A known-active answer at one chain member does not make the chain valid when another member's answer is not understood. This document defines no failure-code vocabulary for chain verification, so the reason an implementation reports for that result is the implementation's own. A verifier that declared an offline posture in advance, with a snapshot source and the maximum snapshot age it declared it would admit on, MAY admit on a snapshot inside that bound. The record MUST name the snapshot source, the instant the snapshot was known correct, the age it admitted at, and the declared bound. A verifier that declared no bound in advance MUST NOT admit on a snapshot. Being offline does not soften an observed revocation. Where a decision is cached, the profile declares two limits. The first is the maximum age of a cached authorization decision usable without consulting the authority again. The second is the maximum delay between a revocation being acknowledged and denial of subsequent protected operations. A cached decision past the first limit MUST be re-resolved at the next authorization boundary, on a retained session, after a reconnect and on any other worker holding the same credential. A grant the authority can be reached for but whose state it cannot resolve is denied rather than served from cache. Coverage is measured over the source set the relying party declared, and the record states which denominator was used. A coverage block reporting that every declared source produced a usable determinate answer MUST NOT be read as a statement that the declared set was every source that mattered. A verifier MUST NOT read a state claim as covering more than the claim states. The reason codes for this subsection are STATUS_ACTIVE_ALL_SOURCES_AGREE, ADMITTED_ON_SNAPSHOT_WITHIN_DECLARED_BOUND, STATUS_REVOKED, STATUS_SOURCES_CONFLICT, STATUS_STALE_BEYOND_BOUND, STATUS_COVERAGE_INCOMPLETE and STATUS_NO_USABLE_OBSERVATION. The bases a record carries for why one answer was or was not used are within_freshness_bound, revocation_observed_outside_bound_still_used, stale_active_admitted_by_policy, stale_beyond_bound, source_gave_no_answer, answer_dated_after_boundary and source_not_accepted. What this subsection does not establish. It does not solve completeness. The coverage rule is a rule for reading a claim, not a duty to establish that a set was complete, and the completeness invariant stays open. It declares no freshness number, and a deployment with no declared bound has nothing to measure against. It does not say which sources a profile must accept for which state. It does not choose what a conflict returns or whether a stale answer counts, and two implementations choosing differently are both consistent with this text. It does not rule clock skew beyond refusing an answer dated after the boundary. It does not say what a relying party that acted on stale but authentic evidence is entitled to. Requirements. APS-LC-STATUS-SOURCE-ACCEPTED, a lifecycle-state claim is established only from a source the profile accepts for that state, and an answer from a source it does not accept establishes nothing whatever the answer says. APS-LC-FRESHNESS-PER-SOURCE, freshness is declared per source, and an answer dated after the boundary instant is recorded as skew and not used. APS-LC-STATUS-CONFLICT-NO-ADMIT, a verifier does not admit on an unresolved conflict between determinate answers, and the record names both states and their sources. APS-LC-COVERAGE-AS-STATED, a verifier does not read a state claim as covering more than the claim states. APS-LC-OFFLINE-DECLARED-IN-ADVANCE, a verifier that declared no snapshot bound in advance does not admit on a snapshot. All five are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: conflicting-status-sources, 14 cases. revocation-resolution-forward-compat, 14 cases. cached-authorization-revocation, 9 cases. Implemented requirements: APS-LC-STATUS-SOURCE-ACCEPTED, APS-LC-FRESHNESS-PER-SOURCE, APS-LC-STATUS-CONFLICT-NO-ADMIT, APS-LC-COVERAGE-AS-STATED. Related implementation surfaces: the unrecognised-answer path is in the released chain verifier of agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python), which report it as REVOCATION_UNKNOWN under their own failure-reason vocabulary. Multi-source status, per-source freshness and the coverage block are the status-coverage module of the same two packages, experimental and opt-in. The cached-decision limits are no released package.

Succession, Handover and Reauthorization Continuity after an authority ends means a new grant from a principal who currently holds authority. It never means reversing a revocation and it never means re-parenting the old chain onto a new ancestor. Revocation is irreversible, and a succession record is not an exception to that. A successor does not inherit the predecessor's delegation tree. A successor's grant covers what the successor issues. A descendant whose ancestor artifact was revoked stays invalid until a party with current authority issues it a new grant, and the departure is not what invalidated it. A successor's fresh grant is bounded by the successor's own ceiling and not by the predecessor's. An agent identity can appear as the subject of one chain issued under one root and, separately, as the subject of a chain issued under an independently issued root. Revoking the shared ancestor of the first chain invalidates that chain at that ancestor's own index. The second chain is unaffected. This is the whole of what chain verification says about a handover, and a verifier MUST NOT read the continuing identity as continuity of the revoked authority. How the cutover is ordered is a deployment choice. A planned handover may accept a short overlap and a compromised principal may call for revoking first and accepting a gap. In either case the old grant cannot authorize a new effect at the next authorization boundary after revocation, and continued operation has to run on the replacement authority. A delegation may be bound to an office, so that turnover moves it, or to an identity, so that turnover does not. Where the delegation's terms declare neither and the actor is the very subject the delegation names, the answer is valid and the missing term does not have to be resolved. Where the terms declare neither and the actor is somebody else, the binding mode is not established, and a verifier MUST NOT supply a default in either direction. Not established here is not a finding that the new occupant inherits, and it is not a finding that they do not. Under office binding, an office-holder record from a party with standing, whose window covers the action instant, has to name the acting party. No covering record leaves the question not established. A covering record naming somebody else is invalid, which is a positive finding rather than a missing one. A vacancy record covering the action instant leaves the question not established, and a verifier MUST NOT carry the last known holder through a vacancy. A verifier MUST NOT read an attestor's role off the record body. Replacement authority does not have to be issued after the contingency. Where an instrument or a declared rule of the authority model pre-commits it, the replacement holder's authority derives from that source at the scope that source declared, and becomes exercisable when the declared contingency is established by evidence the model accepts for that contingency. A pre-committed replacement whose pre-committing instrument is itself revoked or otherwise invalid is invalid with it. Pre-commitment does not reverse a revocation, and the successor receives the scope the pre-committing source declares for the successor, not the predecessor's other descendants. Where an instrument names several co-equal holders, the declared decision rule is evaluated over the holders current at the action instant. A holder whose vacancy reaches that instant is not a current holder and that holder's approval is not counted. An acting holder's own vacancy ends the enquiry. Where the model declares a majority rule, a vacancy does not have to be filled before the remaining holders can act. A later record from a party with standing may attach effects to an act already taken, including effects the governing authority model gives retroactive reach. Such a record is a new record that references the earlier one. It does not rewrite the decision record the earlier boundary produced, and a verifier evaluating before that later record exists reaches the answer the evidence then available supports. Where the model bounds such a record, for example by requiring it to cover the whole of a single act, by requiring capacity at the moment it was made, or by excluding effect on interests acquired in the meantime, those bounds are checked and recorded. What this subsection does not establish. It does not say what happens when nobody holds an office and nobody is empowered to exercise, reaffirm or revoke what the previous holder issued. That stays open. It sets no bound on what an outgoing issuer may pre-commit, so grants signed shortly before a departure stay open. It does not say whether an operation already running resumes, restarts, compensates or stops after the authority it ran under changes. It does not say which clock governs a contingency. It does not decide the order of a cutover for any deployment. Requirements. APS-LC-SUCCESSION-NEW-GRANT, continuity after an authority ends is a new grant from a principal who currently holds the authority, never a reversal of a revocation and never a re-parenting of the old chain. APS-LC-BINDING-MODE-NO-DEFAULT, where a delegation's terms declare neither office nor identity binding and the actor is not the named subject, the binding mode is not established and a verifier supplies no default in either direction. APS-LC-VACANCY-NOT-ESTABLISHED, a vacancy record covering the action instant leaves the question not established and a verifier does not carry the last known holder through a vacancy. All three are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-root-authority-succession, 13 cases. lifecycle-fiduciary-succession, 25 cases. sponsor-handover, 6 cases. lifecycle-organization-events, 35 cases. Implemented requirements: APS-LC-SUCCESSION-NEW-GRANT. Related implementation surfaces: chain verification, revocation state per chain member and the independence of separately rooted chains are the released chain verifier of agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python). Subject binding mode, office-holder and vacancy records, co-holder decision rules, pre-commitment and later attached effects are no released package.

Principals, Identities and What Changes When a Person Leaves A person's departure is not a revocation. It is an external event, and its effect on authority depends on the authority relationship involved and the rules that govern it. A personnel change does not silently remove a dependency, re-parent authority or create replacement authority. Where an authority artifact a grant currently depends on is revoked, the dependent authority is invalid, and a departure does not change which artifact that is. Whether an artifact was validly issued and whether it still confers authority are two findings, established separately. Issuance standing turns on the issuer at the moment of issuance and does not change with later events. Continuing authority turns on what the grant depends on now, on its lifecycle state, on any restriction from outside the grant chain, and on the profile's freshness rules. A verifier MUST NOT report either finding as if it answered the other. A person can be the principal of a grant. A person can instead be an issuer acting for an organization or an office, with standing to issue that comes from another authority relationship. These are not interchangeable, and the supporting evidence has to distinguish the principal, the issuer and the relevant dependency. Where it cannot, continuation of authority is not established. Identity continuity does not establish authority continuity. The same agent identity can appear under an old chain and under an independent replacement chain. Revoking the old chain's ancestor invalidates the old chain and leaves the replacement chain standing on its own. A record of a principal event, such as death, a finding of incapacity, a forfeiture of an appointment or the appointment of an outside authority over the principal, decides nothing without a role the profile accepts for that record type. A verifier MUST NOT read an attestor's role off the record body, and MUST NOT honour a grant's own claim that it survives an event when nothing outside the grant supports that claim. A finding recorded later may reach an earlier instant where the model gives it that reach. Such a finding is a new record that references the earlier one and does not rewrite the decision record an earlier boundary produced. Recording a transition and observing it are different events. Where a profile makes a change effective on a party's notice rather than at the event, the notice finding carries its own time, and a verifier records a notice finding or records that it has none. Where a grant's own terms make an action class effective only once an agreed confirmation procedure with the principal has been completed, and that confirmation cannot be obtained, the boundary outcome is not established. It is neither an approval nor a denial. Silence past a deadline MUST NOT be read as the principal answering, and an unreachable principal MUST NOT be read as a refusal. A confirmation reaches an action only from the instant the confirmation exists, it has to come from a party the profile accepts for it, and it has to cover this action rather than another. A different action class under the same grant, at the same instant, is unaffected. Authority can also end from the agent's side. An agent may end its own role, and where the profile makes that effective on delivery of notice, the principal's silence is not a veto. A stated later date or a stated triggering event moves when it takes effect and does not change what it is. An obligation outside this protocol that the renunciation may have breached belongs to the accountable principal and is outside this document. A verifier does not answer it, and the result carries no finding about it. A renunciation that breached such an obligation reaches the same verdict and the same reason code as a clean one. Continuity of a name does not establish continuity of the thing named. Where a grant depends on an identifier that no party in the delegation graph controls, such as a mail domain a recovery path delivers to or an account name a reference resolves, that identifier has its own lifecycle run by a custodian. states the rule for that case, including which outcomes deny the action and which leave continuity not established, and this subsection adds nothing to it. The reason the case belongs here as well is that a departure is one of the events that moves control of such an identifier without producing any record in the delegation graph. A credential more than one person can drive establishes authority and does not establish who acted. Accountability is a separate finding with its own evidence. Where a record from a party with standing assigns the action to an individual and covers this action at this instant, accountability is established. Where no such record exists, where two such records overlap and resolve to neither individual, or where the record references a different action, authority can be valid and accountability not established at the same boundary. An accountability finding does not by itself establish legal liability. What this subsection does not establish. It does not say whether a validly issued organizational grant survives the departure of the individual who issued it. Authority models differ and the departure alone does not choose between them, so this document leaves the choice to the profile. It does not resolve office vacancy, and it does not bound what an issuer may sign shortly before leaving. It establishes nothing about who covers an agent's work after the agent gives up the role. It makes no claim that any doctrine of human agency law applies to an AI agent. Those doctrines are a source of case shapes here and nothing more. Requirements. APS-PRIN-TWO-FINDINGS, whether an artifact was validly issued and whether it still confers authority are established separately and neither is reported as if it answered the other. APS-PRIN-ROLE-NOT-FROM-BODY, a verifier does not read an attestor's role off the record body and does not honour a grant's own claim that it survives an event when nothing outside the grant supports it. APS-PRIN-SILENCE-NOT-CONSENT, silence past a deadline is not the principal answering and an unreachable principal is not a refusal. APS-PRIN-ACCOUNTABILITY-SEPARATE, authority can be valid while accountability is not established at the same boundary. All four are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: lifecycle-principal-events, 32 cases. lifecycle-principal-unreachable, 12 cases. lifecycle-identifier-reuse-and-rename, 13 presentations. lifecycle-shared-identity-with-no-accountable-principal, 12 cases. lifecycle-agent-renunciation, 13 cases. Implemented requirements: none. Related implementation surfaces: chain verification and revocation state per chain member are the released chain verifier of agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python). Principal-event records, confirmation procedures, renunciation and accountability findings are no released package. Identifier custodian records are implemented, in the experimental capability-binding module of the same two packages, which is the surface records and to which this subsection adds nothing.

Candidate Lifecycle Extensions This subsection is informative. Each entry below is a candidate extension: a short name, the rule in precise terms, its status, the families that exercise it or a record that none does, the strongest counterexample found against it, and whether adopting it would change Core behavior. Nothing here is normative, nothing here is an adoption claim, and no requirement elsewhere in this document depends on any of it. Two candidates that were in this list are not here. A candidate whose strongest counterexample is unresolved is not a candidate extension, it is an open question, and it is carried in with the behavior this document requires until the question is settled. The two are the conferral rule, at , and the effectiveness-rule default, at . Status: none of the entries below is a feature an implementation can claim. Implemented: the lifecycle-state vocabulary these statements are written in is the lifecycle-state module of agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python), experimental and opt-in. No released package decides any statement in this subsection.

CAND-01: An External Event Is Authority-Changing Only When Established A verifier may treat an external event as authority-changing only when evidence it accepts establishes both the event and its authority effect under the applicable authority model. Absence of such evidence gives not established for the event, which is not a finding that the event did not occur. Strongest counterexample. A successor designation is simply missing, and under the applicable model the absence resolves to a named fallback holder. A literal reading returns not established and denies authority the model says exists. The clause about the applicable model carries this, because the established event is the absence and the model's own default rule supplies the authority effect. What it does not establish. It does not claim the world only changes when a record exists, and it does not claim that a valid verdict means no authority-changing event occurred. It does not say which events are authority-changing. It does not resolve when a change becomes effective. Related fixture families: lifecycle-purpose-exhaustion, 21 ordered events, the unauthenticated event record and the record authenticated by a party without standing. conflicting-status-sources, 14 cases, for two accepted sources disagreeing. Not covered: events a model makes effective with no record anywhere, and a default supplied on absence. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-02: Later Evidence Does Not Rewrite Earlier Evidence Later lifecycle evidence does not rewrite contemporaneous decision evidence. A later finding is a new record that references the earlier one and states its own effect, including how far back that effect reaches. Strongest counterexample. A later denial of ratification recharacterises a past action as having only ever been provisional, which is the closest thing in the corpus to a rewrite. The recharacterisation is itself a dated record from a party with standing, and the sentence it has to write is only writable while the original record still exists in its original form. What it does not establish. It does not claim the earlier decision's authority effect is unchanged, and retroactive effect is real. It does not claim a later finding can reach back without limit. It does not claim records are immutable, and it does not override an obligation to correct the content of a record. It does not say who has standing to make a later finding. Related fixture families: authority-epoch-rollback, 12 cases, a signed withdrawal accepted as a new record with the original still held and still verifying. conflicting-status-sources, 14 cases, where a later conflict does not change the record written at the earlier boundary. Not covered: the bounded-reach limb and the amendment-obligation case. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-03: Issuance Validity, Later Attached Effects and Current Validity Are Three Separate Findings Three findings about an authority artifact are separate and separately established. Whether it was validly issued, which turns on the issuer's standing at issuance and does not change with later events. Whether a later record from a party with lifecycle standing has attached effects to it or to acts taken under it. Whether it is currently valid, which turns on its dependencies, its lifecycle state, any restriction from outside the chain and the profile's freshness rules. A verifier does not report any one of these as if it answered another. Strongest counterexample. Where the finding is that issuance was never valid, current validity looks moot, and if the findings always moved together the separation would be decoration. They do not move together. Issuance can be untouched while continuing scope is narrowed from outside the chain, and issuance can be valid while exercisability is still pending. A void-from-issuance status is also not a revocation event, which needs the issuance question to stay answerable after the fact. What it does not establish. Standing at issuance cannot be inferred from a valid signature. It does not claim an organizational grant survives its issuer's departure and it does not claim the opposite. It does not resolve grants signed just before a departure, and it does not resolve office vacancy. Related fixture families: no family in this suite. No built fixture tests issuer standing at issuance. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-06: Collective Authority Must Satisfy Its Declared Composition Where the authority model requires an operation to be authorized collectively, the operation is authorized only when the declared composition rule is satisfied at the boundary the operation requires. A composition rule states which members are required, the threshold, the direction, and any restriction carried by an individual member. What it takes to authorize an action is not necessarily what it takes to stop or narrow it. A single valid chain does not satisfy a multi-member rule however broad that chain is. The authority the collective act exercises is the authority the rule attaches to, and satisfying the rule adds nothing to any contributing member's own scope. Where collective authority is required and the rule's membership, threshold or direction is not declared, composition is not established and a verifier does not supply one. A default declared by the authority model is a declared rule and not an inference. Strongest counterexample. A joint release that neither party may perform alone does something neither may do alone, which an earlier drafting of the no-widening clause forbade. The scope clause is about contributing members. The collective authority was never either individual's to begin with, so neither member's scope grows. What it does not establish. Composition is not a union of scopes. Composition rules are not symmetric. There is no universal default for undeclared composition. Not every member must be reachable. Concurrences may not be aggregated across time without a declared freshness rule. A standing superior override is lifecycle standing and not composition. Related fixture families: chain-selection-no-union, 11 vectors, the negative half only. The obligation half has no coverage and must not be reported as covered. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-09: Chain Validity Is Not Permission to Execute Whether an authority chain is valid and whether the action it authorizes is permitted by rules outside the grant chain are separate findings. This candidate is stated in full at , with its counterexample and its limits, and is listed here so that the candidate set is complete. Related fixture families: no family in this suite. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-11: A Valid Grant Can Be Unexecutable An artifact can be valid while the target, executor or capability it names no longer exists, in which case the artifact verdict is unchanged and the execution attempt fails. This candidate is stated in full at , with its counterexample and its limits, and is listed here so that the candidate set is complete. Related fixture families: no family in this suite. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

CAND-12: Ending Authority Bounds Future Effects and Does Not Undo Past Ones Ending or narrowing authority takes effect at the next authorization boundary the operation requires. Where an operation has a terminal boundary after which no further authorization decision occurs, a change arriving after that boundary does not reach the completed effect and is recorded as a later event rather than as a denial. Ending authority does not undo effects already completed, does not retract information already obtained, and does not by itself end sessions or derived credentials already issued. Where the model provides a compensating or reversing action, that action is separate authority with its own boundary and its own record. Strongest counterexample. Models that allow cancellation after acceptance in defined circumstances look like undoing a completed effect. They are a separately authorized action rather than an automatic consequence, which is what the last sentence of the statement says. What it does not establish. This is not an argument against terminating sessions on revocation. Session termination is a control a profile may and often should require, and the claim is only that it does not follow automatically, so a profile that wants it has to say so. It does not claim a post-boundary reversal is impossible. It does not claim exhaustion is always a separate step from use. It does not resolve work in flight. Related fixture families: no family in this suite. Changes Core behavior: no. No requirement of APS Core conformance depends on this statement, and an implementation that ignores it is not for that reason non-conforming.

BROAD-L6: Every Authorization Boundary the Operation Requires An earlier approval or authorization decision does not establish current authority at any later authorization boundary the operation requires. Each boundary is evaluated against lifecycle state the verifier can establish as current and effective at that boundary, including boundaries added from outside the grant chain and boundaries inside a long-running or multi-step operation. Rechecking current lifecycle state is not re-evaluating the operation under a newer policy version, and which policy version governs is a separately declared rule. Strongest counterexample. Two cases where more rechecking is the wrong answer. An in-flight instance whose remaining steps have to resolve against a pinned policy version, where jumping to current rules mid-replay is not a safety improvement. And a declared graceful-shutdown window, where the final in-flight call should succeed. The statement survives by separating current lifecycle state from policy version and by leaving the boundary set to the operation. What it does not establish. It does not claim the operation must be re-evaluated against the current policy version. It does not claim a retry of an already decided effect is a new boundary. It does not claim the start of a shutdown is a boundary, nor that every technical step is one. It does not claim a recorded change is automatically effective at the next boundary. It does not own the terminal-boundary rule. It does not resolve work in flight. Related fixture families: no family in this suite. The cached-authorization-revocation family, 9 timeline cases, exercises the narrower published invariant about rechecking revocation state at execution time and is a related family rather than coverage of this broadening. Changes Core behavior: yes, if adopted. The recheck obligation at the moment an approval is consumed is a requirement of the closed core. This statement extends rechecking to every authorization boundary the operation requires, including boundaries the core does not name, so adopting it would widen a Core requirement rather than add a feature beside it.

Decision to Effect A policy decision and an external effect are separate facts about separate moments. The records of carry the decision side and the boundary's own observation after dispatch. The effect side needs evidence a verifier resolves under . This section states what a verifier may carry across that gap, what it may not, and what it reports when the evidence it holds does not settle the question. This section answers five questions, separately, and never lets an answer to one stand in for an answer to another. Was the action authorized. Was it still admissible at the moment of admission. Was it admitted. Was dispatch attempted. Was the external effect established. A deployment that can answer the first and reports it as an answer to the fifth has lost four findings. The stage vocabulary this section uses has seven positions: proposed, then authorized or denied, then admitted or refused, then dispatch attempted, then result observed, then external effect established or not established, then settled or compensated. The positions are findings and not record types. states which of them any record in this document carries. One of the five questions has no durable answer in this revision. The admission transition produces no record. Whether an approval was consumed is enforcement-boundary state keyed by the approval's identity, and it is not content of any record this document defines, so a verifier without access to that state reports the approval-state axis as not established and can reach no further. carries what that leaves open and what this document requires until it is settled. Everything in this section is a Candidate feature except the Core restatements and name. It is specified here and tested against this text. A Candidate part of it is normative for an implementation claiming the feature and is not a requirement of APS Core conformance. No part of it is a conformance claim.

Relations Between a Decision and an Effect Four relations sit between a valid authority artifact and an effect in the world. None of them is transitive, and a finding about one is not a finding about the next.

1. A valid authority chain does not establish that an enforcement boundary authorized an action.
2. An authorization does not establish that the exact authorized call was the call dispatched.
3. An exact dispatched call does not establish that the effect was reached only through the boundary that admitted it.
4. Dispatch does not establish that the intended effect occurred.

A verifier MUST report each of these as its own finding. It MUST NOT derive a later one from an earlier one, and MUST NOT report a finding it did not establish. A caller holding a report on one of them MUST NOT read it as a report on another. This is the axis discipline of applied across the decision and the effect rather than within one record. Where a verifier holds a receipt and a decision, the binding between them is a recomputation, not a presumption. The reference is rebuilt under from the full decision evidence together with the action reference the receipt itself carries, and it MUST equal the receipt's decision_ref. A decision supplied alongside a receipt that does not bind to it is not evidence about that receipt, and a verifier MUST settle the binding before it reads any member of the decision, including its validity window. Reading a window off a decision that belongs to a different receipt reports a temporal relation the verifier never checked. The four relations were named on , where the last three are stated as "an authorized action does not imply the exact authorized call ran", "an exact authorized call does not imply execution was non-bypassable" and "execution does not imply the intended effect occurred". The candidate corpus this section is written against isolates those three. What this subsection does not establish. It does not establish that a verifier can reach any of the four findings from signed records alone. Three of the four need evidence from outside the record set. It does not establish an order in which a deployment must attempt them. It states only that a finding on one is not a finding on another. Requirements. APS-EVID-RELATIONS-NOT-TRANSITIVE, a verifier reports each of the four relations as its own finding, derives no later one from an earlier one, and reports no finding it did not establish. Specified, not exercised. APS-REC-DECISION-REF-RECOMPUTED, the decision reference is rebuilt from the full decision evidence and the receipt's own action reference and must equal the receipt's decision_ref. That is the requirement states with a keyword and step 8 performs, restated here and not added here, and receipt-decision-relation exercises it by asserting DECISION_REF_MISMATCH over its seven vectors. APS-REC-DECISION-BINDING-BEFORE-READ, the binding is settled before any member of the decision is read, including its validity window, which the closed core does not state. Specified, not exercised: no vector asserts the ordering of the binding check against the temporal check. Status: Core for one proposition, carried by APS-REC-DECISION-REF-RECOMPUTED, which restates and step 8. The rest of this subsection is a Candidate feature, normative for an implementation claiming it and not a requirement of APS Core conformance, and the additions are the four non-transitive relations and the ordering rule of APS-REC-DECISION-BINDING-BEFORE-READ. Related fixture families: receipt-decision-relation, 7 vectors. action-result-binding, 6 cases. approval-single-use, 9 presentations. The interop record cosai-ws4-149-decision-to-effect in the same suite, 11 cases, which is an interop record and not a fixture family. Exercised requirements: APS-REC-DECISION-REF-RECOMPUTED. Implemented requirements: APS-REC-DECISION-REF-RECOMPUTED, APS-REC-DECISION-BINDING-BEFORE-READ. Related implementation surfaces: agent-passport-system receipt-core 7.2.0 (TypeScript) and 4.2.0 (Python) for the receipt-to-decision binding and its temporal relation, no released package for the remaining three relations.

The Exact Call An approval admits one action. The permit or narrow record of is bound to the action reference it approves, and that reference commits to the call, not to a class of calls. At the next authorization boundary the boundary MUST compare the call it is about to admit against the action the approval names, and MUST NOT admit a call whose action reference differs from it. An argument changed after the decision produces a different action reference, so the comparison catches it without any separate argument-level rule. A refusal on that ground is a finding in its own right and the boundary SHOULD record the cause it attributes the refusal to. Where a refusal carries no attributed cause, a verifier MUST NOT read it as a finding about the exact call, because a refusal on its own does not say which boundary refused or why. What this subsection does not establish. It does not establish that admitting the call was the right decision under whatever policy governs the deployment. A call can match its approval exactly and still be a policy mistake. It does not establish that the arguments mean what the requesting agent intended them to mean. The comparison is between references over canonical bytes, not between intentions. Requirement. APS-ENF-EXACT-ACTION-MATCH, the boundary compares the call it is about to admit against the action the approval names and admits no call whose action reference differs. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: approval-single-use, action-result-binding, actionref-canonical, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: no released package for the boundary-side comparison. agent-passport-system 7.2.0 (TypeScript) and 4.2.0 (Python) recompute the action and decision references the comparison reads.

Bypass and the Mediation Assumption This document establishes that a governed path was valid. It does not establish that no other path reached the same effect. That assumption is load bearing, and a deployment that does not hold it loses the third relation of and nothing else in this document replaces it. A verifier that cannot establish coverage over the paths to an effect MUST NOT report that the effect was reached only through the boundary that admitted it. One observed use of a path that did not pass the boundary settles that finding negatively on its own. The absence of an observed alternate path settles nothing about paths outside what was actually observed. A coverage premise is supplied to the verifier and is not established recursively by the same check. Where one is supplied, it MUST name the scope it covers and the claim instance it is bound to, and a premise whose scope or claim differs from the one being evaluated leaves the finding not established rather than settled either way. A premise that is asserted rather than established is not a premise for this purpose. A verifier that holds the boundary's admission state MUST resolve a claim that a credential use went through the boundary to the admission that covers it. Where that verifier holds the admission state and the claim resolves to no admission, the claim is malformed input, not a weaker finding, because accepting it would let a relabelling turn a negative finding into an unsettled one. Where the boundary's admission state is not available to the verifier, the coverage claim is not established, and the verifier reports neither a governed path nor a malformed claim. What this subsection does not establish. It does not establish that no alternate path exists anywhere. A coverage premise is scoped, and a path outside that scope is a path the verifier did not look at, in either direction. It does not establish that the boundary is the only way to reach the effect. It does not enumerate paths, and nothing here is a completeness claim. Requirements. APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM, a verifier that cannot establish coverage over the paths to an effect does not report that the effect was reached only through the boundary that admitted it. APS-ENF-COVERAGE-PREMISE-SCOPED, a coverage premise names the scope it covers and the claim instance it is bound to, and a premise whose scope or claim differs leaves the finding not established. APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION, a verifier holding the boundary's admission state resolves a claim of a governed path to the admission that covers it and treats a claim resolving to no admission as malformed input, and where that state is not available to the verifier the coverage claim is not established. All three are specified, not exercised: the interop record settles the negative direction on an observed alternate path and no vector establishes coverage. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: cached-authorization-revocation, runtime-authority-denial-continuity, conflicting-status-sources, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: no released package.

Effect Verification An action-result record attests what the enforcement boundary observed after dispatch, as states. A verifier MUST NOT report an effect as externally established from an action-result record alone, whatever its status member says and whatever effect_ref it carries. Where a deployment compares an executing tool's own report against a read-back obtained independently of that tool, three outcomes follow. Where the two agree, the verifier may report agreement between two records. Where they disagree, the verifier MUST NOT report the effect as established. Where the read-back cannot be obtained, the verifier MUST report the effect finding as not established and MUST name the source it could not obtain. A runtime status value that names its own indeterminacy is evidence about the run. A verifier MUST NOT read it as a report about the effect finding, in either direction. The two are different objects: one says what the executing system observed, the other says what the evidence establishes. What this subsection does not establish. Agreement between a self-report and a read-back does not establish that the action under test caused the state read back. Something else may have produced the same state, or the state may have held before the call ran. It does not establish that the read-back source is trustworthy. A verifier that treats the read-back as the arbiter is reporting agreement between two records and not ground truth. Establishing the standing of the read-back source is a separate question this document does not answer. Requirements. APS-EVID-EFFECT-NOT-FROM-RESULT, a verifier does not report an effect as externally established from an action-result record alone, whatever its status member says. APS-EVID-READBACK-OUTCOMES, disagreement between a self-report and an independent read-back does not establish the effect, and an unobtainable read-back gives not established with the unobtainable source named. Both are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: action-result-binding, lifecycle-evidence-and-record, accountability-record, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: no released package.

When the Evidence Is Not Enough A finding about any of the relations of has three outcomes and not two. The property is established, the property is settled negatively, or the evidence does not settle it. The third is not a weak form of the second. It is a statement about the verifier's evidence, not a statement about the world. A verifier reporting that the evidence does not settle a property MUST name what is missing, and the name MUST identify a source, a freshness bound or a coverage claim rather than restating the property. A caller MUST NOT collapse that outcome into either of the other two. A deployment MAY deny an action on it, and the denial states the unsettled property as its reason. False and not established stay apart in the record. A verifier that establishes an alternate path was used reports a negative finding. A verifier that cannot establish coverage reports that it cannot. A record that writes the second as the first claims a finding nobody made, and a record that writes the first as the second loses one. What this subsection does not establish. It does not define a code vocabulary for what is missing. The names a verifier reports are its own and are not protocol constants. It does not say how a deployment should act on an unsettled finding beyond permitting denial. It does not make an unsettled finding a defect in the records that were presented. Requirement. APS-EVID-MISSING-NAMED, a verifier reporting that the evidence does not settle a property names what is missing, and the name identifies a source, a freshness bound or a coverage claim rather than restating the property. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: activation-not-established, conflicting-status-sources, revocation-resolution-forward-compat, lifecycle-evidence-and-record, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: agent-passport-system lifecycle-state 7.2.0 (TypeScript) and 4.2.0 (Python), both experimental, for the verdict and boundary-outcome vocabulary, no released package for the decision-to-effect properties.

Execution States That Are Not Synonyms Eight findings about one action are routinely written as if they were one. They are not, and a record that uses one name for another loses the distinction permanently.

authorized

A boundary evaluated the policy chain and issued an approval bound to the action.

admitted

That approval was consumed at the next authorization boundary, after the rechecks requires.

dispatch attempted

The boundary handed the call onward. Nothing about the downstream system follows from this alone.

downstream response observed

The boundary observed a response. This is what an action-result record attests.

effect externally established

Evidence resolved outside the boundary establishes the effect. This needs and is never carried by the record alone.

settled

A reservation the approval created against a bounded quantity was closed out at the amount actually used.

compensated

A later action reversed or offset the effect. This is its own action with its own authorization.

unknown

The boundary reached no observation. This is the status member value an action-result record carries for that case.

A verifier MUST NOT report one of these findings from evidence that establishes another. In particular, it MUST NOT report an effect externally established from an admitted approval, and MUST NOT report an action admitted from an approval that was issued. This document defines no member name, enumeration or wire encoding for the eight. The status member of an action-result record carries succeeded, failed and unknown, as defines, and those three do not partition the list above. Settled and compensated are stated here because the distinctions are real in the case corpus, and no fixture family in the conformance suite exercises either of them. They are informative in this document for that reason. What this subsection does not establish. It does not add a state machine. It does not require a deployment to record all eight, or to record any of them as a distinct artifact. It does not establish that the eight are exhaustive. Requirement. APS-EVID-STATES-NOT-SYNONYMS, a verifier does not report one of these findings from evidence that establishes another, and in particular reports neither an effect externally established from an admitted approval nor an action admitted from an approval that was issued. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. The feature covers authorized, admitted, dispatch attempted, downstream response observed, effect externally established and unknown. Settled and compensated are informative here, because no family exercises either. Related fixture families: approval-single-use, action-result-binding, cached-authorization-revocation, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: no released package.

An Indeterminate Result After Dispatch An action-result record with status unknown says the boundary reached no observation. It does not say the effect failed to occur, and a verifier MUST NOT read it as either outcome. A consumed approval admits no further dispatch. A later attempt MUST obtain a fresh authorization decision and MUST NOT reuse the consumed approval, which already makes unusable a second time. The rest of this paragraph is informative. A deployment that reaches the same effect by a different call, a different tool or a different path has not continued the first attempt, and the rule above still applies to each attempt on its own, because it is stated on the approval a boundary consumed. This revision defines no identity for an effect, so a verifier cannot establish that two calls reach one effect, and the rule is not stated over an effect identity. Where the action carries a reversibility ceiling at which no compensating action exists, a deployment that retries on an unknown result risks a second effect it cannot undo, and the record of the first attempt does not say whether the first effect occurred. This document states no normative retry rule for that case. No fixture family exercises one, and the deduplication mechanisms deployments use for it, including idempotency keys and at-least-once delivery, resolve to execution behaviour rather than to an authority finding. The case corpus records them as boundary cases for that reason. Compensation is a new record. A compensating or reversing action is separate authority with its own authorization boundary and its own records, and its record refers to the prior action rather than amending it. A later finding about an earlier action, including a finding that the earlier effect did occur, is recorded the same way. A verifier MUST NOT treat a later record as having replaced an earlier one, and both MUST remain independently verifiable. Whether an operation interrupted at an authorization boundary resumes, restarts, compensates or stops is open and is not settled here. What this subsection does not establish. It does not establish that a compensating action exists for any effect, or that a party holds authority to take one. It does not define a record type for compensation. It does not establish what the first effect was. An unknown result stays unknown until evidence outside the record set settles it, and a compensation record does not retroactively settle it. Requirements. APS-ENF-RETRY-NEW-DECISION, a consumed approval admits no further dispatch, and a later attempt obtains a fresh authorization decision and does not reuse the consumed approval. APS-ENF-COMPENSATION-NEW-RECORD, a compensating action carries its own authorization boundary and its own records, a verifier does not treat a later record as having replaced an earlier one, and both remain independently verifiable. Both are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: authority-epoch-rollback, conflicting-status-sources, runtime-authority-denial-continuity, approval-single-use, action-result-binding, and the interop record cosai-ws4-149-decision-to-effect in the same suite, which is an interop record and not a fixture family. Implemented requirements: none. Related implementation surfaces: no released package.

The Reservation and Retry Contract This subsection is informative. It adds no requirement. It reads four sections of the closed core together and states the single contract they hold between them, because those four sections are where an implementer most often assembles two contracts by mistake. The reservation contract is the core's, and it has four moments. Reserve at approval: places the reservation against the boundary-held cumulative total at the moment the approval is issued, and requires the reservation to succeed against every bounded ancestor in the selected chain before dispatch. Complete at admission: requires the boundary to verify the approval has not expired, atomically consume its receipt_id, recheck time and revocation state, and complete any spend reservation, all at the moment the approval is consumed to admit dispatch. Settle after the result: moves every ancestor counter from reserved to committed on successful settlement. Release only before dispatch or on trusted evidence that dispatch did not occur, which is the only release permits. The reservation is keyed by action_ref and its footprint is the action_ref, the unit, the amount and the set of bounded ancestor delegation identifiers. A request presenting a footprint already reserved and not yet settled or cancelled is a retry of the same reservation and the boundary reserves no second amount for it. A request under the same action_ref whose unit, amount or bounded ancestor set differs is conflicting reuse and is rejected. An idempotent reservation lookup is not permission to dispatch again. That is entailed by , under which only an approval that has neither expired nor been consumed admits dispatch. Recognising a footprint tells the boundary that it already holds a reservation. It does not tell the boundary that the approval is still unconsumed, and the approval is what admits dispatch. The three identities are separate and stay separate: the reservation footprint, keyed by action_ref, the consumable approval identity, keyed by the policy-decision record's receipt_id, and the agent nonce, which the intent record carries inside the action input object that action_ref commits to and which the boundary refuses when the same agent reuses it inside the deployment's replay window, as requires. A consumed approval does not become reusable because its reservation is still outstanding. What this leaves open is the recovery contract. Nothing in this revision says what a boundary does after a crash between consumption and dispatch, how two concurrent admissions on one approval resolve beyond the requirement that consumption be atomic, or how an operation resumes without repeating its effect. carries that, and it is the one thing a durable admission record would have to define before it could enter. Requirement identifiers for the four core moments, so that a claim can cite them: APS-ENF-RESERVE-AT-APPROVAL, APS-ENF-COMPLETE-AT-ADMISSION, APS-ENF-SETTLE-AFTER-RESULT, APS-ENF-RELEASE-PRE-DISPATCH-ONLY, and APS-ENF-CONFLICTING-REUSE-REJECTED. All five are requirements of the closed core, restated here and not added here. records their coverage. What this subsection does not establish. It does not establish that any released package holds a reservation ledger, and none does, because the enforcement boundary is not a published package. It does not establish that a deployment's ledger is linearizable, which requires for live spend status to be determinate at all.

Chain Validity Is Not Permission to Execute This subsection is informative and states no requirement. No fixture family in the conformance suite exercises it, which is a fact about the corpus and not the reason. Whether an authority chain is valid and whether the action it authorizes is permitted by rules outside that chain are separate findings. A restriction from outside the chain can block execution with no event anywhere in the chain, and removing the restriction restores execution on the unchanged chain without creating new authority. A verifier that returns one of those findings is not to be read as having answered the other. The reason-code rule of is what keeps them apart in a record: a restriction from outside the chain does not make the chain invalid, it denies the action. Block and release are not always symmetric. Where what changed is which party holds the resource rather than a restriction on reaching it, no release restores anything, and the case corpus carries that counterexample against any symmetric reading. Where the represented principal itself changes rather than being restricted, this is not the finding that applies. What this subsection does not establish. It does not ask a verifier to decide whether an action is lawful. It does not claim a restriction pauses descendants. It says nothing about whether any legal doctrine applies to an AI agent, and no case behind it is a source of rules for one.

A Valid Grant Can Be Unexecutable This subsection is informative and states no requirement. No fixture family in the conformance suite exercises it, which is a fact about the corpus and not the reason. An authority artifact can be valid, unexpired, unexhausted and under no live restriction while the target, the executor or the capability it names no longer exists. The artifact verdict is unchanged. The execution attempt fails, and the record carries the referent that could not be resolved. A verifier reporting such an artifact invalid, expired, revoked or suspended reports a lifecycle event that did not happen. Unexecutable is an execution outcome and not an artifact verdict. This document proposes no additional verdict for it. What this subsection does not establish. It does not prescribe which party re-points a grant whose referent is gone, or whether that party may. It does not claim the authority is unaffected in the world, since a grant naming a permanently absent executor may well be worth revoking. It claims only that nothing in the grant's own lifecycle has changed. It does not cover a referent that changed rather than vanished.

Worked Examples The five examples below are informative. Each carries a state trace with six columns, and each walks one situation through the records this document defines, the lifecycle transition it turns on, the decision, the point at which an approval is consumed to admit dispatch, the result, and what an offline verifier holding only the records can and cannot conclude. Each names the case identifiers in that the situation comes from and the fixture families that exercise the shapes involved. Naming a family records that vectors for that shape exist. It does not make any statement in an example a conformance result. The examples use no record shape this document has not already defined. Field names are those of the authority delegation record in and of the receipt envelope and stages in and . Verdict and outcome names are those of , and the lifecycle states are those of . Reason codes are the module strings the reference implementations carry.

A Purchasing Grant Narrowed by a Subagent A principal issues a root authority delegation to a procurement agent. Its scope facet grants commerce:checkout, its spend facet bounds per_action and cumulative in minor units of one currency, its depth facet leaves two hops remaining, and its time facet closes at the end of the quarter. The procurement agent issues a child delegation to a subagent that handles one supplier. The child narrows scope to the one supplier's catalogue, lowers per_action, keeps cumulative at or below the parent, and sets depth remaining to one. The lifecycle transition is issuance, and nothing about the parent changes. The child is a new artifact whose issuance validity rests on the issuer's standing at the moment it was signed. Because the issuer checks the parent's signature and temporal validity before signing, per the issuance obligations in , a child under an expired parent is refused at the issuer rather than left for a later verifier. The subagent then submits one purchase. It emits an action-intent record whose subject_agent is itself, whose delegation_ref is the child delegation, and whose action_ref commits the action input object. The enforcement boundary evaluates the single root-to-leaf chain the subagent presented, issues a policy-decision record with verdict permit, and reserves the amount against the boundary-held cumulative total. At the next authorization boundary, which is the moment that approval is consumed to admit dispatch, the boundary rechecks time and revocation state, atomically consumes the decision's receipt_id, and dispatches. The action-result record carries status succeeded and an effect_ref. Three narrowing failures are what this shape is worth walking. A child that widens scope is no wider than its parent only when every component comparison succeeds, so a widened child yields scope_not_covered and an invalid chain. A child issued past the parent's declared depth is a distinct failure from a scope failure, which is LC-H-008. A subagent that holds a scope and hands it to a process it spawned has not thereby acquired authority to confer it, which is LC-E-006. If the subagent also holds a second chain from an unrelated root, the two are never combined: each action selects one chain, and an amount above the presented chain's own ceiling but below the two ceilings added together is denied, with chain_set_presented_as_one where a caller presents both as one. LC-C-012 is the case that forces this to be a refusal to union rather than a refusal to coordinate. The trace below has six columns, split into two tables keyed by step so that each half fits the page width. Columns one to three are the state before the step, the artifact or event, and the verifier rule that applies. Columns four to six are the new authority state, the next action the state permits, and the evidence available afterwards. Purchasing grant narrowed by a subagent: state before, event, and verifier rule

Step	State before	Artifact or event	Verifier rule
1	no authority for the subagent	root AuthorityDelegationV1 signed by the principal	issuer standing is fixed at issuance
2	root valid, two hops remaining	child AuthorityDelegationV1 narrowing scope, per_action and depth	no facet wider than the parent under its component order
3	chain valid to the leaf	action-intent receipt committing the action reference	intent is a declaration and not an admission
4	chain valid, no approval	policy-decision receipt, verdict permit, amount reserved	one root-to-leaf chain, no union across chains
5	approval unconsumed	consumption at the enforcement boundary	recheck time and revocation, consume atomically, complete the reservation
6	dispatched	action-result receipt, status succeeded, effect reference present	an observed outcome is not an external effect

Purchasing grant narrowed by a subagent: new state, permitted next action, and evidence afterwards

Step	New authority state	Permitted next action	Evidence afterwards
1	root valid	issue a child inside the root facets	the signed root
2	chain valid to the leaf	declare an intent	two signed delegations
3	unchanged	seek a decision	the intent receipt
4	approval exists and is unconsumed	present the approval at the boundary	the decision receipt
5	approval consumed	dispatch the exact bound call	none durable, the approval-state axis stays not established
6	unchanged, the reservation settles	resolve the effect evidence	the three-record chain

An offline verifier holding the two delegations, the three receipts and the action input object can conclude that the chain narrows at each hop, that the receipt identifiers and signatures recompute, that the action binding holds because the supplied action input object's agent_id equals the record's subject_agent, and that the decision reference rebuilds from the decision evidence. It cannot conclude that the approval was consumed once, because whether a decision's receipt_id has been consumed is boundary state and not content of the record, so the approval-state axis is not established. It cannot conclude that the cumulative total across the subtree was correct, because the boundary holds that total. It cannot conclude that the purchase reached the supplier, because the action-result record attests to what the boundary observed. Families. lifecycle-subdelegation-edges, 13 cases. lifecycle-conferral-without-authority, 10 vectors. single-chain-selection, 6 cases. chain-selection-no-union, 11 cases. lifecycle-purpose-exhaustion, 21 events, on an unmerged candidate branch. issuance-refusal-expiry, two parts, issuance and verification. What this example does not establish. It does not establish that the subtree total was enforced, that the supplier received anything, or that the deployment's own facets are the seven this document defines. It does not establish that the child was the only child the parent issued.

An Employee Leaves with In-Flight Descendant Work A bookkeeping agent runs under a chain rooted in an organization and issued by an employee acting for an office. Descendants of that chain have work in progress. The employee resigns. The departure is not a revocation. It is an external event, and its effect depends on the authority relationship and the rules that govern it. Two findings stay separate. Whether the grant was validly issued turns on the issuer's standing at issuance and does not change with the departure. What the grant continues to depend on is a separate question about the present. Where the record cannot distinguish the principal, the issuer and the relevant dependency, continuation has not been established, and not established is ignorance rather than a finding that the chain is invalid. Suppose the organization revokes the employee's issuing authority. At the next authorization boundary, the old grant cannot authorize any new effect. Once a verifier establishes the revocation under the freshness rules this document states for chain verification, every chain containing the revoked delegation is invalid with reason revoked, which is , whether or not any record names the descendant and whether or not the descendant was ever enumerated. Replacement authority is a fresh grant from a principal who currently holds authority, and the successor's grant covers what the successor issues, not the departing principal's whole tree. What happens to the work already in flight is a different question, and this document does not answer it in general. It answers one part. Effects already completed stand. A decision already consumed to admit dispatch is not undone by a later revocation, and an action-result record issued after the consumed decision's valid_until has passed is not invalid on that ground alone, because execution and observation can complete after the approval is consumed. Whether the operation resumes, restarts, compensates or stops is open, and states why. LC-B-029 supplies one instrument's concrete boundary, a receiving institution's acceptance, after which a mid-flight authority change no longer stops the order. LC-E-013 is the same interval from the agent's side, where invalidation arrives mid-run rather than at the next gateway check. A handover can be ordered differently from a compromise. A planned handover may require the incoming holder's acknowledgment, with authority staying with the outgoing holder until it arrives, which is LC-C-014. A compromised principal may call for revoking first and accepting a gap. In neither case does the old chain remain the basis for continuity. The trace below has six columns, split into two tables keyed by step so that each half fits the page width. Columns one to three are the state before the step, the artifact or event, and the verifier rule that applies. Columns four to six are the new authority state, the next action the state permits, and the evidence available afterwards. Employee leaves with in-flight descendant work: state before, event, and verifier rule

Step	State before	Artifact or event	Verifier rule
1	chain valid, issued by the employee for an office	no event	issuance standing does not change with later events
2	valid	the employee resigns, no APS record exists	a departure is not a revocation
3	valid	the organization revokes the issuing authority	an established revocation invalidates every chain containing it
4	invalid	action-result receipt for work admitted before the revocation	execution and observation complete after admission
5	invalid	a new grant from a principal who currently holds the authority	a successor does not inherit the predecessor tree

Employee leaves with in-flight descendant work: new state, permitted next action, and evidence afterwards

Step	New authority state	Permitted next action	Evidence afterwards
1	valid	act under the chain	the chain
2	valid, continuation not established where the evidence cannot separate principal, issuer and dependency	act only where continuation is established	none inside APS
3	invalid	none under this chain	the revocation record and a status observation
4	invalid, the completed effect stands	none under the old chain	the receipt chain of the earlier action
5	a separate chain is valid, the old chain stays invalid	act under the replacement chain	the new delegation records

An offline verifier holding the chain, a revocation record in a format its profile defines, and the receipts can conclude that the chain is invalid from the point it established the revocation, and can conclude from the receipts which actions the boundary recorded before that point. It cannot conclude that the set of descendants processed by a teardown was every descendant at the relevant moment, because that is a completeness claim with a basis this document does not define. It cannot conclude, from an audit window with no records in it, that nothing happened in that window, which is LC-F-027. It cannot conclude when any particular relying party learned of the revocation, because recording a transition and observing it are different events. Families. sponsor-handover, 6 cases. lifecycle-organization-events, 35 cases. lifecycle-principal-events, 32 cases. ancestor-revocation-chain, 4 cases. cached-authorization-revocation, 9 cases. lifecycle-evidence-and-record, 12 cases. What this example does not establish. It does not establish what the in-flight operation should do, it does not establish that the teardown was complete, and it does not establish that any relying party had notice. It states nothing about whether any legal rule about human agents applies here.

Two Independent Holds and One Clears One grant acquires two causes at once, from two sources. A regulator imposes a suspension. The organization's own compliance function imposes a second, unrelated suspension. The chain itself is untouched and every signature still verifies. The lifecycle transition is suspension, not revocation, which is and . Suspension pauses the use of authority and of what depends on it, and it is releasable. Revocation is terminal for the artifact it names. The verdict is suspended, and it names which causes remain rather than collapsing to one flag, because causes compose and each release has to come from a source with standing over that cause. The regulator's release arrives. It is genuine, its signature verifies, and the standing registry places its signer over the cause it releases. That cause clears. The verdict stays suspended, because the compliance suspension still stands, and a release from one source does not reach a cause imposed by another. Two further shapes matter. A release from a source the registry does not place over a cause does nothing to that cause even when the record is genuine. A release from a source that does hold standing over a cause it did not itself impose is effective, because standing is not authorship. LC-B-024 is the case that forces independent release, and LC-B-011 is the case where an externally imposed restriction needs an equally external release trigger. Where only a restriction is left, the verdict is restricted rather than suspended, because authority continues in reduced form under a live constraint that does not pause it. A composition rule that is not satisfied does not make any artifact invalid. It denies the action, with reason composition_not_satisfied, and LC-C-011 is why a concurrence requirement is a gate at the next authorization boundary rather than a second chain to combine with the first. Two timing shapes sit next to this one. A revocation recorded while the grant was suspended still makes the chain invalid after every cause has been released, and an unresolvable revocation answer leaves the chain not established rather than exercisable. A queued action that outlasts a suspension needs a live check when it fires rather than only at the moment it was queued, which is LC-E-034, a reviewed hypothetical whose point is that a scheduler with no view of suspension state can reach the right answer for the wrong reason. The trace below has six columns, split into two tables keyed by step so that each half fits the page width. Columns one to three are the state before the step, the artifact or event, and the verifier rule that applies. Columns four to six are the new authority state, the next action the state permits, and the evidence available afterwards. Two independent holds and one clears: state before, event, and verifier rule

Step	State before	Artifact or event	Verifier rule
1	chain valid, no causes	no event	chain verification
2	valid	a suspension cause record from the regulator	causes standing against one artifact are a set
3	suspended, one cause	a second suspension cause from the compliance function	causes compose and a count does not satisfy the reporting rule
4	suspended, two causes	a release record from a signer the standing registry places over the first cause	each named cause is decided independently, standing is resolved outside the record
5	suspended, one cause	the remaining cause is of kind restriction only	a restriction leaves the artifact in force
6	restricted	a revocation record dated inside the suspension	illustrative deployment outcome, the chain result reported ahead of the pause state

Two independent holds and one clears: new state, permitted next action, and evidence afterwards

Step	New authority state	Permitted next action	Evidence afterwards
1	valid	act under the chain	the chain
2	suspended, one cause named	none	one cause record
3	suspended, two causes named	none	two cause records
4	suspended, one cause remaining	none	two causes and one release
5	restricted	act within the live constraint	the cause set as it stands
6	invalid	none	the revocation record

The cell marked illustrative deployment outcome is one deployment's outcome and not a rule of this document. requires a verifier not to report the pause state as if it answered the chain question, and states no order in which the two findings are reported. An offline verifier holding the chain, the two cause records and the one release can conclude that the chain's signatures verify, that two causes attached, and that one release came from a signer the supplied standing registry places over the cause it names. It cannot conclude that no further cause exists, because it can only report on the causes it holds. It cannot conclude a precedence order among causes, because none is defined. It cannot conclude that the grant is exercisable now, because that is a boundary outcome against live state. Families. suspension-cause-composition, 16 cases and 5 gates. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-time-and-scheduling, 61 vectors. lifecycle-multiple-principals-and-conflict, 92 vectors. lifecycle-outside-the-chain-standing, 22 vectors. What this example does not establish. It does not establish a precedence order among causes, it does not establish that the cause set it holds is complete, and it does not establish that any release restored an exercisable state.

A Cross-Org Action Needing Separate Human Approval and One-Time Admission A settlement adds a requirement that a named official personally certify a defined category of transactions, for the life of the settlement. It touches no existing delegation. LC-B-026 is that shape: a party outside the principal-agent relationship injects a new approval gate into an otherwise unmodified, valid chain. The chain stays valid. A transaction inside the settlement's scope is no longer sufficient on the chain alone. The lifecycle state is restricted rather than suspended, because the added gate does not pause the grant. A gateway that rechecks only the chain keeps authorizing exactly the transactions the settlement was meant to catch, because nothing in the delegation changed. An agent in one organization then submits an action against a target in another. It emits an action-intent record. The enforcement boundary evaluates the chain, the applicable policy version, and the additional evidence its profile requires for that category, and issues a policy-decision record with verdict permit or narrow. That record is the consumable approval. Its receipt_id is the consumable identity, its action_ref is the binding to the exact action, and its valid_until is the bounded lifetime. At the next authorization boundary, the boundary verifies the approval has not expired, atomically consumes its receipt_id, rechecks time and revocation state, and completes the spend reservation. An approval already consumed, expired, or failing that recheck does not admit execution. A deny record is terminal and is never consumed as an approval. Consumption is what makes the admission one-time, and an approval that is still cryptographically valid after consumption does not admit the action a second time. This document specifies the single-use approval bound to an action_ref and the rules under which it is consumed. It does not specify that the approver be a human distinct from the executing agent, it does not specify a designation of such a requirement carried inside delegated authority, and it does not specify preservation of such a designation across narrowing. A deployment that needs those states them in its profile. states them as requirements on some mechanism and selects no mechanism. The trace below has six columns, split into two tables keyed by step so that each half fits the page width. Columns one to three are the state before the step, the artifact or event, and the verifier rule that applies. Columns four to six are the new authority state, the next action the state permits, and the evidence available afterwards. Cross-org action with separate approval and one-time admission: state before, event, and verifier rule

Step	State before	Artifact or event	Verifier rule
1	chain valid	an externally imposed certification requirement, touching no delegation	illustrative deployment outcome, a restriction from outside the chain denying the action while the chain stays valid
2	restricted	action-intent receipt	intent is not admission
3	restricted	policy-decision receipt, verdict permit, issued after the required evidence resolved	the decision commits to the evaluated authority state, the policy input and the decision context
4	approval unconsumed	consumption at the enforcement boundary	single use, recheck, complete the reservation
5	approval consumed	the same approval presented a second time	an already consumed approval admits nothing

Cross-org action with separate approval and one-time admission: new state, permitted next action, and evidence afterwards

Step	New authority state	Permitted next action	Evidence afterwards
1	restricted	obtain the certification	none inside APS
2	restricted	seek a decision	the intent receipt
3	approval exists and is unconsumed	present the approval at the boundary	the decision receipt and the resolved evidence reference
4	approval consumed	dispatch the exact bound call	none durable
5	unchanged	obtain a fresh decision	none

The cell marked illustrative deployment outcome is one deployment's outcome and not a rule of this document. is informative and states no requirement. An offline verifier holding the intent, decision and result records, the chain and the decision evidence can conclude that the decision commits to the action, the evaluated authority state, the policy input, the decision context and the decision output, because the decision reference rebuilds from those and the record's own action reference. It can conclude that the decision's validity window closed strictly after the receipt was issued. It cannot conclude that the approval was consumed once, or consumed at all, because consumption is boundary state keyed by the approval's receipt_id and the approval-state axis is not established without access to it. It cannot conclude that the named official's certification was genuine unless the evidence reference for it resolves under the rules its artifact_type names, and a verifier that does not resolve evidence reports that axis as not attempted, which is indeterminate. Families. approval-single-use, 9 presentations and a declared defective fail set of 3. arap-binding, 12 denial-binding cases, 10 approval cases and 5 enforcement-point fallback cases, candidates against an unmerged profile. receipt-decision-relation, 7 vectors. lifecycle-policy-change, 13 presentations. lifecycle-legal-regulatory-events, 44 vectors. What this example does not establish. It does not establish that the approval was consumed once, that the approver was a human, that the approver was distinct from the executing agent, or that the two organizations share a trust anchor. It states nothing about whether any legal rule about human agents applies here.

A Post-Dispatch Unknown That Cannot Be Retried An approval is consumed, the boundary dispatches, and the target system returns nothing the boundary can classify. The connection drops after the request was accepted for processing. The boundary observed a dispatch and did not observe an outcome. The action-result record carries status unknown. For unknown, both effect_ref and error_code are null, because the boundary has no effect to digest and no stable failure identifier to name. That is the honest record. Writing status failed would assert a finding the boundary does not hold, and writing succeeded with an invented effect_ref would assert one it cannot ground. The approval is gone. Its receipt_id was atomically consumed at the admission point, so it cannot admit a second dispatch, and no rule in this document restores a consumed approval. A retry is a new action, needing a new intent, a new decision and a new admission, evaluated against current authority and current policy. Whether the operation should be retried at all is not an authority question. It depends on whether the effect is idempotent at the target, and two boundary cases record why that belongs to the target rather than to the delegation layer. LC-E-010 is an idempotency-key retry that returns the original result instead of re-executing. LC-E-011 is a reused key with changed parameters that errors outright rather than silently doing either thing. A valid grant can be unexecutable, which is . Its verdict does not change when its target, its named executor or its named capability no longer resolves, and the unresolvable referent belongs in the record. LC-E-002 is that shape. Unexecutable is an execution outcome and not a verdict on the artifact. The trace below has six columns, split into two tables keyed by step so that each half fits the page width. Columns one to three are the state before the step, the artifact or event, and the verifier rule that applies. Columns four to six are the new authority state, the next action the state permits, and the evidence available afterwards. Post-dispatch unknown that cannot be retried: state before, event, and verifier rule

Step	State before	Artifact or event	Verifier rule
1	approval unconsumed	consumption at the enforcement boundary	single use, recheck, complete the reservation
2	approval consumed	the call is handed to the effect adapter	holding the input does not establish that dispatch was attempted
3	dispatched	action-result receipt, status unknown, effect reference and error code null	unknown is an outcome and not the absence of one
4	unknown result held	no event	a reservation is released only before dispatch or on trusted evidence that dispatch did not occur
5	unknown result held	a new action-intent receipt for the same effect	a further attempt is a new action needing a fresh authorization decision
6	unknown result held	separately resolved evidence about the target system	an external effect is never inferred from the result record

Post-dispatch unknown that cannot be retried: new state, permitted next action, and evidence afterwards

Step	New authority state	Permitted next action	Evidence afterwards
1	approval consumed	dispatch the exact bound call	none durable
2	unchanged	wait for a result	none until a result
3	unchanged	none follows automatically	the three records
4	the reservation stays outstanding	obtain settlement evidence	boundary ledger state only
5	unchanged	a fresh decision if policy admits one	the new intent receipt
6	unchanged, the external-effect axis moves for the claim the evidence supports	settle or compensate	the resolved evidence

An offline verifier holding the three receipts can conclude that the result commits to the decision the boundary consumed, because the result's decision reference equals that decision's and step 8 recomputes it. Predecessor continuity is not established. Each record's prev names its predecessor, and neither nor step 9 requires a verifier to resolve prev or to report a failure where it does not match, which records as held. It can conclude that the boundary recorded an unknown outcome at a stated time. It cannot conclude whether the external effect occurred, because status unknown records the absence of an observation rather than the absence of an effect, and these are not the same. It cannot conclude that the effect did not occur. It cannot conclude what the grant was used for over its whole valid window from the fact that the grant is valid, which is LC-D-025. It cannot read an empty window in an evidence store as proof that nothing happened in it, which is LC-F-027. Resolving the outcome needs separately resolved evidence about the external system, and until that resolves the outcome stays not established with the missing source named, as states. Families. action-result-binding, 6 cases. receipt-decision-relation, 7 vectors. runtime-authority-denial-continuity, 9 cases. lifecycle-evidence-and-record, 12 cases. lifecycle-infrastructure-failure, 30 cases. What this example does not establish. It does not establish whether the effect occurred, it does not establish that a retry is safe, and it does not establish that the boundary's own observation was complete.

Institutional Governance as an Authority-Source Model This section is informative. Where a rule it describes is normative, the rule is stated in the section this text cites, and naming a fixture family sets the normative status of nothing. It describes how an organization's own authority structures reach the delegation layer this document specifies. It does not specify wire formats, lifecycle or semantics for those structures. A profile has to define each projection and each containment check before monotonic narrowing can be checked across an institutional structure.

Charter, Office, Holder, Root Authority Basis, Delegation, Action Six objects, each constraining the next. A charter is the instrument that bounds what an organization may authorize. An office is a named position that carries standing authority under a charter. A holder is the party occupying an office over a stated window. A root authority basis is what a verifier accepts as the head of a chain for one action. It takes one of three forms: an APS root delegation whose parent identifier is null, authority imported from outside APS under an importing profile, or a trust anchor the verifier's own policy accepts. Under an institutional model the first form is the ordinary one, issued under an office's authority, and it is where the delegation layer begins. Accepting a basis does not establish which principal the authority represents, which is a separate and currently unanswered question at . This document defines no object for the step from a principal to a first authority, and nothing in this section depends on one. A delegation is one narrowing hop. An action is what an enforcement boundary decides. The holder is not the office and the office is not the charter. Three findings that an implementation will be tempted to merge stay apart. Whether a party currently holds an office. Whether the office carries the authority the grant claims. Whether the charter permits the office to carry it.

Monotonic Projection An institutional layer reaches the delegation layer by projecting its authority into the faceted authority vector of and applying the component orders at each layer. A charter constrains offices, an office constrains delegations, and a delegation constrains actions. Authority decreases at each transfer point and never increases. A projection is lossy where the institutional layer carries a dimension the vector has no facet for. A profile states what it dropped rather than widening a facet to absorb it, and an unprojectable dimension makes the projection unsupported rather than silently absent. A profile that invents a facet value the institutional instrument does not supply has widened authority at the projection, which is the failure this subsection names. This subsection is informative and states no requirement. No family in this suite exercises the projection itself, which is a fact about the corpus and not the reason. The component orders and the containment check a projection would have to satisfy are already specified in , and no released package projects an institutional instrument into the authority vector.

Departure and Succession A holder leaving an office is an external event. It is not a revocation, and it does not by itself remove a dependency, re-parent authority or create replacement authority. Whether a grant issued under an office survives the departure of the individual who signed it is a question the governing authority model answers. Models differ, and this document does not choose between them. Where the delegation is bound to an office, turnover moves it and the new occupant exercises it with nothing reissued. Where it is bound to an identity, turnover does not move it and the new occupant needs a fresh chain. Where the terms declare neither and the actor is not the named subject, the binding mode is not established and a verifier does not supply a default in either direction. A successor does not inherit the predecessor's delegation tree. The successor's grant covers what the successor issues, and a descendant whose ancestor artifact was revoked stays invalid until a party with current authority reissues it. A departure is not a revocation, and where the delegation is bound to the office the turnover moves it with nothing reissued. This is the rule an implementation gets wrong most often, because inheriting the tree is the behaviour that keeps an organization running and it is the behaviour that silently restores revoked authority. Informative. This subsection states no requirement, so it carries no status block and no requirement identifier. Related families: lifecycle-root-authority-succession, lifecycle-principal-events, lifecycle-organization-events, lifecycle-fiduciary-succession. Related implementation: chain verification in agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python). Office-holder records, vacancy records and binding mode are no released package.

Handover A handover replaces the party responsible for an agent while the agent keeps its identity. The agent continues. Its old authority does not survive revocation of the ancestor it depended on, and the replacement chain stands on its own because it was independently issued. A handover may require the incoming holder's acknowledgment, with authority staying with the outgoing holder until that acknowledgment arrives, rather than an instant at which one party's authority ends and another's begins. Ordering is a deployment choice. A planned handover may accept a short overlap. A compromised holder may call for revoking first and accepting a gap. In both cases the old chain must not remain the basis for continuity, and at the next authorization boundary after revocation the old grant authorizes no new effect. Informative. This subsection states no requirement, so it carries no status block and no requirement identifier. Related families: sponsor-handover, lifecycle-organization-events. Related implementation: chain verification in agent-passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python). Acknowledgment-gated handover is no released package.

Break-Glass A party outside the principal-agent relationship can hold standing to replace authority it never issued. A body appointed over the principal, a neutral forum holding a disputed root, or a collective body acting under its own composition rule are three shapes of this. Such a party issues a replacement grant on terms it supplies. It does not revive the terminated grant and it does not re-parent the old chain, so the replacement is new authority with its own scope and its own record. In this revision such a party ends the dependent authority by revoking its own ancestor grant where it holds one, or through a suspension cause under . names only the issuer for a direct revocation, and direct revocation by a party other than the issuer is open at . A collective body's own composition is a precondition for the validity of what it issued. Without the declared composition there is no body action to evaluate, which is a different finding from a defective but real action. Where a root is disputed and held by a neutral forum, its state is neither valid nor invalid. A verifier reports not established and does not pick a claimant. Informative. This subsection states no requirement, so it carries no status block and no requirement identifier. Related families: lifecycle-outside-the-chain-standing, lifecycle-fiduciary-succession. No released package resolves standing held from outside the chain.

Re-Rooting Informative. Replacing the trust root an organization's chains descend from changes which issuers a verifier accepts, which is a change to verifier trust policy rather than a lifecycle event on any artifact. A verifier can stop trusting an issuer with nothing revoked anywhere. No artifact changes and no revocation occurs. A verifier that no longer accepts the old root returns the result gives for a root a trust policy does not accept, which is invalid with a root-trust reason at the root's index. That is one verifier's finding under its own policy at one moment, and a verifier that still accepts the root returns valid on the same bytes. Those are two different statements and a record must not merge them. No family in this suite exercises re-rooting, and no released package implements it, so this document states no rule for it. A deployment that re-roots has to decide, and record, whether artifacts under the old root are reissued, carried by a cross-signature, or left to expire.

What This Section Does Not Establish It specifies no institutional wire format, no charter record, no office record and no holder registry. It does not say who publishes an office-holder registry or how a verifier comes to accept one. It does not resolve office vacancy, and it does not bound what an outgoing holder may sign before leaving. It makes no claim that a doctrine of human agency law, corporate law or fiduciary law applies to an AI agent. Those bodies of material are a source of case shapes for the questions above and nothing more. Where a case in this document derives from such material, it is a source of the question, never a source of the rule.

Protocol Bindings

MCP Binding APS specifies a binding to MCP . For this binding, an enforcement gateway mediates the privileged actions selected by deployment policy. A privileged action is any action the policy chain () is configured to evaluate, including any action whose required scope is non-empty under the Scope rules of . In an APS-mediated MCP deployment, privileged actions covered by APS policy MUST pass through the gateway, which validates the delegation chain, evaluates the policy chain, and generates signed receipts. In deployments where the gateway is the exclusive holder of the target API credentials, the agent cannot bypass the gateway for those privileged actions; this exclusivity is a deployment precondition of the kind describes, not an unconditional property of the binding.

Other Bindings This document does not specify an A2A binding. specifies a binding for OAuth identity-assertion authorization grants. Other protocol bindings are not specified here.

OAuth Identity-Assertion Grant Binding Deployments in which an agent's authority originates from an enterprise authorization system need the delegation chain to begin from that system's grant rather than from an APS-native passport. This section specifies the binding for an OAuth identity-assertion authorization grant , pinned to an identified draft version of that specification. The binding is verifier-first: the importing party verifies the external grant by that specification's own rules before any APS structure is built, and APS records the verification rather than performing it. The record of verification is a caller-signed attestation, an accountability artifact naming the grant reference and the verification time under the importing party's own key, so that the party on the hook for the verification is identifiable. The binding does not re-verify the grant, and a binding result is never collapsed to a single safe-for-execution boolean; it reports what was projected and under what basis. Two anchors are kept separate and MUST NOT be merged. The source grant reference is a digest over a committed preimage of the grant's provenance fields, its issuer, subject, grant identity, client, and audience, and never covers scope, spend, chain content, or receipt content. The delegation chain root is the canonical content digest over the APS-signed hops built under the imported grant. The first identifies where authority came from; the second identifies what was built under it; conflating them makes chain content unrecomputable from the records. Scope projection from the external grant into the APS Scope dimension is lossy, and the binding preserves the grant's authorization details verbatim alongside the projection rather than pretending the projection is complete. A spend dimension MUST NOT be invented at import: because AuthorityDelegationV1 requires all seven facets, an external grant that carries no spend semantics cannot be projected into a conforming chain root unless an importing profile supplies an explicit spend basis accepted by verifier policy; otherwise the projection is unsupported. The grant's audience is carried in the binding but not enforced by it; the relying party at the point of use MUST reject an audience mismatch.

Adapter Contracts An adapter carries APS authority into another protocol's request, or carries another protocol's authority into an APS chain. Five things can fail to survive that trip: the principal on whose behalf the action is taken, the exact action, the authority epoch the decision was made in, the purpose bound the grant carries, and the evidence the grant requires before the action is admitted. This section states what an adapter must do about a dimension that has no carrier on the far side, and then records, per target protocol, which dimensions survive and which do not. The general shape of the failure is silent widening. An adapter that drops a dimension and emits a request the far side reads as unconstrained has produced authority the APS side never granted. Recording the loss is what keeps it visible. Every binding below fills one loss model, and the model has six values. Preserved exactly, the target representation carries the semantic with no change. Transformed with equivalent semantics, the representation differs and the set of actions admitted does not. Narrowed, the target representation admits a strict subset of what the APS side admits. Omitted and irrelevant to the operation, the semantic has no carrier and the adapter has established that the operation does not depend on it. Not representable, the semantic has no carrier and the operation does depend on it. Externally resolved, the semantic crosses as a reference and the far side resolves it under rules this document does not state. Loss of a semantic required by the target operation or by the applicable profile prevents a valid result. Explicit narrowing may remain valid where the target representation preserves the narrowed semantics. Omission of a semantic established as irrelevant to the operation does not by itself prevent validity. A profile states, for each APS semantic, which of the six values applies to it, as requires.

What an Adapter Must Do With a Dimension It Cannot Carry An adapter MUST NOT produce a target-side authority that admits an action the APS authority it was built from does not admit. Where an APS dimension has no carrier in the target representation, the adapter MUST record that dimension as unsupported, and MUST NOT emit a value that a target-side evaluator reads as the dimension being satisfied. An unsupported dimension and a satisfied dimension are different findings and a verifier reports them differently. An attribute carried across by any transcription scheme satisfies a target-side predicate only when the target-side authority independently permits the action. Transcribing an attribute never supplies a scope, an audience or an actor the target-side authority does not have. Where the adapter re-expresses the action in the target's own terms, the action reference MUST be recomputed from the adapter's own payload rather than copied from the source record, and a mismatch MUST fail closed. Where an adapter carries a commitment that names a stage of a pipeline, a commitment made at one stage MUST NOT satisfy a check at another stage, and a stage name outside the closed set MUST fail rather than default to any member of the set. An adapter that maps an APS record into another stack's signed envelope MUST state the canonicalization it applies, and MUST NOT assume byte agreement with another implementation of the same canonicalization rule. Agreement on the rule and agreement on the bytes are separate facts. This subsection does not establish that any released adapter satisfies these rules across its whole surface, and it does not establish a complete list of dimensions. It names five dimensions that the corpus behind this document repeatedly showed being lost. Requirements. APS-ADAPT-NO-WIDENING, an adapter produces no target-side authority that admits an action the APS authority it was built from does not admit. APS-ADAPT-NO-SILENT-SEMANTIC-LOSS, a dimension with no carrier in the target representation is recorded as unsupported and no value is emitted that a target-side evaluator reads as the dimension being satisfied. APS-ADAPT-RECOMPUTE-ACTION-REF, where the adapter re-expresses the action, the action reference is recomputed from the adapter's own payload rather than copied, and a mismatch fails closed. APS-ADAPT-STAGE-COMMITMENT, a commitment made at one stage does not satisfy a check at another, and a stage name outside the closed set fails rather than defaulting. APS-ADAPT-CANONICALIZATION-STATED, an adapter states the canonicalization it applies and does not assume byte agreement with another implementation of the same rule. APS-ADAPT-STAGE-COMMITMENT is exercised by k8s-receipt-admission-stage-negatives, whose five candidate vectors reject a cross-stage digest, a mismatched stage kind and an unknown stage name. The other four are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: cross-stack, 11 sub-families at the pinned commit. actionref-canonical, 6 vectors. k8s-receipt-admission-stage-negatives, 5 vectors. canonical-bytes, 10 vectors. Exercised requirements: APS-ADAPT-STAGE-COMMITMENT. Implemented requirements: APS-ADAPT-RECOMPUTE-ACTION-REF. Related implementation surfaces: agent-passport-system 7.2.0 (npm) for the adapter surfaces, and agent-passport-system 4.2.0 (PyPI) for the action reference forms only.

Model Context Protocol MCP carries a tool name and an arguments object. The exact action survives, because a name and an arguments object are enough to recompute an action reference over the adapter's own payload. Nothing else on this list has a carrier defined by the base protocol. The principal, the authority epoch, the purpose bound and the required evidence are unsupported unless a profile assigns them keys in the _meta object, which the specification describes as the general extension point: "The _meta property/parameter is used by MCP to allow clients and servers to attach additional metadata to their interactions." An adapter that assigns _meta keys carries a further obligation that is described in : the component that checks the request and the component that runs it may not receive the same bytes. The requirement that privileged actions pass through the boundary, stated in , has no fixture in the conformance suite. The suite's coverage inventory records it as not exercised, since no vector asserts which actions were routed through a boundary. It is restated here as a deployment precondition and not as an exercised requirement. Loss model. Exact action: preserved exactly, because the tool name and the arguments object are enough to recompute an action reference over the adapter's own payload. Principal, authority epoch, purpose bound and required evidence: not representable in the base protocol, and preserved only where a profile assigns them keys in the extension object, in which case they are externally resolved by whatever holds that profile. This subsection does not establish that a profile assigning _meta keys is interoperable with any other profile doing the same, and it does not establish that an MCP server honours a governance key it does not recognise. Requirement. APS-ADAPT-MCP-EXTENSION-DECLARED, an adapter that assigns extension-object keys for APS material states which keys it uses and does not rely on a server honouring a key it does not recognise. Specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: cross-stack (mcp-audit-gateway-v0.6). actionref-canonical, 6 vectors. Implemented requirements: none. Related implementation surfaces: agent-passport-system 7.2.0 (npm).

Agent2Agent This document specifies no A2A binding. An Agent Card describes an agent and its skills. It is not an authority record and it names no action, so none of the five dimensions crosses at the card layer. An adapter that derives APS scope strings from card skills is deriving a vocabulary and not importing authority. Signing a card establishes who published the description, which is a narrower fact than it looks. records what reproducing that signature across two implementations showed. Loss model. Not applicable. An Agent Card is not an authority record and names no action, so none of the five dimensions has a source value to carry and no cell of the model can be filled. This subsection is informative. It does not establish that a signed Agent Card conveys any authority, and it does not establish that skills declared on a card correspond to actions the agent is authorized to take.

OAuth Identity-Assertion Authorization Grant The OAuth identity-assertion grant binding of this document imports a caller-verified grant. Of the five dimensions, the principal survives as the grant's subject. The exact action does not cross: the grant is about access to an audience and a set of scopes, not about one call with its arguments, so the exact action is constructed on the APS side after import and is never imported. The acting party is indeterminate rather than unsupported, which is a distinction worth keeping. carries an actor token parameter and then declines to say what it means: "This specification does not define normative processing requirements for actor_token or whether an act claim is included in the issued ID-JAG." An importer therefore cannot read an actor claim as establishing who acted. The reference implementation reconciles the claim against the chain leaf literally and marks the result advisory rather than authoritative, which is the correct handling of a field whose processing the source specification leaves open. The authority epoch, the purpose bound and any required-evidence condition have no carrier in the grant and are unsupported on import. The spend dimension is the case where the rule is already stated normatively elsewhere in this document: a spend basis MUST NOT be invented at import, and an external grant carrying no spend semantics yields an unsupported projection unless an importing profile supplies an explicit basis that verifier policy accepts. Scope projection is lossy, so the binding keeps the grant's authorization details verbatim beside the projection. The audience is the one dimension that crosses and then has to be enforced somewhere else. It is carried in the binding and not enforced by it, and the relying party at the point of use rejects a mismatch. The conformance corpus exercises that rule, and it exercises it on a different object: the vectors are an RFC 8693 token exchange, where an evaluation of the exchanged token denies with the family's audience_mismatch reason at the point of use. No fixture in the corpus carries an identity-assertion grant. The rule is exercised, the object is not, and the status block below says so. The same family pins the attenuation property that the general rules above state abstractly. A widening exchange is an invalid vector that a runner must refuse to evaluate rather than a case with a deny answer, an evaluation of the exchanged token reads only claims present on it, and an attribute transcribed from the subject token satisfies a predicate only where the exchanged token's own scope, audience and actor conditions independently permit the action. Loss model. Principal: preserved exactly, as the grant's subject. Audience: preserved exactly in the binding and enforced externally at the point of use. Exact action: not representable, and constructed on the APS side after import rather than imported. Acting party: externally resolved, and the source specification declines to say what its actor token means, so an importer reads no actor claim as establishing who acted. Authority epoch, purpose bound and required evidence: not representable. Spend: not representable, and a spend basis is never invented at import, so the projection is unsupported unless an importing profile supplies an explicit basis that verifier policy accepts. This subsection does not establish that an identity-assertion grant has been imported by any tested implementation, and it does not establish that the separation of the source grant reference from the delegation chain root has a fixture. The suite's coverage inventory records that separation as not exercised. Requirement. APS-ADAPT-NO-INVENTED-SPEND-BASIS, a spend basis is not invented at import, and an external grant carrying no spend semantics yields an unsupported projection unless an importing profile supplies an explicit basis that verifier policy accepts. This restates a requirement of and adds nothing to it. Specified, not exercised: the suite's coverage inventory records the corresponding requirement as partial and its vectors are an RFC 8693 token exchange rather than an identity-assertion grant. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Its one requirement identifier is an exception: APS-ADAPT-NO-INVENTED-SPEND-BASIS restates a requirement of in the closed core, and carries it as a Core restatement rather than as part of this feature. Related fixture families: cross-stack (token-exchange-attenuation-v0), 12 cases, on an RFC 8693 token exchange rather than on an identity-assertion grant. Implemented requirements: APS-ADAPT-NO-INVENTED-SPEND-BASIS. Related implementation surfaces: agent-passport-system 7.2.0 (npm).

Authorization API Loss model. Verdict: narrowed to the point of loss in the outward direction, because a three-valued verdict collapses onto a boolean and collapsing narrow to true widens the decision. Constraints, effective authority reference, expiry and single-use semantics: not representable in the decision object. Inward, a decision obtained through that API is an input to admission and not an APS policy-decision record. This subsection is informative. No fixture family in the conformance corpus exercises a mapping to or from the Authorization API, so nothing here is stated as a requirement. The direction that matters is inward, and it is narrow. An Authorization API decision is a boolean with optional context: "Decision is an object that contains a REQUIRED decision key with a boolean value, and an OPTIONAL context key with an object value." An APS policy-decision record is not that shape. It carries a three-valued verdict, the constraints a narrow verdict imposes, a reference to the exact effective authority admitted, an expiry, and single-use semantics at the next authorization boundary. None of those four has a defined carrier in the decision object, so a decision obtained through that API is an input to admission and not an APS policy-decision record. Treating it as one would supply an approval with no expiry, no binding to an exact action, and no consumption point. Outward, an APS verdict maps onto the boolean with loss. A narrow verdict and its constraints have nowhere to go, and collapsing narrow to true widens the decision. This subsection does not establish that any implementation performs this mapping, and it does not establish what a profile that assigned the missing fields to the optional context object would have to specify.

Workload and Agent Identity Credentials Loss model. Not applicable in either direction. There is no credential format on the far side of this adapter, so no APS semantic has a carrier to be measured against and no cell of the model can be filled. This subsection is informative. No fixture family exercises a mapping to a WIMSE credential format, and there is a plain reason for that: is a problem statement, and it says so in its own abstract, "It does not specify a solution." There is no credential format on the far side of this adapter yet, so there is nothing to map into and no requirement to state. What that document does carry is a requirement list, and one of its requirements is the admission rule this document arrives at from the evidence side. It requires evidence "bound to the specific action, including its arguments, its target resource, and the on-behalf-of principal", relied on at most once, and it requires that an unrecognized designation be treated as unauthorized: "A relying party that does not recognize a designation MUST treat the designated action as unauthorized." The convergence is worth recording. It is not adoption and it is not a claim that either document influenced the other. This subsection does not establish that APS satisfies any requirement in that list, and it does not establish that a future credential format in that space will carry any of the five dimensions.

Transparency Service Carriage Loss model. All five dimensions: preserved exactly, because the record travels whole rather than being re-expressed. Signer authority: externally resolved, and registration establishes nothing about it. This subsection is informative. No fixture family exercises carriage of an APS record as a signed statement to a transparency service, so nothing here is stated as a requirement. Carriage preserves all five dimensions, because the record travels whole rather than being re-expressed. What carriage adds is inclusion evidence, and what it does not add is anything about the signer's authority to make the statement. states the limit directly: "Issuers can make false Statements either intentionally or unintentionally; registering a Statement only proves it was produced by an Issuer." That maps exactly onto the separation this document already keeps between cryptographic integrity, signer authority and external truth. A receipt from a transparency service raises confidence that a record was registered and has not been altered since. It moves nothing on the authority question. An adapter that presents a transparency receipt as evidence of authority has crossed the two axes. This subsection does not establish that any APS record has been registered with a transparency service, and it does not establish a mapping from the APS receipt envelope described in into a COSE signed statement.

A2A Agent Card Signing This section is informative. It records a cross-implementation failure class that two independent signing implementations of the same specification reached, and what the canonicalization vectors in the conformance corpus do and do not cover against it. The failure class sits above the canonicalization algorithm. Two implementations can both apply correctly, byte for byte, and still fail to check each other's signatures, because one of them removed a field the other signed. Canonicalization pins the bytes for a given document. It says nothing about which document you had.

What Was Observed The A2A specification requires a card to be canonicalized under before signing, and it states a field-presence rule that runs first. Fetched from the specification repository on 2026-09-24 at commit 43e0c874d3baba68ed84b98678d7f2268438e69f, section 8.4.1: "Fields marked with REQUIRED MUST always be present, even if the field value matches the default." Two implementations of that rule diverge in opposite directions, and each divergence originates in its own language's object-to-JSON mapping rather than in its canonicalizer. Reproduced locally on 2026-09-23 against a2a-go pull request 441 at commit bb750f5c7913b967d8dcbe3d24537a8a84dd1a61 and a2a-python at commit f3ac82489dd84ce9dcd3802357cb4e987ffdbb74, using only each implementation's own public construction, serialization and signing interfaces and one shared Ed25519 key. Six single-field cases were built on an otherwise identical card. Of the six, three failed one direction: an explicitly empty description, an explicitly empty skills list, and an explicitly empty tags list on the first skill. In each of the three the Go side kept the field in the bytes it signed and the Python side rebuilt the card from those bytes for verification, dropping the field again, and verified a different payload than the one that was signed. The card was never altered in transit. The reverse direction passed on all six, and the control case with no empty or default values produced byte-identical canonical payloads on both sides. The pull request was open at the time of that run. Fetched on 2026-09-24, it is merged, and the maintainer's response to the report reads the same way this document does about where the divergence sits: "This is unfortunate, but python behaviour is not spec-compliant here." A report of the Python side of the divergence was filed by this document's author as issue 1278 on the a2a-python repository. Fetched on 2026-09-24, it is open, and its title names the class: "Signing/verification canonicalization drops REQUIRED fields at their default value, breaks cross-SDK Agent Card signature verification." The later merge and the earlier reproduction are separate records. The merge does not rewrite what was observed at the earlier commits. This subsection does not establish that either implementation is defective in general, that the divergence affects deployments in practice, or that the merged state of the Go pull request changes the Python side. It records six cases at three named commits.

What the APS Canonical-Bytes Vectors Cover The canonical-bytes family pins the byte contract of across implementations. Ten vectors, each naming the rule it exercises, cover the places a canonicalizer diverges without meaning to: the decimal-to-exponential threshold and how the exponent is spelled, negative zero, integers above the exactly-representable range and above signed 64-bit range, key ordering by UTF-16 code unit rather than code point, keys used exactly as given without Unicode normalization, and recursive sorting with array order preserved. The family runs the same ten vectors through four canonicalizers in four languages and publishes where the bytes and the digests agree or differ. A result there is a byte diff on ten cases and not a verdict on any implementation. Running those ten vectors through the Go implementation's canonicalization entry points on 2026-09-23 produced ten matches under both decode paths, twenty comparisons in total. The same run against the A2A project's own canonicalization corpus separated two further findings that are worth keeping apart from the field-presence class: three of the eight scorable must-reject vectors were rejected, and five unpaired surrogate vectors were not, because the decoder substitutes the replacement character rather than refusing. That is a decode-layer finding, upstream of canonicalization. The actionref-canonical family covers the adjacent APS-native property, where the action reference is a digest over the canonicalization of a fixed four-field tuple with each scope normalized to NFC and the scope array sorted by code point. Its vectors include the case where code-point order and code-unit order disagree, and two negatives on duplicate scopes, one raw and one that collides only after normalization. Neither family covers the failure class above. Both take a document and pin its bytes. Whether a field was in the document is decided before either family's first vector runs, and no vector in either family asserts field presence against a schema's required-field rule. Stating that gap is the point of this subsection. This subsection does not establish that a passing canonical-bytes run means two implementations will verify each other's signatures.

Gateway Extension Processors This section is informative. It records one seam that an adapter carrying APS material through a third-party MCP gateway has to account for, and it is the concrete case behind the obligation named in . An MCP-aware gateway can call out to an external processor before forwarding a call, so that the processor can allow, deny or rewrite it. In one such interface, fetched on 2026-09-24 at commit 25702c3b561a0bc2130da75427e3debbd5b13918, the field carrying the call to the processor is described as "JSON-RPC params as raw JSON bytes; absent when the method has none", and the rewrite result is described as replacing those same params, with the note that "The gateway does not re-run other RBAC on the mutated request." The seam is that the bytes the processor sees and the bytes the tool sees are not the same bytes. A local reproduction on 2026-09-23, against that same commit with a stub processor and a hand-written upstream server that logs its raw input, sent one tool call whose params carried a _meta member. The three captured surfaces are below, verbatim from that run. A backslash at the end of a line is a continuation inserted here to fit the page width and is not part of the captured bytes. First, the client's exact request body: what the external processor received as the call under check: and what the upstream server received on its own input: The _meta member reached the tool and did not reach the check. For an adapter that carries a passport reference, a delegation reference or an approval reference in _meta, that is the whole problem: the component asked to decide cannot see the material the decision depends on, and the component that runs the call can. An adapter in this position either carries its material where the processor can see it, or treats the processor as unable to decide and denies rather than defaulting. The interface also rewrites. A processor that replaces the params has changed the exact action, and the gateway does not re-run its other access checks on the replacement. An adapter that recomputes the action reference after a rewrite gets a different value than one computed before it, which is the general recomputation rule in applied to a specific seam. This section does not establish that this behaviour holds at any other commit of that gateway, that other MCP gateways behave the same way, or that the behaviour is a defect. It records what one pinned build did with one call on one date. It also does not establish what a profile assigning _meta keys for APS material should do about it, which stays open.

Enforcement Gateway Reference Architecture This section is informative. It describes one arrangement of an enforcement boundary that runs the checks this document specifies, taken from the open-source Agent Passport Gateway. It is a description, not a conformance target. An implementation that arranges these functions differently is not for that reason non-conforming, and nothing in this section adds a requirement to the ones stated elsewhere in this document. Deployment topology, network interfaces and operator configuration are out of scope here. This section does not establish that any deployment is arranged this way, that the described arrangement is safe, or that the reference implementation is free of defects.

Judge and Executor In this arrangement the boundary both decides and performs. The acting agent sends a signed request naming a tool and its arguments. The boundary evaluates the request, calls the target itself, and writes the record of what happened. The agent never constructs that record. The reference implementation states the reason in its own source: without the boundary holding execution, the library is optional and the agent can route around it. A policy decision point may be a separate service. Only the enforcement boundary admits an action to dispatch. Where a decision point is separate, it computes the decision and the boundary is the issuer of the aps:policy-decision:v1 record that carries it, as requires. Approval consumption, the reservation, dispatch and the external effect are four steps and are not one atomic transaction in this revision. A verdict arriving from a separate decision point is an input to admission, in the same class as a revocation answer or a freshness answer, and it is not itself admission. The Authorization API draws the same line from the other side, placing the decision point's internals outside its own scope: "The policy language, architecture, and state management aspects of a PDP are beyond the scope of this specification." Its response object is correspondingly thin: "Decision is an object that contains a REQUIRED decision key with a boolean value, and an OPTIONAL context key with an object value." The arrangement assumes there is no alternate privileged credential path to the same target. If the target accepts a credential the agent holds directly, the boundary governs one path and the other path is ungoverned. The MCP binding in this document already states that exclusivity as a deployment precondition rather than a property of the binding. The assumption is load bearing and it is worth naming plainly: an APS record establishes that a governed path was valid, and it does not establish that no ungoverned path existed. A verifier that cannot establish that the boundary implements the grant's declared scope reports the wider reachable scope or reports that the narrower scope is not established. This subsection does not establish that the boundary is the only path to the target, and it does not establish that a separate decision point and the boundary evaluated the same inputs.

Admission, Consumption, Reservation and Settlement The boundary checks before the effect, not only before the approval. In the reference implementation the order at the next authorization boundary after an approval is: confirm the approval is unconsumed and unexpired, confirm the agent and the delegation still exist, recheck revocation and status against current state rather than the state read at approval time, recheck the governance version the approval was granted under, recheck any cross-context permit that the approval relied on, recheck the authority tier against the current reputation state, mark the approval consumed, and only then call the target. Consumption is atomic against concurrency and not only against sequence. The reference implementation serialises execution per agent and re-tests the consumed flag inside the serialised section, because the test that runs before the lock lets two concurrent calls on the same approval both pass it and both reach the tool. Where a budget must be held rather than spent, the boundary reserves. A hold is checked against the delegation's limit less the sum of live holds before it is granted, and it is released on fulfilment or on expiry. Where the budget is spent at admission instead, the reference implementation increments the used amount inside the same transaction that records the permit, so a permit and its charge cannot come apart. Settlement comes after the result. Settlement records are assembled from recorded contributions over a closed period. They are not produced at admission and they are not an input to it. The cross-organizational delegation requirements in state the same ordering as a requirement on any solution in that space: "Consumption of the reliance unit occurs only upon admission: evaluation, exact-action matching, and refusal at any stage MUST NOT consume it". Two things are worth separating here, because the ordering above is one implementation's and the obligation is this document's. The protocol requirement is the one stated at and : at the moment the approval is consumed to admit dispatch, the boundary verifies the approval has not expired, atomically consumes its identity, rechecks time and revocation state, and completes any spend reservation. This document requires no particular order among the other checks the reference implementation runs, and it requires none of them. It also does not make consumption, reservation, dispatch and the external effect one atomic transaction, and states what that leaves to a deployment. This subsection does not establish that a reservation released on failure was released before any external effect, and it does not establish what happens to work already in flight when authority changes during execution.

Evidence the Boundary Produces What the reference implementation does. A denial and a permit both produce a record, so a refusal is evidence rather than an absence of it. The implementation signs the denial record under the boundary's own key. For a permit it stores what its own source calls a permit record, with a content hash and no signature. That object is not a receipt in the sense of , it is not an aps:policy-decision:v1 record, and this document names no such object. The implementation's source gives its reason directly: a denial is signed as proof of restraint, a permit is treated as routine. The structural reading is that a refusal leaves no other artifact anywhere, so a record nobody signed is the only trace it has, while a permitted action goes on to produce a separately signed result record at the next stage. What this document requires, separately. The boundary records the policy decision, permit, narrow or deny. That record is not evidence of admission (, ). defines the signed policy-decision record and makes the boundary its issuer, for permit, narrow and deny alike. This document states no requirement about an additional internal permit object, defines no wire shape for one, and places no signing obligation on one, because it defines no such object at all. An implementation that keeps one is keeping deployment state, not producing an APS record. The cost of that choice belongs beside the choice. An unsigned permit record is not attributable to the boundary by a third party. It can be checked for integrity against its own hash by a party who already trusts the store that holds it, and that is a different and weaker property. A deployment that needs a permit to be presentable as boundary-attributable evidence has to sign permits too. This subsection does not establish that the store holding an unsigned permit record is honest, and it does not establish that a signed denial record was the only decision reached for that action. It does not establish that the reference implementation's permit record and the policy-decision record of this document are the same object, and they are not.

Ancestor Revocation at the Boundary At each authorization boundary the reference implementation walks the bound chain of the delegation it selected, following each record's stored parent link rather than re-resolving whatever parent is current. A revoked or suspended member anywhere on that walk ends the leaf's authority, up to and including the terminal grantor, even when the leaf's own record still reads as active. The walk fails closed, so a leaf whose bound chain is dead is denied even where some other chain the same agent holds would still be live. This is the boundary-side form of the core invariant that a chain is rejected when any member is revoked, stated in . The same walk runs a second time inside the write transaction when a new delegation is granted under an existing one, because the first read happens outside the lock and a revocation can commit between the two. Enumerating descendants is a reporting and cleanup tool in this arrangement. It is not what makes a chain-verifiable descendant invalid. Where a credential carries no chain a verifier can walk, such as an opaque bearer token, an issuer-side revocation mechanism is still needed. This subsection does not establish that revocation state was fresh at the moment of the walk, and it does not establish that a credential issued outside the chain was reached at all.

What the Gateway Does Not Do It does not decide truth about the world outside it. It records what it evaluated and what the target returned. Whether the external effect matched the returned result is a separate finding with separate evidence. It does not classify content and it does not judge whether an action was a good idea. A permitted action is an action the presented authority and the configured policy admitted. Settings that identify an operator are reconciliation and not a revocation mechanism. Removing such a setting later does not remove a role already held. Blast-radius preview before a revocation is read-only. It changes nothing and it is not a revocation. It is not a transparency service. On its own it gives no third party the ability to detect that it presented different histories to different parties. The reference implementation's own research notes list an append-only log with consistency proofs, and separating the receipt signer from the executor, as directions rather than as present behaviour. This subsection does not establish a complete list. It names the limits that the corpus behind this document repeatedly turned up.

Conformance An implementation of this document is not one thing. A party that issues delegations, a party that verifies them, a party that admits actions at the boundary and a party that reads receipts have different obligations, and an implementation that does all four is rare. This section defines the classes a claim is made in, the identifiers a claim cites, the form of the claim, and the three results an implementation reports per vector. The executable corpus this section refers to is the APS conformance suite , which is work by this document's author. Nothing in this section is a statement that any implementation has passed anything, and the corpus issues no verdicts.

Conformance Classes An implementation claims conformance in one or more of the following classes. A claim MUST name its classes. An implementation MUST NOT claim a class whose obligations it does not implement, and MUST NOT present a claim in one class as covering another.

Authority issuer.

Mints delegation records. Verifies the parent signature and temporal validity before signing a child, refuses to issue under an expired, not-yet-valid or revoked parent, and never issues a record whose invalidity is left for a later verifier to find. Related fixture families: issuance-refusal-expiry, lifecycle-conferral-without-authority.

Delegation verifier.

Reads a root-to-leaf chain and returns valid, invalid, indeterminate or unsupported. Applies the component orders, selects one chain per action, takes no union across chains, resolves keys at the artifact's own issuance time, and never collapses indeterminate or unsupported into valid. Related fixture families: chain-selection-no-union, single-chain-selection, key-rotation-historical, ancestor-revocation-chain and revocation-resolution-forward-compat.

Lifecycle and status verifier.

Answers what is currently established about an authority whose records are unchanged but whose surroundings have moved. Reads status sources with a stated freshness, reports a conflict between sources rather than picking one silently, and distinguishes an answer that is false from one that is not established. Related fixture families: conflicting-status-sources, authority-epoch-rollback, activation-not-established, suspension-cause-composition, cached-authorization-revocation and the lifecycle families named in .

Receipt verifier.

Recomputes a receipt identifier before verifying any signature, checks the stage and its closed result object, resolves referenced evidence or reports it unresolved, and reports cryptographic integrity, signer authority, referenced-artifact resolution and policy semantics on separate axes. Related fixture families: accountability-record, receipt-decision-relation, action-result-binding, read-fidelity-receipt, merkle-root-parity and instruction-provenance.

Enforcement boundary.

The next authorization boundary an action reaches after a decision. Re-validates what can have changed since the decision was issued, consumes a single-use approval atomically, reserves spend against every bounded ancestor, and refuses an approval that is expired, already consumed, or terminal. Related fixture families: approval-single-use, runtime-authority-denial-continuity. The corpus records the remaining boundary obligations as untested in receipt-decision-relation's own verifier header.

Profile implementation.

Holds a profile as defined in and supplies its constructions to the classes above. Reports a record naming a profile it does not hold as unsupported. Related fixture families: key-rotation-historical, capability-binding-drift, each of which defines its own test profile and says so.

Protocol adapter.

Carries APS records or concepts over another protocol. Records, for every concept, whether it survives the mapping, becomes unsupported, or becomes not established, and never widens a concept silently to fit the external construct. Related fixture families: arap-binding and the cross-stack families.

A requirement identifier applies to one or more of these classes, through its area. The table below maps each area of to the classes in which a requirement carrying that area is mandatory for a Core requirement and claimable for a Candidate one. Three areas carry no identifier in this revision and are listed for completeness of the taxonomy. Identifier area to conformance class

Area	Classes
ID	delegation verifier, receipt verifier. No identifier in this revision
PRIN	lifecycle and status verifier
AUTH	delegation verifier
LC	lifecycle and status verifier
POL	enforcement boundary. No identifier in this revision
ENF	enforcement boundary
REC	authority issuer, receipt verifier
EVID	receipt verifier, lifecycle and status verifier
PROF	profile implementation
ADAPT	protocol adapter
GOV	no class in this revision, and no identifier
CONF	every class, in whichever classes the claim names

The classes are not a maturity ladder and are not ordered. An implementation in one class is not a partial implementation of another. A Core requirement outside every class an implementation claims is not an obligation on that implementation, and a claim that omits a class is not a claim that the class was met. What this subsection does not establish. It does not establish that the seven classes partition the obligations of this document without gap or overlap, that a family named against a class covers that class, or that passing every family named against a class makes an implementation conforming in it. The families named are the ones that reach some obligation of the class, and the coverage each reaches is recorded in . Requirement. APS-CONF-CLASS-NAMED, a claim names its classes, an implementation does not claim a class whose obligations it does not implement, and a claim in one class is not presented as covering another. Specified, not exercised. Status: Core, document requirement, specified, not exercised. APS-CONF-CLASS-NAMED binds every conformance claim made under this document, in every class, and is not gated by a feature a claimant can decline. It is a requirement on a claim document rather than a runtime check a verifier performs, of the same kind as the profile requirements of , so no runtime vector reaches it and a static claim fixture is needed before it is recorded as exercised. A claim is the one artifact whose form this document fixes for every claimant, because a claim that need not name its classes cannot be read at all. Related fixture families: issuance-refusal-expiry, lifecycle-conferral-without-authority, chain-selection-no-union, single-chain-selection, key-rotation-historical, ancestor-revocation-chain, revocation-resolution-forward-compat, conflicting-status-sources, authority-epoch-rollback, activation-not-established, suspension-cause-composition, cached-authorization-revocation, accountability-record, receipt-decision-relation, action-result-binding, read-fidelity-receipt, merkle-root-parity, instruction-provenance, approval-single-use, runtime-authority-denial-continuity, capability-binding-drift, arap-binding, cross-stack. Implemented requirements: none. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI) for the authority issuer, delegation verifier and receipt verifier classes. No released package for the enforcement boundary, the profile implementation or the protocol adapter classes.

Requirement Identifiers This subsection is informative. It describes the identifier scheme this document uses, so that a claim can cite a requirement without quoting it. A requirement identifier has the form APS-<AREA>-<SEMANTIC-SLUG>. The area is one of twelve fixed values: ID, PRIN, AUTH, LC, POL, ENF, REC, EVID, PROF, ADAPT, GOV and CONF. The slug names the proposition the requirement states, in uppercase words joined by hyphens. An identifier names what a requirement says rather than where it sits, so it never changes because a section moves, and it is never reused. Renumbering this document moves no identifier, and an identifier retired with its requirement stays retired. Five identifiers from show the shape: APS-PRIN-SILENCE-NOT-CONSENT, APS-AUTH-CHAIN-NO-UNION, APS-LC-NO-RESURRECTION, APS-ENF-COMPLETE-AT-ADMISSION and APS-EVID-EFFECT-NOT-FROM-RESULT. Each reads as a proposition, which is what makes it citable without the surrounding text. Each identifier belongs to a conformance class through its area, under the map in , and a claim cites an identifier in the class it applies to. is the sole authority for which requirements an exact vector exercises. It records one of two coverage states per requirement. Exercised means a named vector plus a runner assertion that fails when the requirement is violated. Specified, not exercised means no such vector exists, whatever related fixture material does exist. A requirement whose violation no input produces is specified and not exercised even where a validator carries the check, because a check no input reaches is not coverage. The conformance suite's own inventory identifiers for draft-pidlisnyi-aps-03 appear in this document in and nowhere else. They are section-derived and bound to that revision, and they are reproduced there as a legacy mapping rather than as a scheme a claim against this revision uses. What this subsection does not establish. It does not establish that the identifiers cover every obligation of this document, since an obligation stated across two sentences, or stated in the closed core with no restating subsection, carries no identifier. It does not establish that a fully exercised matrix would mean an implementation is correct. This subsection is informative and carries no requirement identifier.

Core and Candidate Every normative subsection of this document outside the closed core carries a status of Core or Candidate. Two places are outside that scheme. The BCP 14 sentences carried from -03 in and are closed-core carryover. They keep the force they had in -03, they carry no status block and no requirement identifier, and does not list them, because that appendix records what this revision states outside the closed core. Core means the requirement is mandatory for an implementation claiming the conformance class to which the requirement applies, under the area-to-class map in . Candidate means the requirement belongs to an opt-in feature. A Candidate requirement is normative for an implementation that claims that feature and is not a requirement of APS Core conformance. Candidate is not weaker normative language and not a lower grade of Core, and it is not a promise that the requirement will become Core. A claim therefore names the classes it claims and the Candidate features it claims, in the form "APS Core in the named classes, plus named features", and states what else a claim carries. Lifecycle Core is an informative grouping name and not a claimable base. It names the propositions in that restate a requirement of the closed core, carried by six requirement identifiers drawn from six of the twelve continuity rules. L1 is in it whole. One identifier each comes from L3, for irreversibility, from L5, for one chain per action with no union, from L6, for the recheck at the moment of consumption, from L7, for an unknown revocation state not being active, and from L9, for historical key selection with its issuer-claim timestamp and indeterminate signing instant. lists the six with the core sections they restate. Everything else in that section, including the rest of L3, L5, L6, L7 and L9, is one or more Candidate features. The Candidate features an implementation can claim in this revision are: the revocation record format of , the evidence model of and , the profile model of , the lifecycle continuity rules outside Lifecycle Core together with the material in L3, L5, L6, L7 and L9 outside their Core propositions, each lifecycle mechanism of named as its own feature, the decision-to-effect model of , the adapter contracts of , and the per-vector result vocabulary of . A claim that names no feature is a claim of APS Core alone. The claim rules of and are not a Candidate feature. They bind every claim made under this document, whatever classes and features the claim names, because they are the form in which a claim is legible rather than a behavior an implementation opts into. They are document requirements of the same kind as states for a profile, so no runtime vector reaches them and marks all three specified and not exercised. The corpus carries its own label with a similar name and a narrower meaning. A family labelled candidate_against_proposed states that a runnable case exists against proposed text at one commit of one repository. That label is a statement about the family, and this document's Candidate is a statement about a requirement. The two are recorded separately and neither implies the other. The corpus itself records that the label spelling is not yet uniform across families and that two families carry the shorter spelling on their per-vector records while stating the longer one at the family level. What this subsection does not establish. It does not establish that a Candidate requirement is correct, that the boundary between Core and Candidate is drawn the same way by any other document, or that a family passing means the rule it tests is the right rule. A pass establishes that a boundary implementing the stated reading reaches a stated verdict on stated bytes. This subsection is informative and carries no requirement identifier.

Conformance Claims A claim is APS Core in the classes it names, plus the Candidate features it names. It carries no other base. The requirements in this subsection bind a claim document. Like the profile requirements of , they are not runtime checks and no vector exercises them. A conformance claim MUST state all of the following.

Implementation.

The name of what was tested and enough of a reference to fetch exactly that, which means a repository and commit, or a package and version.

Classes.

The classes of claimed, and no others.

Requirements.

The requirement identifiers claimed, each under the semantic scheme of . An identifier does not move between revisions, so a claim names the revision it was tested against for the text of each requirement rather than to resolve the identifier.

Corpus.

The tag or commit of the corpus run against.

Per-vector results.

One result per vector under , not a summary and not a percentage.

Commands and output.

The commands run and their output, uncut.

Environment.

Language, runtime version and operating system.

Who ran it.

The party that ran it, and whether that party authored the vectors, the claim inputs, or the implementation whose output supplies the recomputation. A claim MUST NOT be presented as independent where any of those three is the claiming party's own work.

Profiles.

Every profile the implementation holds, by identifier and version.

A claim MUST NOT be stated as a verdict issued by this document, by the corpus, or by any party other than the claimant. A claim is a record of what one party observed on stated inputs. A later claim by another party is appended as a new record and does not alter or replace an earlier one, and a later finding does not rewrite what an earlier record states. What this subsection does not establish. It does not establish that a complete claim is correct, that a claim covering every requirement means the implementation is safe, or that any registry of claims exists. It does not define a machine-readable claim format. Requirements. APS-CONF-CLAIM-CONTENT, a claim states every item in the list above. APS-CONF-CLAIM-NOT-VERDICT, a claim is not stated as a verdict issued by this document, by the corpus, or by any party other than the claimant, and a later claim is appended as a new record rather than replacing an earlier one. Both are specified, not exercised, and no fixture exists for a requirement on a claim document. Status: Core, document requirement, specified, not exercised. APS-CONF-CLAIM-CONTENT and APS-CONF-CLAIM-NOT-VERDICT bind a claim document and not a runtime verifier, so no runtime vector reaches them. A static claim fixture is required before either is recorded as exercised, and none exists. Related fixture families: none. Implemented requirements: none. Related implementation surfaces: no released package.

Per-Vector Results An implementation reports one of exactly three results per vector.

pass

The implementation reached the vector's declared outcome. For a negative vector this means the implementation rejected the input for the reason the vector declares, not merely that it rejected the input.

fail

The implementation reached a different outcome, or reached the declared outcome for a different reason.

not_supported

The implementation has no surface on which the vector's question can be asked. The concept the vector exercises is absent from the implementation, so there is nothing to run and nothing to reject.

An implementation MUST NOT report not_supported as pass, and MUST NOT report a vector it did not run at all. not_supported and fail are different findings. A fail says the implementation answered and was wrong. A not_supported says it could not be asked. A count of not_supported results MUST NOT be presented as a coverage score, a completeness percentage, or a comparison between implementations. The reason is arithmetic rather than editorial. The unit a family records differs by family, because the question differs. Some families record one row per named claim, some one row per verification layer, some a count of reachable exports, and some commit no per-vector record at all and print it on demand. Rows from different units do not add, and a total over them is an artifact of how each family chose to write its record. A family's own record is authoritative for that family and for nothing else. A not_supported result is also not a defect report about the package it names. It states what a fixture could and could not get from a published package at a pinned version, which is a statement about that package's surface at that version. What this subsection does not establish. It does not establish that the three results are exhaustive for every verification model, that the boundary between fail and not_supported is unambiguous in every case, or that two implementations reporting the same tallies are equally correct. It does not establish any suite-wide number. Requirements. APS-CONF-THREE-RESULTS, an implementation reports one of exactly three results per vector, reports no not_supported as pass, and reports no vector it did not run. APS-CONF-NOT-SUPPORTED-NOT-SCORE, a count of not_supported results is not presented as a coverage score, a completeness percentage, or a comparison between implementations. Both are specified, not exercised. Status: Candidate feature. Normative for an implementation claiming this feature, not a requirement of APS Core conformance. Related fixture families: activation-not-established, lifecycle-credential-events, lifecycle-multiple-principals-and-conflict, lifecycle-outside-the-chain-standing, lifecycle-legal-regulatory-events, lifecycle-identifier-reuse-and-rename, lifecycle-principal-events. Implemented requirements: none. Related implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI) are the packages whose surface those families probe. No released package emits a per-vector result record.

What a Passing Run Does Not Establish This subsection is informative. A passing run does not establish a rule. It establishes that a boundary implementing the reading under test reaches a stated verdict on stated bytes, and that the named defective boundaries diverge on exactly their declared sets. It does not establish that the reading under test is the correct one. For a Candidate requirement the reading is this document's, and a family that runs it does not confirm it. It does not establish that the reference runners are independent implementations. Both were written for the corpus by this document's author. It does not establish liability or any accountability outcome. Where a family touches an accountability record, that family states its own limit. It does not establish that any legal doctrine applies to AI agents. The corpus uses scenarios drawn from how institutions handle authority as a source of cases, and each family that does so says so. A case is a source of a test, never a source of a rule. It does not establish adoption, endorsement or production use by any party whose artifacts the corpus carries. Admission of an external family means the vectors were deterministic, in scope and correctly labelled. This subsection is informative and carries no requirement identifier.

Related Work Several independent efforts, contemporaneous with this document's revisions, have specified adjacent primitives. This section situates them. None is normative here, and the mappings below are informative. Documents are cited by their series name and revision, which is how documents sharing a title are distinguished. A document that had expired at the time of writing is marked as expired where it is cited, and is retained as prior art rather than dropped. PEDIGREE specifies signed JWT delegation chains for workload and agentic identity, with per-parent mandate narrowing: it requires each hop's scopes to be a subset of the immediate parent's, limits token lifetime to the parent's remaining lifetime, and checks chain depth against the parent chain. This is the same narrowing-only rule as the Core Invariants of ; PEDIGREE applies it to scope, lifetime, and depth, while APS applies it across the seven constraint dimensions of . APS also differs in binding the narrowing evidence into signed receipts at each transfer point and in the gateway two-phase execution model, where admissibility is evaluated and evidenced before dispatch. A family of OAuth drafts specifies multi-hop agent delegation natively in that ecosystem. defines the delegation_chain JWT claim as a companion to the act claim of RFC 8693, on the stated grounds that act carries actor identity but not the authorization constraints applied at each hop and is constructed by the Authorization Server without confirmation from the delegating party. The claim is an ordered array of delegation records, each carrying the Authorization Server's attestation and, where present, delegated policy constraints and the delegator's cryptographic confirmation; the attestation and confirmation signatures are computed over an RFC 8785 canonicalization of a named field set. Delegated scope is required to be a subset of the delegator's, and scope expansion across a domain boundary is not permitted. A companion draft defines an authorization details type under Rich Authorization Requests carrying signed evidence of user confirmation and an audit trail: the evidence object is embedded in JWT access tokens and retrieved by reference when opaque tokens are used, and the draft recommends that Resource Servers log evidence information for audit purposes. These specify delegation lineage and consent evidence as OAuth token content, evaluated by Authorization Servers and Resource Servers; APS specifies standalone signed records evaluated at an enforcement point at the time of the action, and separately signs the pre-dispatch admission decision and the post-dispatch outcome as artifacts distinct from the authorization event. The revocation models differ in mechanism: makes descendants of a revoked root invalid by rule, with Resource Servers required to confirm the root authorization remains valid at the time of use, while APS keeps the authority result for a chain separate from the state of the evidence recording a revocation's processing, so that cascade evidence, where produced, records processing without being what makes a descendant chain invalid (). The same author set frames these as parts of one flow. An integration framework combines cross-domain identity, policy-based authorization, user-consent evidence, and multi-hop delegation into one authorization framework for agents acting on behalf of users, and supplies its policy layer in Rego. The Rego draft draws the audit boundary in its own terms, distinguishing the behaviors a policy permits from evidence of the behaviors actually performed; it recommends that Resource Servers record the policy identifier, a hash or summary of the evaluated input, the result, and the timestamp. The signed admission and outcome records of this document specify one form of such a record. A further cluster of individual proposals works the same problem from the actor claim of , which expresses that delegation has occurred and identifies the acting party to whom authority has been delegated. defines six actor-chain profiles for Token Exchange on the stated ground that the claim permits nested prior actors but defines no interoperable rules for preserving, extending, disclosing and validating a delegation path across successive exchanges, and its verified profiles add actor-signed step proofs with cumulative commitment state. profiles the same claim differently, extending it with a sub_profile member for entity-type classification across JWT assertion grants, JWT access tokens and transaction tokens, and states that the policies deciding whether a given actor may act for a subject stay deployment-specific. moves the question earlier, carrying a signed authorization request delegation chain as an authorization_details object under Rich Authorization Requests so that an upstream Authorization Server can apply policy to the visible delegation path before it issues a token. None of the three is a working group document, and they have not converged on one representation. APS is not a token profile: it specifies standalone signed records evaluated at an enforcement point, and defines the single OAuth grant binding this document carries. Closest of that cluster to is , which starts from the observation that invalidating a credential does not establish that every path from the revoked authority to a consequential effect has been closed. It models authority as a directed graph and holds a revocation cut set valid only if every declared path from the revoked root to a consequential sink intersects it, and it requires that where an implementation cannot establish that the revoked authority can no longer create authority-bearing edges bypassing that cut set, closure is reported as unknown, partial or failed rather than closed. It defines no encoding for the resulting closure receipt. This document approaches the same question from the record side. Both bound what a record may assert by the coverage its emitter declares. That draft requires a closure claim to identify the enforcement scope it applies to and not to imply closure of unknown or out-of-scope systems, and requires a party emitting a cascade-completion record to be able to state the basis on which the processed set was complete. A best-practices framework maps deployed standards onto agent interactions: it applies the OAuth 2.0 family and the WIMSE workload identity architecture to agent authentication and authorization, states that rather than defining new protocols it describes how existing and widely deployed standards can be applied or extended, and identifies gaps to guide future standardization. Its policy model and document format are declared out of scope and are not recommended there as a target for standardization. The framework was adopted by the WIMSE working group after this document's previous revision, where it is titled AI Identity Management System and defines the term Agent Identity Management System (AIMS) as a conceptual model describing the set of functions required to establish, maintain and evaluate the identity and permissions of an agent workload. That document states that AIMS does not refer to a single product, protocol or deployment architecture. It is the one agent-specific document in that working group at the time of writing. APS specifies mechanisms in part of the space that framework surveys: the transfer-time narrowing rule across the seven constraint dimensions of , and the signed admission and outcome records evaluated at an enforcement point. Two transparency specifications were published in June 2026 and were not cited in the previous revision. defines an architecture for single-issuer signed statement transparency, in which registration is the process of submitting a signed statement to a Transparency Service, applying that service's registration policy, adding it to a verifiable data structure and producing a receipt, and a Transparency Service is the entity that maintains and extends that structure and endorses its state. defines the receipt encoding, where a receipt proves properties of a verifiable data structure to a verifier. Three individual drafts profile that architecture for agent actions . One of them, , states the property at stake. Registration obtains a Transparency Service's signed proof that the statement was registered in its log, which that draft calls a property a self-signed chain cannot provide alone. The ReceiptV1 envelope of stays a standalone signed record and is not a profile of that architecture in this revision. The reason is the dependency rather than the encoding. A registration receipt is a statement about a log that a Transparency Service maintains, so what a relying party gets from it is bounded by that service and by the monitoring the relying party performs. The records of are evaluated at an enforcement point at the time of the action, and this document states, per record class, what each record proves and what it does not, without requiring a Transparency Service to be reachable at that moment. The two are composable rather than alternative. A ReceiptV1 record is a candidate payload for a signed statement, and registering one would add transparency properties that does not claim. Specifying that carriage is future work (). The Delegation Receipt Protocol specifies a user-signed delegation receipt carrying scope, a validity window, a hash of the operator instruction, and a model-state commitment, anchored to an append-only log before the agent acts. For multi-agent delegation chains, DRP enforces a narrowing-only rule under which a sub-agent receipt's scope is a strict subset of its parent's, specifies cascade revocation with signed revocation records anchored to the same log, and includes an instruction provenance check against the operator-instruction hash. The designs differ in anchoring: DRP anchors receipts to an external log before execution, while APS evidences the admission decision and the outcome as separate signed records at the gateway. DRP additionally specifies model-state attestation, which this document does not. An identity and delegation framework specifies self-certifying agent identifiers derived from public keys, discovery through indexed metadata, and jointly signed authorization capabilities: a capability is co-signed by the client-side and service-side providers, carries the permitted actions and operational limits (roles, quotas, budgets, time window, audit requirements), and is recommended to be holder-bound with proof-of-possession and expiry. The framework and APS address adjacent layers: it specifies identity bootstrap and per-mission capability establishment between providers, while APS specifies narrowing-only transfer of authority across the seven constraint dimensions of and signs the admission decision and the outcome as separate records at each action. specifies a deterministic, content-addressed action identifier computed over an agent identifier, action type, scope, and timestamp under RFC 8785 canonicalization, such that any party holding the preimage fields can independently recompute the identifier. This matches the External Correlation Form of in preimage fields, canonicalization, hash, timestamp discipline, and lowercase hexadecimal encoding, so the two computations yield equal values for identical field inputs. Both preimages are limited to action-identifying fields. In APS, decision attributes such as policy identity are bound in the signed record () rather than folded into the correlation preimage, which keeps the key recomputable by a party that does not hold decision-time state. An architecture document specifies a human identity root, delegation semantics in which nested delegation may pass only a subset of granted authority, and a provenance structure tracing agent actions to the authorizing human; it states that it defines no protocol, wire format, or credential format. That document also specifies narrowing-only delegation, stated at the architecture level rather than as a token or record format, and its human identity root corresponds to the principal that APS keeps visible through the principal binding of . The record formats, signature scheme, and enforcement-point evaluation that the architecture leaves open are what this document specifies. Three independent drafts each titled Agent Identity Protocol specify different layers under the same name, and are distinguished here by series name. defines a decentralized identity, delegation, and authorization framework on W3C Decentralized Identifiers, with capability manifests and constraint overlays validated attenuation-only: an overlay may not expand any constraint, and chain validation applies recursive attenuation semantics so each child manifest is a valid attenuation of its parent; prompt injection prevention is stated out of scope. The attenuation-only rule is narrowing-only delegation applied to capability constraints; APS additionally binds the narrowing evidence into signed receipts at each transfer point and separates current-state validity from revocation evidence. , which had expired at the time of writing and is retained here as prior art, specifies registry-anchored agent identifiers with per-action signing and an enforcement proxy interposed between the client and each tool server, evaluating declarative policy to an allow, deny, or hold decision before the tool is reached. The interposition parallels the APS gateway's position in the action path; the models differ in that APS evaluates admissibility against the delegation chain's narrowed constraints and signs the pre-dispatch admission decision and the post-dispatch outcome as distinct records. The third binds identity, authorization, scope constraints and provenance into invocation-bound capability tokens, in a compact JWT mode and a chained mode with append-only blocks and Datalog policy evaluation, under a rule that at each delegation step scope can only narrow or stay equal and never widen. That rule also specifies narrowing-only delegation, reached over a token format rather than over standalone records. A parallel set of individual Internet-Drafts develops the surrounding problem space as requirements and evidence-layer documents. A problem statement enumerates ten requirements for cross-organizational agent delegation, among them recursive attenuation, bounded-staleness revocation, and tamper-evident composable audit, and it specifies no solution. Its tenth requirement, added after this document's previous revision, is that classes of actions be designatable as requiring, at execution time, evidence of an authorization decision made by an accountable human approver distinct from the executing agent, bound to the specific action and relied upon at most once. The overlap is partial. and of this document specify a single-use approval bound to an action_ref and the rules under which it is consumed. This document specifies no requirement that the approver be a human distinct from the executing agent, no designation of such a requirement carried in delegated authority, and no preservation of such a designation across narrowing. A companion set specifies pieces of an evidence layer above individual record formats. One defines a transport-agnostic composition object and a fail-closed evaluation algorithm that returns satisfied or unsatisfied together with a replayable evaluation record . A second introduces and rotates an organization's evidence-issuing keys through a signed, hash-chained sequence, and records the authority a subject held at a registry snapshot, including role, action scope, material limits, policy binding, validity and revocation status . A third binds named-human authorization evidence into an action record in a host-agnostic way . A fourth binds per-action authorization and memory provenance into an action capsule . These efforts specify requirements and evidence-composition mechanisms, several with their own implementations. APS records are candidate member artifacts for such composition, and each mechanism retains its own verification, acceptance, and sufficiency rules. The requirements overlap with APS mechanisms in part: recursive attenuation with the narrowing rule of and , revocation evidence with , and tamper-evident audit with the signed records of . Where these efforts define what a cross-organizational solution must satisfy, this document states, per record class, what each record proves and what it does not. Two lines of work outside the IETF bear on the boundary the MCP binding of sits on. Inside MCP's specification-enhancement process, one proposal defines a signed tool-call attestation envelope, on the stated ground that MCP has no standard mechanism to prove cryptographically which agent called which tool, with what arguments and for what purpose . A second carries client-asserted invocation audit context and states that its fields are explicitly not authorization evidence . A third defines a canonical byte form and an append-only hash chain for audit records, with admission, runtime-security and caller-governance context attached under one digest . A fourth, a server-side signed execution record, was withdrawn by its author, who continued the work as an Internet-Draft . The first and third were closed in September 2026 under a maintainer decision that new proposals be developed with a working group, which is a disposition of process and not of content. The resulting split between an attestation of the request, an audit context, and a separately chained record tracks the three-record policy chain of and , and the server-authoritative record of a decision and its outcome, which left that process when the fourth proposal was withdrawn, is what and specify. The Authorization API , final in January 2026, standardizes the exchange by which Policy Decision Points and Policy Enforcement Points communicate authorization requests and decisions without requiring knowledge of each other's inner workings. That API and this document address different halves of one boundary. The API specifies how a decision is asked for and returned at the time of the request, while specifies a signed record of the decision that a party other than the two endpoints can evaluate afterwards, and binds the inputs the decision was made against into that record. In the Coalition for Secure AI's agentic-systems workstream, three open proposals touch this document. One specifies a signed, pre-execution declaration layer for agentic systems . A second asks what a verifier may conclude when evidence is absent, stating that a verifier finding no evidence for a property has three possible answers while most systems implement only two . A third defines decommissioning as a lifecycle phase that ends an agent's authority to act, under which the same agent identity cannot resume once the phase is complete . The second restates, for a general evidence layer, the distinction , and already draw between a negative result and a result that could not be established, and this document keeps its own outcome vocabulary rather than renaming it against an unadopted proposal. The third is adjacent to the irreversibility of revocation in and covers a broader lifecycle event than this document specifies. All three were open and unadopted at the time of writing. Two artifacts maintained by this document's author are named here as follow-on work rather than as independent corroboration. An authority lifecycle document records invariants about what happens to an agent's authority when the people, keys, approvals and roles around it change, each carrying a status label that separates what this document specifies, what a runnable case exercises, what an implementation ships, and what is only proposed. A public conformance suite holds the vectors those labels point at. Neither is normative here. The questions that document lists as open, among them completeness of a teardown, release from multiple concurrent suspensions, and authority state restored from a backup, are outside the scope of this revision.

Capability Map The two tables below set every document cited above against fourteen dimensions. They are one table, split at dimension h so that each half fits the page width, and every row appears in both. A cell records what the cited document states about that dimension. It does not record agreement with this document, and it does not rank the documents. Cell values. S, specifies, means the document states a rule for that dimension in its own normative text. D, describes, means the document states a model or a survey finding for that dimension without stating a rule. R, requires, means the document states the dimension as a requirement on some other mechanism. O, out of scope, means the document states that the dimension is outside what it defines. A blank cell means this document records no finding for that dimension from the cited text. A blank is not a finding that the dimension is absent from that document. Column keys.

a:

identity

b:

represented principal

c:

initial grant

d:

recursive attenuation

e:

resource and purpose bounds

f:

lifecycle and status

g:

revocation freshness

h:

exact-action binding

i:

decision record

j:

atomic admission

k:

effect evidence

l:

transparency

m:

adapters

n:

executable conformance

Documents cited above against dimensions a to g

document	a	b	c	d	e	f	g
	S			S			S
				S			S
	S
					S
	D	D		D
					S
				S
				S
						S	S
	D
		S
		S	S	S	S		S
	S		S		S
		D		D			D
	S			S	S
	S
	S			S	S		S
	R	R		R			R
					O
	S				S	S
						D

Documents cited above against dimensions h to n

document	h	i	j	k	l	m	n
				S
		S
		D
		S
		O
		O
					S
					S
		S
		S		O	S
		S		S	S		S
					S
			S
	S	S		S			S
							S
	S	S			S
	S					S
	R	R	R		R	R
	S	S	O	O
	S	S	O
	S	S
		O
		S
		S		S			S
		S
		D
		D

Two rows carry no cells. and are maintained by this document's author, the prose above states what they are, and this table records external documents. carries no cells. Its author withdrew it and continued the work as , which has its own row. What this table does not establish. It does not establish that a document without a cell in a dimension states no rule for it, because the reading behind each row was bounded to the text that row cites. It does not establish that two documents marked S in one column state the same rule, and the prose above is where the differences are stated. It does not establish that any document in it has been implemented, has been adopted, or has run a vector from any suite. It is not evidence about which document stated a dimension earlier.

Security Considerations Protocol properties that depend on mediation hold only when all privileged effects pass through the enforcement gateway described in . When agents use an SDK without an external enforcement boundary, those properties depend on agent cooperation. This section considers four attacker classes: adversarial agent, messaging attacker, runtime attacker, and compromised-but-signing agent. Runtime compromise is outside what this document specifies. A compromised-but-signing agent is a hijacked agent that produces cryptographically valid signatures over false claims about its own state. Signature verification can succeed because the signing key remains available to the attacker. Addressing this class requires evidence issued outside the compromised agent's trust domain. This document separates proof of possession from key authority (), defines historical and external signer resolution ( and ), defines separately signed principal bindings and claim levels (), and keeps attestation provenance separate from verification status (). These distinctions constrain what a verifier may conclude from a signed claim. They do not close the attack class. A single-domain deployment remains exposed, and general operationally independent witnessing of agent state remains future work (). This epistemic boundary extends to signed receipts. The gap between what a cryptographic governance protocol can prove and what it cannot is analyzed in . A signed receipt attests what the policy chain observed and decided. It does not attest ground truth about the external world. A valid receipt signature proves that the issuer attests the receipt's payload; it does not prove the payload corresponds to external fact. Verifiers MUST treat receipts as evidence of what was attested, not as proof of what is true. Signed governance mutations are exposed to a substitution class when an approval signature binds an identifier and a description rather than the mutated content itself. An approver who signs a proposal identifier can have a different proposal body substituted under the same identifier between approval and application. Approval signatures over any governance mutation SHOULD bind the full proposed content and the version transition it applies to, not a reference to them. The normative preimage for specific governance structures is companion work (); the consideration applies to any signed mutation of standing authority. Where a deployment issues consumable challenge, token, or approval artifacts carrying an expiry (for example, the approval artifact of , or challenge artifacts in a protocol binding), verifiers MUST enforce the expiry, and issuance against an expired or unparseable challenge MUST fail closed. An expiry that is carried but not enforced is equivalent to no expiry. The external correlation form () hashes fields as supplied by the correlating ecosystem. A matching external action reference is evidence of correlation between records, not of the authenticity, authority, or integrity of either record, and it MUST NOT be treated as an authority claim; correlation strength is bounded by the external ecosystem's own field discipline. The action references of and are correlation keys, not integrity seals. A reference stored in the same record as its own preimage fields binds nothing against that record's writer: a party able to edit the fields can recompute the reference in the same act. Recomputation detects accidental corruption, and detects alteration only relative to an independently held copy of the reference or of the record. Tamper evidence against a record's writer comes from a signature over the record () or from an independently held copy, not from the reference itself. An imported external chain root () relocates the root of trust for the chain built under it: APS signature verification begins at the first APS-signed hop, and the standing of everything above that hop rests on the importing party's verification of the external grant. The caller-signed verification attestation exists to make that party identifiable; a verifier that accepts imported roots accepts the importing party as a trust anchor for those chains, and SHOULD treat the attestation as the auditable record of that acceptance. A verifier that has not itself verified the external grant under its native rules holds the imported root at the strength of the importer's claim, and an audience check omitted at the point of use can admit a grant outside its intended audience. An activation condition of is enforced only at a boundary that claims that feature. A delegation gated by a recorded_event condition verifies as valid at a boundary that does not claim it, because the condition is a separate record the chain does not carry and chain verification never reads. An issuer that needs a gate applied by every verifier has only the time facet of , whose not_before every chain verifier applies. Every protocol artifact a decoder or verifier receives is untrusted input. Length, count, or size fields carried inside an artifact MUST NOT drive reads or allocation beyond the input actually received: a declared element count that exceeds the remaining input is a decoding error, and a read past the end of the input MUST fail rather than yield default values. Verification interfaces SHOULD handle a structurally malformed artifact through a defined result, whether a return value or a typed error, rather than an unhandled failure, so that malformed input cannot crash a verifier.

Corpus Failure Classes and the Assumptions They Defeat The considerations above are attacker classes. The classes below are failure shapes drawn from the case corpus this document is written against. Each one is stated with the deployment assumption it defeats and with what in the conformance suite exhibits it. Naming a fixture family means the suite carries executable cases of that shape. It does not mean the class is closed, and several classes have no family at all, which is recorded where it is true.

Principal substitution

An authority path depends on an identifier no party in the delegation graph controls, such as a mail domain a recovery flow delivers to or a namespace a reference resolves. The string is unchanged and the party behind it is not. Assumption defeated: the identifier an authority path depends on is still held by the party it was issued to. Exhibited by: lifecycle-identifier-reuse-and-rename, and by the case in action-result-binding where one record names two different acting agents.

Ambient bypass

A credential reaches the target by a path that never passes the enforcement boundary. Every record the boundary holds is valid and none of them is about the effect that occurred. Assumption defeated: all privileged effects pass the boundary. This is the mediation assumption of and it is load bearing. Exhibited by: the interop record cosai-ws4-149-decision-to-effect, whose bypass cases settle negatively on an observed alternate path and stay unsettled without a coverage premise. No fixture family establishes coverage over the paths to an effect, and the boundary-case corpus keeps the incident shapes for this class outside the lifecycle model as security-control cases.

Stale approval after an epoch change

A restored snapshot or a lagging replica presents authority state from before a reauthorization, succession or re-root, and an approval evaluated under the earlier state is admitted under the later one. Assumption defeated: no party can present pre-change state as current, and a write-fencing holder from the earlier epoch cannot publish. Exhibited by: authority-epoch-rollback.

Approval burned before admission

An approval is consumed once and then presented again, or presented after its window closed. Assumption defeated: consumption is atomic at the boundary and the expiry is enforced at consumption rather than only at issuance. An expiry that is carried and not enforced is equivalent to no expiry. Exhibited by: approval-single-use, including the already-consumed, expired and deny-not-consumable cases.

Replay after admission

Two presentations of one approval race at the boundary and both are admitted, or one approval admits a second call whose action reference differs from the one it approved. Assumption defeated: the boundary serializes consumption and compares the action reference at the moment of consumption. Exhibited by: approval-single-use, whose race pair admits the first presentation and refuses the second, and whose action-binding case refuses a call the approval does not name.

Stale revocation

A revoked grant continues to admit calls because a session, a warmed cache or a second worker never re-resolved status, or because a resolver answer the implementation did not recognise was read as active. Assumption defeated: a revocation answer reaches the boundary before the next authorization boundary, and a cache does not outlive its declared freshness bound. Exhibited by: cached-authorization-revocation, revocation-resolution-forward-compat, ancestor-revocation-chain. The corpus also records a cache whose configured lifetime drifts past its declared freshness policy as a configuration defect rather than an authority finding.

Partial teardown

A revocation cascade processes the descendants it knew about. A descendant issued locally, or signed after the revocation under a chain that still verifies, was never in that set. Assumption defeated: the set a teardown processed was every authority descendant at the relevant boundary. Signed lineage establishes structure and does not establish that a descendant was accepted authority when the revocation took effect. Exhibited by: ancestor-revocation-chain and the history-reconciliation cases of lifecycle-infrastructure-failure. No family establishes completeness, and completeness is an open question, not a settled rule.

Successor and rollback resurrection

A successor to an office or a sponsor is treated as holding the predecessor's whole delegation tree, or a restore brings back authority that had ended. Assumption defeated: a successor does not inherit the tree, and continued operation after a handover runs on the replacement chain rather than on the old one. Exhibited by: sponsor-handover, lifecycle-root-authority-succession, authority-epoch-rollback.

Concurrent suspension release

Three causes from three sources pause one grant. One is released and the grant is treated as usable. Assumption defeated: release is per cause, and a grant stays paused while any cause is live. Exhibited by: suspension-cause-composition.

Adapter semantic loss

An adapter carries an authority artifact into another stack and the dimensions that stack has no member for are dropped rather than reported as unsupported. The result is silently wider than what was granted. Assumption defeated: an adapter that cannot carry a dimension says so. Exhibited by: the cross-stack families, which record what each external format carries and what it does not.

Trust-root substitution

The root a verifier begins at is not the one the deployment intended. The imported-root case is covered above: APS signature verification begins at the first APS-signed hop and the standing of everything above it rests on the importing party. Assumption defeated: the verifier and the deployment agree on where verification begins. The corpus also carries a shape that sits upstream of any chain check, where the constants the verification arithmetic itself relies on were substituted in a build. No fixture family exercises that shape, and the corpus records it as a build-integrity case outside the authority model.

Accidental chain union

One agent holds more than one independently rooted chain and a verifier reads the union of their scopes or budgets. Neither chain granted what the union grants. Assumption defeated: each action is decided against one root-to-leaf chain. Exhibited by: chain-selection-no-union, single-chain-selection.

Indeterminate post-dispatch retry

An action-result record carries status unknown and the deployment retries. Where the effect cannot be undone, the retry risks a second effect while the record of the first says nothing about whether it occurred. Assumption defeated: a retry after an unknown result cannot produce a second effect that no compensating action reaches. Exhibited by: the unknown-status surface of action-result-binding, the no-retry cases of runtime-authority-denial-continuity, and the effect cases of the interop record cosai-ws4-149-decision-to-effect. This document states no normative retry rule for the irreversible case, as records, and the corpus keeps deduplication mechanisms such as idempotency keys and at-least-once delivery as execution behaviour rather than as authority findings.

Two of these classes have no fixture family at all, ambient bypass on the coverage side and the build-integrity half of trust-root substitution. None of the thirteen is closed. A family exhibits a shape and closes nothing, so a reader treating the list as a checklist a deployment works through is reading it as something it is not. None of the cases behind any class is a source of rules for AI agents, and nothing here states that a legal doctrine applies to one.

Privacy Considerations APS uses persistent identifiers and signed records to support attribution and audit. These records can expose or correlate an agent's principal, authority path, counterparties, action timing, target systems, and referenced evidence across administrative domains, in the sense described by RFC 6973 . Hashing a value does not make it anonymous when the input space is small or available to the observer. Deployments SHOULD disclose only the fields and evidence references needed for the verifier's decision, SHOULD avoid personal data in identifiers and free-text fields, and SHOULD define access and retention policies for passports, delegations, receipts, and evidence records. A receipt signature protects integrity; it does not authorize secondary use or onward disclosure. Where global correlation is unnecessary, profiles SHOULD use context-specific agent and principal identifiers. Key rotation does not prevent correlation when a stable agent identifier, action reference, or delegation lineage remains visible.

IANA Considerations This document has no IANA actions. DID methods are recorded in the W3C DID Specification Registries rather than through IANA. The versioned strings defined or referenced here include provenance tiers, resolution outcomes, principal claim levels, receipt_type values, profile identifiers, and the external correlation label. They are published with the reference implementation; establishing registries for them is future work.

Attribution Axes and Scope APS distinguishes four attribution axes for agentic work. They are distinct because, in multi-party workflows, they may resolve to different entities.

Authority

The delegation chain under which an action was permitted. This document specifies the authority axis in full ( and ).

Contribution

The sources, such as data, models, tools, or prior work product, that fed into a deliverable. This document does not specify a contribution-attribution model.

Principal

The entity on whose behalf, or under whose account, the agent acted. A verifier resolves the claim level of a principal binding and reports it as self_asserted, principal_attested, or externally_verified_principal under . Whether the principal that binding names is the principal the accepted authority lineage represents is profile and trust-policy dependent and may remain not established, which is the open question at .

Beneficiary

The entity that receives the value, credit, or downstream benefit the work creates. This document does not specify a beneficiary-attribution model.

The protocol must preserve the distinction between principal and beneficiary. An agent may act on behalf of an authorizing principal, such as a consulting firm, to produce a deliverable whose beneficiary is a third party, such as that firm's client. Collapsing the two axes would make this ordinary case unrepresentable. The mechanisms in this document resolve the authority axis from the selected chain, and resolve the claim level of the principal axis from the binding material, where that material is available. Associating that principal with the accepted authority lineage is profile and trust-policy dependent and may remain not established (). Contribution and beneficiary remain distinct attribution axes, but their normative mechanics are left to companion specifications. The allocation of credit, benefit, compensation, liability, or ownership across beneficiaries is out of scope for this document and is not implied by the authority chain.

Limits and Open Questions This section is informative and has two parts. The first states five limits of what this document specifies. A limit is a property of the protocol and not a question waiting on an answer. The second states the open design questions, each with what is unresolved, why the current evidence does not settle it, what this document requires until it is settled, and whether it touches APS Core or a Candidate feature. Nothing in either part is a defect report about this revision. A limit is a boundary a later revision does not move by adding a record type. An open question is a place where this document states less than an implementation already does, or less than a deployment needs.

Known Protocol Limits This subsection is informative. The five limits below are properties of what this document specifies. They are not questions awaiting an answer, and no later revision closes them by adding a record type.

No external truth.

A signature establishes that an authorized signing key attested to canonical bytes. It establishes nothing about the world the bytes describe. A valid chain, a valid receipt and a resolved evidence reference together establish what parties said and how their records relate, and never that an external event occurred. This is why keeps external truth on its own axis and why refuses to report an effect from a result record.

The mediation assumption.

Everything here rests on the deployment routing privileged effects through the enforcement boundary. That assumption is load bearing and it is not self-checking. Where a target system accepts a credential that never passes the boundary, the records defined here describe the governed path and are silent about the rest. states it and states what a verifier may conclude without it.

Live state is not in a signed record.

A signature fixes static limits. Current revocation state, the current cumulative spend total and whether an approval has been consumed are enforcement-boundary state. A verifier without access to that state reports the corresponding axis as not established and can reach no further, however complete the records it holds.

Unsupported profile semantics.

This document leaves constructions to profiles, and an implementation that does not hold a profile a record names reports unsupported. Unsupported is not a narrower reading and it is not valid. Two implementations holding different profiles can both be conforming and reach different results on the same bytes.

No proof of absence.

Nothing here establishes that a record does not exist, that a path was not used, or that a set was complete. An empty result over an interval inside a declared delivery lag is delivery lag rather than absence. A verifier that reports absence from silence has reported a finding nobody made.

What this subsection does not establish. It does not establish that the five are the only limits of this document, and it does not establish that a deployment holding all five in mind is safe.

Open Design Questions This subsection is informative. It lists the questions this document does not answer, so that the rest of the document is not read as a claim about them. Each question states four things: what is unresolved, why the current evidence does not settle it, what this document requires until it is settled, and whether it touches APS Core or a Candidate feature. A question that touches Core is one an implementation cannot opt out of by declining a feature. Nine of these come from the authority lifecycle document . Three are transitions in that no section of this revision establishes. Two were drafted as candidate lifecycle extensions and are carried here instead, because the strongest counterexample against each is unresolved and a candidate with an unresolved counterexample is a question rather than an extension. One is the distance between the lifecycle standing of and the issuer-only revocation of . Each item names the cases in that force it, where a case does, and the fixture families whose vectors touch it. None of those closes the question. A family's vectors are candidates against proposed text rather than conformance results, and naming one is not a conformance claim.

Teardown Completeness A list of processed descendants does not establish that the list was every authority descendant at the relevant boundary. Delegation can be issued locally, so a descendant can exist that the teardown process never saw, and a descendant can be signed after the revocation with a valid parent chain. Signed lineage establishes structure. It does not establish that the descendant was accepted authority when the revocation took effect. Three things a completeness claim needs are unsettled. What set a boundary claims to have accepted at a given moment. What prevents something from entering that set afterwards while still counting as earlier authority. What public commitment can establish closure over that set without exposing private state. This is why the revocation evidence rules of this document require a party emitting a cascade-completion record to be able to state the basis on which its set was complete, and define no such basis. See also and . What is unresolved. What basis makes a completeness claim over a set of descendants checkable, and what prevents an addition to that set afterwards that still counts as earlier authority. Why the current evidence does not settle it. Every family named above exercises what happens to one artifact or one chain. None of them presents a boundary asserting a set and a second party checking that assertion, because no record shape carries the basis on which the set was closed. What this document requires until it is settled. A claim that a set is complete states the basis on which it is complete, under APS-LC-COMPLETENESS-BASIS. A verifier that cannot establish that basis reports not established with the coverage limb named, and does not read an incomplete teardown as a finding that the descendants the record does not name are valid. Scope. Candidate. It touches the lifecycle continuity rules and no requirement of APS Core conformance. Cases. LC-B-022, a legal-claims exception as an actual basis for retention. LC-B-023, preservation triggered by anticipated litigation, earlier than formal process. LC-D-003, a believed inventory standing in for a verified one. LC-D-025, what a grant was used for as a different completeness claim from whether it is valid. LC-F-027, an empty audit window as delivery lag rather than absence. Candidates. BROAD-L7, whose coverage limb is a rule for reading a state claim rather than a duty to establish coverage. CAND-02, which keeps a later completeness finding as a new record rather than a rewrite. Neither closes it. Families. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-credential-events, 42 cases. lifecycle-infrastructure-failure, 30 cases. LC-B-023 has no family, because no record set decides it. This does not establish that a complete teardown is unachievable. It establishes that this document states no basis on which a party could assert one.

Work in Flight When authority is revoked while a workflow is running, the old grant cannot authorize a new effect at the next authorization boundary. What happens to the operation itself, whether it resumes under new authority, restarts, compensates or stops, depends on the kind of effect. There is no general model for it here. What is unresolved. Whether an operation already running resumes, restarts, compensates or stops after the authority it ran under changes. Why the current evidence does not settle it. The families carry timelines in which authority changes mid-operation and record the authority result at each boundary. None of them decides what the operation does next, because that decision belongs to the effect and not to the authority record. What this document requires until it is settled. The old grant authorizes no new effect at the next authorization boundary, under APS-LC-RECHECK-AT-ADMISSION. Effects already completed stand. A consumed approval admits no further dispatch, and a later attempt needs a fresh authorization decision, under APS-ENF-RETRY-NEW-DECISION. Scope. Candidate. It touches the lifecycle continuity rules and the decision-to-effect feature. Cases. LC-B-029, a receiving institution's acceptance as a terminal boundary a later change does not reach. LC-C-006, an ancestor found invalid long after the fact. LC-E-008, which policy version a long-running instance resolves its remaining steps against. LC-E-013, invalidation arriving mid-run rather than at the next gateway check. LC-E-020, dormant scheduled authority whose creator is gone. Candidates. BROAD-L6, the decision at each boundary is fresh. CAND-12, completed effects stand. CAND-16, when a recorded change becomes effective. None of them says whether the operation resumes, restarts, compensates or stops. Families. lifecycle-organization-events, 35 cases. lifecycle-multiple-principals-and-conflict, 92 vectors. lifecycle-time-and-scheduling, 61 vectors. cached-authorization-revocation, 9 cases. This does not establish that completed effects are unaffected by every kind of later finding. It states that this document bounds future effects and says nothing about the in-flight operation.

Release from Suspension Lifting one suspension should not clear another, bypass a revocation recorded while the agent was suspended, or recreate rights that changed in the meantime. Multiple suspension causes need to compose, with each one released separately. That composition is stated as a candidate and no precedence order among causes is defined. What is unresolved. Which cause is read first where two releases point in opposite directions, and whether releasing a cause can restore the shape authority had before the cause was imposed. Why the current evidence does not settle it. The composition family exercises independent release per cause. It carries no case in which two releases conflict, because the rule it tests defines no precedence and a fixture cannot test an order that does not exist. What this document requires until it is settled. Causes are a set, each release is decided independently under APS-LC-RELEASE-PER-CAUSE, and authority stays inactive while any suspension cause remains. Where a standing resolver cannot say, the state is not established rather than released. Scope. Candidate. It touches the suspension mechanism and no requirement of APS Core conformance. Cases. LC-B-011, an externally imposed restriction needing an equally external release trigger. LC-B-024, independent suspensions released independently. LC-C-022, a pending-ratification state that is neither revoked nor not revoked. LC-E-034, a queued action that outlasts a suspension. Candidates. CAND-05, which makes causes a set and requires standing for each release. CAND-09, which separates chain validity from an external block and its removal. CAND-05 defines no precedence order. Families. suspension-cause-composition, 16 cases and 5 gates. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-multiple-principals-and-conflict, 92 vectors. lifecycle-time-and-scheduling, 61 vectors. This does not establish that causes never interact. It states that no rule here decides which cause is read first when two releases conflict.

Critical Revocation Revoking a high-level authority can end the authority of a large set of agents at once. One design binds an approval for such a revocation to a snapshot of its impact and checks it again immediately before the revocation takes effect, treating uncertain impact as large rather than small. That design is written down and is neither built nor tested. What is unresolved. Whether revoking an authority whose dependents are numerous needs an approval path different from any other revocation, for example one bound to a snapshot of its impact and rechecked immediately before it takes effect. Why the current evidence does not settle it. No family in the suite exercises an impact snapshot, an approval bound to one, or a recheck against one. The design is written down and has never been run. What this document requires until it is settled. Nothing. A revocation of any size is the ordinary revocation of APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS, and this document places no additional condition on a revocation because of how many dependents it reaches. Scope. Candidate. Adopting an additional condition would change a Core behavior, which is why it is not proposed here. Cases. LC-B-025, one revoked licence invalidating every chain that depends on it at once. LC-D-004, a compromised operator identity as an implicit ancestor over many independent trees. LC-D-014, an issuer whose own issuance log cannot be relied on. LC-F-033, systemic issuer misbehaviour escalating to distrust of the whole issuer. Candidates. CAND-01, an external event is authority-changing only when established. ANX-01, a verdict records its event-class coverage. Neither proposes binding an approval to an impact snapshot. Families. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-credential-events, 42 cases. This does not establish that a large revocation needs a different approval path. It records that no vector here exercises one.

Office Vacancy and Succession Where authority was exercised for an office and nobody currently holds it, nobody may be empowered to exercise, reaffirm or revoke what the previous holder issued. Whether office-based grants continue, suspend or need reaffirmation during a vacancy, and who may act for the office until it is filled, is not defined. What is unresolved. Whether office-based grants continue, suspend or need reaffirmation while nobody holds the office, and who may act for the office until it is filled. Why the current evidence does not settle it. The succession families exercise a covering holder record, a covering vacancy record and a conflicting pair. None of them exercises a vacancy in which no party holds standing to exercise, reaffirm or revoke what the previous holder issued, because a fixture with no standing source has nothing to assert against. What this document requires until it is settled. A vacancy record covering the action instant leaves the question not established under APS-LC-VACANCY-NOT-ESTABLISHED, and a verifier does not carry the last known holder through a vacancy. Not established here is not a finding that the authority ended. Scope. Candidate. It touches the succession mechanism and no requirement of APS Core conformance. Cases. LC-A-019, a vacancy that does not have to be filled before the remaining holders can act. LC-C-007, office binding against identity binding as an explicit design choice. LC-C-008, a missing successor designation resolving to a named default rather than failing closed. LC-C-009, a succession order that is deliberately not public. LC-I-009, an interim holder's caretaking scope, including extending its own mandate. Candidates. CAND-13, replacement authority may be pre-committed. CAND-04, activation is established, not yet effective, or not established. CAND-03, which separates issuance validity from current validity. None says what happens when nobody holds the office and nobody is empowered to act for it. Families. lifecycle-root-authority-succession, 13 cases. lifecycle-fiduciary-succession, 25 cases. activation-not-established, 19 cases and 5 gates. lifecycle-expiry-and-renewal, 15 vectors. This does not establish that a vacancy ends office-based authority. It states that this document selects none of the three outcomes.

Grants Signed Just Before a Departure Where issuer standing is evaluated at issuance, an issuer who knows they are leaving can sign long-lived grants that stay valid after they are gone. A bounded lifetime for grants issued for an office, or a review when the office changes hands, are possible answers. Neither is specified. What is unresolved. Whether anything bounds what an issuer who knows they are leaving may sign, for example a bounded lifetime for office grants or a review when the office changes hands. Why the current evidence does not settle it. Issuer standing is evaluated at issuance and the families exercise it there. None of them carries an issuer signing in anticipation of a departure, because the record of such a grant is indistinguishable from any other grant signed at the same instant. What this document requires until it is settled. Nothing beyond the temporal facet the grant itself carries. Issuance validity and current validity stay separate findings under APS-PRIN-TWO-FINDINGS, and a grant signed before a departure is valid until an ordinary lifecycle event ends it. Scope. Candidate. It touches the succession mechanism and no requirement of APS Core conformance. Cases. LC-A-016, replacement authority pre-committed at issuance rather than issued after the fact. LC-C-007, whether the grant was bound to the office or to the person. LC-H-010, a resignation effective on delivery of notice, which fixes when the departure happened. LC-I-009, an interim holder extending its own reach. Candidates. CAND-03, which separates issuance validity from current validity and deliberately does not answer this. CAND-13, which covers pre-commitment and not a bound on what an outgoing issuer may pre-commit. Families. lifecycle-root-authority-succession, 13 cases. lifecycle-principal-events, 32 cases. lifecycle-agent-renunciation, 13 cases. lifecycle-expiry-and-renewal, 15 vectors. This does not establish that such grants are invalid. It states that nothing here bounds what an outgoing issuer may sign.

Authority Rollback Restoring a backup, a snapshot or a lagging replica can bring back authority state from before a revocation. An authority epoch, or an append-only record of revocations that a restore has to replay, would stop a restore from reviving revoked authority. Neither is specified here, and what a verifier should return after a restore is not tested. What is unresolved. What a verifier returns after a restore, and what a verifier does when its own remembered high-water mark was itself restored from stale state. Why the current evidence does not settle it. The rollback family exercises the rejection of stale authority: a presented value that regressed against an established high-water mark is refused. It carries no case in which the remembered mark is the thing that was restored, so it is not evidence about recovery from stale verifier memory. What this document requires until it is settled. An enforcement point does not act on a state older than the newest it has established for that subject, under APS-LC-EPOCH-NO-REGRESSION, and refuses rather than resolving by recency of write. An implementation claiming the epoch feature defines its stale-verifier-state handling or reports the feature unsupported, under APS-LC-EPOCH-FEATURE-DEFINITION. Scope. Candidate. It touches the authority-epoch mechanism and no requirement of APS Core conformance. Cases. LC-E-023, a faithfully restored process holding authority that may no longer be current. LC-F-016, a storage-layer partition resurrecting revoked authority below the application layer. LC-F-017, a revocation true at the source and false at a lagging replica. LC-F-018, regional enforcement points briefly disagreeing. LC-F-024, a lock holder whose pause outlasts its lease. LC-F-026, an isolated primary accepting writes nobody else will see. Candidates. CAND-08, which forbids acting on a state older than the newest established for that subject and requires an explicit attributable record to restore superseded authority. Families. authority-epoch-rollback, 12 cases. lifecycle-infrastructure-failure, 30 cases. conflicting-status-sources, 14 cases. This does not establish that a restore revives revoked authority. It states that no rule here prevents it.

Semantic Drift A grant can stay byte for byte the same while what it authorizes changes, because a tool, an API version or a resource classification changed underneath it. When a change in meaning should invalidate an earlier grant or approval, and how a verifier would detect it, is open. What is unresolved. When a change in what a grant authorizes, with no change to the grant itself, should invalidate the grant or an approval under it, and how a verifier holding only records would detect such a change. Why the current evidence does not settle it. The drift family exercises the pinned case, the unpinned case and a change of controller against a model-declared basis. Every one of those starts from something that was pinned or declared. No vector presents a change no party declared, because a fixture cannot supply evidence of a change nobody recorded. What this document requires until it is settled. Where the authority model declares a class of referent change capability-relevant, continuity across such a change is established by something that pins it, under APS-LC-REFERENT-CONTINUITY-PINNED. Where nothing pins it, continuity is not established and the verdict says so. An unchanged name is never read as evidence of an unchanged referent. Scope. Candidate. It touches the capability-binding mechanism and no requirement of APS Core conformance. Cases. LC-E-001, a stable model alias as a pointer with a documented default. LC-E-002, a valid grant whose named executor is gone. LC-E-027, a precedent for gating expanded capability behind re-consent. LC-E-033, a provider-side capability upgrade with no delegation-layer event. Candidates. CAND-07, a stable name does not establish stable semantics, which handles the pinned, unpinned and controller cases against a model-declared basis. CAND-11, a valid grant can be unexecutable. Whether a change in meaning should invalidate an earlier grant, and how a verifier would detect it unaided, stays open. Families. capability-binding-drift, 8 presentations and a declared defective fail set of 5. lifecycle-agent-side-events, 20 presentations. This does not establish that a pinned referent is enough. It states that detection of a meaning change by a verifier holding only records is not specified.

Notice and Relying Parties A revocation can be recorded at one moment and reach an agent, a gateway and an outside counterparty at different moments. What a relying party that acted on stale but authentic evidence is entitled to, and what evidence of notice a principal needs to show, is not defined here. What is unresolved. What a relying party that acted on stale but authentic evidence is entitled to, and what evidence of notice a principal needs to show. Why the current evidence does not settle it. The families exercise what a verifier establishes from records. Entitlement is not a finding a verifier returns from records, so no vector can assert it, and the reliance-notice family records the separation rather than resolving it. What this document requires until it is settled. Recording a transition and observing it stay separate events. Where a profile makes a change effective on a party notice, the notice finding carries its own time and a verifier records a notice finding or records that it has none. This document states no entitlement for any party. Scope. Candidate. It touches the principal and departure mechanism. No case behind this question states that a rule about human agents applies to an AI agent. Cases. LC-A-001, termination effective on the agent's notice rather than at the event. LC-A-027, a verifier's chain-is-void finding and a relying party's protected reliance as two facts. LC-A-028, two tiers of notice for known counterparties and for strangers. LC-H-006, a disputed root deposited with a neutral forum. LC-I-001, a re-registered identifier with no delegation-layer event marking the change of hands. Candidates. ANX-03, which separates chain validity from a party's knowledge and gives the notice finding its own timestamp. CAND-16, on when a recorded change becomes effective. ANX-03 proposes the separation and nothing about entitlement. Families. lifecycle-principal-events, 32 cases. lifecycle-third-party-reliance-notice, 12 vectors. lifecycle-multiple-principals-and-conflict, 92 vectors. lifecycle-identifier-reuse-and-rename, 13 presentations. The cases above come from bodies of law about human agents. Nothing here states that any of those rules applies to an AI agent, and nothing here establishes any entitlement for a relying party.

Associating a Principal with an Accepted Authority A verifier can accept a principal binding and accept a root authority basis independently, and still have established nothing about whether the two belong to one authority context. Accepting a root establishes that a chain has a head the verifier's trust policy admits. It does not establish which principal that authority represents. What is unresolved. Which artifact or verifier state associates the principal axis with the accepted authority lineage for one action, and what standing the party supplying that association has to hold. Why the current evidence does not settle it. This revision defines no artifact for the step from a principal to a first authority. PrincipalBindingV1 names the principal an agent acts for and is scoped to audiences and authority profiles. A root delegation names an issuer, a subject and an authority vector. Neither carries a reference to the other, so no family can present a substituted principal and a matching one as two vectors that a verifier separates, and none does. What this document requires until it is settled. The association is profile and trust-policy dependent, over the binding, the accepted root basis and the authority-state material. Where it cannot be made it is not established, and a verifier does not infer it from agent identity or from root selection alone, which is the safe behavior until the question is settled. A verifier that cannot establish it does not report the action as taken for the principal the chain names. Scope. Core. Every verification of every action passes through this arrow, which is why it is named here rather than left to a feature. The design work named for it is a component schema for the authority_state_ref of binding the principal, the accepted root basis, the current status and the action. That schema is tested before any new object or decision-format change, and nothing in this revision depends on it. Cases. LC-D-004, a compromised operator identity acting as an implicit ancestor over many independent trees. LC-I-001, a re-registered identifier with no delegation-layer event marking the change of hands. Families. None. The security considerations name principal substitution as a failure class and name lifecycle-identifier-reuse-and-rename for the identifier half of it. No family binds a principal reference across a decision and an admission.

A Durable Record of Admission The stage chain is intent, decision, result. Admission sits between the second and the third and produces nothing. Whether an approval was consumed is enforcement-boundary state keyed by the approval's identity, and it is not content of any record this document defines. What is unresolved. Whether the admission transition should produce a signed record, and if it should, what that record's predecessor is, what a refusal before admission produces, and what becomes the predecessor of the action-result record. Why the current evidence does not settle it. No family exercises a fourth stage. The family that pins the action-result stage supplies no predecessor in any of its cases, so the predecessor axis a fourth stage would depend on is reported as not checked throughout. A signed admission record would also not establish that the boundary performed consumption, reservation and dispatch atomically, so the record alone would not answer the question it looks like it answers. What this document requires until it is settled. A verifier that holds no consumption state reports the approval-state axis as not established, under the axis discipline of , and does not report an action admitted from an approval that was issued, under APS-EVID-STATES-NOT-SYNONYMS. Evaluation alone never consumes an approval, and a refusal before admission leaves the approval unconsumed. Scope. Core. The stage chain is core, so any durable admission record changes a Core construction rather than adding a feature beside it. Versioning, predecessor resolution and the handling of records written under this revision are settled together or not at all. Families. action-result-binding, 6 cases, with the predecessor axis not checked in all six. approval-single-use, 9 presentations, which exercises consumption at the boundary without producing a record of it.

Recovery Across Consumption, Reservation and Dispatch Consumption of an approval is atomic. Reservation against every bounded ancestor is atomic. Dispatch is neither of those things and the three are not one transaction. What is unresolved. What a boundary does after a failure between consumption and a durably established dispatch, how two concurrent admissions on one approval resolve beyond the requirement that consumption itself be atomic, and how an operation resumes without repeating its effect. Why the current evidence does not settle it. The single-use family exercises a race pair at the boundary and admits the first presentation while refusing the second. That establishes serialisation of consumption. It does not reach a failure after consumption, because a fixture that stops a boundary mid-transaction would be testing the boundary's storage and not the protocol. What this document requires until it is settled. The four moments the closed core already holds, which reads together without adding to them. An idempotent reservation lookup is not permission to dispatch again, and a consumed approval does not become reusable because its reservation is still outstanding, both entailed by , under which only an approval that has neither expired nor been consumed admits dispatch. A reservation is released only before dispatch or on trusted evidence that dispatch did not occur, which states. Scope. Core. The reservation contract is the core's. A portable recovery contract would have to be defined before any durable admission record could carry one, which is why the two questions are settled in that order. Families. approval-single-use, 9 presentations, for serialised consumption. lifecycle-infrastructure-failure, 30 cases, for the partition and restore shapes a recovery contract would have to survive.

Whether Holding a Scope Establishes Authority to Confer It This question was drafted as a candidate lifecycle extension and is carried here instead, because the counterexample against it is unresolved. What is unresolved. Whether an agent's holding a scope establishes that it may confer that scope on another party, including a child process it spawns or a copy of itself. Why the current evidence does not settle it. The statement that conferral needs its own declared authority has a counterexample nothing in the drafting answers. Authority models exist in which conferral needs no separate grant, because a platform default creates the child with no explicit pass, and models exist in which a principal may grant the power to designate successors by name, office or function. Both are real models and the statement denies authority in both. The conferral family reaches an undeclared conferral right as a schema failure rather than as a finding about conferral, so its vectors do not separate the two readings. What this document requires until it is settled. Nothing beyond what the closed core already states. Monotonic narrowing bounds what a child may receive and says nothing about who may create one, and depth exhaustion is a separate structural limit. A verifier does not report a conferral finding this document does not define. Scope. Candidate. Nothing in APS Core conformance depends on it. Cases. LC-E-006, a subagent handing a held scope to a process it spawned. Families. lifecycle-conferral-without-authority, 10 vectors.

When a Recorded Lifecycle Change Becomes Effective This question was drafted as a candidate lifecycle extension and is carried here instead, because the counterexample against it is unresolved. What is unresolved. What an authority model that declares no effectiveness rule for a change type falls back to. Why the current evidence does not settle it. The drafted default was effective from the moment the change is recorded. The counterexample is the default itself. Effective on observation is equally defensible and is what a lagging enforcement point actually does, and a deployment that treats actions allowed by a lagging boundary inside a declared bound as a declared and bounded risk has chosen it deliberately. No family runs the same change under both readings, so nothing here distinguishes them. What this document requires until it is settled. A verifier that treats a recorded change as effective records which rule it applied. Where the model declares a rule, the rule governs. Where it declares none, this document supplies no default and the effectiveness of the change at a given boundary is not established. Scope. Candidate. This is not a freshness rule, which asks how old a verifier's answer is rather than whether the change took effect at all, and it is not a notice rule about third parties. Cases. LC-F-018, regional enforcement points briefly disagreeing. Families. conflicting-status-sources, 14 cases. lifecycle-infrastructure-failure, 30 cases.

Ending Authority Without Issuer Standing A party can hold standing to end an authority artifact it never issued. names that standing and gives three shapes of it. For a direct revocation names one party, the delegation's issuer, and the format at carries one revoker member and requires it to equal that issuer. What is unresolved. Whether a party holding lifecycle standing over an artifact it did not issue can end that artifact directly, and what record carries such an act. Why the current evidence does not settle it. One requirement is keyed to the revoker member, APS-REC-REVOCATION-REVOKER-IS-ISSUER, which states for that format and marks specified and not exercised, and no vector named there presents a revocation from a party other than the issuer. A vector in either direction would need a standing source the corpus does not model, which is the same missing piece as the standing registry named elsewhere in this section. What this document requires until it is settled. A direct revocation is the issuer's. A party with lifecycle standing that is not the issuer ends dependent authority by revoking its own ancestor grant, or through a suspension cause under , which pauses use without ending the artifact. A verifier does not accept a revocation record whose revoker is not the named delegation's issuer, which the format at carries as APS-REC-REVOCATION-REVOKER-IS-ISSUER for records under that format. Scope. Core. The revocation rule is in the closed core, so a party other than the issuer is not admitted by claiming a feature. Cases. LC-B-008, authority ending completely and instantly from outside the delegation system. LC-B-025, one revoked licence invalidating every chain that depends on it at once. Families. lifecycle-outside-the-chain-standing, 22 vectors, for standing held from outside the chain. authority-revocation-record, 8 vectors, which exercises the format for an issuer revocation only.

Two Items Held Out of This Revision The two items below were drafted, reviewed and left out on purpose. They are recorded here so that the sections they would touch are not read as settled. Both are held by a ruling rather than by a missing answer, which is why they are listed apart from the questions above. The cascade-derived and cascade-completion record formats. This revision now specifies one direct revocation record format, at , which a family exercises against five independent negatives and a duplicate-offer case. That subsection defines neither a cascade-derived record nor a cascade-completion record, and no released package issues or verifies either. What is missing before this document could specify them is a family that settles who signs a cascade-derived record, how duplicates are treated, and on what basis a completion record could claim its set was complete, which is the question at . Until then the SHOULD of and its profile-defined format stand, and a verifier without both the originating revocation record and a profile for its format reports the evidence cascade state as indeterminate, which does not change the authority result. The action-result predecessor binding. For an action-result record, the prev clause carries no BCP 14 keyword while the decision-reference equality in the same sentence carries MUST, and the step that validates prev and stage transitions during receipt verification carries none. Both reference implementations accept an action-result record whose prev names the action-intent record rather than the consumed policy decision. Opt-in predecessor binding shipped in the reference implementations and is recorded there as hardening rather than as a conformance fix, and the family that pins the action-result stage supplies no predecessor in any of its cases, so the predecessor axis is reported as not checked throughout. Two things a ruling has to settle first. Whether the action-intent to policy-decision link is made normative at the same time, since it is stated in the same unkeyworded form and is a different pairing with a different expected predecessor type. What a verifier that cannot obtain the predecessor reports, which on the axis discipline this document applies elsewhere is indeterminate rather than invalid, because an unobtainable predecessor is a gap in the verifier's evidence and not a defect in the record. Families. action-result-binding, 6 cases, with the predecessor axis not checked in all 6. receipt-decision-relation, 7 vectors. Neither item establishes a defect in this revision. Each records a place where this document states less than an implementation already does.

Four Designs Under Consideration The four designs below are written down and are not part of this document. Each is stated with the one thing missing before it could enter, which in every case is a conformance family that exercises it. None of them is a commitment, and their presence here is not notice that a later revision will carry them. A root authority grant object. Authority delegation in this document starts from a record whose parent identifier is null, and acceptance of such a root is verifier policy rather than something the record establishes. A separate object for the step from a principal to the first authority would make that step checkable from records. Missing: no family exercises a record for that step, so every family starts from a chain whose root is accepted by configuration. A principal reference bound through the decision and the admission. The action-binding rule during receipt verification compares the supplied action input object's agent_id with the record's subject_agent. Both name the acting agent. A principal reference carried through the decision and then through the moment the approval is consumed would let a verifier establish that the action was admitted for the principal the chain names, and would bear on principal substitution. Missing: no family binds a principal reference across the decision and the admission point, so no vector distinguishes a substituted principal from a matching one at that boundary. An admission record between the decision and the result. Today the stage chain is intent, decision, result, and whether a decision was consumed is boundary state rather than record content, which is why the approval-state axis is not established for a verifier without access to that state. A fourth stage would make the admission itself a signed record, would give a record to rest on, would make a refusal a signed record rather than an absence, and would make the result's predecessor the admission rather than the decision. Missing: no family exercises a fourth stage, and the predecessor axis that a fourth stage would depend on is not checked in any case of the family that pins the action-result stage. A facet partition into core and profile dimensions. The authority object here carries exactly seven facets, a missing facet is invalid rather than an implicit unconstrained value, and a profile change on a facet is unsupported rather than narrower. Splitting the set into facets every implementation compares and facets a profile declares would let a deployment add a dimension without making every other implementation report unsupported. Missing: no family exercises a facet set other than the seven, so no vector shows what a verifier should return for a facet it does not know. None of the four establishes a gap that this revision has to close. Each records a design whose entry condition is a family that does not exist.

Future Work Future work includes a uniform wire vocabulary for verifier claims and evidence states across APS artifacts. This revision defines principal claim levels (), key and evidence resolution outcomes ( and ), and separate receipt-verification axes (). Generalizing those results into one normative vocabulary remains future work. A crosswalk from those results to whatever vocabulary the wider evidence-sufficiency discussion settles on is future work on the same footing. This revision does not rename its own outcomes against an unadopted proposal. Cross-implementation profiles for DecisionRefV1 also remain future work. defines the digest computation, while authority_state, policy_input, and decision_context contain deployment-defined structures. A profile that requires independent recomputation across implementations must define those component schemas and disclosure rules. The contribution-attribution and beneficiary-attribution layers () and the normative specification of institutional governance structures () remain companion work. A profile carrying a ReceiptV1 record () as a signed statement for registration with a Transparency Service also remains future work. positions the envelope against that architecture. This revision does not define the carriage, the protected claims such a registration requires, or what a relying party may conclude from a registration receipt. Operationally independent witnessing of agent state remains partially addressed. This revision separates proof of possession from signer authority (, , and ), defines separately signed principal bindings and claim levels (), and keeps attestation provenance separate from verification status (). These mechanisms constrain what a verifier may conclude from signed claims. They do not provide a general witness for the internal state of a compromised-but-signing agent, which remains open. Reasoned reaffirmation and constitutional change are future work. This revision states that a recorded revocation is irreversible, that restoring superseded authority is a new record from a party with lifecycle standing rather than a reversal, and that a successor inherits no tree. It states nothing about the case where the rule that grants authority changes rather than the authority itself: an institution amending its own charter, a principal changing the terms on which every grant beneath it stands, or a party reaffirming an authority for a stated reason after the condition that suspended it is gone. Each of those needs a record whose subject is a rule rather than an artifact, and needs a verifier to decide what a change to a rule does to the artifacts issued under the previous rule. Nothing here specifies either. Entry would need a family that exercises a rule change against the artifacts under it, which no family in the corpus does.

References Normative References The Unicode Consortium Informative References W3C Credentials Community Group Model Context Protocol Project A2A Project W3C expired 17 September 2026 Model Context Protocol Projectspecification enhancement proposal, closed 22 September 2026 Model Context Protocol Projectspecification enhancement proposal, open Model Context Protocol Projectspecification enhancement proposal, withdrawn by its author 18 July 2026 Model Context Protocol Projectspecification enhancement proposal, closed 22 September 2026 OpenID AuthZEN, Final Coalition for Secure AI, Workstream 4proposal, open Coalition for Secure AI, Workstream 4proposal, open Coalition for Secure AI, Workstream 4proposal, open IETF IETF IETF version 0.2.0-draft, commit 1e2bab7ccee3682a5dd40ccd59f8c87a4afc07e1, work by this document's author merge commit 5829e2ff00d75f49ce21e9d87e756658deb1ef33, work by this document's author

Implementation Status This section records the open-source implementations maintained by this document's author, as of 24 September 2026. It is informative and does not define APS conformance. The results below record consistency among artifacts maintained by this document's author and do not establish independent implementation or adoption. No conformance run was performed for this revision beyond the one recorded under . What the lines below rest on. Every Implemented line in this appendix, and every yes in the implementation columns of , comes from reading the sources of agent-passport-system 7.2.0 on npm and agent-passport-system 4.2.0 on PyPI. No run backs any of them except the authority-revocation-record run recorded under . A vector named anywhere in this document under an identifier that marks specified and not exercised carries no assertion keyed to that identifier, and is named because the family reaches the same subject matter. The releases described here are the TypeScript package "agent-passport-system" 7.2.0 (npm), the Python package "agent-passport-system" 4.2.0 (PyPI), the npm package "agent-passport-system-mcp" 6.1.0, and the Go repository at https://github.com/aeoess/agent-passport-go at v0.7.0. The TypeScript and Python packages carry both a pre-draft record line and a draft-native line, and only the draft-native line implements the wire formats of , and . The Go repository implements a subset centred on canonicalization, action-reference computation, verification and, since v0.7.0, issuance. The MCP package exposes protocol-layer tools. The enforcement boundary described in is a separate deployment component and is not part of the published packages. The description in that section was read from the Agent Passport Gateway repository at https://github.com/aeoess/agent-passport-gateway, at commit 05a6aac8f7261d1866316fe03bd91fe0613dfaf5 of 22 September 2026. No A2A binding is specified by this document, and the released A2A adapter code is experimental. The lifecycle modules of ship in both packages as experimental and opt-in surfaces: activation, bounds, capability-binding, authority-state, chain-selection, lifecycle-state, status-coverage and suspension. Opt-in means an application that does not import them gets none of their behavior, and experimental means the packages' own changelogs decline to promise their surfaces are stable.

Implemented and Exercised These mechanisms are implemented in the releases above and are covered by those packages' own test suites.

• The passport of and the principal binding of , in the closed wire shapes those sections define.
• Per-key validity-window selection at the artifact's signed issuance time, and the resolution outcomes of , including the ambiguous outcome for a duplicated key identifier.
• AuthorityDelegationV1 of with all seven facets inside the signed content, and the component orders of .
• Phase-major chain verification of , including the unrecognized-revocation-outcome rule and the root exemption from the not_before rule, except for the timestamp behavior recorded under the known deviations below.
• The revocation record format of . Both packages issue and verify it. The authority-revocation-record family reports 8 pass, 0 fail and 0 not_supported on each, asserting the state, the valid flag and the full failure list including message strings. That family is merged into the conformance suite at commit 5829e2ff00d75f49ce21e9d87e756658deb1ef33. Both packages also decide a record whose revoker member differs from the named delegation's issuer as invalid under a revoker-not-issuer reason code and refuse to issue one, which is APS-REC-REVOCATION-REVOKER-IS-ISSUER. That behavior is implemented in both and no vector in the family reaches it, so marks the identifier specified and not exercised. The subsection is a Candidate feature because supporting this one format is not a requirement of APS Core.
• Single-chain selection with no union across chains, which is the only continuity rule of whose module both packages ship as stable rather than experimental.
• The action_ref of and the external correlation form of , exercised across the TypeScript, Python and Go implementations with shared known-answer vectors.
• The ReceiptV1 envelope of , the identifier and signature constructions of , and the three stages of . Both packages accept the expected enforcement-boundary identity as a verifier trust input and perform the step 4 comparison against the receipt issuer.
• The decision_ref of over all five component references, and the receipt-to-decision binding and its temporal relation, which the receipt-decision-relation family exercises over seven vectors.
• The strict RFC 8785 canonicalization, checked in continuous integration for byte-identical output against independent RFC 8785 implementations.

A conformance fixture set is published at https://github.com/Agent-Authority-Conformance/aps-conformance-suite. Current versions and results are maintained at https://github.com/aeoess/agent-passport-system.

Specified but Not Implemented The following mechanisms are specified by this document and implemented by no released package. The mechanism list is followed by the identifier list generated from the implementation columns of , which is exhaustive for identified requirements and is the authority where the two disagree.

• The consumption of a permit or narrow policy-decision record as a single-use approval, at . The released verification path checks the envelope, the stage, the predecessor and the decision binding, and does not consume a receipt_id or hold single-use state. The enforcement boundary that would consume it is not a published package, which is also why the reservation and settlement ledger of and is absent.
• The not_attempted value of . No released package reports that value on the evidence-resolution axis.
• Evaluation of a relying party's trust-policy pin at the artifact's issued_at, at . The released trust-policy path evaluates a pin's validity window and its rotation overlap against verification time.
• Cascade-derived records and cascade-completion records, at . Neither is issued nor verified by any released package, and defines neither.
• The mediation-assumption rule of . No released package checks that a governed path was the only path.
• Every requirement of except the receipt-to-decision binding and its temporal relation. The interop record the section cites carries its own harness and is not a released package.
• The profile model of . No released package implements a profile document, a profile registry, or profile-context passing, and no fixture exists for a requirement on a profile document.
• The adapter contracts of , beyond the action-reference recomputation both packages already perform.
• The conformance reporting of . No released package emits a per-vector result record, and no machine-readable claim format is defined.
• Inside : the cached-decision limits of , the policy-version limb of , the binding mode, office-holder records, vacancy records, co-holder decision rules and pre-commitment of , and the principal-event records, confirmation procedures, renunciation and accountability findings of . The identifier custodian records of are evaluated and are not on this list: the released capability-binding module evaluates custodian binding and retention records supplied to it and resolves custodian standing through caller-supplied resolvers, and it issues and signs no such record. Production of those records is implemented by no released package.

Identifier list. marks 49 of its 99 identifiers no in both implementation columns, meaning neither agent-passport-system 7.2.0 on npm nor agent-passport-system 4.2.0 on PyPI has a surface that implements the requirement, read from source. A no in both columns is not a statement that the requirement is wrong or unreachable, only that no released package carries it. They are: APS-EVID-NO-RETROACTIVE-REWRITE, APS-EVID-DIGEST-MISMATCH-NOT-ESTABLISHED, APS-ENF-NO-ABSENCE-INFERENCE, APS-PROF-REQUIRED-CONTENT, APS-PROF-SEMANTIC-PRESERVATION, APS-PROF-NO-WIDENING, APS-PROF-UNKNOWN-NOT-VALID, APS-LC-ISSUER-VS-LIFECYCLE-STANDING, APS-LC-SUCCESSOR-NO-INHERITANCE, APS-LC-RECHECK-AT-ADMISSION, APS-LC-CACHED-DECISION-FRESHNESS, APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED, APS-LC-COMPLETENESS-BASIS, APS-LC-POLICY-VERSION-IDENTIFIED, APS-LC-POLICY-TIGHTENING-RESTRICTS, APS-LC-EPOCH-FEATURE-DEFINITION, APS-LC-OFFLINE-DECLARED-IN-ADVANCE, APS-LC-BINDING-MODE-NO-DEFAULT, APS-LC-VACANCY-NOT-ESTABLISHED, APS-PRIN-TWO-FINDINGS, APS-PRIN-ROLE-NOT-FROM-BODY, APS-PRIN-SILENCE-NOT-CONSENT, APS-PRIN-ACCOUNTABILITY-SEPARATE, APS-EVID-RELATIONS-NOT-TRANSITIVE, APS-ENF-EXACT-ACTION-MATCH, APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM, APS-ENF-COVERAGE-PREMISE-SCOPED, APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION, APS-EVID-EFFECT-NOT-FROM-RESULT, APS-EVID-READBACK-OUTCOMES, APS-EVID-MISSING-NAMED, APS-EVID-STATES-NOT-SYNONYMS, APS-ENF-RETRY-NEW-DECISION, APS-ENF-COMPENSATION-NEW-RECORD, APS-ENF-RESERVE-AT-APPROVAL, APS-ENF-COMPLETE-AT-ADMISSION, APS-ENF-SETTLE-AFTER-RESULT, APS-ENF-RELEASE-PRE-DISPATCH-ONLY, APS-ENF-CONFLICTING-REUSE-REJECTED, APS-ADAPT-NO-WIDENING, APS-ADAPT-NO-SILENT-SEMANTIC-LOSS, APS-ADAPT-STAGE-COMMITMENT, APS-ADAPT-CANONICALIZATION-STATED, APS-ADAPT-MCP-EXTENSION-DECLARED, APS-CONF-CLASS-NAMED, APS-CONF-CLAIM-CONTENT, APS-CONF-CLAIM-NOT-VERDICT, APS-CONF-THREE-RESULTS, APS-CONF-NOT-SUPPORTED-NOT-SCORE. The remaining identifiers are marked yes in at least one column and are outside this subsection. Where a mechanism named above covers an identifier not on this list, the mechanism is partly implemented and the implementation columns say which part.

Implementation-Specific Behavior The following items are implementation choices where this document leaves a construction to a profile or to a deployment.

• The record types named in under the proposed: namespace. The released packages ship them under that prefix in their experimental modules. This document fixes no wire name for any of them, no fixture family mints a record under any of them, and a later revision may change any of them.
• The authority-epoch marker the authority-state module carries. It is unsigned, it is not a wire field, and the module supports neither durability nor concurrency. This document defines no epoch wire field, and turns the open design choices into obligations on an implementation that claims the feature.
• The reason_code value space of and , on which neither section imposes a grammar, and the verification_method field, which does not name. The releases constrain neither.
• The target string construction requires a profile to define.
• The TypeScript Revocation-Observation emitter computes its signature over the project's legacy canonicalization rather than the RFC 8785 profile specified in this document, and verifiers of that record validate over the same form. The two canonicalizations differ only in the treatment of null-valued object members, which the legacy form omits. The record as emitted carries no null-valued members, so its signed bytes coincide with RFC 8785 for that record. The Evidence-Bundle supporting-record emitter uses the RFC 8785 profile. Revocation-Observation is not a record this document specifies.

Known Deviations

• The released delegation, receipt-core and action-reference surfaces admit the second value 60 as 23:59:60 on the last calendar day of a month. rejects the second value 60 wherever it appears. The passport and principal-binding surface rejects it. The revocation record surface of states a second value of 00 through 59 and no authority-revocation-record vector carries a second value of 60, so its behavior on that value is not established either way.
• The capability-binding-drift and lifecycle-identifier-reuse-and-rename families label an established pinned-referent mismatch as not established, in a verdict set with no denial member. specifies a denial with a mismatch reason, and both released packages decide the denial. A family run that reproduces the earlier labelling is reproducing that family's own vocabulary and is not deciding the rule.
• The actionref-canonical family's README states four vectors and its fixture file carries six, the two extra being duplicate-scope negatives, one raw and one colliding only after normalization. The count used throughout this document is six, which is the file.
• The conformance suite pins agent-passport-system 7.1.0 in its own manifest at the commit this document cites. The package sources read for this document are 7.2.0 on npm and 4.2.0 on PyPI, so a result the suite records against its pinned package ran a version one minor release behind those sources. The authority-revocation-record run reported under is the exception: it ran against clean installs of agent-passport-system 7.2.0 from npm and agent-passport-system 4.2.0 from PyPI, overriding the suite's 7.1.0 pin, and a separate run against the pinned 7.1.0 was recorded alongside it.

Changes from -03 This section is informative. It summarizes the principal changes between draft-pidlisnyi-aps-03 and this revision. It is a history and not a specification, and where it disagrees with a section of this document the section governs. The comprehensive integration did not rewrite the stabilized core beyond the -04 repairs summarized in and the edits logged under ruling R-A. The carried sections are , , , , , and , which carry the -03 rules as revised below. and sit inside that range and are new. Every literal cross-reference in that text was converted to a cross-reference by anchor, because this revision renumbers the document. The R-A edits are two. In , "principal authority is carried by the separate record" became "the principal relationship is carried by the separate record", because a binding is not a grant. In , "outside the protocol guarantees" became "outside what this document specifies".

New Sections

• , Authority and Verification Model, is new and sits before any wire format. It names the nine actors, states seven distinctions the rest of the document enforces, fixes the closed set of six artifact verdicts and the three boundary outcomes, states what evidence establishes and what it does not, names the mediation assumption as load bearing, and carries the transition contract the whole document is written against.
• is new. It specifies one wire format for the revocation record that has required since -03 without defining. It is a Candidate feature, not a change to the SHOULD above it.
• , Profile Model, is new. It states what a profile document identifies, including the loss value that applies to each APS semantic it touches, and collects the extension points at which this document defers a construction.
• , Authority Lifecycle, is new. It has four parts: concepts, twelve authority continuity rules, eight lifecycle mechanisms, and candidate extensions. Six of the twelve continuity rules restate a requirement of the closed core, one identifier each, and those six identifiers are the enumerated Lifecycle Core set. Everything else in it is a Candidate feature.
• , Decision to Effect, is new. It separates five questions a deployment routinely answers as one, states the four non-transitive relations between a decision and an effect, and states the reservation and retry contract the closed core already holds across four of its sections.
• replaces the -03 Institutional Governance section. The -03 text described an organization's structures. This revision describes how they reach the delegation layer, as charter, office, holder, root authority basis, delegation and action, and states that no family exercises the projection.
• , the enforcement gateway reference architecture, is new and informative. It describes one arrangement taken from the open-source gateway and separates what that implementation does from what this document requires.
• , Conformance, is new. It defines seven conformance classes, the form of a claim, and the three results an implementation reports per vector.
• , Limits and Open Questions, is new. It separates five limits of the protocol from fifteen open design questions, each with what is unresolved, why the evidence does not settle it, what this document requires until it is, and whether it touches Core or a Candidate feature. Two further items are held out of this revision by ruling and four designs are recorded as under consideration.
• , and are new subsections of Protocol Bindings. is a new subsection of Related Work.
• and are new appendices. The first is the provenance index from each rule to its hardest adversarial case. The second records every requirement identifier of this revision with the vectors that exercise it.

Changes Carried From -03

• Result model. makes the expected enforcement-boundary identity a trust input the verifier supplies. adds a boundary-identity comparison to step 4 of its order. This changes the conditions under which a receipt reaches valid, because a verifier given no expected boundary identity reports that axis as not established. now states that an axis a verifier did not establish never contributes to a valid result, and now states that omitting the evidence-resolution axis is not a permitted verifier scope while declining to resolve evidence is.
• Root trust. now states the chain result for a root the verifier's trust policy does not accept: invalid, with a root-trust reason at the root's index. -03 left the result for an untrusted root unsaid.
• Cascade. The -03 requirement that a revocation MUST initiate a cascade to all transitive descendants is now a MAY to produce cascade evidence. Descendant invalidity follows from the revocation check applied to every chain member.
• Revocation record. The -03 requirement that a revocation MUST produce a signed revocation record is now a SHOULD, in a format the applicable profile defines. The four minimum content elements are unchanged. This revision adds one such format at , which satisfies the SHOULD without narrowing it.
• Reservation identity. A reservation is keyed by action_ref. A request matching an unsettled and uncancelled footprint is an idempotent retry, and a request under the same action_ref whose unit, amount or bounded ancestor set differs is conflicting reuse and is rejected. reads that rule together with the three other core sections that bear on it.
• Leap second. A timestamp carries a second value from 00 through 59 in every section, and a verifier rejects the second value 60 wherever it appears. This is narrower than RFC 3339.
• Key-resolution outcome names. The five failure outcomes of carry stable names. The resolved outcome carries no failure name, and this document defines no further key-resolution outcome. no longer promises a stable failure code for chain verification, because this revision defines no failure-code vocabulary for it.
• not_before. The rule that a record's not_before MUST NOT predate its issued_at is scoped to a member whose parent_delegation_id is not null. A root MAY take effect before its own issued_at.
• Ceiling rule. An implementation ceiling reached while parsing or verifying is indeterminate with a reason naming the limit, not invalid. A syntax violation observed before any ceiling is reached remains invalid.
• Approval artifact. The -03 sentence permitting a profile to define a further approval artifact bound to the same action_ref was removed. The permit or narrow policy-decision record of identifies the consumable approval.
• Historical key selection. extends the evidence requirement to any historical key-selection boundary, including a relying party's trust-policy pin, with the ambiguous outcome as the result without such evidence.
• Approval-state axis. step 10 reports an approval-state axis, not established where the verifier holds no consumption state.
• Unit equality. states that a unit is an opaque non-empty string, that two units are the same unit when their UTF-8 byte sequences are equal, and that an implementation neither rejects a unit for failing a grammar this document does not state nor treats two unequal unit strings as one unit. -03 stated no equality rule.
• Revocation record scope. now states that this document defines no wire encoding, identifier construction, signature construction, reason-code vocabulary or signer rule for the revocation record it asks for. -03 stated the four minimum content elements and left the rest unsaid.
• Invariant citations. now states that INV-4 is reported as the evidence cascade state of and is not an input to the authority result, where -03 said a cascade-completion record made INV-4 verifiable from records. The names of INV-2, Scope Monotonic Narrowing, and INV-3, Spend Limit Narrowing, and the issuance-time enforcement that section places on them and on INV-8, are unchanged from -03. cites INV-5 where it states that a party does not replace a record it already holds.
• Title. The -03 title was "Agent Passport System (APS): Verifiable Agent Identity, Faceted Authority, and Signed Action Receipts". This revision is titled "Agent Passport System (APS): Verifiable Authority, Lifecycle, Enforcement, and Evidence for AI Agents", because authority and its lifecycle are what the document is organized around and receipts are one mechanism inside that.

Conventions Introduced by This Revision

• Every normative subsection outside the closed core carries a status block: Core, or a named Candidate feature, with the fixture families that exercise it and the released packages that implement it.
• Requirements outside the closed core carry stable semantic identifiers of the form APS-AREA-NAME, listed in . An identifier never changes because a section moves and is never reused.
• A requirement is recorded as exercised only where a named vector carries an assertion that fails when the requirement is violated. Everything else is recorded as specified and not exercised.
• Record types belonging to a Candidate feature stay in the proposed: namespace. One name graduates in this revision, aps:authority-revocation:v1, because its semantics are fixed for that record_type and version, its wire shape is specified, a family exercises it against independent negatives, and both reference implementations map to it.

Case and Rule Provenance Index This appendix is informative. It is the provenance index for the lifecycle material in this document. It has two parts: an index from each rule to the case that is the hardest adversarial instance of it, and eighteen cases given in full. The corpus itself stays where it is maintained, in , pinned at the commit that reference names, and this appendix reproduces no full listing of it. How the sources are used. The cases are drawn from law, corporate governance, aviation, medicine, banking, insolvency, government succession, military command, distributed systems, cryptographic infrastructure and published security incidents. Every one of those sources is used as a source of a case shape or of a counterexample. None of them says anything about AI agents. Nothing in this appendix states that a legal doctrine, a statute, a regulation or an institutional rule applies to an AI agent, and no such reading is intended or supported. A precedent here answers the question "what shapes does authority actually take", not the question "what rule governs an agent". Status values. "verified" means the case has a source that was fetched and quoted. "reviewed hypothetical" means the case was written and reviewed with no external precedent claimed. "candidate" means the case names a gap and is held as a candidate rather than a settled shape. "boundary" means the case is sound and resolves to something other than an authority state a verifier returns from records, which is why it is listed separately. A status is a statement about the case, not about any implementation. Family names are the fixture families of the conformance suite . Naming a family records that vectors for that shape exist. It is not a conformance result and not a claim that any implementation passes them. What this appendix does not establish. It does not establish that the corpus is complete, that the cases are independent of each other, or that any case has been tested. It does not establish that this document specifies a rule for every case listed, and several cases exist precisely because it does not.

Rule and Case Provenance Index Each entry names one rule of this document, the case that is the hardest adversarial instance of it found in the corpus, the fixture families that carry cases of that shape, and the status of the canonical case. Status values are those defined above. Where the canonical case is given in full below, the entry says so.

L1, an ancestor revocation reaches what depends on it

Canonical adversarial case LC-C-006, an ancestor found never to have been valid rather than revoked, given in full below, verified. Families: lifecycle-multiple-principals-and-conflict, ancestor-revocation-chain.

L2, identity continuity is not authority continuity

Canonical adversarial case LC-B-008, authority ending through an external fact with no artifact in the delegation graph, given in full below, verified. Families: lifecycle-legal-regulatory-events, sponsor-handover.

L3 and L4, succession creates new authority and inherits no tree

Canonical adversarial case LC-A-016, replacement authority pre-committed inside the original instrument, given in full below, verified. Families: lifecycle-principal-events, lifecycle-root-authority-succession, lifecycle-fiduciary-succession.

L5, independent chains are not combined

Canonical adversarial case LC-C-012, two independently rooted chains coordinating on one objective, given in full below, verified. Families: lifecycle-multiple-principals-and-conflict, chain-selection-no-union, single-chain-selection.

L6, an earlier approval is not current authority

Canonical adversarial case LC-B-029, a receiving institution's acceptance as a boundary a later change does not reach, given in full below, verified. Families: lifecycle-organization-events, cached-authorization-revocation.

L7, unknown revocation state is not active

Canonical adversarial case LC-F-018, regional enforcement points briefly disagreeing, given in full below, verified. Families: lifecycle-infrastructure-failure, revocation-resolution-forward-compat, conflicting-status-sources.

L8, suspension is not revocation

Canonical adversarial case LC-C-022, a pending-ratification state that is neither revoked nor not revoked, given in full below, verified. Families: lifecycle-multiple-principals-and-conflict, suspension-cause-composition.

L9, key rotation is not delegation revocation

Canonical adversarial case LC-D-013, key custody narrowed to a few named holders and defeated by one unmanaged device, verified. Families: lifecycle-credential-events, key-rotation-historical. This case is a boundary case for the authority model and is carried in the corpus rather than in full here.

L10, expiry is not revocation

Canonical adversarial case LC-A-001, authority ending at a factual moment under a notice-effective rule, given in full below, verified. Families: lifecycle-principal-events, lifecycle-expiry-and-renewal, lifecycle-purpose-exhaustion.

L11, no silent authority resurrection

Canonical adversarial case LC-E-023, a faithfully restored process holding authority that may no longer be current, verified. Families: lifecycle-infrastructure-failure, authority-epoch-rollback, chain-selection-no-union.

L12, completeness is a separate and stronger claim

Canonical adversarial case LC-F-027, an empty audit window as delivery lag rather than absence, given in full below, verified. Families: lifecycle-infrastructure-failure, lifecycle-evidence-and-record. Second canonical case LC-D-025, completeness of what a still-valid grant was used for, also given in full below.

Activation conditions

Canonical adversarial case LC-C-008, a missing successor designation resolving to a named default rather than failing closed, given in full below, verified. Families: lifecycle-time-and-scheduling, activation-not-established.

Purpose bounds and exhaustion

Canonical adversarial case LC-A-008, purpose exhaustion ending authority once an authenticated record shows the purpose was met rather than once the agent decides it was, verified. Families: lifecycle-principal-events, lifecycle-purpose-exhaustion.

Capability binding and policy version

Canonical adversarial case LC-E-033, a provider-side capability upgrade with no delegation-layer event, verified. Families: lifecycle-agent-side-events, capability-binding-drift, lifecycle-policy-change. Second canonical case LC-E-002, a valid grant whose named executor is gone, given in full below.

Authority epoch and fencing

Canonical adversarial case LC-F-016, a storage-layer partition resurrecting revoked authority below the application layer, verified. Families: lifecycle-infrastructure-failure, authority-epoch-rollback.

Suspension, cause sets and release

Canonical adversarial case LC-B-024, independent suspensions released independently, given in full below, verified. Families: lifecycle-legal-regulatory-events, suspension-cause-composition.

Status sources, freshness and coverage

Canonical adversarial case LC-F-017, a revocation true at the source and false at a lagging replica, verified. Families: lifecycle-infrastructure-failure, conflicting-status-sources, cached-authorization-revocation.

Succession, handover and reauthorization

Canonical adversarial case LC-C-014, a handover gated on the incoming holder's acknowledgment, given in full below, verified. Families: lifecycle-time-and-scheduling, sponsor-handover, lifecycle-organization-events.

Principals, identities and departure

Canonical adversarial case LC-B-026, a third party injecting an approval gate into an unmodified valid chain, given in full below, verified. Families: lifecycle-legal-regulatory-events, lifecycle-principal-events, lifecycle-principal-unreachable.

Conferral of a held scope

Canonical adversarial case LC-E-006, a scope handed to a spawned process, given in full below, verified. Families: lifecycle-agent-side-events, lifecycle-conferral-without-authority. This rule is an open question at rather than a rule of this document.

Work in flight

Canonical adversarial case LC-E-013, invalidation arriving mid-run rather than at the next gateway check, given in full below, verified. Families: lifecycle-agent-side-events, lifecycle-organization-events, lifecycle-time-and-scheduling. This is an open question at .

The queued-action shape

Canonical adversarial case LC-E-034, a queued action outlasting a suspension, given in full below, reviewed hypothetical. Families: lifecycle-time-and-scheduling, suspension-cause-composition.

Principal-to-authority association

Canonical adversarial case LC-D-004, a compromised operator identity acting as an implicit ancestor over many independent trees, verified. Families: lifecycle-credential-events, lifecycle-identifier-reuse-and-rename. This is an open question at and no family binds a principal reference across a decision and an admission.

What this index does not establish. It does not establish that the canonical case named for a rule is the only adversarial case for it, that the families named exercise the rule at the level this document states it, or that a rule with a canonical case is better covered than a rule without one. Coverage is recorded in and nowhere else.

Eighteen Cases in Full Twelve of these are the cases the lifecycle document and its candidate statements cite most. Nine of the twelve are cited eight times or more across those two documents, and the other three are cited seven times and are also used by the worked examples in . The remaining six are the cases the worked examples and the open questions of this document turn on directly. Each case carries five fields. Situation is what happened. Authority question is what a verifier has to answer. Rule exercised names the rule in this document the case bears on. Disposition in this document says what this revision does with the case, and every case carries one. What the rule does not establish is the boundary of that rule. Two further lines are kept where they exist: the source the case was drawn from, and the failure a naive implementation reaches, which is what makes the case adversarial rather than illustrative. Where the corpus recorded a proposed outcome, that line is kept as the pressure the case puts on an authority model and not as a rule. A case from another domain is a source of the question and never a source of the rule, and the disposition line is where this document answers. LC-C-008. A missing successor designation should fail open to a named statutory fallback, not fail closed like an unknown revocation Status verified. Family lifecycle-time-and-scheduling. Domain government. Situation. A role becomes vacant and the organization never issued an explicit order naming who acts in the meantime. A verifier looking for a successor designation finds none recorded. Source. The Federal Vacancies Reform Act's default rule that the first assistant to a vacant Senate-confirmed office automatically becomes the acting officer, subject to a prior-service requirement and disqualification if the President has nominated that person. US Government Accountability Office, GAO-02-272R (): "the first assistant to the office of such officer shall perform the functions and duties of the office temporarily in an acting capacity." Authority question. Does an unrecorded successor designation leave the office authority not established, or does the authority model supply a named default that the verifier must apply? Pressure this case puts on an authority model. A model that treats every unknown the same way answers this one badly. The corpus records that the domain solved it with a named default holder, resolved outside the record and checkable against its own eligibility conditions, which puts the question of whether an authority model can carry a pre-committed default at all. What a naive implementation gets wrong. A framework modeled only on L7's fail-closed rule for unknown revocation state will wrongly fail closed here too, and block a routine, lawful vacancy that the statute already solved with an affirmative default. Rule exercised. Invariants L7. L7 is about an unknown or stale revocation answer, which fails closed. An unknown successor designation is a different unknown, and in the source domain it resolves to a named fallback holder with its own eligibility gate rather than to a refusal. The two unknowns are not one. Disposition in this document. A statutory fallback is a pre-committed instrument in the sense of , and this document defines no such instrument and no default holder. Without one the vacancy is not established, with the coverage limb named, and a verifier supplies no default in either direction. What the rule does not establish. It does not establish that a named default holder exists in any deployment, and it does not establish which unknowns should resolve to a default. It establishes that an unknown successor designation and an unknown revocation answer are two different unknowns. LC-C-006. A tainted ancestor invalidates dependents only from the moment the taint is found, not retroactively Status verified. Family lifecycle-multiple-principals-and-conflict. Domain government. Situation. A chain of appointments rests on a person's authority to make them. Eighteen months later, an independent investigator finds that person's own appointment was never valid, not revoked, never valid in the first place, and by then the downstream appointees have signed many orders that already took effect. Source. The GAO's August 2020 finding that DHS acting secretary Chad Wolf's and acting deputy secretary Ken Cuccinelli's appointments were invalid, because Kevin McAleenan, who named them, had himself been installed outside the statutory order of succession and had no authority to amend that order. GAO finding, reported by GovExec (): "McAleenan's subsequent appointments of Wolf and Cuccinelli were therefore invalid, GAO said, as he was not eligible to make them." Authority question. What does a verifier report about an ancestor established to have been invalid from issuance rather than revoked, and about the decisions taken while it looked valid? Pressure this case puts on an authority model. An ancestor invalid from issuance and discovered late is not a revocation event, and a model with only a revocation event has nothing to record. The corpus also separates what a finding does going forward from what it does to effects already taken, which the finding itself does not answer. What a naive implementation gets wrong. A revocation-only model finds nothing wrong here, because no one ever revoked anything. It has no way to represent "this grant was void from issuance" discovered after the fact, and no way to backdate that discovery without either pretending nothing happened or silently erasing evidence of effects already taken. Rule exercised. Invariants L1, L12. Open question: work in flight. L1 (revoking an ancestor invalidates dependents) assumes the ancestor was once valid and was later revoked. This case is the harder one L1 does not cover, an ancestor invalid from the start, discovered long after the fact. Also touches the "work in flight" open question and L12 (completeness), since the orders executed under the tainted chain are exactly the evidence a completeness claim needs to account for. Disposition in this document. Void from issuance is the artifact verdict invalid, carrying its own reason code and separated from revoked by that code, under . The finding reaches the chain from the moment a verifier establishes it. What becomes of effects already taken is a different question, open at . What the rule does not establish. It does not establish what becomes of effects already taken under the chain while the chain looked valid, and it does not establish a moment at which the invalidity began for a relying party. LC-F-018. Multiple regional enforcement points are physically distinct copies of authority state, and can briefly disagree Status verified. Family lifecycle-infrastructure-failure. Domain distributed-systems. Situation. An APS deployment runs multiple regional gateways sharing a globally-replicated authority store. A principal revokes a delegation. The gateway in the same region as the write enforces the revocation immediately. A gateway in a different region still serves the pre-revocation decision for some seconds to minutes. Source. AWS documents IAM's own distributed, eventually-consistent propagation path. AWS IAM troubleshooting guide (): "Any changes that you make in IAM (or other AWS services)... take time to become visible from all possible endpoints. Some delay results from the time it takes to send data from server to server, replication zone to replication zone, and Region to Region." Authority question. When two enforcement points hold separate copies of authority state and disagree, which answer does a verifier treat as the state of the authority? Pressure this case puts on an authority model. A deployment with more than one enforcement point holds more than one copy of authority state, so a model has to say what a lagging copy does to an answer and what an answer outside any declared bound is worth. The corpus records propagation lag as a bound a deployment declares and tests, and the case is what forces the question rather than the answer to it. What a naive implementation gets wrong. Assuming a single "the" authority store with one true current state, when a multi-region deployment has physically distinct copies that can each individually be asked whether something is revoked and briefly disagree. Rule exercised. Invariants L7. None of L1-L12 model multiple enforcement points each holding their own view of a replicated authority store. The L7 shape, "the authority is unreachable," doesn't capture "reachable but behind." Disposition in this document. A result is what one verifier established from the sources it read at one moment. makes freshness and coverage properties of the source rather than of the authority, and makes a stale or unavailable revocation answer indeterminate and never active. This document states no propagation bound. What the rule does not establish. It does not establish a propagation bound for any deployment. It establishes that a deployment with more than one enforcement point holds more than one copy of authority state. LC-C-022. A pending-ratification state is neither "revoked" nor "not revoked," and if ratification is denied, the record has to say the action was provisional throughout, not that a final revocation was later reversed Status verified. Family lifecycle-multiple-principals-and-conflict. Domain military. Situation. A commander relieves a subordinate of command. The required written approval from a higher general officer has not yet arrived. Until it does, the relief has a lesser, provisional effect. If the approval never comes, the action is retroactively recharacterized as having only ever been the lesser effect, not undone from a final state. Source. US Army relief-for-cause procedure. Fort Carson command policy memo, quoting AR 600-20 (): "Any commander may temporarily suspend a subordinate from command, but the final action to relieve an officer from any command position will not be taken until after written approval by the first general officer in the chain of command." Authority question. How does a verifier report a change that has been initiated, has partial effect, and becomes final only on a separate approval that may never arrive? Pressure this case puts on an authority model. A change that has partial effect and becomes final only on a separate approval fits neither revoked nor not revoked. The corpus records the domain treating the interval as provisional throughout, so a model that only has a final state has to recharacterize the earlier record afterwards, which is the move this document does not allow. What a naive implementation gets wrong. Conflating this with an ordinary self-declared, self-terminated suspension. This is a different shape, an external, unilateral suspension by a superior that only becomes a final revocation with a specific separate approval. Treating the two the same either finalizes a revocation that legally never became final, or fails to suspend the subordinate while waiting on paperwork. Rule exercised. Invariants L8. Open question: release from suspension. Adds a ratification-pending intermediate state with retroactive recharacterization on denial, a shape not present in L8's plain suspension and revocation split, and directly relevant to release from suspension, . Disposition in this document. A pending ratification is a suspension cause under . Authority is inactive while the cause stands, the cause is released only by a party with standing over it, and a release creates no new authority. No verdict for a revocation that is not yet final is defined here. What the rule does not establish. It does not establish who may ratify, and it does not establish how long a pending state may stand before something else has to happen. LC-A-001. A principal's death ends actual authority regardless of durability, effective on the agent's notice, not at the instant of death Status verified. Family lifecycle-principal-events. Domain agency-law. Situation. A principal dies. An agent holding a delegation from that principal, durable or not, keeps trying to act on the principal's accounts. Nobody has processed a revocation record. Source. Restatement (Third) of Agency §3.07: reproduced text, staff.washington.edu (): "The death of an individual principal terminates the agent's actual authority. The termination is effective only when the agent has notice of the principal's death." Durability does not change this: Uniform Power of Attorney Act (2006) §110(a), as enacted at N.H. RSA 564-E:110 (): a power of attorney terminates when "(1) the principal dies; (2) the principal becomes incapacitated, if the power of attorney is not durable." Authority question. Does authority end at the event, or at the moment the acting party has notice of it, and which of the two does a verifier hold evidence for? Pressure this case puts on an authority model. In the source domain authority ends at the principal's death whatever the instrument says, and takes effect for a party on that party's notice rather than at the instant of the event. A model that records only a manual revocation has no place for either the event or the notice, and recording a transition and observing it are two events with two times. What a naive implementation gets wrong. A revoke-only system waits for an explicit revocation record and misses that death is a self-executing terminating event. A system can also over-read "durable" as blanket death-immunity, when durability is scoped only to surviving incapacity, not death. Every power of attorney, durable or not, ends at death. Rule exercised. Invariants L1, L10. L1, L10. Termination happens at a factual moment (death) under a notice-effective rule, not an ancestor-revocation record. The scope of "durable" (incapacity-survival only, never death-survival) is a distinction no invariant states, and a naive system easily over-generalizes it. Disposition in this document. An external event changes a verifier's answer only through a record from a party in a role the authority model accepts, which is and . The death itself reaches no verifier. A record of the event decides nothing without that accepted role, and where the role cannot be resolved the continuation of authority is not established. What the rule does not establish. It does not establish that any rule about human agents applies to an AI agent. It does not establish how notice is evidenced, or who carries the burden of showing it. LC-B-029. A receiving bank's acceptance is the hard boundary after which a mid-flight authority change no longer stops the order Status verified. Family lifecycle-organization-events. Domain banking-payments. Situation. A treasury agent submits a payment order under a valid delegation. The authorizing principal's authority is revoked minutes later. If the receiving bank has not yet accepted the payment order, the revocation stops it from settling. If the bank already accepted it, the order proceeds regardless of the revocation, unless the bank itself agrees to unwind it. Source. UCC 4A-211's acceptance boundary. Cornell LII (): "After a payment order has been accepted, cancellation or amendment of the order is not effective unless the receiving bank agrees or a funds-transfer system rule allows cancellation or amendment without agreement of the bank." Authority question. Once an operation has passed a boundary after which no further authorization decision occurs, does a later authority change reach it? Pressure this case puts on an authority model. The corpus leaves work in flight open. In this document that is : the old grant cannot authorize a new effect at the next authorization boundary, and what happens to the operation itself is unsettled. This supplies a concrete resolution for one instrument type: the receiving institution's acceptance is the hard boundary. Before it, revoking the authorizing delegation stops the order. After it, the order proceeds independent of what the delegation graph says. What a naive implementation gets wrong. Assuming revocation automatically halts any payment order already submitted under it ignores that acceptance gives the order a revocation-proof effect. Assuming revocation never matters for in-flight orders ignores that unaccepted orders remain fully stoppable. Rule exercised. Invariants L6. Distinct from the already-verified LC-B-028 (stop-payment), which is a customer-initiated cancellation decision under L6's recheck principle. This is the underlying delegated authority itself changing mid-flight, the specific question left open under work in flight, . Disposition in this document. The old grant admits no new effect at the next authorization boundary, under APS-LC-RECHECK-AT-ADMISSION. What happens to an operation already under way is open at , and this document defines no acceptance boundary inside a target system. What the rule does not establish. It does not establish a boundary for any instrument other than the one it names, and it does not establish what the operation should do once that boundary has passed. LC-B-026. A third party outside the principal-agent relationship can inject a new approval gate into an otherwise unmodified, valid chain Status verified. Family lifecycle-legal-regulatory-events. Domain regulatory. Situation. A company settles a regulatory action. The consent decree does not touch any existing delegation. It adds a new, externally-imposed requirement that a named "responsible employee or official" personally certify a defined category of future reports, for the life of the decree. Source. Consent decree practice requiring a named responsible official to certify compliance reports under penalty of law. SEC EDGAR filing (): "...which makes any representation concerning the Defendants' compliance or noncompliance with any requirement of this Consent Decree shall be certified by a 'responsible employee or official' of the Defendants." Authority question. How does a verifier report an approval gate added from outside the delegation chain, when no artifact in the chain changed? Pressure this case puts on an authority model. The original delegation chain is untouched and still valid, and a transaction in the decree's scope is no longer sufficient on that chain alone. It also needs the named official's separate certification, until the decree's own sunset date. What a naive implementation gets wrong. A gateway that only re-verifies the original chain has no slot for a chain-external approval requirement injected by an outside party. It keeps authorizing exactly the transactions the decree was meant to catch, because nothing in the delegation itself changed. Rule exercised. Structurally close to a dual-control policy, but the source of the added gate is external (a court-approved settlement, not internal risk policy), which none of L1-L12 name as a category. Also the strongest sourced instance found of "policy change" as a family. Disposition in this document. The chain stays valid and the added gate denies the action at the boundary, which is the restricted state of . No record defined here carries the gate, and a deployment that needs one states it in its profile. What the rule does not establish. It does not establish how an externally added gate is carried in a record, and it does not establish that the added gate narrows the underlying grant. LC-B-008. Authority can end completely, instantly, and outside the delegation system entirely Status verified. Family lifecycle-legal-regulatory-events. Domain regulatory. Situation. A bank's officer authority does not merely get revoked. A federal receiver is appointed and by statute steps into every power that officer held, the instant the appointment takes effect, with zero notice to the delegation system that was relying on that officer's authority. Source. 12 U.S.C. § 1821(d), under which the FDIC as receiver of a failed bank succeeds by operation of law to all rights and powers of the institution and its officers. Cornell LII (): "The Corporation shall, as conservator or receiver, and by operation of law, succeed to all rights, titles, powers, and privileges of the insured depository institution." Authority question. What does a verifier do when the authority at the head of a chain ends through an external fact that produces no artifact anywhere in the delegation graph? Pressure this case puts on an authority model. In the source domain every delegation rooted in the former officer's authority ends when the receiver is appointed, whether or not any system recorded a revocation, and no replacement authority exists until the new principal issues one. A model in which authority ends only through a record it holds has nothing to read here, which is what makes the case adversarial. What a naive implementation gets wrong. A system that expects the terminating event to show up as a revocation record in the infrastructure it monitors sees nothing, because the ancestor authority ended through an external legal fact with no corresponding artifact anywhere in the delegation graph. Rule exercised. Invariants L1, L2. A harder-edged instance of L1 and L2, where the "ancestor" whose end triggers invalidation is not an APS artifact or even a company-internal record, but a statute taking effect the instant a regulator acts. Disposition in this document. An external event changes a verifier's answer only through a record from a party in a role the authority model accepts, which is and . The appointment reaches no verifier by itself. Replacement authority is a new grant from a party that currently holds the authority granted, under . What the rule does not establish. It does not establish that an external legal fact is observable to a verifier, and it does not establish the moment at which a verifier could establish one. LC-A-016. Some replacement authority is pre-committed at issuance time, not issued fresh after the fact Status verified. Family lifecycle-principal-events. Domain agency-law. Situation. A single delegation instrument names a primary delegate and an ordered list of successors. The primary exits: dies, resigns, becomes incapacitated. The next-in-line successor should be able to act under the same original grant, with no new document and no action required from the principal at the moment of handoff. Source. The Uniform Power of Attorney Act's successor-agent provision. UPOAA (2006) §111, hosted by the Mississippi Secretary of State (): "A principal may designate one or more successor agents to act if an agent resigns, dies, becomes incapacitated, is not qualified to serve, or declines to serve." Authority question. Where replacement authority was pre-committed inside the original instrument, does the successor act under that instrument or need a fresh grant? Pressure this case puts on an authority model. In the source instrument the successor's authority comes from the original grant, at the scope and terms that grant already set, and becomes exercisable on the primary's exit with nothing issued at handoff time. A model in which replacement authority is always issued fresh after the fact has no shape for a grant that was pre-committed at issuance. What a naive implementation gets wrong. A system built around "replacement authority always means a fresh grant from a currently-authorized principal" (the L3/L4 pattern) has no slot for succession pre-committed inside a single instrument. It either treats the successor as unauthorized until a new grant appears, or wrongly treats the successor as inheriting the primary's entire personal delegation tree rather than just this one instrument. Rule exercised. Invariants L3, L4. L3 and L4 assume replacement authority is issued fresh, after the fact, by whoever currently holds authority. This is a third pattern, authority pre-committed at issuance for a defined contingency, that neither invariant names. Disposition in this document. Pre-commitment is named at and no released package implements it. Where the terms declare no binding mode and the actor is not the named subject, the mode is not established and a verifier supplies no default. What the rule does not establish. It does not establish that a pre-committed successor is exercisable, and it does not establish what the successor may do before its activating condition is established. LC-E-034. A queued action that outlasts a suspension needs a live check at fire time, not just at the moment it was queued Status reviewed hypothetical. Family lifecycle-time-and-scheduling. Domain agent-native. Situation. An agent's authority is suspended pending an investigation. It already had a recurring action queued to fire later. The suspension is lifted before the queued action's scheduled fire time. The scheduler holding the queued action has no visibility into suspension state at all, it only knows the schedule, and fires the action exactly as originally planned. Source. No external precedent claimed. Authority question. Does a queued action carry the authority state it was queued under, or the state live at the moment it fires? Pressure this case puts on an authority model. This particular timeline is benign under L8's own logic, since the suspension was already lifted before the action fired, so denying it would be wrong. The case is worth naming because the scheduler got the right answer by accident, having never checked live suspension state at all. The same scheduler would fire the action identically even if the suspension were still active at fire time, which is the actual failure this case points at. What a naive implementation gets wrong. A scheduler that only checks authority state at the moment an action was queued, not at fire time, produces the correct result in this timeline purely by luck. Change nothing about the scheduler and only change the timeline so the suspension is still active at fire time, and it fires an action that should have been paused, because dormant queued work was never something L8's stated mechanism has a hook to act on until the scheduler itself checks live state at fire time. Rule exercised. Invariants L8. L8 is specified only in terms of pausing the use of authority and everything that depends on it, which implicitly assumes a live dependency to pause. A queued-but-not-yet-executing action is dormant, not in use, so L8's text does not make explicit that the scheduler must check live state at fire time for the scheduled-action case specifically. Disposition in this document. The recheck at the moment of consumption is APS-LC-RECHECK-AT-ADMISSION. A scheduler is not an enforcement boundary in this document, and a queued action reaches an authority answer only at the next authorization boundary. What the rule does not establish. It claims no external precedent. It does not establish that any scheduler behaves this way, and the timeline it names is benign. Its value is the failure next to it, a scheduler that would fire identically with the suspension still standing. LC-F-027. An empty audit window can mean the record hasn't arrived yet, not that nothing happened Status verified. Family lifecycle-infrastructure-failure. Domain distributed-systems. Situation. An APS deployment's audit pipeline batches evidence records for delivery rather than writing them synchronously. A revocation is enforced immediately at the gateway, but the durable audit record proving the decision happened does not land in the evidence store for some minutes afterward. Source. AWS documents that CloudTrail log delivery is not instantaneous. AWS CloudTrail FAQs (): "Typically, CloudTrail delivers an event within 5 minutes of the API call." Authority question. Can a verifier read an empty window in an evidence store as a finding that nothing happened in that window? Pressure this case puts on an authority model. An evidence store read inside its own delivery lag is not a complete account of the interval asked about, so a model that reconstructs authority state at a past instant has to say what an empty window is worth. The corpus records delivery lag as a bound a deployment declares and monitors, and it does not follow that an enforcement decision waits on its own audit record. What a naive implementation gets wrong. Treating an empty audit-log window as proof nothing happened during that window, when it may only mean the batched delivery hasn't caught up yet, exactly the wrong conclusion for an investigation happening in near-real-time. Rule exercised. Invariants L12. L12 (completeness is a separate and stronger claim). This is the delivery-lag instance: a record that hasn't arrived yet is not evidence of absence. Disposition in this document. A verifier does not read absence from silence. APS-LC-COMPLETENESS-BASIS makes a completeness claim state its basis and reports not established with the coverage limb where that basis cannot be established, and carries no proof of absence as a limit of this document. What the rule does not establish. It does not establish a delivery bound, and it does not establish that a record which has not arrived will arrive. LC-D-025. "Authority is currently valid" and "a complete record exists of what was done under it" are different claims a verifier answers separately Status verified. Family lifecycle-credential-events. Domain security-incident. Situation. An outsourced support role is legitimately scoped to view sensitive customer data as part of its ordinary function. Some holders of that access are bribed to misuse it within that same valid scope. The org detects and terminates the involved principals before an extortion attempt surfaces, but the data already copied out cannot be recovered by the termination. Source. Coinbase's May 2025 disclosure that criminals bribed a number of its outsourced, India-based customer support contractors to copy customer data, which was then used in a $20 million extortion attempt. The Hacker News (): "What these attackers were doing was finding Coinbase employees and contractors based in India who were associated with our business process outsourcing or support operations, that kind of thing, and bribing them in order to obtain customer data." Authority question. Does establishing that authority is no longer valid establish anything about what was done under it while it was valid? Pressure this case puts on an authority model. Revoking a misbehaving principal's authority answers whether it can still act and answers nothing about what it already did while the authority was valid. The second question needs its own account, built from evidence of exercised authority inside the valid window, and a model that reports only the first has no way to say that the second is unanswered. What a naive implementation gets wrong. Treating "we revoked their access" as having closed the incident conflates stopping future authorized action with establishing what happened during the entire window the authority was, by every technical measure, valid and properly scoped. A validly scoped grant misused for its whole active duration leaves a gap no revocation, however prompt, can retroactively close. Rule exercised. Invariants L12. Distinct from L12's teardown-completeness framing, which is about whether a descendant list was complete at a boundary. This is about whether the record of what a still-valid grant was actually used for is complete, a related but separate completeness claim about exercised authority rather than about descendant enumeration. Disposition in this document. Chain validity and an account of what was done under a grant are two findings. APS-LC-COMPLETENESS-BASIS governs the second, and this document defines no basis on which such an account is complete. What the rule does not establish. It does not establish what a complete record of exercised authority would contain, and it does not establish that the revocation was late. LC-C-012. Independently rooted chains can commit to a shared objective without unioning their scopes Status verified. Family lifecycle-multiple-principals-and-conflict. Situation. One agent holds two chains from two unrelated roots. It proposes an action whose amount is above the ceiling of either chain on its own and below the two ceilings added together, and presents both chains for the one action. Authority question. Does holding two valid chains give an agent authority that neither chain gives it, and is coordinating on one objective the same thing as combining two authorities? Rule exercised. APS-AUTH-CHAIN-NO-UNION and APS-AUTH-CHAIN-SET-NOT-A-SELECTION, at . Each action is decided against one root-to-leaf chain. A concatenated presentation is not a selection of one chain and no action is decided against it. Independently rooted chains may coordinate on a shared objective while each keeps its own scope. Disposition in this document. APS-AUTH-CHAIN-NO-UNION decides it. One chain per action, no union of scope grants or spend ceilings, and cross-principal composition needs a profile this document does not supply. What a naive implementation gets wrong. A verifier that unions the two ceilings admits an amount neither principal granted, and reports a single result for a decision it made against a set. What the rule does not establish. It does not establish how an action selects its chain, which is an implementation choice. It does not establish that cross-principal composition is impossible, only that it needs a profile this document does not supply. LC-E-006. Holding a scope does not carry authority to hand it to something you spawn Status verified. Family lifecycle-agent-side-events. Situation. An agent holding a scope spawns a child process and passes the scope to it, with nothing in the authority model declaring that the agent may confer authority. Authority question. Is authority to exercise a scope the same authority as authority to confer that scope on another party? Rule exercised. Nothing normative in this revision. The question is carried at because the counterexample against the drafted rule is unresolved. Monotonic narrowing bounds what a child may receive and says nothing about who may create one. Disposition in this document. Nothing normative in this revision. The question is carried at , and until it is settled a verifier that cannot establish conferral authority reports it as not established rather than reading it out of possession. What a naive implementation gets wrong. A framework that reads conferral out of possession creates authority for a party the principal never named, and a framework that forbids it outright denies authority in models where a platform default supplies it. What the rule does not establish. It does not establish that conferral always needs a fresh act of the principal, and it does not decide what happens to children already issued without declared conferral authority. LC-C-014. A handover can require the incoming holder's acknowledgment, with authority staying put until it arrives Status verified. Family lifecycle-time-and-scheduling. Situation. Responsibility for an agent moves from one holder to another. The instrument governing the handover makes the move effective on the incoming holder acknowledging it rather than at a stated instant. Authority question. Is a handover an instant at which one party authority ends and another begins, or an interval with a condition at its end? Rule exercised. APS-LC-SUCCESSION-NEW-GRANT and the handover rules at . The agent keeps its identity, its old authority does not survive revocation of the ancestor it depended on, and the replacement chain stands on its own because it was independently issued. Ordering is a deployment choice: a planned handover may accept an overlap and a compromised holder may call for a gap. Disposition in this document. The acknowledgment-gated handover is described at and no released package implements it. Where the terms declare no binding mode, the mode is not established and a verifier supplies no default. What a naive implementation gets wrong. A framework that models a handover as an instant has no state for the interval, and either grants the incoming holder authority before the acknowledgment or leaves the outgoing holder with none after the announcement. What the rule does not establish. It does not decide the cutover order for any deployment, and it does not establish what covers the agent work during the interval. LC-B-024. Multiple independent suspensions on the same principal have to be released independently, not cleared by any one of them lapsing Status verified. Family lifecycle-legal-regulatory-events. Situation. Two parties, acting for unrelated reasons, each impose a suspension on one grant. One of the two releases its own. Authority question. Does a release from one source reach a cause imposed by another, and what is the state of the grant while one cause remains? Rule exercised. APS-LC-CAUSE-SET-NOT-FLAG, APS-LC-RELEASE-PER-CAUSE and APS-LC-RELEASE-STANDING-EXTERNAL, at . Causes are a set, each named cause is decided independently, standing over a cause is resolved outside the record, and a party holding standing over a cause it did not impose can release it. Disposition in this document. APS-LC-CAUSE-SET-NOT-FLAG and APS-LC-RELEASE-PER-CAUSE decide it, and defines no precedence order among causes. What a naive implementation gets wrong. A framework holding one suspension flag clears the whole pause on the first release, and a framework that reads standing from the release record lets any genuine signature clear any cause. What the rule does not establish. It does not define a precedence order among causes, and it does not establish that a release returns authority to the shape it had before the cause was imposed. LC-E-002. A valid, non-expired, non-revoked grant can become unexecutable, and that is a fourth state, not a variant of the other three Status verified. Family lifecycle-agent-side-events. Situation. A grant names a target, an executor or a capability that no longer resolves. Nothing in the grant has changed and no lifecycle event has occurred. Authority question. Does a referent that has vanished change the verdict on the artifact, or does it change only what happens at execution? Rule exercised. The unexecutable statement at , which is informative because no family exercises it. The artifact verdict is unchanged, the execution attempt fails, and the record carries the referent that could not be resolved. Unexecutable is an execution outcome and not an artifact verdict. Disposition in this document. , which is informative. The artifact verdict is unchanged, the execution attempt fails, and the record carries the referent that could not be resolved. What a naive implementation gets wrong. A framework that reports such an artifact invalid, expired, revoked or suspended reports a lifecycle event that did not happen, and loses the distinction between an authority that ended and a target that vanished. What the rule does not establish. It does not prescribe which party re-points a grant whose referent is gone, or whether that party may. It does not cover a referent that changed rather than vanished. LC-E-013. A long job's own logic must expect authority invalidation to arrive silently mid-run, not only at its next gateway check Status verified. Family lifecycle-agent-side-events. Situation. An agent is part way through a long operation when the authority it is running under is revoked. The next authorization boundary is some distance away. Authority question. What does the agent do between the revocation and the next boundary, and does the revocation reach the work already under way? Rule exercised. APS-LC-RECHECK-AT-ADMISSION at , and CAND-12 at . The old grant authorizes no new effect at the next authorization boundary. Effects already completed stand, and ending authority does not by itself end sessions or derived credentials already issued. Disposition in this document. APS-LC-RECHECK-AT-ADMISSION decides the next authorization boundary. Whether the operation resumes, restarts, compensates or stops is open at . What a naive implementation gets wrong. A framework that checks authority only at a gateway treats the interval between boundaries as covered by the last check, and an implementation that assumes revocation halts a running operation assumes a control this document does not require. What the rule does not establish. It does not say whether the operation resumes, restarts, compensates or stops, which is the question at .

Boundary Cases These 36 cases came out of the same research as the cases above and each one is sound. What each lacks is a lifecycle verdict. Each resolves to a liability outcome, a detection-surface gap, an operational practice or an evidence question rather than to an authority state a verifier returns from records. They are listed because they bound the model. They mark where the authority question stops and a different question starts, and a design that answers one of them by extending the authority model is answering a different question from the one it looks like. Grouped by the reason each is outside the authority question, with the count in each group: execution and scheduler mechanics, 5. Implementation or configuration defect, 2. Liability or legal consequence, 5. No authority transition in the scenario, 2. No verifier in the scenario, 3. Security control, 19. The full list is held in and is not reproduced here. Eight of the thirty-six are named elsewhere in this document and are given here so that those references resolve. LC-E-010, an idempotency-key retry returning the original result instead of re-executing, and LC-E-011, a reused key with changed parameters erroring outright, both under execution and scheduler mechanics, and both behind the statement at that deduplication is execution behavior rather than an authority finding. LC-E-022, at-least-once delivery making the target rather than the scheduler responsible for preventing duplicate execution, same group. LC-F-036, a cache whose configured lifetime drifts past its declared freshness policy, under implementation or configuration defect, which the stale-revocation failure class names as a configuration defect rather than an authority finding. LC-D-016, a substituted cryptographic constant defeating structural verification, under security control, which the trust-root substitution class names as the build-integrity half with no fixture family. LC-D-023 and LC-D-019, an admin credential on a readable share and harvested credentials remaining sufficient, both under security control, behind the ambient bypass class. LC-D-027, a narrowly granted vendor credential reaching unrelated systems because nothing enforced the boundary, same group and same class. Several of these are published security incidents. They are listed as sources of case shapes. Nothing here attributes fault to any named organization, and nothing here states that any incident would have gone differently under this document. This list does not establish that a boundary case is unimportant, and it does not establish that the six reasons are the only reasons a case could fall outside the authority question. It establishes which cases were read and set aside, and why.

Requirement Matrix This appendix is informative. It records every normative requirement this revision states outside the closed core, under the stable semantic identifier that requirement carries, with the section that states it, the feature it belongs to, the vectors that exercise it, and whether each reference implementation covers it. Identifiers have the form APS-<AREA>-<SEMANTIC-SLUG> defined in . The areas are fixed: ID, PRIN, AUTH, LC, POL, ENF, REC, EVID, PROF, ADAPT, GOV and CONF. An identifier never changes because a section moves and is never reused. Renumbering this document moves no identifier. Feature values. Core means a requirement of APS Core conformance, mandatory for an implementation claiming the class the requirement's area maps to in . Core, restated means the requirement is stated in the closed core and the named section restates it without adding to it, so citing either place cites one requirement. Lifecycle Core is an informative grouping name for the six identifiers in that restate the closed core, one from each of six of the twelve continuity rules, and it is not a claimable base. Core, document requirement means a requirement of APS Core conformance that binds a document a party writes rather than a runtime check a verifier performs, so no runtime vector can reach it. Every other value names one Candidate feature an implementation can claim. Vector columns. A requirement is recorded as exercised only where a named vector carries an assertion that fails when the requirement is violated. A related family is not coverage, and a family named in a status block is not coverage on its own. Where both vector fields read none, the requirement is specified and not exercised. Of the 99 requirements below, 14 are exercised by a named vector and 85 are specified and not exercised. Implementation columns. TypeScript is agent-passport-system 7.2.0 on npm and Python is agent-passport-system 4.2.0 on PyPI. A value of yes means the named package has a surface that implements the requirement, read from its source, not that a run was observed. The one run this document records is the authority-revocation-record run at , and no other run backs a value in these columns. Corpus pin. Every vector named below is present in the APS conformance suite at merge commit 5829e2ff00d75f49ce21e9d87e756658deb1ef33, dated 24 September 2026, which includes the authority-revocation-record family. Vectors were read from the working tree at commit 04c2e334395c55c029f061ae0ca55f80aeb6ee9e plus that family, and no vector changed between the two commits.

Requirements of This Revision The implementation values below come from reading the sources of agent-passport-system 7.2.0 on npm and agent-passport-system 4.2.0 on PyPI, on the same basis as . No run backs any of them except the authority-revocation-record run recorded under . A vector named under an identifier marked specified and not exercised carries no assertion keyed to that identifier. Where a status block elsewhere in this document lists implemented requirements, it lists the identifiers this list marks yes for at least one of the two packages.

APS-EVID-VERDICT-SET-CLOSED

Section: . Feature: Evidence model. Positive vectors: lifecycle-evidence-and-record, all 12 cases, whose runner asserts the closed verdict vocabulary on every case. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-EVID-REASON-CODE-REQUIRED

Section: . Feature: Evidence model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-EVID-NOT-ESTABLISHED

Section: . Feature: Evidence model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-EVID-NO-RETROACTIVE-REWRITE

Section: . Feature: Evidence model. Positive vectors: lifecycle-evidence-and-record LC-G-006-b, LC-G-006-c. Negative vectors: lifecycle-evidence-and-record LC-G-006-d, LC-G-006-e. Implementation: TypeScript no, Python no.

APS-EVID-DIGEST-MISMATCH-NOT-ESTABLISHED

Section: . Feature: Evidence model. Positive vectors: none. Negative vectors: lifecycle-evidence-and-record LC-G-006-f. Implementation: TypeScript no, Python no.

APS-ENF-NO-ABSENCE-INFERENCE

Section: . Feature: Evidence model. Positive vectors: none. Negative vectors: accountability-record vector 9, positive-deny-executed. Implementation: TypeScript no, Python no.

APS-REC-REVOCATION-TIME-SIGNED

Section: . Feature: Revocation record format. Positive vectors: authority-revocation-record ARR-01. Negative vectors: authority-revocation-record ARR-04. Implementation: TypeScript yes, Python yes.

APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED

Section: . Feature: Revocation record format. Positive vectors: none. Negative vectors: authority-revocation-record ARR-05. Implementation: TypeScript yes, Python yes.

APS-REC-REVOCATION-RECOMPUTE-IDS

Section: . Feature: Revocation record format. Positive vectors: authority-revocation-record ARR-01. Negative vectors: authority-revocation-record ARR-02, ARR-03, ARR-06. Implementation: TypeScript yes, Python yes.

APS-REC-REVOCATION-FIRST-WINS

Section: . Feature: Revocation record format. Positive vectors: authority-revocation-record ARR-07. Negative vectors: authority-revocation-record ARR-08. Implementation: TypeScript yes, Python yes.

APS-REC-REVOCATION-REVOKER-IS-ISSUER

Section: . Feature: Revocation record format. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-PROF-REQUIRED-CONTENT

Section: . Feature: Profile model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PROF-SEMANTIC-PRESERVATION

Section: . Feature: Profile model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PROF-NO-WIDENING

Section: . Feature: Profile model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PROF-UNKNOWN-NOT-VALID

Section: . Feature: Profile model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-STANDING-NOT-FROM-RECORD

Section: . Feature: Lifecycle concepts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-STANDING-THREE-VALUED

Section: . Feature: Lifecycle concepts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-ISSUER-VS-LIFECYCLE-STANDING

Section: . Feature: Lifecycle concepts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-VERDICT-ENUMERATIONS-DISTINCT

Section: . Feature: Lifecycle concepts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-NOT-ESTABLISHED-LIMB

Section: . Feature: Lifecycle concepts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-IDENTITY-NOT-AUTHORITY

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-NO-REVOCATION-REVERSAL

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-NO-REPARENTING

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-SUCCESSOR-NO-INHERITANCE

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-AUTH-CHAIN-NO-UNION

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: single-chain-selection SCS-06, chain-selection-no-union CSNU-01 to CSNU-11. Implementation: TypeScript yes, Python yes.

APS-AUTH-CHAIN-SET-NOT-A-SELECTION

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: single-chain-selection SCS-06. Implementation: TypeScript yes, Python yes.

APS-AUTH-CHAIN-REPORT-ONE-CHAIN

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-RECHECK-AT-ADMISSION

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-CACHED-DECISION-FRESHNESS

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-UNKNOWN-NOT-ACTIVE

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-SUSPENSION-NOT-REVOCATION

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-ROTATION-NOT-REVOCATION

Section: . Feature: Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-REVOCATION-NOT-ABOUT-KEY

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-EXPIRY-NOT-REVOCATION

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-NO-RESURRECTION

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-COMPLETENESS-BASIS

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: lifecycle-infrastructure-failure LC-F-016-b, LC-F-026-a, LC-F-027-a, LC-F-027-b, LC-F-029-a. Implementation: TypeScript no, Python no.

APS-LC-ACTIVATION-SOURCE-DECLARED

Section: . Feature: Activation conditions. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-ACTIVATION-EVIDENCE-ORDER

Section: . Feature: Activation conditions. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-ACTIVATION-NOT-INVALID

Section: . Feature: Activation conditions. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-BOUND-KINDS-DISTINCT

Section: . Feature: Purpose bounds and exhaustion. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-PURPOSE-MEMBERSHIP-NOT-EXHAUSTION

Section: . Feature: Purpose bounds and exhaustion. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED

Section: . Feature: Purpose bounds and exhaustion. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-EXHAUSTION-IRREVERSIBLE

Section: . Feature: Purpose bounds and exhaustion. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-REFERENT-CONTINUITY-PINNED

Section: . Feature: Capability and policy binding. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-PINNED-MISMATCH-DENIES

Section: . Feature: Capability and policy binding. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-POLICY-VERSION-IDENTIFIED

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-POLICY-TIGHTENING-RESTRICTS

Section: . Feature: Capability and policy binding. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-EPOCH-FEATURE-DEFINITION

Section: . Feature: Authority epoch. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-EPOCH-NO-REGRESSION

Section: . Feature: Authority epoch. Positive vectors: none. Negative vectors: authority-epoch-rollback AER-01 to AER-12, for rejection of stale authority. Implementation: TypeScript yes, Python yes.

APS-LC-EPOCH-SCOPE-DECLARED

Section: . Feature: Authority epoch. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-WITHDRAWAL-NOT-REMOVAL

Section: . Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-CAUSE-SET-NOT-FLAG

Section: . Feature: Suspension cause sets. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-RELEASE-PER-CAUSE

Section: . Feature: Suspension cause sets. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-RELEASE-STANDING-EXTERNAL

Section: . Feature: Suspension cause sets. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-CHAIN-RESULT-PRECEDES-PAUSE

Section: . Feature: Suspension cause sets. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-STATUS-SOURCE-ACCEPTED

Section: . Feature: Status sources. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-FRESHNESS-PER-SOURCE

Section: . Feature: Status sources. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-STATUS-CONFLICT-NO-ADMIT

Section: . Feature: Status sources. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-COVERAGE-AS-STATED

Section: . Feature: Status sources. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-OFFLINE-DECLARED-IN-ADVANCE

Section: . Feature: Status sources. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-SUCCESSION-NEW-GRANT

Section: . Feature: Succession and handover. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-LC-BINDING-MODE-NO-DEFAULT

Section: . Feature: Succession and handover. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-LC-VACANCY-NOT-ESTABLISHED

Section: . Feature: Succession and handover. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PRIN-TWO-FINDINGS

Section: . Feature: Principals and departure. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PRIN-ROLE-NOT-FROM-BODY

Section: . Feature: Principals and departure. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PRIN-SILENCE-NOT-CONSENT

Section: . Feature: Principals and departure. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-PRIN-ACCOUNTABILITY-SEPARATE

Section: . Feature: Principals and departure. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-EVID-RELATIONS-NOT-TRANSITIVE

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-REC-DECISION-REF-RECOMPUTED

Section: . Feature: Core, restated. Positive vectors: receipt-decision-relation pass, temporal-equal, temporal-earlier. Negative vectors: receipt-decision-relation substitution and the three flipped counterparts. Implementation: TypeScript yes, Python yes.

APS-REC-DECISION-BINDING-BEFORE-READ

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-ENF-EXACT-ACTION-MATCH

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-COVERAGE-PREMISE-SCOPED

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-EVID-EFFECT-NOT-FROM-RESULT

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-EVID-READBACK-OUTCOMES

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-EVID-MISSING-NAMED

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-EVID-STATES-NOT-SYNONYMS

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-RETRY-NEW-DECISION

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-COMPENSATION-NEW-RECORD

Section: . Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-RESERVE-AT-APPROVAL

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-COMPLETE-AT-ADMISSION

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-SETTLE-AFTER-RESULT

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-RELEASE-PRE-DISPATCH-ONLY

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ENF-CONFLICTING-REUSE-REJECTED

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ADAPT-NO-WIDENING

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ADAPT-NO-SILENT-SEMANTIC-LOSS

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ADAPT-RECOMPUTE-ACTION-REF

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.

APS-ADAPT-STAGE-COMMITMENT

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: k8s-receipt-admission-stage-negatives cand1 to cand5. Implementation: TypeScript no, Python no.

APS-ADAPT-CANONICALIZATION-STATED

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ADAPT-MCP-EXTENSION-DECLARED

Section: . Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-ADAPT-NO-INVENTED-SPEND-BASIS

Section: . Feature: Core, restated. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python no.

APS-CONF-CLASS-NAMED

Section: . Feature: Core, document requirement. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-CONF-CLAIM-CONTENT

Section: . Feature: Core, document requirement. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-CONF-CLAIM-NOT-VERDICT

Section: . Feature: Core, document requirement. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-CONF-THREE-RESULTS

Section: . Feature: Conformance reporting. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

APS-CONF-NOT-SUPPORTED-NOT-SCORE

Section: . Feature: Conformance reporting. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.

What this list does not establish. It does not establish that any implementation ran any vector, that an exercised requirement is correctly implemented anywhere, or that the requirements listed are every obligation this document places on an implementation. An obligation stated across two sentences, or stated without a BCP 14 keyword, carries no identifier and does not appear here.

Map From the Suite Requirement Identifiers The rows below are every requirement the inventory records against a named fixture. The 43 requirements the inventory records as not exercised with no fixture at all are not reproduced here and are listed in the inventory itself. Requirement coverage, corpus inventory rows with a fixture

REQ id	Sec	Family	Vec	Impl	Result
REQ-2.2-1	2.2	cross-stack/receipts-amdal	6	PY	partial
REQ-2.2-4	2.2	cross-stack/receipts-amdal	6	PY	partial
REQ-2.4-2	2.4	cross-stack/oracle-safety-check	13	TS, PKG	partial
REQ-2.5-4	2.5	cross-stack/oracle-safety-check	13	TS, PKG	partial
REQ-2.6-1	2.6	instruction-provenance	10	TS	partial
REQ-3.2-1	3.2	cross-stack/oracle-safety-check	13	none	not exercised
REQ-3.2-2	3.2	cross-stack/oracle-safety-check	13	TS	exercised
REQ-3.2-3	3.2	cross-stack/oracle-safety-check	13	TS	partial
REQ-3.2-4	3.2	cross-stack/oracle-safety-check	13	TS	exercised
REQ-3.2-5	3.2	cross-stack/oracle-safety-check	13	TS	partial
REQ-3.2-7	3.2	cross-stack/oracle-safety-check	13	TS	exercised
REQ-3.2-8	3.2	cross-stack/oracle-safety-check	13	TS	partial
REQ-3.2-9	3.2	cross-stack/oracle-safety-check	13	TS	exercised
REQ-3.3-1	3.3	cross-stack/oracle-safety-check	13	TS	partial
REQ-3.5-1	3.5	cross-stack/oracle-safety-check	13	TS	partial
REQ-3.5-2	3.5	interop/aae-envelope	4	TS	partial
REQ-4-1	4	cross-stack/oracle-safety-check	13	none	not exercised
REQ-4-2	4	cross-stack/oracle-safety-check	13	none	partial
REQ-4.1-1	4.1	actionref-canonical	6	none	not exercised
REQ-4.1-2	4.1	actionref-canonical	6	none	not exercised
REQ-4.1-3	4.1	actionref-canonical	6	TS	partial
REQ-4.1-7	4.1	cross-stack/action-ref-v1-negatives	14	NODE	partial
REQ-4.1-8	4.1	cross-stack/action-ref-v1-negatives	14	NODE	partial
REQ-4.2-1	4.2	cross-stack/argentum-action-ref-v1v2	10	PY	exercised
REQ-5.1-1	5.1	cross-stack/receipts-aeoess	2	PY, PKG	partial
REQ-5.1-2	5.1	cross-stack/receipts-aeoess, cross-stack/oracle-safety-check	2, 13	PY, TS	partial
REQ-5.1-3	5.1	cross-stack/receipts-aeoess	2	PY, PKG	partial
REQ-5.2-1	5.2	cross-stack/receipts-aeoess	2	PY	partial
REQ-5.3.1-1	5.3.1	cross-stack/receipts-aeoess	2	none	partial
REQ-5.3.2-3	5.3.2	cross-stack/oracle-safety-check	13	none	not exercised
REQ-5.4-1	5.4	receipt-decision-relation	7	TS	partial
REQ-5.4-2	5.4	receipt-decision-relation	7	none	not exercised
REQ-5.5-1	5.5	cross-stack/oracle-safety-check	13	TS	partial
REQ-5.6-1	5.6	cross-stack/oracle-safety-check	13	TS	partial
REQ-7.3-3	7.3	cross-stack/token-exchange-attenuation-v0	12	TS	partial
REQ-9-3	9	cross-stack/aat-amdal	5	PY	partial
REQ-9-4	9	cross-stack/action-ref-v1-negatives	14	NODE	partial
REQ-9-6	9	interop/scitt-cose-vectors-ietf126	not run	TS	partial
REQ-9-7	9	composition/a2a-1496-negative-paths	4	TS	partial

Reading the table. A vector count is the count for the file the inventory row names, not for every file in the family. Where a family carries dated files, the count is for the file cited. The oracle-safety-check rows share one 13-vector set and differ in which mutation of it the row reaches, so the counts do not add across rows. The scitt-cose row records a verifier that exists but needs an external test-vector checkout that is not in the tree, and the corpus records that run as skipped. What this table does not establish. It does not establish that an exercised row means the requirement is correctly implemented anywhere, that a partial row is close to exercised, or that the ratio of the three results measures anything. It does not carry the 43 requirements with no fixture, so it is not a coverage summary.

Families Named in Status Blocks The families below are named in the status blocks of and . Five of them are named in as the vectors that exercise a requirement of this revision: accountability-record, authority-epoch-rollback, chain-selection-no-union, receipt-decision-relation and single-chain-selection. The rest carry no requirement identifier, because the inventory at covers the -03 text and these families were written against text proposed after it. Fixture families named in status blocks of the profile and conformance sections

Family	Vec	Counted from	Declared status
activation-not-established	19	cases	candidate_against_proposed
accountability-record	12	vectors	not declared in the vectors file
action-result-binding	6	cases	not declared in the vectors file
ancestor-revocation-chain	4	cases	not declared in the vectors file
approval-single-use	9	presentations	not declared in the vectors file
arap-binding	27	denial_binding_cases 12, approval_cases 10, pep_fallback_cases 5	candidate
authority-epoch-rollback	12	cases	candidate
cached-authorization-revocation	9	cases	candidate
capability-binding-drift	8	presentations	candidate_against_proposed
chain-selection-no-union	11	cases	candidate_against_proposed
conflicting-status-sources	14	cases	candidate_against_proposed
instruction-provenance	10	vectors	not declared in the fixture file
issuance-refusal-expiry	8	part_a_issuance 5, part_b_verification 3	not declared in the vectors file
key-rotation-historical	5	cases	not declared in the vectors file
lifecycle-conferral-without-authority	10	vectors	not declared in the vectors file
lifecycle-credential-events	42	cases	candidate_against_proposed
lifecycle-identifier-reuse-and-rename	13	presentations	candidate_against_proposed
lifecycle-legal-regulatory-events	44	vectors	not declared in the vectors file
lifecycle-multiple-principals-and-conflict	92	vectors	candidate_against_proposed
lifecycle-outside-the-chain-standing	22	vectors	candidate_against_proposed
lifecycle-principal-events	32	cases	candidate_against_proposed
merkle-root-parity	6	vectors	not declared in the vectors file
read-fidelity-receipt	8	vectors	not declared in the fixture file
receipt-decision-relation	7	one file per vector	not declared in a vectors file
revocation-resolution-forward-compat	14	cases	not declared in the vectors file
runtime-authority-denial-continuity	9	cases	not declared in the vectors file
single-chain-selection	6	cases	not declared in the vectors file
suspension-cause-composition	16	cases	candidate_against_proposed

The cross-stack group named in the protocol adapter class is not one family. At the pinned commit it holds nine external-system families and two lab-authored regression families, each admitted under its own evidence document and each declaring its own verification split. They are not counted as a single number here for the same reason the corpus refuses a suite-wide support number. Counted from. The Counted from column names the key in the family's vectors file that the count was taken from. The key differs by family because the unit differs, which is the same reason gives for refusing a total. A count in this table is a count of entries under one named key and is not comparable across rows. Declared status. The value is read from the family's vectors file, from its status member or its label member. Where a file carries both and they differ in spelling, the longer spelling is recorded, which is the reading the corpus itself states for the two families that do this. Not declared in the vectors file means the file carries neither member. That does not mean the family has no status, and several state one in the README only. Every family in this table is run by the repository's own test entry point at the pinned commit, which is a fact about the package manifest at that commit rather than an observation of a run. What this table does not establish. It does not establish that any family passed, that the families listed are a complete set for this document, or that vector counts measure the strength of a family. A family with 92 vectors is not four times the family with 22.