]> Action State Group, Inc.

spec@actionstate.ai

Security agent accountability conformance verification composition audit SCITT An architecture for auditing agent-driven interactions (draft-kuehlewind-audit-architecture) identifies the record types an auditable agent system produces — interaction, action, delegation, and authorization-transition — and the role of an Auditor that determines whether recorded behaviour matched intent and the authorization in force. That architecture does not specify how an Auditor, or any independent party, deterministically verifies that a set of such records — produced by different parties, in different profiles, and composed into one case — is internally consistent and correctly derives an audit conclusion. This document specifies a horizontal conformance and verification methodology for composed agent-accountability records. It organizes conformance into three tiers: the payload-binding layer, per-record-type (per-slot) conformance, and composition (combination) conformance. It defines the determinism boundary between what is mechanically derivable from the binding rules and the individual records, and what is irreducibly semantic; a conformance-vector discipline (positive, negative, and must-fail cases, checked in both directions) that any record profile reuses rather than reinvents; and a deterministic method for deriving composition-conformance vectors from binding rules, individual-record vectors, a composition manifest, and a set of cross-record predicates. The methodology is profile-agnostic: it applies uniformly to any accountability record type and to any declared composition of them, whether those records are joined across parties or across attestation layers. Its lower two tiers verify a single record, so the method applies where no composition is present and strengthens as records are composed. It is intended as the composition-verification work item of the auditing architecture — the one its enumerated work items do not yet cover. Note to Readers This document is an individual submission, written as a method companion to the architecture for auditing AI agent delegation and interactions (draft-kuehlewind-audit-architecture) and to the agent-accountability composition model (draft-mih-sato-agent-accountability-composition). Discussion is invited on whatever venue is chartered for the auditing architecture work.

Introduction Autonomous and semi-autonomous agents increasingly take consequential actions across administrative and trust boundaries. Their behaviour is, in whole or in part, non-deterministic — driven by a model whose output cannot be reproduced by re-running it — so the record of what an agent did cannot be taken at face value, and cannot be re-derived by consulting the agent itself. The record is therefore only useful to a party who trusts neither the operator nor any single layer if that party can verify it deterministically: from the bytes and the rules, reproducibly, and independently of the agent that produced it. That verification MUST be performable by a disinterested third party: in an adversarial dispute — where the operator, or a counterparty, has a stake in the outcome — only a record that a party with no interest can check from the bytes constitutes proof. Designing the record once for third-party verifiability is also what keeps non-repudiation cheap and on demand: a disinterested transparency receipt (the SCITT model) need be obtained only when non-repudiation is actually required, rather than trusting a log continuously. That requirement — deterministic, third-party verification of an intrinsically non-deterministic producer — is what this document addresses, and it is why conformance here is defined by derivation rather than by assertion. The architecture for auditing agent delegation and interactions frames this well: it identifies the record types that must be auditable, the trust mechanisms (attestation, transparency) that make individual records authentic and non-repudiable, and an Auditor whose duty is to "determine whether recorded behaviour matched the User's intent and the authorization in force." What that architecture leaves open — and what its enumerated work items do not cover — is the Auditor's actual work: given records from several parties, in several profiles, referencing one another, how does an independent party deterministically establish that the composition is consistent and that a stated audit conclusion follows from it, and how is an implementation of that verification tested for conformance? Today this is done ad hoc. Independent constructions that appear to agree turn out to agree only under unstated preconditions; aggregate dispositions are sometimes written by hand rather than derived; and conformance, where it exists at all, is asserted rather than checked. These are not hypothetical failures. They have been observed directly in cross-implementation runs against composed agent-action records — including a run in which two independently written constructions agreed on only a minority of a shared vector suite, with every divergence and every unexpected agreement attributed to a declared rule, and the residual traced to a precondition neither side had stated. Three layers divide the work. The payload-binding layer defines how a record is canonicalized, digested, and referenced — the same for every record, regardless of profile. This document defines the two layers above it: how a single record of a given profile is verified (per slot), and how a composition of records is verified. Composition is where the difficulty concentrates, and it concentrates in two places in particular. Records are composed across parties — two organizations, each on its own stack and its own profile, meeting at a trust boundary where neither accepts the other's format — and across the layers of one stack — an execution-environment attestation, a model attestation, and an action record, each independently produced and bound into one accountable statement about the same event. Both are heterogeneous by nature: the profiles and vocabularies differ, and the number of admissible combinations grows combinatorially, so composition conformance cannot be hand-authored and kept correct by inspection; it must be derived from the parts. It is also continuous, not one-time: as parties revise the statements and profiles that fill their slots, the compositions that include them change, and their conformance must be re-derived rather than re-asserted. Composition conformance is thus an operational property of a living system, not a certificate issued once. The single-record layer below is verified in isolation, and the method applies there too: a deployment that composes nothing still uses its lower two tiers. This document specifies the missing layer: a horizontal conformance and verification methodology that sits above the payload-binding layer and is independent of any particular record profile. It is intended as the verification companion to the auditing architecture — in the terms of that document's own work-item structure, the composition-verification work item that is not yet enumerated ().

Scope and Non-Goals This document specifies verification and conformance for records that other layers already produce. It does NOT define identity, authorization, or delegation semantics (which are the province of the OAuth and WIMSE work the auditing architecture builds on), nor attestation of execution environments (RATS ), nor a transparency service (SCITT ), nor a new record format. Artifacts of those layers appear here only as slot contents and evidence inputs; nothing in this document modifies their semantics. It defines only how composed records are verified and how that verification is tested.

Conventions and Definitions 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.

Accountability record:

A signed statement, in some profile, describing one party's part of an agent action — for example an Action Record , a delegation record, or an authorization-transition record .

Slot:

A claim type within a composition — the kind of thing a record proves (permission, delegation, conduct, enforcement). A slot is a claim type, not a deployment unit. See .

Slot semantics:

The small canonical vocabulary of what a given slot may conclude, defined once, with the slot, by the composition model. See .

Slot mapping:

A registered, enumerated function from one profile's own vocabulary to the slot semantics of the slot that profile fills. See .

Composition:

A set of accountability records, one or more per slot, joined by reference under a composition manifest, from which an aggregate audit disposition is derived.

Composition manifest:

The declared statement of what a composition requires: the required slots, which party is expected to fill each, the controlling order, the cross-party shape () where slots span parties, and the total derivation function for the aggregate disposition.

Conformance vector:

A frozen, byte-pinned input with its expected verification result, classified positive, negative, or must-fail.

Cross-record predicate:

A relation that holds between records and cannot be established from any single record alone (for example, that a credential subject and a protected-action actor identify the same actor).

Refusal (of a verifier):

The verifier outcome in which no disposition is produced and a defect is reported instead. A refusal is distinct from a mismatch (a produced result that differs from the expected one); must-fail vectors require refusal, not mismatch ().

Relationship to Other Work This methodology composes existing building blocks; it does not redefine them.

• Payload binding. How any record's payload is canonicalized, digested, and referenced by another record is defined by (CPB). This document assumes CPB for all binding; tier 1 of the conformance model is CPB conformance.
• The auditing architecture. supplies the roles, the record types, and the Auditor whose verification this document specifies and makes testable. This document is intended to slot into that architecture as its composition-verification work item ().
• Record profiles. Individual record types are defined by their own profiles — the Action Record by , user-facing interaction records by , and others. This document defines the conformance discipline those profiles reuse, so that conformance is specified once, horizontally, rather than reinvented per record type.
• Composition. defines what composes (the slots and the join). This document defines how a composition is verified and how that verification conforms.
• Transparency and attestation. and make individual records non-repudiable and authentic; this document is orthogonal to and composes with both. Where the architecture profiles those substrates for auditing (its WI-6 and WI-7), this document consumes the profiled results as evidence about individual records and adds nothing to either substrate.

Relationship to the Composition Model and this document are a matched pair: a model and a method. That document defines what composes — the slots (CAN, WHO, WHAT, AUDIT), the shared action-digest that joins them, the binding seam, and the standing invariants a conforming composition MUST preserve, among them that "two independent implementations must agree." It states those invariants; it does not specify how they are tested. This document supplies the missing how: the conformance-vector discipline (), the determinism boundary (), and the deterministic derivation () that make each invariant testable and each composition vector reproducible rather than hand-authored. The cross-verification vectors already produced against that model — an authorization-record-to-action-record pair joining a CAN profile to a WHAT profile — are the first composition (tier-3) instances governed by the method defined here. The two documents evolve independently: the composition document changes what composes; this document changes how a composition is verified.

Position in the Architecture's Work-Item Structure Section 6 of enumerates eleven potential work items, WI-1 through WI-11. Each supplies a part this document depends on or composes with, and none covers composition verification. WI-1 gives the four record types their canonical structure — the records this method verifies. WI-3, WI-4, and WI-8 profile three of the record types; in the terms of this document, their owners are tier-2 vector authors (). WI-6 and WI-7 profile the attestation and transparency substrates that make individual records authentic and non-repudiable — evidence this method consumes, not produces. WI-9 gives the Auditor a query surface over the Audit Store and Transparency Log — how the records reach the Auditor. What no enumerated item covers is what the Auditor does once the records are in hand: establishing, deterministically and testably, that the composed set is consistent and that the audit conclusion follows from it. This document proposes that work item. Stated in the architecture's own work-item style:

• WI-12: Composition Verification and Conformance. A profile-agnostic method by which an Auditor (Section 4.3 of the architecture), given records of the WI-1 record types together with the receipts and attestation results that bind them, deterministically verifies cross-record consistency — binding resolution, cross-record predicates, and a controlling composition manifest — and derives the aggregate audit disposition; together with a conformance-vector discipline (positive, negative, and must-fail cases; derivation rather than assertion) by which implementations of that verification are themselves tested. This item defines no record format, no identity or authorization semantics, and no transparency or attestation mechanism; it consumes the outputs of WI-1 through WI-8 and is exercised over the access surface of WI-9.

The Auditor's duty as the architecture states it — determining "whether recorded behaviour matched the User's intent and the authorization in force" — divides into a mechanically checkable part and an irreducibly semantic part. This document specifies the mechanical part and requires the semantic part to be expressed as explicitly defined predicates before it can influence a verification result (). Nothing semantic is decided implicitly.

Mapping to Audit Record Types The record types of are slots in the sense of this document. Informally:

Audit architecture record type	Slot (claim type)	Example profile
Interaction Record	intent / human-in-the-loop
Action Record	conduct (what was done)
Delegation Record	delegation	(per the architecture)
Authorization Transition Record	permission over time	(per the architecture)

The conformance methodology in this document is identical across these slots; only the per-slot vectors (authored by each profile's owner) differ.

The Three-Tier Conformance Model Conformance is organized into three tiers with distinct owners and distinct change cadences.

1. Binding conformance (tier 1). Does an implementation canonicalize, digest, and reference correctly? This is profile-agnostic and is defined entirely by CPB . Every record, in every slot, binds the same way and is tested by the same vectors.
2. Per-slot conformance (tier 2). Does a record of a given profile verify correctly on its own — its own semantics and its own must-fail cases? Per-slot vectors are authored and owned by each profile's owner, using the discipline of . The registered artifacts of this tier are the profile's entry for the slot it fills and its slot mapping ().
3. Composition conformance (tier 3). Does a declared composition of records verify correctly — do the cross-references resolve, do the cross-record predicates hold, and does the aggregate disposition derive correctly? Tier-3 vectors are, as specifies, derived from tiers 1 and 2 plus a manifest and predicate set rather than hand-authored.

Registries for the three tiers are kept distinct so that a change in one does not silently invalidate another. [Registry structure TBD in a future revision.]

The Determinism Boundary A precise boundary separates what a verifier can derive mechanically from what must be defined as semantics. Drawing it explicitly is the core contribution of this document. Composition verification is a function. Its inputs are: the record bytes of the composition; the composition manifest; the definitions of the cross-record predicates the manifest invokes; and a pinned snapshot of the registered artifacts in force (profiles, slot mappings, and vocabularies, each identified by version). Its outputs are the per-check results and either the derived aggregate disposition or a refusal. The function MUST be deterministic: two conforming implementations given byte-identical inputs MUST produce identical outputs. No input may be the output of a non-deterministic process evaluated at verification time; in particular, no model output enters the function except as record bytes under verification. Anything not derivable from these inputs is outside the verification result. Mechanically derivable (deterministic given the inputs):

• Binding of a composition. Given the individual records (tier 2) and the CPB typed-reference rules (tier 1), whether each cross-reference resolves is a pure recomputation: recompute the referenced record's derived identifier and compare. Positive and negative binding vectors for a composition are generable directly.
• Aggregate disposition, given a manifest. Given the individual records' verdicts and a composition manifest that states the required slots, the controlling order, and the derivation rule, the aggregate disposition is a pure function of those inputs. An ACCEPT disposition requires every required slot to satisfy its manifest-defined success condition; a non-success disposition may result from the failure, uncertainty, or non-eligibility of any required slot; and no single record's own verdict determines the aggregate. The signed result MUST bind the deterministic derivation, not restate a hand-written conclusion.

Irreducibly semantic (must be defined, not derived):

• Cross-record predicates. Relations that exist only between slots — for example that an integrity-protected credential subject and a protected-action actor identify the same actor — are not present in any single record and cannot be derived from the slots alone. They MUST be defined. Once defined as deterministic checks, their vectors are generable.
• Slot semantics and slot mappings. What a slot may conclude, and how a given profile's vocabulary maps onto it, are semantic declarations (). Once declared and registered, applying a mapping is mechanical.
• Preconditioned coincidences. Two independent constructions may agree only under a stated precondition and fail silently outside it. Such a coincidence is a valid conformance claim only when expressed as a frozen vector whose preconditions are stated as explicit conjuncts and checked in both directions (see ). For example, an independent construction that digests an RFC 8785 (JCS) serialization under SHA-256, but does not apply an exclusion set, does not apply absent-field normalization, and does not guard against digest-bearing floating-point or out-of-safe-range integer values, coincides with the canonical construction only when a payload carries none of those cases — three conjuncts, the third of which is not implied by the first two. Stating the coincidence over positive cases alone, while a must-fail case that one side refuses and the other accepts sits within the same suite, is precisely the silent failure this discipline forbids. This is not hypothetical: it is the observed result of running an independent agent-action construction against the canonical vector suite.
• Totality of the derivation function. A deterministic generator exists only if the aggregate-disposition function is total (defined for every combination of slot verdicts, including empty and absent required slots). Specifying that totality is semantic work. [The composition derivation function is specified as total in in a future revision; this document depends on that property.]

Conformance-Vector Discipline A conformance suite for any tier obeys the following, which any record profile reuses:

1. Two-sided vectors. A suite carries positive vectors (a well-formed record MUST verify) and must-fail vectors (a specified defect MUST cause the verifier to refuse, not merely mismatch). A suite that checks only for mismatch would pass a verifier that never refuses anything.
2. Attributed divergence, both directions. Every divergence between two constructions, or between a mutated and a reference vector, MUST be attributed to a declared rule or step. An unattributed divergence is a hard failure. So too is an agreement on a vector where a declared step should have changed the bytes: a silent agreement where a difference was expected is as much a failure as an unexplained difference.
3. Mutation-probe self-test. For each must-fail category, the suite generates the condition-removed mutant and asserts the verifier flips to failure on it. A check whose condition-removed mutant still passes is reported assertion-free and fails conformance. Every category MUST register such a probe or the suite refuses to count it as exercised.
4. Cross-construction coincidence rule. A claim that two constructions coincide is valid only as a frozen vector stating all preconditions as explicit conjuncts, with must-fail rows included in the biconditional check. A coincidence asserted over positive rows only is not evidence.
5. Derived provenance. Every frozen vector carries its provenance: the pinned inputs and rule versions it was produced from and, for derived (tier-3) vectors, the generator that produced it. An expected result is always the output of the deterministic derivation or verification of this document — never an assertion, and never the unverified output of any assisting tool ().

Deriving Composition Vectors Tier-3 vectors are a pure function of four inputs: the CPB binding rules; the individual-record (tier-2) vectors and their verdicts; a composition manifest (required slots, party attribution, shape, order, and the total derivation function); and the set of cross-record predicates. A generator over these inputs emits the combination vectors, their expected results, and their mutation probes, deterministically. When a tier-1 or tier-2 input changes, the affected composition vectors are regenerated, not re-authored; their provenance is the generator plus the pinned inputs. Only declared compositions (those named by a manifest) are generated; the method does not enumerate the full power set. [The generation algorithm, its input schema, and the manifest format are specified in a future revision.] walks one composition — a CAN-slot record paired with a WHAT-slot record — through the checks this method requires, with a positive, a negative, and a must-fail vector.

Assisted Authoring (Non-Normative) Enumerating the cases a suite should exercise is, in part, a judgement task — for both per-slot semantic vectors (tier 2: the positive, negative, edge, and must-fail cases a single profile's semantics should cover) and the cross-record predicate library and composition vectors (tier 3). Such candidates MAY be drafted with the assistance of automated tools, including machine-learning models, given as input the profile's registry snapshot and invariants, its enumerated must-fail categories, and the determinism boundary of . Any such candidate is only a proposal, and three closures keep it one:

1. A candidate's expected result MUST be assigned by running it through the deterministic derivation and verification of this document, and only that deterministic result is frozen as a vector.
2. A candidate on which the deterministic derivation is undefined is out of domain and MUST be rejected, not adjudicated — neither the proposing tool nor any other model may supply the missing result.
3. A vector's provenance (, rule 5) records the derivation and its pinned inputs. A vector whose expected result cannot be traced to that derivation is not a conformance vector, whatever proposed it.

A model proposes candidates; the pinned rules decide. This is deliberately the same shape as the accountability records this method verifies. An agent proposes an action; a deterministic gate, or a human in the loop, disposes of it; and the disposition — not the proposal — is what is recorded and later verified. Assisted vector authoring inherits that discipline exactly: the model's proposal is never the authority, and every frozen expected result is derived or confirmed, never asserted. [Guidance on the generator inputs — the registry snapshot, the invariant set, and the must-fail taxonomy a model should be given — is expected in a future revision or companion.]

Cross-Party Composition The compositions that matter most to cross-organization auditing are those whose slots are filled by different parties. A bilateral exchange is the canonical case: two organizations each sign their own attestation over the same action — joined, as in any composition, by the shared action-digest — and neither holds the other's records. This raises questions a single-party composition does not, and this method treats them as first-class.

What a Conforming Slot Record Is Cross-party composition turns on what "conforming" means for a slot, so this section fixes it. A record conforms to a slot when both of the following hold:

1. it is a well-formed instance of some profile registered for that slot, verified under that profile's own tier-2 semantics; and
2. its slot-relevant values map, under that profile's registered slot mapping (), to the slot's canonical semantics.

The canonical semantics of a slot — the small vocabulary of what that claim type may conclude — is owned by the composition model : one vocabulary per slot, defined with the slot, never per profile. This document does not restate those vocabularies and does not depend on their particular contents; it requires only that each slot have such a vocabulary and that each profile map onto it. Illustratively, a CAN slot might conclude one of {authorized, denied, conditional} and a WHAT slot one of a verdict-complete disposition set; the authoritative vocabularies are whatever the composition model defines. Profiles and their mappings are registered per slot in the tier-2 registry () — the single-slot registry, in the composition model's terms. [The registry structure, including the mapping entry format, is TBD alongside the registry work noted in .] "A conforming CAN," then, is not any one profile's notion of authorization; it is any registered authorization profile whose verdict maps to the shared CAN semantics — which is exactly what lets a CAN from one party compose with a differently-profiled CAN from another.

Slot Mappings Make Heterogeneous Profiles Comparable Two parties need not use the same profile for the same claim type — one side's authorization record may be in one profile and the other side's in another. Verifying each per its own profile (tier 2) is necessary but not sufficient: to compose, a verifier must establish that the two assert the same thing at the slot level, and two profiles are two vocabularies — left unreconciled, they are two languages that only appear to agree. Comparability is provided by the slot's canonical semantics together with a slot mapping registered by each profile. A slot mapping MUST be:

• Enumerated. An explicit, finite list of (profile value, slot value) pairs — never computed heuristically, inferred from lexical similarity, or supplied at verification time. A profile value absent from the list is unmapped.
• Registered and versioned. Part of the profile's tier-2 registry entry for the slot it fills, pinned by version in the registry snapshot that is an input to verification ().
• Frozen and tested. A testable artifact under : positive vectors for each mapped pair, a must-fail vector for an unmapped value, preconditions stated as explicit conjuncts, and the biconditional checked in both directions including the must-fail rows.

Two heterogeneous records in one slot are then compared through their mappings into the common slot semantics, never against each other's raw vocabulary: a verifier maps each record's slot-relevant value under that record's own registered mapping and compares the images in the slot vocabulary. All slot-success conditions in a manifest are expressed over the slot vocabulary, so the same manifest governs any admissible pairing of profiles. An unmapped value fails closed at the composition tier: a value with no registered mapping is unrecognized and MUST NOT satisfy any slot-success condition, because it cannot be shown to mean what the condition requires. This is disposition-level fail-closure, and it is consistent with — not in tension with — the open-vocabulary posture of existing record profiles, under which an unknown vocabulary value is reported as an informational finding rather than invalidating the record. The two rules govern different tiers: an unmapped value does not make the record non-conforming at tier 2, and it does not contribute success at tier 3. Unknown is tolerated as content and rejected as evidence; unknown never grades up. Profile heterogeneity across parties is thus permitted — and made verifiable — by the slot mapping, not by forcing every party onto one profile.

Party Attribution and the Controlling Manifest Two further rules apply when slots span parties:

• Slots may be attributed to distinct parties. A composition manifest MAY state which party is expected to fill which slot. The shared action-digest is what makes the cross-party join verifiable without either party's cooperation at verification time.
• The parties may hold different manifests. When each side has its own view of what the composition requires, the controlling manifest MUST be identified, and it is an input to verification — never an output. A verifier MUST NOT let a party unilaterally satisfy a required slot the controlling manifest attributes to the counterparty, nor treat a slot absent on one side as satisfied because the other side supplied a different one. Reconciling divergent manifests is a cross-record predicate () and MUST be stated, not assumed.

The Two Cross-Party Shapes Two cross-party shapes are distinguished, because they compose differently and MUST NOT be silently interchanged:

• Mutual attestation — a common understanding. Each party attests its own side and, through the slot mappings, is verified to understand the other's; together they form a joint record both are bound to — in effect a contract about what happened. The aggregate disposition is joint: it derives from both parties' slots under the controlling manifest, and the completed acknowledgment pair of the bilateral exchange () binds each party to the other's attestation. Graceful-degradation and reduced-assurance markings carried by the underlying exchange are preserved into the derivation as inputs, never discarded or upgraded.
• Cross-organization acknowledgment. A party records that it observed or acknowledged the other party's action, without forming a mutual contract. This is the weaker binding, and deliberately so: consistent with the bilateral exchange's definition of acknowledgment as receipt rather than assent, the acknowledgment is a cross-record predicate over the counterparty's record, but it does not, by itself, make the acknowledging party co-responsible for a disposition it did not assert.

The shape is declared by the controlling manifest and is an input to the derivation function; a verifier MUST NOT infer the shape from the records themselves. A manifest that requires mutual attestation is not satisfied by an acknowledgment, however well-formed: a verifier presented with acknowledgment-shape records under a mutual-attestation manifest MUST treat the mutual-attestation slots as unsatisfied. The two shapes derive different aggregate dispositions from the same underlying action, which is precisely why substituting one for the other must be structurally impossible rather than merely discouraged.

Relationship to the Bilateral Base The bilateral attestation exchange is the base this section builds on, and this document changes nothing in it: the four-move exchange (request attestation, constraint evaluation, action attestation, acknowledgment), the binding obligations, the acknowledgment-is-receipt semantics, and the reduced-assurance marking are used as defined there. The correspondence is direct: a completed bilateral exchange — both attestations, both acknowledgments — is the canonical instance of the mutual-attestation shape, and an acknowledgment without a counterpart attestation instantiates the acknowledgment shape. Where that exchange degrades gracefully, the reduced-assurance indicator it records enters the derivation here as a slot input; this document adds no second marking scheme. What this section adds is one generalization, at the composition tier only: the two sides of an exchange MAY fill their slots with different registered profiles, reconciled through the slot semantics and slot mappings of rather than required to share a vocabulary. Where both sides use the base exchange's shared disposition vocabulary, both mappings are the identity and this section adds nothing — the homogeneous case is the special case, not the rule. Heterogeneous parties are the general case this method is built for. Run-time protocols that reconcile heterogeneous per-party attestations into a single disposition are consumers of this method: the reconciled result is itself a composition, conformant only if it derives from the parties' records under a stated controlling manifest and the predicates above. [The manifest-reconciliation rules and the reduced-assurance composition cases are specified in a future revision.]

Cross-Layer Composition The cross-party compositions of join records held by different parties. A second axis joins records produced at different layers of one party's stack: an execution-environment attestation (RATS , the auditing architecture's WI-6), a model or reasoning attestation, and the action record a party emits for the same action. Each is a distinct claim about the same event — the environment it ran in, the model that produced the proposal, and what was ultimately done — and each is produced and signed independently. This is composition in exactly the sense of this document. The layer records are joined by the shared action-digest and an aggregate disposition is derived from them under a manifest, using the same determinism boundary (), the same conformance-vector discipline (), and the same derivation () as any other composition. The layer attestations enter only as slot contents and evidence inputs; this document adds nothing to RATS or to any attestation format, exactly as states. What it adds is the ability for an independent party to verify not merely that an agent took an action, but that it did so on an attested environment, with an attested model — a deeper accountability claim, checkable down to the layer that produced it. Cross-layer composition is deliberately independent of whether any cross-party or cross-profile composition is present. A single party whose stack is one coherent profile still composes these layers, and this method verifies that composition without requiring a second party or a second profile. Where the architecture profiles the attestation and transparency substrates (its WI-6 and WI-7), this work item is what binds their results to the WI-1 record types and derives a disposition over the bound set. [A manifest profile for the environment/model/action layers is specified in a future revision.]

Security Considerations The verification specified here inherits, and does not replace, the authenticity and non-repudiation properties of the underlying attestation and transparency layers. A verifier MUST fail closed: an unrecognized or unestablished value MUST NOT satisfy a predicate or slot-success condition required for a successful disposition (). Because the manifest and the registry snapshot are inputs to verification (), substituting either substitutes the verification result; a manifest or snapshot MUST therefore be identified by digest in any signed verification result, so that two parties disputing a disposition can first establish whether they verified against the same inputs. Shape substitution — presenting acknowledgment-shape records against a mutual-attestation requirement — is prevented structurally by . [Full threat model, including manifest substitution and predicate-omission attacks, TBD in a future revision.]

Privacy Considerations Conformance vectors are synthetic by construction and carry no production content. Verification operates over digests, not payloads, and therefore inherits the content-privacy posture of the record profiles it checks. [Correlation considerations for composition manifests TBD.]

IANA Considerations This document will request registries for cross-record predicates and for composition manifests in a future revision. This -00 has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Action State Group Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly re-derive the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, a receipt placed in the unprotected header of the Signed Statement, and a typed reference mechanism that lets one record cite another by digest across profile boundaries. This document defines that construction as a reusable profile — the Canonical Payload Binding — so that each payload class declares its canonicalization algorithm and exclusion set once, obtains an interoperable derived identifier, and inherits statement-to-receipt binding and typed digest reference semantics without restating the mechanics in every profile. IANA registries govern both the canonicalization algorithms and the artifact types that may appear in typed references; entries are immutable. Informative References Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additonal logging for transparency. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are expressed as SCITT Signed Statements (COSE_Sign1) and made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Action State Group, Inc. MyAuberge K.K. Independent EMILIA Protocol, Inc. Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. Action State Group, Inc. When an agent operated by one organization requests a consequential action from an agent operated by another, today's record of that exchange — if one exists — is kept by one side, editable by that side, and deniable by the other. Disputes reduce to my-log-versus- your-log. This document describes a bilateral attestation exchange for such actions: the requesting organization signs a request attestation binding it to the action and its material terms; the performing organization evaluates the request against deterministic constraints at the boundary where the action takes effect and signs an action attestation recording the constraint results and the disposition — performed, declined, or escalated to a human — by reference to the request; and each party acknowledges the other's attestation. The combined record binds each organization to its part, gives each proof of the other's, and can be anchored to a transparency service so that a third party who trusts neither organization can verify the record end-to-end. The exchange records refusals with the same fidelity as performance, and degrades gracefully when a counterparty cannot attest, marking the record's reduced assurance rather than blocking the transaction. Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON.

A Worked CAN-and-WHAT Composition (Informative) This appendix walks one two-slot composition through the checks this method requires. It is synthetic: the profiles, vocabularies, and values are invented for this appendix and carry no production content. The composition follows the CAN/WHAT seam of : a pre-action authorization record (CAN slot) is cited by digest from a post-action record (WHAT slot). Slot semantics (illustrative; the authoritative vocabularies are the composition model's): the CAN slot concludes one of authorized, denied, conditional; the WHAT slot concludes one of the verdict-complete dispositions, of which this example uses executed and blocked. Profiles and mappings (tier-2 registry entries):

• Profile can-x fills the CAN slot. Its own verdict vocabulary is {granted, rejected, granted_with_conditions}; its registered slot mapping is the enumerated list: granted maps to authorized, rejected maps to denied, and granted_with_conditions maps to conditional.
• Profile what-y fills the WHAT slot. Its own outcome vocabulary includes {completed, refused}; its registered slot mapping sends completed to executed and refused to blocked.

Manifest M-1: required slots CAN and WHAT; CAN is the parent (controlling order: the WHAT record cites the CAN record); a single party fills both slots, so the cross-party rules of are not exercised here; one cross-record predicate, P-1; derivation function D: the aggregate disposition is accept if and only if the binding check, P-1, and both slot-success conditions hold, where CAN slot success is authorized and WHAT slot success is executed; every other defined combination derives a named non-accept disposition attributing the earliest failed check. D is total over slot verdicts, including absent slots. Predicate P-1 (same actor): the byte string in the CAN record's subject field equals the byte string in the WHAT record's actor field. (A deliberately minimal identity rule; a real predicate library would define equality with more care. The point is that the rule is stated, deterministic, and checked — not assumed.) Records (payload sketches; digests abbreviated): The verification walk, in order:

1. Binding check (tier 1). Recompute the CAN record's derived identifier under its registered digest context (CPB ) and compare it with the digest carried in the WHAT record's authority typed reference.
2. Per-slot checks (tier 2). Each record verifies under its own profile's semantics and must-fail categories.
3. Mapping check. Map each record's slot-relevant value under its registered slot mapping; an unmapped value fails closed ().
4. Predicate check. Evaluate P-1 over the two records.
5. Aggregate derivation. Apply D to the mapped slot verdicts and check results; compare the derived disposition with the vector's frozen expected result.

Three vectors derived from these inputs:

Vector	Contents	Expected result
V-POS	Records as above: granted / completed; binding digest matches; P-1 holds	Derivation yields accept; every check attributed
V-NEG	Identical, except authority.digest carries the derived identifier of a different CAN record	Non-accept disposition attributed to the binding check (step 1); later checks still evaluate, per D's totality
V-MF	Identical to V-POS, except the CAN verdict is approved — a token with no entry in can-x's registered mapping	The verifier refuses: it reports the unmapped token and produces no accept; the CAN slot-success condition is unsatisfiable (). A run that instead produced a disposition merely mismatching the expected one would fail the suite

Mutation probes (rule 3 of ): for V-MF, the condition-removed mutant replaces approved with granted; the verifier MUST flip to accept on the mutant, demonstrating that the refusal was caused by the unmapped token and not by an unrelated defect. For V-NEG, restoring the correct digest must likewise flip the result to accept. Both directions (rule 2): a second, independent implementation run over the same three vectors must agree on all three results; any divergence must be attributed to a declared rule, and an agreement on a vector where a declared step should have changed the outcome — for example, both implementations accepting V-MF — is equally a hard failure. Everything in this walk is a pure function of the pinned inputs: the two records' bytes, M-1, P-1, and the registry snapshot carrying the two profiles and their mappings. Regenerating the three vectors from those inputs reproduces them byte-for-byte; that reproduction, not this prose, is their provenance.

Acknowledgments This work builds on the architecture for auditing agent delegation and interactions and composes with the SCITT, RATS, and agent-accountability communities. Cross-implementation conformance runs by independent implementers surfaced the precondition and hand-written-disposition failure modes this document is designed to make impossible.