Agent Passport System (APS): Verifiable Authority, Lifecycle, Enforcement, and Evidence for AI Agents

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. 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 (Section 3.3).¶

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 (Section 4.3). 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 (Section 3.1) and named as subject_agent on the records of a governed action (Section 7.1).¶

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 (Section 4.1).¶

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 (Section 5). It may be a separate component from the enforcement boundary.¶

Enforcement boundary

The component that issues the policy-decision record (Section 7.3.2) and the action-result record (Section 7.3.3), consumes the approval at the next authorization boundary, applies the state current at that moment, and completes any spend reservation (Section 5.3). 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 Section 19.2.11 records what that leaves open.¶

Target system

The system the action operates on. It appears in the action input object hashed into action_ref (Section 5.1). 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 (Section 3.5), and what resolution reports is its own axis (Section 7.5).¶

Verifier

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

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.¶

2.2. 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 (Section 4.1) and a principal binding scoped to named audiences and authority profiles (Section 3.3). 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 (Section 7.2). 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 (Section 3.5). 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 (Section 7.3.2). 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 (Section 5.3). 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 (Section 7.6).¶

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 Section 9 and Section 19.2.11. 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 (Section 7.3.3). 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 (Section 7.3.3). 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 (Section 5.2).¶

Evidence of a claim is not its truth. An evidence reference is a commitment, not evidence availability (Section 7.5). 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.¶

2.3. 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 Section 8.3.1 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 Section 4.3, 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 Section 4.3, 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 Section 8.1, Section 8.3.3 and Section 8.2.12. 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.¶

2.4. 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 (Section 7.2). 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 (Section 5.2). 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 Section 7.5 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 (Section 3.5). 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 Section 7.5, 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.¶

2.5. 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.¶

2.6. 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 Section 19 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.¶

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 Section 3.3 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. Section 19.2.10 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 Section 8.3.1, 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. Section 4.5 establishes the transition and Section 4.5.2 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 Section 9.9, 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 Section 3.4, and a party with standing revokes the records that depended on the compromised key. Neither step reaches artifacts already signed under that key, and Section 15 states that a model needing that reach has no rule here. Section 8.2.9 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. Section 5.3 and Section 7.3.2 state those consumption semantics. No durable record of this transition exists in this revision, which is open at Section 19.2.11, 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.¶

3.1. 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 Section 3.3.¶

The public key is a multibase base58btc encoding of the multicodec Ed25519 [RFC8032] 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 [RFC8785] over validated I-JSON, UTF8 converts the resulting string to bytes, and || denotes byte concatenation:¶

passport_id = lowercase-hex(SHA-256(
    ASCII("APS-PASSPORT-ID-V2") || 0x00 ||
    UTF8(JCS(passport without passport_id and signature))))

signature = Ed25519-Sign(agent_private_key,
    ASCII("APS-PASSPORT-SIG-V2") || 0x00 ||
    UTF8(JCS(passport without signature)))

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.¶

3.2. Agent Identifiers

APS is DID-method-agnostic. agent_id and verification_method use the syntax and resolution rules of the selected DID method [DID-CORE]. New self-certifying passports SHOULD use an existing generative DID method whose identifier commits to the signing key, such as did:key [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.¶

3.3. 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.¶

3.4. 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 Section 3.5.¶

A verifier MUST report that indeterminate result through the ambiguous resolution outcome of Section 3.5, 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.¶

3.5. Key Resolution for External and Evidence Signers

Section 3.1, Section 3.2 and Section 3.4 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 Section 7.5.¶

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 Section 3.4, in which the artifact's signing time relative to a key-validity boundary cannot be established from acceptable evidence, is reported as ambiguous.¶

3.6. 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.¶

4.1. 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.¶

{
  "record_type": "aps:authority-delegation:v1",
  "version": "1.0",
  "delegation_id": "sha256:<64-lowercase-hex>",
  "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 Section 5 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:¶

delegation_id = "sha256:" || lowercase-hex(SHA-256(
    ASCII("APS-AUTHORITY-DELEGATION-ID-V1") || 0x00 ||
    UTF8(JCS(delegation without delegation_id and signature))))

signature = Ed25519-Sign(issuer_private_key,
    ASCII("APS-AUTHORITY-DELEGATION-SIGNATURE-V1") || 0x00 ||
    UTF8(JCS(delegation without signature)))

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.¶

4.2. 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 [APS-NARROWING] and [APS-FACETED].¶

4.3. 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 Section 4.2; 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 [RFC3339], 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.¶

4.4. 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. Section 5 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.¶

4.5. 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. Section 5.3, Section 7.3.2 and Section 7.3.3 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 Section 4.3. 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 Section 4.3.¶

A revoking party MAY additionally produce the cascade evidence described in Section 4.5.1. 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 Section 4.3. The evidence cascade state for a revocation is complete, incomplete, or indeterminate, as specified in Section 4.5.1. An evidence cascade state MUST NOT be reported as an authority result.¶

  {
    "record_type": "aps:authority-revocation:v1",
    "version": "1.0",
    "revocation_id": "sha256:<64-lowercase-hex>",
    "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>"
  }

  cascade_transaction_id = "sha256:" || lowercase-hex(SHA-256(
      ASCII("APS-AUTHORITY-REVOCATION-CASCADE-TRANSACTION-ID-V1")
      || 0x00 ||
      UTF8(JCS(revocation without revocation_id, signature and
               cascade_transaction_id))))

  revocation_id = "sha256:" || lowercase-hex(SHA-256(
      ASCII("APS-AUTHORITY-REVOCATION-ID-V1") || 0x00 ||
      UTF8(JCS(revocation without revocation_id and signature))))

  signature = Ed25519-Sign(revoker_private_key,
      ASCII("APS-AUTHORITY-REVOCATION-SIGNATURE-V1") || 0x00 ||
      UTF8(JCS(revocation without signature)))

4.6. 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 Section 4.5, and is not an input to the authority result. It is verifiable only from a completion record whose basis Section 4.5.1 leaves undefined. The signed receipt layer in Section 7 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 Section 18.¶

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 (Section 4.3), 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.¶

5.1. 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:¶

{
  "profile": "aps-action-ref-v2",
  "agent_id": "did:key:z6Mk...",
  "action_type": "commerce_preflight",
  "target": "https://api.example/payments",
  "payload_ref": "<64 lowercase hexadecimal characters>",
  "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 [UAX15] strings sorted by the lexicographic order of their UTF-8 encodings. issued_at is an RFC 3339 [RFC3339] 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 Section 4.2. 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:¶

payload_ref = lowercase-hex(
    SHA-256("APS-ACTION-PAYLOAD-V1" || 0x00 || JCS(payload)))

action_ref = lowercase-hex(
    SHA-256("APS-ACTION-REF-V2" || 0x00 || JCS(input_object)))

JCS is RFC 8785 [RFC8785] and SHA-256 is defined in [RFC6234]. 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.¶

5.2. 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":¶

external_action_ref =
    lowercase-hex(SHA-256(canonicalize(input_object)))

where canonicalize is RFC 8785 [RFC8785], 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 Section 5.1. 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 Section 5.1 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.¶

5.3. Two-Phase Execution

Section 4.5 requires revocation to be rechecked at the moment the approval is consumed to admit dispatch, and the action-result record of Section 7.3.3 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 Section 7.3.2 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 Section 4.5. 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 (Section 5) 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.¶

6.1. 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 Section 6, 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 [RFC8785] 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 Section 7.4 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 Section 11.4 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.¶

6.2. 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 Section 4.1 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 (Section 7.6) 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.¶

7.1. 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:¶

{
  "profile": "aps-receipt-v1",
  "receipt_id": "<64 lowercase hexadecimal characters>",
  "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 Section 7.3. issuer is the party responsible for that record. subject_agent is the acting agent. action_ref is the aps-action-ref-v2 digest from Section 5.1. 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.¶

7.2. Receipt Identifiers and Signatures

The receipt identifier is computed over the validated envelope with receipt_id and signatures absent:¶

receipt_id = lowercase-hex(SHA-256(
    ASCII("APS-RECEIPT-ID-V1") || 0x00 ||
    UTF8(JCS(receipt without receipt_id and signatures))))

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:¶

signature_form = {
  "receipt": receipt without signatures,
  "signer": {
    "signer": signer,
    "key_id": key_id,
    "alg": "Ed25519"
  }
}

value = lowercase-hex(Ed25519-Sign(signing_key,
    ASCII("APS-RECEIPT-SIG-V1") || 0x00 ||
    UTF8(JCS(signature_form))))

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.¶

7.3. 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 Section 4.6 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.¶

{
  "profile": "aps-core-decision-output-v1",
  "verdict": "permit",
  "effective_authority_ref":
      "<64 lowercase hexadecimal characters>",
  "constraints": [],
  "valid_until": "2026-04-08T12:00:05.000Z"
}

{
  "profile": "aps-action-result-v1",
  "status": "succeeded",
  "effect_ref": "<64 lowercase hexadecimal characters>",
  "error_code": null
}

7.4. 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:¶

authority_state_ref = H("APS-DECISION-AUTHORITY-V1",
                        authority_state)
policy_ref          = H("APS-DECISION-POLICY-V1",
                        policy_input)
context_ref         = H("APS-DECISION-CONTEXT-V1",
                        decision_context)
decision_output_ref = H("APS-DECISION-OUTPUT-V1",
                        decision_output)

where H(tag, value) =
    lowercase-hex(SHA-256(ASCII(tag) || 0x00 || UTF8(JCS(value))))

The DecisionRefV1 input is a closed object:¶

{
  "profile": "aps-decision-ref-v1",
  "action_ref": "<64 lowercase hexadecimal characters>",
  "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>"
}

decision_ref = lowercase-hex(SHA-256(
    ASCII("APS-DECISION-REF-V1") || 0x00 ||
    UTF8(JCS(decision_ref_input))))

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.¶

7.5. 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.¶

7.6. 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 Section 7.3.2, using the construction of Section 7.4¶
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 Section 7.1 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 Section 5.1 and the record's subject_agent of Section 7.1 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 Section 7.3. 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.¶

8.1. 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 Section 8.3.5, because Section 4.5 names only the issuer for a direct revocation. Direct revocation by a party other than the issuer is open at Section 19.2.15.¶

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 Section 8.3.1.¶

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 Section 8.3.3.¶

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 Section 8.3.4.¶

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 Section 7.3.¶

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 Section 4.3 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 Section 2.3 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 Section 4.3 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 Section 4.1 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.¶

8.2. 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 Section 4.6 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.¶

8.3. 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.¶

8.4. 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 Section 19 with the behavior this document requires until the question is settled. The two are the conferral rule, at Section 19.2.13, and the effectiveness-rule default, at Section 19.2.14.¶

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.¶

9.1. 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 Section 7.6 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 Section 7.4 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 [COSAI-149], 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 Section 7.3.3 states with a keyword and Section 7.6 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 Section 7.3.3 and Section 7.6 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.¶

9.2. The Exact Call

An approval admits one action. The permit or narrow record of Section 7.3 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.¶

9.3. 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 Section 9.1 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.¶

9.4. Effect Verification

An action-result record attests what the enforcement boundary observed after dispatch, as Section 7.3 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.¶

9.5. When the Evidence Is Not Enough

A finding about any of the relations of Section 9.1 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.¶

9.6. 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 Section 7.3 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 Section 9.4 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 Section 7.3 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.¶

9.7. 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 Section 7.3 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.¶

9.8. 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: Section 5.3 places the reservation against the boundary-held cumulative total at the moment the approval is issued, and Section 5 requires the reservation to succeed against every bounded ancestor in the selected chain before dispatch. Complete at admission: Section 7.3.2 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: Section 4.4 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 Section 4.4 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 Section 7.3.2, 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 Section 5.1 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. Section 19.2.12 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. Appendix D 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 Section 4.4 requires for live spend status to be determinate at all.¶

9.9. 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 Section 4.6 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.¶

9.10. 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.¶

9.11. 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 Appendix C 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 Section 4.1 and of the receipt envelope and stages in Section 7.1 and Section 7.3. Verdict and outcome names are those of Section 2.3, and the lifecycle states are those of Section 8. Reason codes are the module strings the reference implementations carry.¶

10.1. 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 Section 19.2.10. 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.¶

10.2. Monotonic Projection

An institutional layer reaches the delegation layer by projecting its authority into the faceted authority vector of Section 4.1 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 Section 4.6, and no released package projects an institutional instrument into the authority vector.¶

10.3. 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.¶

10.4. 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.¶

10.5. 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 Section 8.3.5. Section 4.5 names only the issuer for a direct revocation, and direct revocation by a party other than the issuer is open at Section 19.2.15.¶

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.¶

10.6. 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 Section 4.3 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.¶

10.7. 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.¶

11.1. MCP Binding

APS specifies a binding to MCP [MCP]. For this binding, an enforcement gateway mediates the privileged actions selected by deployment policy. A privileged action is any action the policy chain (Section 5) is configured to evaluate, including any action whose required scope is non-empty under the Scope rules of Section 4.2. 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 Section 15 describes, not an unconditional property of the binding.¶

11.2. Other Bindings

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

11.3. 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 [OAUTH-ID-JAG], 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.¶

11.4. 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 Section 6.1 requires.¶

11.5. 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 [RFC8785] 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.¶

11.6. 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 Section 11.4.2.¶

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:¶

      {"jsonrpc":"2.0","id":2,"method":"tools/call","params":\
      {"name":"echo","arguments":{"x":1},"_meta":{"probe":1}}}

what the external processor received as the call under check:¶

      {"name":"echo","arguments":{"x":1}}

and what the upstream server received on its own input:¶

      {"jsonrpc":"2.0","id":2,"method":"tools/call","params":\
      {"_meta":{"probe":1},"name":"echo","arguments":{"x":1}}}

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 Section 11.4.1 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.¶

12.1. 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 Section 7.3.2 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 [AUTHZEN] 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.¶

12.2. 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 [WIMSE-XORG] 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 Section 7.3.2 and Section 5.3: 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 Section 9.8 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.¶

12.3. 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 Section 7.1, 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 (Section 2.2, Section 19.2.11). Section 7.3.2 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.¶

12.4. 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 Section 4.6.¶

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.¶

12.5. 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.¶

13.1. 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 Appendix D.¶

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 Section 6.1 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 Section 13.2 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.¶

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 Appendix D.¶

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 Section 6.1, 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.¶

13.2. 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 Appendix D 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 Section 13.1, and a claim cites an identifier in the class it applies to.¶

Appendix D 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 Appendix D.2 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.¶

13.3. 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 Section 15 and Section 16 are closed-core carryover. They keep the force they had in -03, they carry no status block and no requirement identifier, and Appendix D 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 Section 13.1. 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 Section 13.4 states what else a claim carries. Lifecycle Core is an informative grouping name and not a claimable base. It names the propositions in Section 8 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. Section 8 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 Section 4.5.2, the evidence model of Section 2.3 and Section 2.4, the profile model of Section 6, 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 Section 8.3 named as its own feature, the decision-to-effect model of Section 9, the adapter contracts of Section 11.4, and the per-vector result vocabulary of Section 13.5. A claim that names no feature is a claim of APS Core alone.¶

The claim rules of Section 13.1 and Section 13.4 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 Section 6.1 states for a profile, so no runtime vector reaches them and Appendix D 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.¶

13.4. 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 Section 6.1, 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 Section 13.1 claimed, and no others.¶

Requirements.

The requirement identifiers claimed, each under the semantic scheme of Section 13.2. 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 Section 13.5, 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.¶

13.5. 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.¶

13.6. 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.¶

14.1. 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¶

Two rows carry no cells. [APS-LIFECYCLE] and [APS-CONFORMANCE] are maintained by this document's author, the prose above states what they are, and this table records external documents.¶

[MCP-SEP-2828] carries no cells. Its author withdrew it and continued the work as [VAARA-RECEIPT], 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.¶

15.1. 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 Section 9.3 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 Section 9.7 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.¶

19.1. 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 Section 7.6 keeps external truth on its own axis and why Section 9.4 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. Section 2.5 states it and Section 9.3 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.¶

19.2. 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 [APS-LIFECYCLE]. Three are transitions in Section 2.6 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 Section 8.1 and the issuer-only revocation of Section 4.5.¶

Each item names the cases in Appendix C 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.¶

A.1. Implemented and Exercised

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

• The passport of Section 3.1 and the principal binding of Section 3.3, 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 Section 3.5, including the ambiguous outcome for a duplicated key identifier.¶
• AuthorityDelegationV1 of Section 4.1 with all seven facets inside the signed content, and the component orders of Section 4.2.¶
• Phase-major chain verification of Section 4.3, 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 Section 4.5.2. 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 Appendix D 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 Section 8 whose module both packages ship as stable rather than experimental.¶
• The action_ref of Section 5.1 and the external correlation form of Section 5.2, exercised across the TypeScript, Python and Go implementations with shared known-answer vectors.¶
• The ReceiptV1 envelope of Section 7.1, the identifier and signature constructions of Section 7.2, and the three stages of Section 7.3. Both packages accept the expected enforcement-boundary identity as a verifier trust input and perform the Section 7.6 step 4 comparison against the receipt issuer.¶
• The decision_ref of Section 7.4 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 [RFC8785] 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.¶

A.2. 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 Appendix D, 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 Section 5.3. 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 Section 4.4 and Section 5 is absent.¶
• The not_attempted value of Section 7.5. 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 Section 3.5. 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 Section 4.5.1. Neither is issued nor verified by any released package, and Section 4.5.2 defines neither.¶
• The mediation-assumption rule of Section 2.5. No released package checks that a governed path was the only path.¶
• Every requirement of Section 9 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 Section 6. 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 Section 11.4, beyond the action-reference recomputation both packages already perform.¶
• The conformance reporting of Section 13. No released package emits a per-vector result record, and no machine-readable claim format is defined.¶
• Inside Section 8: the cached-decision limits of Section 8.3.6, the policy-version limb of Section 8.3.3, the binding mode, office-holder records, vacancy records, co-holder decision rules and pre-commitment of Section 8.3.7, and the principal-event records, confirmation procedures, renunciation and accountability findings of Section 8.3.8. The identifier custodian records of Section 8.3.3 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. Appendix D 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.¶

A.3. 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 Section 8 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 Section 8.3.4 turns the open design choices into obligations on an implementation that claims the feature.¶
• The reason_code value space of Section 4.5.1 and Section 4.5.2, on which neither section imposes a grammar, and the verification_method field, which Section 4.5.1 does not name. The releases constrain neither.¶
• The target string construction Section 5.1 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.¶

A.4. 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. Section 4.3 rejects the second value 60 wherever it appears. The passport and principal-binding surface rejects it. The revocation record surface of Section 4.5.2 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. Section 8.3.3 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 Section 4.5.2 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.¶

B.1. New Sections

• Section 2, 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.¶
• Section 4.5.2 is new. It specifies one wire format for the revocation record that Section 4.5.1 has required since -03 without defining. It is a Candidate feature, not a change to the SHOULD above it.¶
• Section 6, 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.¶
• Section 8, 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.¶
• Section 9, 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.¶
• Section 10 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.¶
• Section 12, 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.¶
• Section 13, Conformance, is new. It defines seven conformance classes, the form of a claim, and the three results an implementation reports per vector.¶
• Section 19, 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.¶
• Section 11.4, Section 11.5 and Section 11.6 are new subsections of Protocol Bindings. Section 14.1 is a new subsection of Related Work.¶
• Appendix C and Appendix D 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.¶

B.2. Changes Carried From -03

• Result model. Section 7.3 makes the expected enforcement-boundary identity a trust input the verifier supplies. Section 7.6 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. Section 7.6 now states that an axis a verifier did not establish never contributes to a valid result, and Section 7.5 now states that omitting the evidence-resolution axis is not a permitted verifier scope while declining to resolve evidence is.¶
• Root trust. Section 4.3 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 Section 4.3 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 Section 4.5.2, 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. Section 9.8 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 Section 3.5 carry stable names. The resolved outcome carries no failure name, and this document defines no further key-resolution outcome. Section 4.3 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 Section 7.3.2 identifies the consumable approval.¶
• Historical key selection. Section 3.4 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. Section 7.6 step 10 reports an approval-state axis, not established where the verifier holds no consumption state.¶
• Unit equality. Section 5 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. Section 4.5.1 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. Section 4.6 now states that INV-4 is reported as the evidence cascade state of Section 4.5 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. Section 4.5.2 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.¶

B.3. 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 Appendix D. 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.¶

C.1. 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 Section 19.2.13 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 Section 19.2.2.¶

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 Section 19.2.10 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 Appendix D and nowhere else.¶

C.2. 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 Section 9.11. 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 (https://www.gao.gov/products/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 Section 8.3.7, 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 (https://www.govexec.com/management/2020/08/top-two-homeland-security-officials-are-serving-illegally-gao-rules/167714/): "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 Section 2.3. The finding reaches the chain from the moment a verifier establishes it. What becomes of effects already taken is a different question, open at Section 19.2.2.¶

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 (https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html): "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. Section 8.3.6 makes freshness and coverage properties of the source rather than of the authority, and Section 4.3 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 (https://home.army.mil/carson/6116/5089/9699/relief-for-cause.pdf): "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, Section 19.2.3.¶

Disposition in this document. A pending ratification is a suspension cause under Section 8.3.5. 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 (https://staff.washington.edu/djdrake/RESt-Agency.doc): "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 (https://gc.nh.gov/rsa/html/LVI/564-E/564-E-110.htm): 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 Section 8.4.1 and Section 8.3.8. 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 (https://www.law.cornell.edu/ucc/4A/4A-211): "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 Section 19.2.2: 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, Section 19.2.2.¶

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 Section 19.2.2, 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 (https://www.sec.gov/Archives/edgar/data/1397516/000119312507093837/dex105.htm): "...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 Section 2.3. 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 (https://www.law.cornell.edu/uscode/text/12/1821): "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 Section 8.4.1 and Section 8.3.8. The appointment reaches no verifier by itself. Replacement authority is a new grant from a party that currently holds the authority granted, under Section 8.3.7.¶

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 (https://www.sos.ms.gov/content/documents/pol_res/power%20of%20attorney/5upoaa_final_may08.pdf): "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 Section 8.3.7 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 (https://aws.amazon.com/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 Section 19.1 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 (https://thehackernews.com/2025/05/coinbase-agents-bribed-data-of-1-users.html): "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 Section 8.2.5. 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 Section 19.2.13 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 Section 19.2.13, 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 Section 8.3.7. 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 Section 8.3.7 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 Section 8.3.5. 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 Section 8.3.5 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 Section 9.10, 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. Section 9.10, 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 Section 8.2.6, and CAND-12 at Section 8.4.7. 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 Section 19.2.2.¶

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 Section 19.2.2.¶

C.3. 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 [APS-LIFECYCLE] 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 Section 9.7 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.¶

D.1. 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 Appendix A. No run backs any of them except the authority-revocation-record run recorded under Section 4.5.2. 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: Section 2.3. 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: Section 2.3. Feature: Evidence model. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-EVID-NOT-ESTABLISHED

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

APS-EVID-NO-RETROACTIVE-REWRITE

Section: Section 2.4. 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: Section 2.4. 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: Section 2.5. 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: Section 4.5.2. 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: Section 4.5.2. 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: Section 4.5.2. 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: Section 4.5.2. 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: Section 4.5.2. Feature: Revocation record format. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-PROF-REQUIRED-CONTENT

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

APS-PROF-SEMANTIC-PRESERVATION

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

APS-PROF-NO-WIDENING

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

APS-PROF-UNKNOWN-NOT-VALID

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

APS-LC-STANDING-NOT-FROM-RECORD

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

APS-LC-STANDING-THREE-VALUED

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

APS-LC-ISSUER-VS-LIFECYCLE-STANDING

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

APS-LC-VERDICT-ENUMERATIONS-DISTINCT

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

APS-LC-NOT-ESTABLISHED-LIMB

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

APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS

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

APS-LC-IDENTITY-NOT-AUTHORITY

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

APS-LC-NO-REVOCATION-REVERSAL

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

APS-LC-NO-REPARENTING

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

APS-LC-SUCCESSOR-NO-INHERITANCE

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

APS-AUTH-CHAIN-NO-UNION

Section: Section 8.2.5. 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: Section 8.2.5. 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: Section 8.2.5. Feature: Continuity rules outside Lifecycle Core. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-LC-RECHECK-AT-ADMISSION

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

APS-LC-CACHED-DECISION-FRESHNESS

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

APS-LC-UNKNOWN-NOT-ACTIVE

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

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

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

APS-LC-SUSPENSION-NOT-REVOCATION

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

APS-LC-ROTATION-NOT-REVOCATION

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

APS-LC-REVOCATION-NOT-ABOUT-KEY

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

APS-LC-EXPIRY-NOT-REVOCATION

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

APS-LC-NO-RESURRECTION

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

APS-LC-COMPLETENESS-BASIS

Section: Section 8.2.12. 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: Section 8.3.1. Feature: Activation conditions. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-LC-ACTIVATION-EVIDENCE-ORDER

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

APS-LC-ACTIVATION-NOT-INVALID

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

APS-LC-BOUND-KINDS-DISTINCT

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

APS-LC-PURPOSE-MEMBERSHIP-NOT-EXHAUSTION

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

APS-LC-FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED

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

APS-LC-EXHAUSTION-IRREVERSIBLE

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

APS-LC-REFERENT-CONTINUITY-PINNED

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

APS-LC-PINNED-MISMATCH-DENIES

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

APS-LC-POLICY-VERSION-IDENTIFIED

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

APS-LC-POLICY-TIGHTENING-RESTRICTS

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

APS-LC-EPOCH-FEATURE-DEFINITION

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

APS-LC-EPOCH-NO-REGRESSION

Section: Section 8.3.4. 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: Section 8.3.4. Feature: Authority epoch. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-LC-WITHDRAWAL-NOT-REMOVAL

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

APS-LC-CAUSE-SET-NOT-FLAG

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

APS-LC-RELEASE-PER-CAUSE

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

APS-LC-RELEASE-STANDING-EXTERNAL

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

APS-LC-CHAIN-RESULT-PRECEDES-PAUSE

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

APS-LC-STATUS-SOURCE-ACCEPTED

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

APS-LC-FRESHNESS-PER-SOURCE

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

APS-LC-STATUS-CONFLICT-NO-ADMIT

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

APS-LC-COVERAGE-AS-STATED

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

APS-LC-OFFLINE-DECLARED-IN-ADVANCE

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

APS-LC-SUCCESSION-NEW-GRANT

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

APS-LC-BINDING-MODE-NO-DEFAULT

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

APS-LC-VACANCY-NOT-ESTABLISHED

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

APS-PRIN-TWO-FINDINGS

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

APS-PRIN-ROLE-NOT-FROM-BODY

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

APS-PRIN-SILENCE-NOT-CONSENT

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

APS-PRIN-ACCOUNTABILITY-SEPARATE

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

APS-EVID-RELATIONS-NOT-TRANSITIVE

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

APS-REC-DECISION-REF-RECOMPUTED

Section: Section 9.1. 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: Section 9.1. Feature: Decision to effect. Positive vectors: none. Negative vectors: none. Implementation: TypeScript yes, Python yes.¶

APS-ENF-EXACT-ACTION-MATCH

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

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

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

APS-ENF-COVERAGE-PREMISE-SCOPED

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

APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION

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

APS-EVID-EFFECT-NOT-FROM-RESULT

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

APS-EVID-READBACK-OUTCOMES

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

APS-EVID-MISSING-NAMED

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

APS-EVID-STATES-NOT-SYNONYMS

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

APS-ENF-RETRY-NEW-DECISION

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

APS-ENF-COMPENSATION-NEW-RECORD

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

APS-ENF-RESERVE-AT-APPROVAL

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

APS-ENF-COMPLETE-AT-ADMISSION

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

APS-ENF-SETTLE-AFTER-RESULT

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

APS-ENF-RELEASE-PRE-DISPATCH-ONLY

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

APS-ENF-CONFLICTING-REUSE-REJECTED

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

APS-ADAPT-NO-WIDENING

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

APS-ADAPT-NO-SILENT-SEMANTIC-LOSS

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

APS-ADAPT-RECOMPUTE-ACTION-REF

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

APS-ADAPT-STAGE-COMMITMENT

Section: Section 11.4.1. 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: Section 11.4.1. Feature: Adapter contracts. Positive vectors: none. Negative vectors: none. Implementation: TypeScript no, Python no.¶

APS-ADAPT-MCP-EXTENSION-DECLARED

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

APS-ADAPT-NO-INVENTED-SPEND-BASIS

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

APS-CONF-CLASS-NAMED

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

APS-CONF-CLAIM-CONTENT

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

APS-CONF-CLAIM-NOT-VERDICT

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

APS-CONF-THREE-RESULTS

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

APS-CONF-NOT-SUPPORTED-NOT-SCORE

Section: Section 13.5. 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.¶

D.2. 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.¶

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.¶

D.3. Families Named in Status Blocks

The families below are named in the status blocks of Section 6 and Section 13. Five of them are named in Appendix D.1 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 Appendix D.2 covers the -03 text and these families were written against text proposed after it.¶