Independent Researcher

founder@phionyx.ai https://phionyx.ai

Security Internet Engineering Task Force agent control delivery evidence reconciliation Agent systems can issue stop, suspend, revoke, constrain, cancel, or override instructions across system and administrative boundaries. A record that such a control was decided or dispatched does not establish that every intended enforcement point received or applied it. Conversely, the absence of an acknowledgement does not, by itself, establish non-delivery. This document defines format-independent evidence requirements for preserving those distinctions. It separates issuer-side emission, required-target resolution, receiver-side observation, enforcement outcome, and observation of the resulting control effect. For a control that must reach more than one enforcement target, the unit of delivery reconciliation is an instruction-target obligation rather than the parent instruction alone. The document also defines bounded negative observations, total reconciliation, population conservation, semantic-preservation requirements for intermediary paths, and a separate qualification for the evidentiary strength of aggregate claims. This document does not define a receipt format, wire protocol, authorization system, policy language, transparency service, or audit regime.

Introduction Agent communication and execution systems increasingly carry control instructions that are expected to constrain a live runtime. Examples include stopping a task, suspending a delegated operation, revoking an outstanding grant, cancelling a tool request, forcing a handoff, or replacing a permissive policy with a restrictive one. These controls frequently cross more than one boundary. A policy component may decide that an activity must stop. An issuer may serialize and dispatch the corresponding instruction. A broker, gateway, sidecar, or operating-system channel may transport it. One or more enforcement points may receive and verify it. Each enforcement point may then apply, refuse, or fail to apply it. Finally, an observer may or may not see the intended control effect. Collapsing those events into a single label such as "sent", "delivered", "enforced", or "stopped" creates an interoperability and security problem. Two implementations can emit syntactically valid records while reaching incompatible conclusions about the same control. A downstream evidence or audit layer cannot reconstruct a boundary fact that was never preserved by either side of that boundary. A second collapse occurs when one control resolves to multiple required enforcement targets. Evidence that target A received the control is existential evidence for target A; it is not evidence that target B, or every target in a required set, received it. A third collapse occurs when a target set is declared closed for a reconciliation run and that declaration is silently promoted into a claim that every possible enforcement path in the deployment was enumerated. Those are different facts. A fourth collapse can occur after the originating boundary. A source can preserve a governance-relevant distinction correctly while an intermediary suppresses, transforms, or collapses it before the relying party sees it. Evidence that a state was preserved at one boundary therefore does not establish that the same semantic distinction survived intact through the path. This document therefore specifies the minimum logical facts and reconciliation behavior needed to preserve control delivery and outcome uncertainty. It also separates a structural reconciliation result from the support available for a particular attribution, completeness, or complete-mediation claim. The requirements are independent of any particular serialization, transport, signature scheme, evidence envelope, or transparency system.

Scope and Non-Goals This document applies when a governance-relevant control instruction crosses a system, process, privilege, trust, or administrative boundary on its way to one or more enforcement points. It covers:

• Binding issuer-side and receiver-side observations to the same control instruction and, where applicable, the same delivery attempt.
• Binding a control to the required target set used for a bounded reconciliation run.
• Assigning delivery dispositions per instruction-target obligation when more than one target is required.
• Distinguishing receipt, enforcement outcome, and observed control effect.
• Preserving positive failures and bounded negative observations.
• Reconciling missing, malformed, duplicated, substituted, orphaned, conflicting, and indeterminate evidence.
• Separating structural reconciliation from the evidentiary qualification of a resulting claim.
• Preserving governance-relevant outcome distinctions through intermediaries, or exposing when a transformation prevents lossless preservation from being established.
• Stating the scope and limitations of any resulting claim.

This document does not:

• Define a new receipt, token, log-entry, or evidence-envelope format.
• Define how an agent is authenticated or authorized.
• Decide whether a control instruction is correct, lawful, safe, or consistent with policy.
• Define the semantics of stop, suspend, cancel, revoke, override, or any other control verb.
• Prove the truth of producer assertions, complete mediation, or physical-world effect.
• Prove that a declared target set enumerates every possible execution or enforcement path unless an applicable profile separately establishes that fact.
• Require public disclosure of prompts, model reasoning, personal data, proprietary policy, or protected content.
• Standardize accountability, auditing, retention, or regulatory compliance.

A protocol or profile can adopt the requirements in this document while using its existing identifiers, errors, acknowledgements, signatures, telemetry, or external evidence format.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document is Informational. The requirement terms make the evidence contract testable by protocol authors and implementers; they do not define an on-wire protocol by themselves.

Terminology

Agent Runtime

A software environment that plans, mediates, dispatches, or executes actions on behalf of an agent or an agentic application.

Control Instruction

A direction intended to restrict, interrupt, replace, or otherwise govern current or future runtime behavior. Examples include stop, suspend, cancel, revoke, constrain, quarantine, handoff, and override. A control instruction is distinct from the business or tool action being governed.

Issuer

The component that emits a control instruction toward an enforcement point. The issuer need not be the policy decision point that caused the instruction to be created.

Enforcement Point

A component that can apply or refuse the control at a relevant runtime or effect path.

Control Boundary

A declared system, process, privilege, trust, or administrative boundary between an issuer-side observation and a receiver-side observation.

Observation Record

An attributable statement that a specified observer saw a specified event at a specified boundary and time. An observation record is an assertion whose integrity and trust basis require separate evaluation.

Required Target Set

For one control instruction and one declared reconciliation profile, the reproducible set of enforcement targets that are required to receive the control. A target set can be closed for a reconciliation run without proving that the set enumerates every possible enforcement path in the deployment.

Delivery Obligation

The tuple formed by a control instruction or delivery attempt and one member of its Required Target Set. It is the minimum unit to which a delivery disposition is assigned when target multiplicity exists.

Receiver Observation

An observation made at, or cryptographically bound to, a particular intended enforcement point after that point has read and matched the control instruction. Acceptance by an upstream transport intermediary is not a receiver observation unless a profile explicitly establishes equivalent endpoint semantics.

Enforcement Outcome

The enforcement point's attributable result after processing the instruction, such as APPLIED, REFUSED, NO_EFFECT, or UNKNOWN.

Control Effect

The change in governed runtime state that the control instruction was intended to cause, such as a task entering a stopped state. This term does not mean the consequential business or physical effect of the action that the agent was attempting to perform.

Negative Observation

A positive record of a bounded condition such as a deadline passing without a matching acknowledgement, a transport rejecting an attempt, or a referenced counterpart remaining unavailable at a stated reconciliation cutoff. It is not a bare absence of data.

Reconciler

A component that correlates observations and reports scoped dispositions and aggregate results without silently converting uncertainty into success or failure.

Bounded Population

A closed, reproducible set of delivery obligations or input records selected by declared inclusion, target-resolution, observation-window, and reconciliation-cutoff rules.

Structural Reconciliation Result

An aggregate result, such as PASS, FAIL, or INCONCLUSIVE, derived from the declared population and reconciliation rules. It does not by itself state the evidentiary strength of every attribution, completeness, or mediation claim.

Claim Support

The separately reported strength with which the available verified evidence supports a particular scoped claim. Section 6.6 defines the conceptual values FULLY_SUPPORTED, CONDITIONALLY_SUPPORTED, and NOT_SUPPORTED.

Independent Observer

An observer whose authority and write path are not controlled by the party or component whose assertion it is intended to corroborate. Administrative, key, process, and storage separation are relevant to this determination.

Problem Statement and Failure Model For a given control instruction and one required target, the following facts are distinct:

1. a governance or policy decision was made;
2. a control instruction was constructed and emitted;
3. the instruction crossed the last issuer-controlled boundary;
4. the target was resolved as a required enforcement point under the declared profile;
5. that enforcement point received and matched the instruction;
6. that enforcement point applied or refused it; and
7. the intended control effect was observed.

Evidence for one item does not, without an explicitly specified and verified binding, establish a later item. In particular, a decision record does not establish dispatch; dispatch does not establish receipt; receipt does not establish enforcement; and enforcement does not establish an observed control effect. When an instruction has multiple required targets, the facts from target A do not establish the corresponding facts for target B. A parent-instruction claim must therefore be derived from the dispositions of all required instruction-target obligations rather than from the existence of any one receiver record. The reverse inference is also unsafe. Missing receiver evidence can result from non-delivery, delayed delivery, delayed evidence export, a failed observer, retention loss, clock disagreement, identifier mismatch, target-resolution failure, or evidence suppression. A receiver cannot report a control it never received. An issuer cannot, from silence alone, prove what happened inside the receiver's boundary. Control activation is also not retroactive. A later APPLIED control result does not retroactively relabel a boundary transition that occurred before the control took effect. An operation that crossed one earlier admission, provider-entry, or other profile-defined effect boundary can nevertheless remain subject to a later applicable enforcement boundary. Evidence of a later refusal does not rewrite the earlier transition and does not by itself prove that any prior external effect was reversed. That operation's outcome requires its own authenticated reconciliation. The failure model includes at least:

• transport rejection, loss, reordering, duplication, and retry;
• identifier collision or reuse;
• the same identifier carrying a different instruction digest;
• a receiver record with no issuer-side counterpart;
• a required target omitted from, added to, or ambiguously resolved within the target population;
• a target set declared closed without an accepted basis for a stronger complete-mediation claim;
• malformed or unverifiable records;
• conflicting observations from the same or different observers;
• partial observer or evidence-store failure;
• clock skew and unsupported ordering claims;
• an enforcement point acknowledging receipt before persistence or processing;
• successful processing that produces no observable control effect;
• an operation already consumed or in flight when a later control becomes effective;
• an intermediary that suppresses, transforms, or collapses a governance-relevant disposition before it reaches the relying party; and
• compromise of an issuer, receiver, observer, verifier, or signing key.

The requirements below do not eliminate those failures. They make the distinctions and residual uncertainty interoperably visible.

Logical Evidence Model An implementation MAY carry the required facts in one artifact, in several artifacts, in protocol fields, in telemetry, or through external references. Regardless of packaging, a consumer needs to distinguish the following logical observations and bindings.

Issuer-Side Emission The issuer-side observation records that a particular instruction crossed a declared issuer boundary. It binds a stable instruction identifier to a digest of the exact governed instruction or declared projection, identifies the target, Required Target Set, or target-resolution input, and attributes the observation to the issuer-side observer. Creation of an in-memory object, enqueueing inside the issuer's own process, or a policy decision that has not reached the declared boundary does not satisfy this observation.

Required Target Set and Delivery Obligations For a bounded reconciliation run, each instruction resolves to one or more required enforcement targets under a profile-defined rule. The result is the Required Target Set for that instruction. The set, or a verifiable reference that resolves to it, is frozen for the reconciliation cutoff before receiver evidence is used to decide which targets were expected. Each member of the Required Target Set creates one Delivery Obligation. A receiver observation for one obligation cannot satisfy another obligation merely because both obligations share the same parent instruction identifier or content digest. A target set that is closed for a reconciliation run establishes the population over which structural accounting can be repeated. It does not, by that fact alone, establish that every possible enforcement path in the deployment has been enumerated. A claim of complete mediation requires a separately stated and verified coverage basis under the declared deployment scope.

Receiver-Side Observation The receiver-side observation records that a particular intended enforcement point, or an endpoint-bound observer acting for it, read an instruction with the same stable identifier and content binding. The record identifies the required target identity, receiving boundary, and verification or matching result. A transport-level "accepted" or "queued" response is evidence about that transport boundary. It MUST NOT be labeled as enforcement-point receipt unless the applicable profile defines the endpoint binding, delivery semantics, persistence point, and failure behavior that make the equivalence valid.

Enforcement Outcome The enforcement outcome reports what one enforcement point did after receiving and evaluating the instruction. At minimum, a profile that reports enforcement MUST be able to distinguish:

APPLIED

The enforcement point reports that it applied the specified control under the declared local semantics and effective boundary.

REFUSED

The enforcement point reports that it intentionally did not apply the control, with a scoped reason or reason class where disclosure policy permits.

NO_EFFECT

The enforcement point processed the control but reports that it caused no change under the declared predicate and observation window.

UNKNOWN

The enforcement point cannot determine or support one of the preceding outcomes.

APPLIED is an attributable enforcement assertion for that enforcement point. It is not, by itself, independent observation of the resulting runtime state, proof that another required target applied the control, or proof that an earlier in-flight operation was reversed.

Control-Effect Observation A control-effect observation records a scoped predicate over the governed runtime state, such as "task X was no longer dispatching tool calls during window W" or "operation O2 did not cross provider entry during window W". It identifies the observer, observation method, target, predicate, window, and result. Where independent corroboration is claimed, the observer MUST be independent of both the issuer and the enforcement point under the stated trust model. An implementation MUST NOT infer independence from a different process name, service label, or signing key alone. A scoped effect observation for one target or one operation MUST NOT be generalized to every target or every dispatch path.

Evidence Preservation Requirements

R-CD-1: Stable Instruction Identity Each control instruction crossing a control boundary MUST have an identifier that remains stable across issuer, transport, receiver, enforcement, and reconciliation observations. The identifier's uniqueness scope and reuse rules MUST be defined. A decision, task, session, action, or delegation reference MAY also be carried, but it MUST NOT replace the instruction identifier unless the protocol defines identical uniqueness and lifecycle semantics. If retries create distinct delivery attempts, the profile MUST define an attempt identifier or equivalent rule that prevents observations from different attempts from being silently merged.

R-CD-2: Content Binding Every observation used to correlate a control instruction MUST bind the instruction identifier to a digest of either the exact instruction or a declared canonical projection of it. The projection, digest algorithm, canonicalization rule, and domain-separation rule, if any, MUST be identified by the applicable protocol or profile. A digest match establishes byte or projection correspondence under the named algorithm. It does not establish semantic equivalence, correctness, authority, or truth.

R-CD-3: Boundary Attribution Each observation MUST identify the observer, the boundary side observed, and the event being asserted. The evidence profile MUST state how the observer identity and its authority are verified. If the producer is able to rewrite the purported corroborating record, the record MUST NOT be described as independent evidence. If a profile permits structural processing when an external trust or authority binding is absent, it MUST expose that limitation through the claim-support qualification defined in . A self-declared key, role, or observer label MUST NOT silently become fully supported attribution.

R-CD-4: Issuer-Side Emission When an implementation claims that a control was dispatched, it MUST emit or preserve an issuer-side observation at the last declared issuer-controlled boundary. The observation MUST include the stable identifier, content binding, target, target-set reference, or resolution input, observed time, and boundary description. Where one instruction resolves to multiple required targets, the profile MUST preserve a stable binding to the Required Target Set, or to a verifiable resolution rule and inputs from which the same set can be reconstructed at the reconciliation cutoff. If emission fails before that boundary, the implementation MUST NOT report the instruction as dispatched. It SHOULD record the failed emission attempt as a positive failure event.

R-CD-5: Receiver-Side Observation An implementation MUST NOT report delivery to a required target unless it has a matching receiver-side observation or a receipt whose endpoint semantics satisfy . The observation MUST carry the stable identifier, content binding, receiver identity, required target identity, receiving boundary, observed time, verification result, and an attempt identifier or equivalent retry binding where the profile distinguishes delivery attempts. A receiver observation MAY satisfy only the Delivery Obligation whose target identity and boundary it is verified to represent. An observation for target A MUST NOT be used to confirm target B merely because the parent instruction identifier and content digest match. A receiver MUST NOT acknowledge a digest or instruction identifier it did not read and match. If verification or content matching fails, the receiver SHOULD preserve a scoped failure observation rather than emitting a successful acknowledgement.

R-CD-6: Separate Enforcement Outcome Receipt and enforcement MUST be represented as separate facts. An implementation that reports an enforcement result MUST distinguish at least APPLIED, REFUSED, NO_EFFECT, and UNKNOWN, or define a lossless mapping from its native states to those meanings. Missing enforcement evidence MUST NOT default to APPLIED.

R-CD-7: Separate Control-Effect Observation An observed control effect MUST be represented separately from both delivery and enforcement. The observation MUST name its predicate, target, method, observer relationship, start and end conditions, and result. A claim that no effect occurred MUST be bounded by an observation window and predicate; silence alone MUST NOT be reported as NO_EFFECT.

R-CD-8: Negative Observations A negative observation MUST record what was positively observed, from which boundary, and as of which cutoff. Profiles SHOULD support at least the following conceptual conditions where applicable:

• deadline elapsed without a matching acknowledgement;
• counterpart missing at the reconciliation cutoff;
• transport rejected the identified attempt;
• verification or content matching failed; and
• outcome remained undetermined after the declared deadline.

The absence of an observation record is not a negative observation. A deadline-elapsed record establishes the reconciler's bounded view; it does not prove that the receiver never received the instruction.

R-CD-9: Time and Ordering Each timed observation MUST identify its time value and the relevant clock or trust basis. A profile that reports cross-observer latency or precedence MUST state how clock synchronization, trusted timestamping, causal linkage, or another ordering mechanism supports that claim. Matching identifiers and digests establish correspondence. They do not, by themselves, establish that one observation preceded another. Unsupported ordering claims MUST be omitted or reported as indeterminate.

R-CD-10: Total Reconciliation A reconciler MUST produce a deterministic disposition for every Delivery Obligation and every input record presented under a declared profile. Malformed, unverifiable, duplicate, conflicting, and unmatched records MUST NOT be silently discarded. A reconciler MUST NOT produce a successful delivery verdict solely because no failure record exists. The expected obligation population MUST be constructed from the declared issuer-side inclusion and target-resolution rules rather than solely from the receiver evidence that happens to be present. Otherwise omitted targets or suppressed failures can disappear before reconciliation begins. The minimum per-obligation delivery dispositions are defined in . A profile MAY add more specific states, provided that it defines a lossless mapping to the minimum set and does not weaken UNCONFIRMED, INVALID, CONFLICT, or INDETERMINATE into success. If several applicable observations or diagnostics are reduced to one primary per-obligation disposition, the reduction rule MUST be deterministic and reviewable. All applicable diagnostics, including diagnostics not selected as the primary disposition-driving diagnostic, MUST remain visible in the report or in an explicitly linked diagnostic collection. This document does not prescribe a universal precedence ordering among profile-specific diagnostics.

R-CD-11: Bounded-Population Accounting An implementation claiming completeness over a set of controls MUST declare a reproducible issuer inclusion rule, Required Target Set or target-resolution rule for each instruction, observation window, reconciliation cutoff, and expected population counts. Each expected Delivery Obligation MUST appear in exactly one per-obligation disposition. Each receiver-side input record MUST also be accounted for as matched, orphaned, duplicated, conflicting where the profile uses a separate record class, or invalid. Every instruction in the bounded issuer population MUST remain accounted for during target-set construction, including an instruction whose target resolution succeeds and yields an empty Required Target Set. Where the Required Target Set for an instruction is empty, the instruction MUST remain in the report, the report MUST state that the instruction contributed zero Delivery Obligations, and the report MUST state the rule or condition under which target resolution produced the empty set. An instruction MUST NOT disappear from reconciliation solely because no Delivery Obligation tuple was added for it. The report MUST publish |I| alongside |O| and MUST publish counts sufficient to distinguish instructions that contributed one or more Delivery Obligations from instructions that contributed zero, as required by . A profile MUST define whether an empty Required Target Set is a valid terminal resolution. Where the profile declared that semantics before reconciliation, an empty set is a legitimate terminal resolution and the instruction is still accounted for as a zero-obligation instruction. Where the profile does not permit it, an empty Required Target Set MUST prevent a structural PASS for the affected instruction and for any parent or aggregate scope that depends on it. An empty Required Target Set MUST NOT be recorded by inventing a synthetic enforcement target or a synthetic Delivery Obligation, and MUST NOT be classified as EXPLICIT_FAILURE unless a positive, attributable failing condition applies under . If the implementation cannot define a closed Required Target Set for an instruction, it MUST NOT claim complete delivery for that instruction over an unspecified target population. It MAY report per-record or per-known-target results with an explicit open-population scope. Closing a target population for reconciliation is not equivalent to proving complete mediation. A report MAY state that every member of a declared target set is confirmed when the evidence supports that scoped statement; it MUST NOT promote that statement into "every possible enforcement path was covered" unless the target-set coverage basis separately supports that stronger claim.

R-CD-12: Resolution Failure If a control instruction refers to an external decision, policy, action, task, target, target set, key, or evidence binding, the applicable protocol or profile MUST define behavior when that reference cannot be resolved, is stale, resolves ambiguously, or resolves to inconsistent content. Unresolved or ambiguous bindings MUST NOT be treated as verified delivery or successful enforcement.

R-CD-13: Scope, Qualification, and Non-Claims Evidence producers and reconcilers MUST state what each result covers and what it does not cover. At minimum, integrity, attribution, delivery, enforcement, observed control effect, ordering, population closure, complete mediation, and independent corroboration MUST NOT be implied unless each is separately supported under the declared trust model. Where an aggregate result is used to support a relying-party claim, the report MUST identify the claim scope and MUST expose the claim-support qualification defined in . A structural PASS MUST NOT be rendered or consumed as an unqualified end-to-end success statement when attribution, target-set coverage, ordering, independence, or another claim predicate remains only declared, unverified, or indeterminate. The co-exposure rule in applies to every representation in which a structural aggregate result is exposed, not only to the representation in which that result was first derived. Evidence that a governance-relevant distinction was preserved at one boundary MUST NOT, by itself, be consumed as evidence that the distinction survived unchanged through later intermediaries to the relying party. Likewise, preservation at an origin boundary does not by itself establish downstream receipt or enforcement, an observed effect, completeness, or that an unrecorded event did not occur. A signature establishes only the properties supported by the verified key binding and signature input. A transparency receipt establishes only the registration or inclusion properties supplied by the relevant transparency service. Neither establishes the truth of a producer's event assertion by itself.

R-CD-14: Consumption and Fail-Safe Handling An unacknowledged or unresolved safety-relevant Delivery Obligation MUST NOT be consumed as delivered. A relying system SHOULD expose UNCONFIRMED, CONFLICT, INVALID, and INDETERMINATE results to operational policy and SHOULD define a fail-safe, retry, escalation, or human notification behavior appropriate to the controlled risk. This document does not select the operational response. It requires that uncertainty remain distinguishable at the point where that local response is chosen.

R-CD-15: Target-Set Closure and Coverage Qualification For each Required Target Set used in a bounded reconciliation, the profile MUST state the set identifier or reproducible resolution rule and the basis on which the set is treated as closed. The report MUST also state whether the completeness of that enumeration for a stronger deployment-level mediation claim is verified under the trust model, merely declared by a source, or indeterminate. A profile MAY use different vocabulary, but it MUST preserve the distinction among at least the following conceptual conditions:

VERIFIED

The relying party accepts evidence, under the declared trust model and scope, that the target set covers the enforcement paths required by the claim.

DECLARED_ONLY

A producer or configuration declares the set closed, so structural reconciliation can use it, but the relying party lacks accepted evidence for the stronger enumeration-completeness claim.

INDETERMINATE

The verifier cannot determine whether the set is complete for the requested claim scope.

A DECLARED_ONLY target set can still support reproducible structural accounting over its named members. It MUST NOT, by itself, support a fully qualified claim of complete mediation across every relevant path. The claim-support rules in determine whether the requested claim is conditionally supported or not supported.

R-CD-16: Semantic Preservation Across Intermediaries When a profile claims that a source-attributable disposition, outcome, target identity, or other governance-relevant state is preserved across one or more protocol intermediaries, the evidence available to the relying party MUST preserve enough source and transformation information to determine whether the relevant distinction survived the path. Where a gateway, broker, adapter, or other intermediary transforms the native representation, the applicable profile MUST define a lossless mapping for every governance-relevant state used by the claim or MUST expose that the mapping is incomplete, ambiguous, or unavailable. An intermediary MUST NOT silently collapse distinct applicable states such as deny, defer, reject, timeout, unresolved, or indeterminate into a representation that a relying party can consume as a stronger or different state. If lossless preservation cannot be established, the resulting state MUST remain explicitly qualified or INDETERMINATE according to the profile. This requirement concerns preservation of meaning, not a mandated carrier. Native fields, structured errors, acknowledgements, events, or references can satisfy it. It does not require every intermediary to emit a new evidence artifact.

Reconciliation Model

Per-Obligation Delivery Dispositions A conforming reconciliation profile MUST preserve at least the following meanings:

CONFIRMED

A receiver-side observation matches the Delivery Obligation's instruction identifier, attempt binding where applicable, content binding, required target identity, and required receiving boundary under the declared verification rules.

EXPLICIT_FAILURE

A positive, attributable failure observation applies to the identified delivery attempt, target, and boundary. The result MUST state its scope and MUST NOT be generalized to other targets or delivery paths.

UNCONFIRMED

An expected Delivery Obligation exists, but no matching receiver-side observation is available at the reconciliation cutoff.

SUBSTITUTION

Applicable issuer-side and receiver-side records address the same Delivery Obligation but carry different content bindings.

CONFLICT

Two or more otherwise applicable records make incompatible assertions that the profile cannot deterministically resolve.

INVALID

The instruction, obligation, or a required record is malformed, fails native verification, or lacks a binding that the profile requires for structural validity.

INDETERMINATE

The available inputs do not support a stronger disposition for a reason other than ordinary absence of a receiver observation, including an unresolved required target or trust binding.

Receiver-side records that match no expected Delivery Obligation in the declared population are ORPHAN records. Duplicate and invalid receiver records are counted separately for record accounting. ORPHAN is not an obligation disposition because there is no corresponding expected obligation. The delivery disposition is independent of the enforcement outcome and the control-effect result. For example, one obligation can have delivery CONFIRMED, enforcement APPLIED, and control effect UNKNOWN while another obligation for the same parent instruction remains UNCONFIRMED.

Parent Instruction Aggregation A parent instruction that has one or more required targets can be reported as fully confirmed within its declared Required Target Set only when every Delivery Obligation for that instruction is CONFIRMED. The report MUST retain the per-target dispositions used to derive that parent result. If any required obligation is EXPLICIT_FAILURE, UNCONFIRMED, SUBSTITUTION, CONFLICT, INVALID, or INDETERMINATE, the parent instruction MUST NOT be reported as fully confirmed. The parent result is scoped to the identified target set and does not, by itself, establish complete mediation over paths not proven to be in that set.

Minimum Reconciliation Procedure For a declared bounded population, a reconciler:

1. freezes the profile revision, trust inputs, issuer inclusion rule, target-resolution rules or target-set references, target-set closure evidence, observation window, and reconciliation cutoff;
2. constructs the expected Delivery Obligation population before using receiver evidence to decide which targets count as expected;
3. parses every input record and retains invalid inputs in an error population;
4. performs each artifact's native integrity, identity, freshness, and authorization checks before consuming its claims;
5. groups valid records by Delivery Obligation identity without assuming that identifier equality implies content, target, or attempt equality;
6. compares content bindings, target identities, target boundaries, and boundary roles;
7. assigns exactly one delivery disposition to every expected Delivery Obligation;
8. accounts separately for every receiver record as matched, orphaned, duplicated, conflicting where separately tracked, or invalid;
9. reports enforcement and control-effect results as separate dimensions;
10. derives any parent-instruction result only from the complete set of required obligation dispositions;
11. derives any structural aggregate result under and preserves it separately from claim support;
12. emits counts, exclusions, claim scope, claim-support qualification, and limitations sufficient for a third party to repeat the same structural verdict and understand what stronger claims remain unsupported.

Profile-specific conflict resolution MAY select among duplicate or superseding records, but the discarded alternatives and the selection rule MUST remain reviewable.

Population Conservation Let I be the bounded set of expected issuer instructions. For each instruction i, let T_i be its closed Required Target Set under the declared reconciliation profile. Let O be the resulting set of Delivery Obligations: O = { (i,t) : i in I and t in T_i } A reconciliation report that claims complete obligation accounting MUST satisfy: |O| = Nconfirmed + Nexplicit_failure + Nunconfirmed + Nsubstitution + Nconflict + Ninvalid + Nindeterminate T_i MAY be empty when the declared target-resolution rule terminates with no required enforcement target for instruction i. Such an instruction contributes no Delivery Obligation to O, so obligation accounting alone cannot demonstrate that it was considered. A report that claims complete accounting MUST therefore also publish |I| and MUST satisfy the separate instruction-level conservation equation: |I| = Ninstructions_with_obligations + Nzero_obligation_instructions Ninstructions_with_obligations counts the instructions in I whose Required Target Set has at least one member. Nzero_obligation_instructions counts the instructions in I whose target resolution terminated with zero members. Each zero-obligation instruction MUST be reported individually with the rule or condition that produced the empty set, as required by . The two equations are independent: |I| accounts for issuer instructions and |O| accounts for Delivery Obligations, and neither substitutes for the other. Let R be the bounded set of receiver-side input records. Complete receiver-record accounting MUST separately satisfy: |R| = Nmatched + Norphan + Nduplicate + Ninvalid_receiver Profiles MAY retain additional record-side classes, including a distinct conflict class, provided that every input record remains accounted for exactly once under a published conservation equation. The equations describe accounting classes, not wire values or IANA registries. Profiles MAY subdivide a class, but the sum of its subdivisions MUST preserve the parent count. Records or targets excluded before population construction MUST be reported with the exclusion rule and count; otherwise the completeness claim is not reproducible.

Structural Aggregate Results A profile MAY define a structural aggregate result such as PASS, FAIL, or INCONCLUSIVE. This result answers whether the declared population reconciled under the profile's structural rules. It does not, by itself, answer whether a stronger attribution, complete-mediation, independence, or physical-effect claim is fully supported. If a profile defines these aggregate results:

• PASS MUST require a closed obligation population, successful population conservation, and every expected Delivery Obligation to meet the profile's successful structural conditions;
• FAIL MUST identify at least one positive failing condition and MUST NOT be inferred solely from missing evidence;
• UNCONFIRMED, CONFLICT, INVALID, or INDETERMINATE obligation input MUST prevent PASS unless the profile explicitly excluded that obligation before population construction under a published rule;
• a population-conservation failure MUST prevent PASS; and
• the report MUST publish the complete class counts rather than only the aggregate label.

A structural PASS can coexist with CONDITIONALLY_SUPPORTED claim support when, for example, every declared obligation reconciles but a trust root or independent population-coverage predicate required by a stronger relying-party claim was not verified. Implementations MUST NOT collapse those two dimensions into a bare PASS.

Claim-Support Qualification For each aggregate claim exposed to a relying party, a report MUST identify the claim scope, including the target set or population, relevant boundaries, observation window or cutoff, and the fact being claimed. The report MUST then preserve a claim-support qualification separate from the structural result. Wherever a structural aggregate result is rendered, returned, exported, or otherwise exposed to a relying party, the corresponding claim scope and claim-support qualification MUST be exposed in the same result context. This applies to PASS, FAIL, and INCONCLUSIVE alike. A profile MUST NOT expose a bare structural result that can be consumed as the complete result without that qualification. The requirement constrains what accompanies the result, not the field layout of any particular serialization: native fields, a nested object, a structured error, a protocol event, or a resolvable reference can satisfy it, provided that a consumer of that result context cannot obtain the structural result without also obtaining its claim scope and claim-support qualification. A profile MAY use different vocabulary, but it MUST define a lossless mapping to at least the following conceptual meanings:

FULLY_SUPPORTED

Every evidence predicate required by the scoped claim is satisfied under the declared verification and trust rules. This value does not claim ground truth beyond those predicates.

CONDITIONALLY_SUPPORTED

The structural result can be stated, but one or more predicates required for the stronger claim are declared-only, unverified, not independently established, or otherwise limited. The report MUST name each condition or missing predicate.

NOT_SUPPORTED

The structural result, population scope, or available evidence does not support the requested claim. The claim MUST NOT be rendered as true.

The structural result and claim support are orthogonal. A positive failure can be strongly evidenced; a structurally balanced or passing population can have conditional attribution; and a structurally complete result over a declared closed target set can still fail to fully support a claim that every possible enforcement path in a deployment was covered. Profiles MUST state which missing predicates may produce CONDITIONALLY_SUPPORTED rather than NOT_SUPPORTED. They MUST NOT use conditional support as a silent fallback for a predicate that the profile declares mandatory for the requested claim.

Protocol Attachment Points A protocol need not carry an audit receipt to preserve the facts needed by an external evidence layer. When a governance-relevant transition crosses a protocol or administrative boundary, the protocol or its implementation profile SHOULD provide attachment points for:

• a stable control-instruction identifier and, where available, a stable delivery-attempt reference and a reference to the upstream decision, action, task, or session;
• a digest of the exact governed instruction or declared action projection;
• a target identity or a stable Required Target Set / target-resolution reference;
• the issuer and intended enforcement-point identities or resolution inputs;
• an attributable outcome that preserves deny, defer, reject, timeout, unresolved, and indeterminate states;
• a way to distinguish transport acceptance from target-bound enforcement-point receipt;
• an explicit rule for stale, missing, ambiguous, or inconsistent external references; and
• a stable reference through which an external evidence system can bind additional observations without changing the protocol's native message format.

These attachment points can be realized as native fields, structured errors, acknowledgements, protocol events, or references. This document does not require that evidence artifacts be transferred inline. Where those facts traverse an intermediary, preservation at the originating boundary alone is not sufficient for a claim that the relying party received the same distinction. A protocol or profile that maps native states through an intermediary SHOULD preserve source attribution and lossless distinguishability; if it cannot, the mapping and resulting uncertainty need to remain visible under . Public AgentProto requirements discussion has drawn the same scope boundary: accountability and audit formats can remain separate while a protocol still preserves stable operation or instruction identity, input binding, source-attributable outcomes, and non-success or non-final distinctions. This document uses that boundary without claiming that the mailing-list discussion constitutes working-group consensus. The distinction is that this document does not ask the protocol to define what an auditor concludes. It asks protocol transitions not to erase the identifiers, bindings, target-set information, outcomes, and failure semantics that any downstream verifier would need, while also refusing to infer that an origin-side fact necessarily survived to the eventual reader.

Composition with Existing Mechanisms

Native Verification First Each credential, signature, attestation, authorization result, transport acknowledgement, telemetry record, and transparency receipt retains its native semantics and verifier. A reconciler MUST perform or consume the result of the native verification before treating the artifact as evidence for a control-delivery claim. A self-declared algorithm, key identifier, role, observer label, or target-set coverage claim MUST NOT drive trust without an externally configured or otherwise verified binding when the requested claim requires that trust. Composition MUST NOT strengthen the weakest input beyond its verified meaning. Where structural processing continues despite a missing trust predicate, the claim-support qualification MUST preserve that limitation.

SCITT Composition defines Signed Statements and receipts for registration in a transparency service. A control observation, target-set binding, or reconciliation report can be carried as, or referenced by, a SCITT Signed Statement. A SCITT receipt can then provide evidence of the registration properties defined by that service. This document does not require a new SCITT receipt format. Existing Signed Statements and profile-specific payload bindings can carry or reference the facts defined here when their native semantics are preserved. SCITT registration does not, by itself, prove that a control was delivered, enforced, correctly observed, or true. Those meanings still depend on the observation boundary, native verification, content and target binding, target-set scope, and reconciliation rules defined here and in the applicable profile.

Telemetry and Trace Composition Telemetry systems can carry timestamps, trace identifiers, and correlated events. A trace identifier can help locate related records, but trace membership alone does not establish instruction-content equality, authority, target-bound receipt, ordering across untrusted clocks, target-set completeness, or independence. Profiles using telemetry MUST state which required bindings are native, derived, declared-only, or absent.

Operational Considerations

Deadlines, Retries, and Late Evidence Deployments SHOULD define acknowledgement and reconciliation deadlines based on the controlled risk and transport characteristics. The deadline source, start event, units, and clock basis need to be explicit. A late receiver observation can change UNCONFIRMED to CONFIRMED in a later reconciliation run, but the earlier report and its cutoff SHOULD remain available. Retries SHOULD reuse or relate identifiers according to a declared rule. Reusing one identifier for different instruction content creates SUBSTITUTION, not a retry. Creating a new identifier for every retry without a common attempt-group reference can hide repeated delivery failures.

Durability and Acknowledgement Point A profile SHOULD state whether receiver acknowledgement occurs after parsing, verification, durable persistence, admission to an enforcement queue, or completed enforcement. Implementations MUST NOT use the same acknowledgement value for several of those points unless the profile defines the combined semantics and residual failure window.

Multiple Enforcement Paths A control can be ineffective even when one enforcement point applies it if an alternate path remains open. A deployment claiming delivery across multiple required enforcement paths SHOULD bind those paths into a Required Target Set and reconcile each resulting Delivery Obligation separately. A deployment claiming complete control mediation SHOULD identify the deployment scope and the evidence by which the Required Target Set is considered to cover all relevant paths. A set being closed for a reconciliation run does not, by itself, prove that the enumeration is complete.

Control Activation and In-Flight Operations A profile that reports APPLIED for a freeze, revoke, cancel, or similar control SHOULD define the local effective boundary and the relationship between the control and operations that were already admitted, consumed, dispatched, or in flight when the control took effect. Every boundary crossing is a historical fact. A reconciler MUST NOT retroactively relabel a boundary transition that occurred before control activation, and MUST NOT relabel an operation as blocked merely because a later control was APPLIED. Only a boundary crossing that actually occurred before activation is protected from retroactive relabelling. Local admission and provider entry are distinct boundaries and are not interchangeable. If an operation was admitted before control activation but had not yet crossed a later provider-entry or other enforcement boundary, a subsequently applied control MAY still prevent that later transition under the applicable local semantics. The report MUST preserve the earlier admission fact and MUST separately preserve the later refusal or blocked transition. An operation that was admitted, or that is in flight, is therefore not automatically exempt from a later applicable enforcement boundary: non-retroactivity protects the record of what already happened, not the operation's remaining transitions. Where the operation did cross the relevant profile-defined boundary before control activation, its outcome at that boundary remains a separate lifecycle fact. Missing authenticated outcome evidence for that operation MUST remain unresolved or indeterminate according to the applicable outcome profile. Similarly, a later control-effect observation that a subsequent operation was blocked does not prove that an earlier operation produced no external effect or that a prior effect was reversed. A reversal, compensation, or remedy requires its own evidence and does not rewrite the historical ordering of the original operation.

Security Considerations The evidence described here is security-relevant because it can drive escalation, incident response, or claims that an agent was stopped. An attacker can target the instruction, the delivery path, the target-resolution input, the observer, the evidence store, the verifier, or the reconciliation population.

Substitution, Replay, and Identifier Reuse An attacker can reuse an instruction identifier with weaker content, replay an old acknowledgement, correlate a receiver record to the wrong attempt, or bind a valid observation from target A to target B. Stable identifiers, attempt semantics, content digests, freshness rules, target binding, and attempt-group semantics mitigate these attacks. Digest algorithms and canonicalization rules need downgrade-resistant selection.

Observer and Key Compromise A valid signature proves control of a signing key over the signed bytes; it does not prove that the observer actually saw the asserted event. Key-to-observer binding, protected key use, process and storage separation, attestation where appropriate, and independent observation can improve confidence. None should be overstated as ground truth.

Evidence Suppression and Selective Population A producer can suppress failed controls, omit a required target, or choose a favorable subset after the fact. Bounded-population construction before receiver-evidence evaluation, target-set binding, entry-emission rules, append-only or transparency mechanisms, and independent counters can make suppression more detectable. An open population cannot support a completeness claim. A target set can also be made deceptively small while remaining internally closed. Structural conservation over that set is not evidence that no omitted path exists. Complete-mediation claims therefore require the separate coverage qualification in R-CD-15.

Availability and Fail-Safe Policy An attacker can withhold acknowledgements or evidence to force fail-safe shutdowns, or flood a reconciler with orphan and invalid records. Implementations need resource limits, authenticated inputs, replay control, rate limiting, and a local policy that balances safety and availability. The evidence layer MUST preserve the uncertain state even when local policy chooses to continue operation.

Semantic and Physical-World Gaps Matching digests do not prove that two implementations assign the same meaning to a control verb. An enforcement assertion does not prove a physical-world outcome. Profiles need versioned control semantics and scoped effect predicates. High-consequence deployments require domain-specific validation beyond this document. An intermediary can also preserve syntax while weakening semantics, for example by mapping several source dispositions to one downstream label or by dropping source attribution. Such a transformation can make a downstream record look more definite than the upstream fact. Profiles that rely on intermediary-carried evidence need the lossless mapping or explicit uncertainty required by R-CD-16; cryptographic integrity of the transformed record does not restore a distinction that the transformation erased.

Privacy Considerations Control evidence can reveal agent identities, user relationships, incident timing, policy decisions, operational topology, target-set membership, and sensitive task state. Stable identifiers can enable correlation across services and observation windows. Implementations SHOULD minimize payloads, use scoped or pseudonymous identifiers where possible, separate identity resolution from routine evidence exchange, apply access controls and retention limits, and support selective disclosure. Raw prompts, chain-of-thought, model context, personal data, and proprietary policy SHOULD NOT be included by default. Publishing a digest instead of content reduces direct disclosure but does not eliminate it. Digests of low-entropy or enumerable values can be guessed. Profiles SHOULD use commitments, nonces, or access-controlled references where dictionary attacks are relevant. Independent observation and explicit target-set accounting increase corroboration but can also increase data replication and linkability. The independence and coverage requirements are scoped to claims that need them; they do not require disclosure of every event or internal topology to every party.

Implementation Status This section records implementation and evaluation experience available as of 4 September 2026 and is intended to be removed before publication as an RFC. The entries below are deliberately scoped to the requirement or failure mode they exercise. Adjacent interoperability results that do not implement this document are not promoted into implementation claims.The AI Runtime Evidence Protocol (AIREP) is an experimental, author-side source for several distinctions in this document. Its v0.1 control-delivery profile records issuer, enforcement-point, and witness observations and includes a total reconciler that does not treat issuer-side emission alone as receiver-side delivery. This is useful implementation input, but AIREP is not the conformance authority for this document and its broader interoperability evidence is not used here as proof of this draft. In particular, the public AIREP external-evidence record contains a v0.1.2 external-producer result and a separate v0.2 external consumer/verifier result; because they target different frozen versions, those results are explicitly non-additive and are not a producer-to-consumer interoperability result for any one AIREP version.A separate author-side runtime probe in phionyx-research records issuer-side and enforcement-point observations on opposite filesystem trust sides and correlates them by instruction identifier and instruction hash. The enforcement-side record explicitly declares that it is writable by the controlled system and is therefore corroboration, not proof. Its delivery audit also states that an issued instruction with no acknowledgement is unaccounted for, not proven undelivered, because delivery failure, evidence-recording failure, and a never-demanded override are not yet distinguishable. The associated tests pin identity/hash correlation, separate-side recording, coverage of every override-consuming gate, and non-silent evidence-write failure. This is partial author-side implementation experience; it does not establish independent implementation, complete mediation, or observed control effect.The historical standalone Agent Control Delivery Evidence Reconciliation (ACDER) probe implements an earlier instruction-target obligation model with seven fixtures. It is retained as a pinned author-side research artifact. It does not implement the full claim-support and intermediary semantic-preservation model in this revision, is not on current AIREP main, and is not an independent implementation of this document.A proposed format-neutral fixture contributed by Iman Schrock of EMILIA Protocol on the SCITT mailing list combines target multiplicity with a control-activation race. Its fixture identifier is freeze-after-provider-entry-with-multiple-required-targets and its SHA-256 is 2d8faa1b64b8a73fd0bf81b21889bbf726cbfb324af099b700499627af84203a. If that fixture is used unchanged, its identifier and digest are preserved. An adapted derivative receives a new fixture identifier and records the source fixture identifier and digest as provenance . The contributed fixture is test input, not an implementation of this document; its historical related-work pin is not silently rewritten when current related-work references advance.Cross-domain review and a pinned population probe against Cedulon informed the bounded-population and claim-qualification rules. The probe exposed a reporting-scope defect in the adjacent implementation rather than a defect in this document. That probe remains pinned to the artifact and package versions it was executed against. Later reviewer-reported measurements against Cedulon 0.8.0 and 0.12.0 were independently rerun by the author on 4 September 2026 from separate clean directories against the published package sets, using the reviewer's pinned case driver at Cedulon commit 52cf577 . The rerun reproduced the scoped behaviors recorded in the public work area. This is an author-side reproduction of an adjacent-domain measurement, not an implementation of this document, and it does not repin or replace the historical 1 September probe. Current Cedulon binds returned audit results to an account, rail, and window and conditions stronger claims on its declared scope and trust predicates. Cedulon remains adjacent-domain evaluation evidence, not an implementation of this document.The AIREP artifacts, the phionyx-research runtime probe, the historical ACDER probe, the contributed EMILIA fixture, and the Cedulon probe retain distinct provenance and claim boundaries. They are not merged into a self-validating conformance suite for this document. Additional independent implementations are sought, particularly for per-target obligation reconciliation, claim-support qualification, and semantic preservation through intermediaries.

Relationship to Adjacent Work The agent communication use-case and requirements work treats accountability and auditing as separate work. This document is compatible with that boundary: it defines only the minimum facts and distinctions that need to survive protocol transitions so an external evidence layer can later bind them. AgentProto mailing-list discussion on a minimal preservation requirement and its path-preservation follow-up sharpen that distinction without creating a receipt format or audit regime. separates claims, carriers, verifiers, bindings, failure behavior, and accepted results for agent protocols. The requirements here specialize that discipline for the control-delivery lifecycle and its boundary sides. Signed decision records preserve authorization decisions, including denials and non-occurring actions, and distinguish correspondence from precedence. A decision record can be an upstream reference for this document. It does not by itself establish that a resulting control instruction reached an enforcement point. The Action Evidence Boundary defines an executor-side processing model for consequential agent effects, including action correlation, local authorization, atomic consumption, invocation, effect outcomes, and reconciliation. This document addresses a different direction and object: a governance control such as stop or revoke moving toward the component that constrains the runtime. The "control effect" here is the governed runtime state, not the consequential business or physical effect of the protected action. Portable Revocation Statements bind revocation to an exact authorization target and effective time but explicitly do not prove that every relying party received the revocation. That distribution boundary composes directly with this document: a valid revocation statement can be an upstream control fact, while receiver-side delivery and enforcement remain separate evidence questions. This document does not redefine the revocation statement format or its atomic execution semantics. Outcome Binding separates evidence availability from comparison and uses pinned source roles and observation windows for post-execution effects. A control-effect observation in this document can compose with such outcome evidence where the predicates align. This document does not redefine consequential-action outcome states, source quorum, or physical-effect reconciliation. Contestability Bindings define a narrower effect path for an authenticated contestation filing. That work separately represents the declared effect policy, executor acceptance, authenticated trigger, ordering, and claimed application. The shared discipline is to avoid collapsing separately evidenced stages into a stronger end-to-end fact. This document therefore treats that effect-state model as a composition boundary rather than restating its states. Execution-finality work distinguishes model tool selection from authorized execution at a dispatch-time gate. A stop or revoke control can target such a gate. The present document asks how delivery and enforcement of that control are evidenced, rather than how the underlying tool action is authorized. The SCITT AI-agent receipt profile defines how an action receipt can be registered using SCITT. This document is format-neutral and can supply control-delivery statement semantics for a SCITT-based profile without changing SCITT's registration semantics. Cedulon reconciles a spend that has already occurred against signed receipts and an authenticated rail extract. Its object moves in the opposite direction from a control instruction moving toward an enforcement point, but the works share bounded-population, total-accounting, and qualified-claim disciplines. Cedulon revision -08 explicitly scopes returned audit results to an account, rail, and window and prevents those results from being read as statements about paths the reconciliation did not examine. This document does not restate Cedulon's payment, settlement, or rail-extract semantics and does not describe Cedulon as an implementation of this document. The OWASP Agentic AI Threats and Mitigations project includes a human-oversight requirement that an unacknowledged kill instruction not be treated as delivered. The requirements and negative-observation rules in this document generalize that implementation concern into a protocol-independent evidence contract.

Changes Since -00 This revision incorporates public SCITT review of -00, relevant AgentProto requirements discussion, and subsequent implementation evidence. The principal changes are:

• Introduced Required Target Set and Delivery Obligation terminology so one receiver observation cannot satisfy a multi-target parent instruction.
• Revised R-CD-4, R-CD-5, R-CD-10, and R-CD-11 to bind target sets and reconcile per instruction-target obligation.
• Added R-CD-15 to distinguish a population that is closed for structural reconciliation from evidence that the target enumeration is complete for a stronger complete-mediation claim.
• Replaced per-instruction population conservation with obligation-level conservation while retaining separate receiver-record accounting, and added instruction-level accounting so an instruction whose Required Target Set resolves to zero members remains reported and conserved rather than disappearing from reconciliation.
• Added parent-instruction aggregation rules: a parent can be fully confirmed within its declared target set only when every required obligation is CONFIRMED.
• Split structural aggregate results from claim-support qualification, defining FULLY_SUPPORTED, CONDITIONALLY_SUPPORTED, and NOT_SUPPORTED conceptual meanings, and required the claim scope and claim-support qualification to be exposed in the same result context as any exposed structural aggregate result.
• Added control-activation rules preventing a later APPLIED freeze or revocation from retroactively relabelling a boundary transition that occurred before activation, while distinguishing local admission from a later provider-entry or other enforcement boundary that a subsequently applied control may still refuse.
• Clarified that SCITT Signed Statements and profile bindings can carry or reference these facts without introducing a new receipt format.
• Added R-CD-16 and protocol-attachment guidance for semantic preservation through intermediaries, including the non-claim that preservation at an originating boundary does not establish that the distinction survived intact to the eventual reader.
• Required many-to-one diagnostic reduction to be deterministic and reviewable, required non-selected applicable diagnostics to remain visible or explicitly linked, and declined to define a universal precedence order.
• Clarified implementation and evaluation status so author-side probes, contributed fixtures, adjacent-domain evaluations, and unrelated cross-version interoperability results retain separate claim boundaries.
• Expanded adjacent-work composition for AgentProto preservation requirements, contestability, revocation, outcome binding, and Cedulon reconciliation.
• Updated implementation/test-vector status with the current AIREP control-delivery source, the phionyx-research author-side runtime probe, the historical ACDER probe, and provenance-preserving treatment of the contributed EMILIA Protocol fixture; broader AIREP cross-version interoperability remains explicitly non-additive.
• Expanded the minimum conformance cases for target multiplicity, target-set coverage qualification, structural-result/claim-support separation, in-flight races, empty required-target populations, bare aggregate results exposed without their qualification, many-to-one diagnostic reduction, and failure asserted from absent population evidence.

IANA Considerations This document has no IANA actions.

Acknowledgements The author thanks participants in the agent2agent, agentproto, and SCITT communities whose discussions helped sharpen the distinction among decision, delivery, enforcement, and effect. The author thanks Iman Schrock of EMILIA Protocol for contributing the proposed freeze-after-provider-entry-with-multiple-required-targets fixture, requesting that the fixture ID and EMILIA Protocol attribution be preserved, and reviewing target multiplicity, the required-target and freeze-race fixture, in-flight operation semantics, and fixture provenance. The author thanks Emek Can Dogru for public review of bounded-population accounting, the separation of the structural reconciliation result from claim support, diagnostic reduction, and the empty required-target accounting observation. Both named reviewers gave permission to be named here. The author also thanks SCITT participants who provided public review on bounded populations, qualified claims, adjacent-work composition, SCITT carriage, and implementation-reporting boundaries, as well as AgentProto participants whose public discussion sharpened the protocol-preservation and intermediary-path non-claims. Specific additional names can be added with permission in a later revision. Being named here records a review contribution only; these acknowledgements do not imply endorsement of this document by any named individual, organization, or working group.

Normative References Informative References Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress OWASP Foundation Repository snapshot at commit 2b210945361bac207f37a21440d0f34c05c07ad9 Repository snapshot at commit 706e40748be18e988d4efd1e307787e009161c6a; control_override.py and test_control_delivery_c1.py Commit a3973ce3b6ad984635867a2bb52d83c472e5c0cb Repository snapshot at commit a3973ce3b6ad984635867a2bb52d83c472e5c0cb Commit 449f4fb6a07fd54b45a6e68208dece109446ef93 SCITT mailing-list message; attached fixture SHA-256 2d8faa1b64b8a73fd0bf81b21889bbf726cbfb324af099b700499627af84203a SCITT mailing-list message AgentProto mailing-list message and quoted review context AgentProto mailing-list follow-up incorporating review from Nancy Sahu and Sumit Ahuja Reviewer-authored case driver exercising published Cedulon packages; commit 52cf577; observed SHA-256 f7f1218abd1535f104b0010b9127c565b3afab0e72242583ebc459000937bc8e. Not test code for this document. Commit 0a3fa04; SHA-256 031f84fda2054b1427a510baa45f880d379ea60dced408a4a74028da12b1fceb

Illustrative Multi-Target Reconciliation Record The following example is deliberately not a wire format. Field names are descriptive placeholders. Equivalent facts can be carried in native protocol messages and external evidence artifacts. { "instruction_id": "ctrl-7f3a", "instruction_digest": "sha-256:<digest>", "required_target_set": { "set_id": "targets:runtime-egress:v1", "structural_closure": "closed", "coverage_qualification": "DECLARED_ONLY", "members": ["EP-A", "EP-B"] }, "target_results": [ { "target_id": "EP-A", "delivery": "CONFIRMED", "enforcement": "APPLIED", "control_effect": "UNKNOWN" }, { "target_id": "EP-B", "delivery": "UNCONFIRMED", "enforcement": "UNKNOWN", "control_effect": "UNKNOWN" } ], "parent_instruction": { "fully_confirmed_within_target_set": false }, "structural_result": "INCONCLUSIVE", "claim": { "scope": "complete delivery to targets:runtime-egress:v1", "support": "NOT_SUPPORTED" } } The example does not support a fully confirmed parent delivery because EP-B is UNCONFIRMED. The DECLARED_ONLY coverage qualification is a second, independent limitation: even if EP-B later became CONFIRMED, the named set alone would not prove that every possible enforcement path in the deployment was enumerated.

Contributed Freeze-Race Fixture Summary This appendix summarizes the proposed format-neutral fixture contributed by Iman Schrock of EMILIA Protocol in . The fixture identifier and SHA-256 are preserved for provenance.

fixture_id

freeze-after-provider-entry-with-multiple-required-targets

contributor

Iman Schrock, EMILIA Protocol

SHA-256

2d8faa1b64b8a73fd0bf81b21889bbf726cbfb324af099b700499627af84203a

required targets

EP-A at checkout/provider-entry and EP-B at alternate-dispatch/provider-entry

population note

The set is closed for the fixture, while enumeration completeness is explicitly not independently proven.

expected EP-A result

delivery CONFIRMED; enforcement APPLIED; scoped control effect observed for a post-freeze operation.

expected EP-B result

delivery UNCONFIRMED; enforcement UNKNOWN; control effect UNKNOWN.

in-flight operation

O1 crossed provider entry before the freeze; it remains consumed or in flight with external effect UNKNOWN pending authenticated reconciliation.

post-freeze operation

O2 is refused by the freeze before provider entry at EP-A.

parent claim

Not fully confirmed; complete-delivery and PASS claims are not permitted for the two-target instruction in the fixture.

The fixture also requires the following non-claims: EP-A receipt does not establish EP-B receipt; EP-A APPLIED does not establish complete control mediation; the scoped O2 observation does not establish that every dispatch path was closed; and applying the freeze after O1 crossed provider entry does not retroactively relabel O1 as blocked or prove that O1 produced no external effect. Provenance handling follows the contributor's clarification . An unchanged use keeps the original fixture identifier and SHA-256. An adapted derivative uses a new fixture identifier and records the original fixture identifier and digest as source provenance, with EMILIA Protocol attribution retained. The original fixture remains pinned to the related-work revisions it named when contributed; updating related-work citations in this document does not silently rewrite the fixture.

Minimum Conformance Cases A profile claiming conformance to the reconciliation requirements SHOULD publish machine-readable test vectors for at least:

1. matching issuer and receiver records for one target: CONFIRMED;
2. expected obligation with issuer evidence only at cutoff: UNCONFIRMED;
3. same obligation identity with different digest: SUBSTITUTION;
4. receiver record with no expected obligation: ORPHAN record accounting;
5. positive transport rejection bound to one attempt and target: scoped EXPLICIT_FAILURE;
6. malformed expected obligation or issuer record: INVALID, retained in counts;
7. malformed receiver record: invalid receiver-record accounting;
8. duplicate matching receiver records: one match plus duplicate accounting under the profile's rule;
9. conflicting valid observations: CONFLICT;
10. missing acknowledgement without a negative-observation record: UNCONFIRMED, not EXPLICIT_FAILURE;
11. deadline-elapsed negative observation followed by late matching receipt: versioned reconciliation results preserving both cutoffs;
12. delivery CONFIRMED with enforcement UNKNOWN;
13. enforcement APPLIED with control effect UNKNOWN;
14. self-declared observer role without verified binding: no independence claim and no silent fully supported attribution;
15. unresolvable required-target or external binding: INDETERMINATE or INVALID according to the declared profile, never CONFIRMED;
16. a bounded obligation population whose category counts fail conservation: structural PASS rejected;
17. one instruction with two required targets, EP-A CONFIRMED and EP-B UNCONFIRMED: one CONFIRMED plus one UNCONFIRMED obligation, parent not fully confirmed, and no complete-delivery PASS;
18. a receiver observation bound to EP-A presented as evidence for EP-B: EP-B is not CONFIRMED;
19. two required targets both CONFIRMED while target-set coverage is DECLARED_ONLY: a scoped result over the named set can be structurally complete, but a complete-mediation claim cannot be FULLY_SUPPORTED solely from that declaration;
20. an open or unresolved Required Target Set: no complete-delivery PASS over an unspecified population;
21. a structurally passing population with a profile-permitted missing external trust predicate: structural result preserved while the stronger claim is CONDITIONALLY_SUPPORTED and the missing predicate is named;
22. a positive failing condition supported by verified evidence: structural FAIL can still have FULLY_SUPPORTED claim support for the scoped failure statement;
23. a freeze applied after operation O1 crossed the relevant provider-entry boundary and before operation O2 attempts entry: O1 is not retroactively labelled blocked, O2 is blocked only within the evidenced target scope, and O1 outcome remains separately reconciled; and
24. a target set closed for the fixture but without independently verified enumeration completeness: structural accounting proceeds over the set while complete-mediation support remains qualified;
25. a source emits DEFER but an intermediary maps it to generic FAILURE without a lossless mapping: the relying party cannot claim that the original disposition survived intact and the resulting preservation state remains qualified or INDETERMINATE;
26. a stable instruction identifier survives an intermediary while the governed instruction content changes: identifier continuity alone does not satisfy content binding and MUST NOT produce CONFIRMED;
27. an issuer instruction whose target resolution succeeds and yields an empty Required Target Set: the instruction remains accounted for in the report, contributes zero Delivery Obligations, is reported together with the rule or condition that produced the empty set, and does not disappear from reconciliation; instruction-level conservation over |I| still balances; and a structural PASS covering that instruction is available only where the profile explicitly declared an empty Required Target Set to be a valid terminal resolution before reconciliation;
28. a structural aggregate result exposed to a relying party without its corresponding claim scope and claim-support qualification in the same result context: a non-conformant representation that cannot be consumed as the complete result, exercised for a PASS result and for a FAIL result alike;
29. one Delivery Obligation or input record with several applicable diagnostics reduced to one primary disposition: the published reduction rule is deterministic and reviewable, exactly one primary disposition is selected, and every non-selected applicable diagnostic remains visible in the report or in an explicitly linked diagnostic collection, without any profile-specific precedence ordering being required by this document; and
30. an implementation reports FAIL because a receipt or issuer-side object is unmatched while the authenticated comparison population itself was never presented or established: the missing population evidence alone does not satisfy the positive failing condition that a structural FAIL requires under , and the result remains INCONCLUSIVE or otherwise qualified according to the profile's semantics. This case exercises the existing rule that FAIL is not inferred from absence; it does not introduce a new disposition.