]> Independent

npgovintarajan@gmail.com

Action State Group, Inc.

steven@actionstate.ai

Security SCITT agent capsule model_attestation runtime provenance This document defines the model_attestation block of the Agent Action Capsule (AAC) profile — referenced twice by the base profile but never defined there — and, within it, the compute_attestation container that already carries runtime extensions in the field: the model-serving runtime, the agent's own execution environment (architectural pattern, orchestration framework, sandbox confinement, invoked tool version), and host hardware, together with model and weights claims. Every claim carries an explicitly declared source; a verifier grades claims by how they were observed and never infers a stronger grade than the evidence supports. Hardware or platform attestation, when present, is cited by content-addressed reference to a foreign attestation record and verified with that record's own verifier.

Introduction An agent action recorded in an Agent Action Capsule (AAC) is executed by a model running within a specific model-serving runtime, itself invoked by an agent process in a specific execution environment, on host hardware. Two capsules recording nominally identical actions can differ in what actually happened depending on model checkpoint, quantization, sandbox confinement, or the version of a tool package the agent invoked; without a record of that environment, a forensic reviewer cannot tell a model-drift event from a compromised tool from an unconfined sandbox. The base profile records the action, seals it under canonicalization , and MAY register its Capsule ID as independently transparent to a SCITT Transparency Service; the agent-domain checks defined by the base profile are verified independently of that registration, by a Class 1 or Class 2 verifier, from the record's own bytes. Its epoch mechanism records baseline configuration shifts across actions. Although the base profile references a model_attestation block, it does not supply a formal definition. Two constraints matter. First, this extension is payload-extension-only: model_attestation lives in the Capsule JSON like every other payload member — the base profile's Section "Extensibility" states that all Capsule extension points are in the Capsule JSON — and it does not touch the Producer Envelope's protected header, which the base profile's Section "Producer Envelope wire profile" holds closed to exactly three entries (Section 3.1). Second, this extension MUST NOT change the base profile's Class 1 or Class 2 verification model (Sections 6 and 8.2); a verifier that does not implement it treats the block as informational (). This extension also imposes no mandatory transport dependency; it is silent on how a Capsule is delivered. model_attestation is a bare top-level payload member name, not a namespaced one. This follows from a fact specific to this field: the base profile already refers to model_attestation by that exact bare name, twice, without defining it (in its epoch-boundary Capsule section and in its Security Considerations), so the name is already reserved by the base profile itself rather than being minted here. This document supplies the definition for a name the base profile already uses, rather than introducing a new namespaced member. This document defines the model_attestation block, generalizes it to per-action use, and formalizes the model-serving runtime, agent execution environment, and hardware facts producers observe — all within the compute_attestation container (). The block is sealed directly inside the Capsule payload and participates in derived identifier generation (capsule_id). The core design principle is honesty of source. A model name reported by the runtime is a claim; a weights digest computed over a loaded file is a stronger claim; a measurement signed by a hardware root of trust is stronger still. They represent distinct facts, and the record states which one it holds. A verifier that cannot resolve a claim to its stated source MUST report it as unresolved, MUST NOT report it as verified, and MUST NOT upgrade an unknown grade to a known one. This block complements rather than replaces the base profile's epoch machinery: it records per-action claims in force for an action while remaining scoped to the active epoch and prevailing epoch-boundary Capsule. model_id is RECOMMENDED, not REQUIRED, in : the epoch-boundary Capsule already records the model transition, and an extension MUST NOT out-mandate its base.

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. Capsule, Producer Envelope, epoch, epoch-boundary Capsule, epoch_id, derived identifier, typed digest reference, and data-admission tiers are used as defined in and . Attester, Verifier, and Evidence are used in the sense of where foreign platform attestation is discussed.

Source label:

A standardized vocabulary declaring how a claim's value was obtained: self_reported (asserted by executing software), provider_reported (returned by a remote model provider or serving API and preserved by the producer without alteration), os_reported (reported by the host operating system), computed (calculated by the producer from bytes it held), or attested (cryptographically bound inside a verifiable foreign attestation record). Additional labels MUST be namespaced.

Every source map in this document (at the model_attestation level and within each compute_attestation sub-object) follows the same default: if the map is omitted, or a field has no entry in it, a verifier MUST treat that field's source as self_reported. This rule is stated once here and applies wherever a source field appears below; it is not restated per sub-object.

The model_attestation Block A Capsule payload MAY carry a member named model_attestation. The block participates in the derived identifier like every payload member: it is canonicalized under JCS and covered by capsule_id. A verifier that does not implement this extension MUST ignore it for verification and MUST NOT fail a Capsule solely because it is present.

Field	Type	Req	Meaning
model_id	string	RECOMMENDED	See .
provider	string	OPTIONAL	See .
model_revision	string	OPTIONAL	See .
weights_digest	object	OPTIONAL	See .
quantization	string	OPTIONAL	See .
decoding	object	OPTIONAL	See .
source	object	OPTIONAL	Field to source label mapping; see above for the omitted-entry default.
compute_attestation	object	OPTIONAL	Container for runtime/compute facts ().
epoch_consistency	string	OPTIONAL	consistent, inconsistent, or unknown ().

Model Members These members define the core model assertions referenced by the base profile's epoch section. They MAY appear in any Capsule and SHOULD appear in every epoch-boundary Capsule.

Field	Type	Req	Permitted Sources	Meaning
model_id	string	RECOMMENDED	self_reported, os_reported, attested	Model name as reported by the runtime.
provider	string	OPTIONAL	self_reported, attested	Model provider or serving system.
model_revision	string	OPTIONAL	self_reported, attested	Provider- or repo-assigned revision.
weights_digest	object	OPTIONAL	computed, attested	{digest_alg, digest, scope} over loaded weights.
quantization	string	OPTIONAL	self_reported, computed, attested	Quantization label (e.g., Q4_K_M).
decoding	object	OPTIONAL	self_reported	Hyperparameters {temperature, top_p, seed}.

For weights_digest, scope MUST be either file (digest over serialized model bytes as loaded from storage) or tensors (digest over in-memory tensor structures, admissible only under attested). A digest of a reference string (e.g., a HuggingFace URI) MUST NOT be carried in weights_digest; such identifiers belong in model_id.

Verification Grade Semantics A verifier MAY derive grades according to the following matrix, never exceeding what source and accompanying evidence substantiate:

Record Fact	Verifier May Report
model_id only	model: self-reported name
weights_digest (scope: file, computed)	model: file-identified (recomputable)
weights_digest (attested via )	model: attested at declared scope
quantization (self_reported)	quantization: claimed

A verifier MUST NOT report "model attested" from model_id alone, and MUST NOT report "quantization verified" from any field in this block, as none of these fields establish which underlying arithmetic was executed. Detection of substituted models or quantizations is out of scope for this record and belongs to redundancy or referee mechanisms at the system level.

The compute_attestation Container compute_attestation groups environment observations into five sub-objects: runtime (, the model-serving runtime), agent_runtime (, the agent's own execution environment), invocation (, what the model provider or serving API reported about this call), hardware (), and attestation_refs (), plus any namespaced member owned by another specification (for example x-mesh-lifecycle-v1, host_binding). runtime and agent_runtime are deliberately distinct: runtime describes the process that served the model's inference (for example, a local inference server or hosted serving stack); agent_runtime describes the process that orchestrated the action — the agent loop, its sandbox, and the tool it invoked — which may be a different process, on different infrastructure, than the one that served the model. A verifier MUST ignore members it does not recognize. A member MUST be absent rather than null when its fact is unavailable.

compute_attestation.runtime

Field	Type	Req	Meaning
name	string	RECOMMENDED	Serving binary name and version.
runtime_digest	string	OPTIONAL	Digest of the serving binary as measured.
measurement_class	string	RECOMMENDED*	Class of measurement (*when digest present).
platform_integrity	object	OPTIONAL	OS integrity bits (e.g., SIP, Secure Boot).
source	object	OPTIONAL	Field to source label mapping; see above for the omitted-entry default.

Standard measurement_class values include self_measured, os_measured, tpm_measured, app_attested, mda_measured, and tee_measured. Field status at the time of writing: self_measured and os_measured are produced by shipping code; tee_measured has a record shape and verifier with real Intel TDX vectors; tpm_measured, app_attested, and mda_measured are named here so that the vocabulary is fixed before their producers exist. Unknown classes MUST be treated as unrecognized, never ordered above known classes; the classes are sibling roots of trust and the ordering above is meaningful only within a single root.

compute_attestation.agent_runtime Where runtime () describes the process that served the model, agent_runtime describes the process that orchestrated the action: the agent loop or orchestration framework, the environment and confinement it ran in, and the version of any tool package it invoked to perform this specific action. This is the environment-blindness gap: two Capsules recording the same nominal action can behave differently depending on sandbox confinement or a tool package's version, and without this record a forensic reviewer cannot distinguish a compromised tool from an unconfined sandbox from a model-drift event.

Field	Type	Req	Meaning
agent_type	string	OPTIONAL	The agent's architectural pattern (e.g., single_agent, multi_agent_orchestrator, react, plan_execute, supervisor_worker).
framework	string	OPTIONAL	Agent orchestration framework or agent-loop implementation, name and version (e.g., langchain 0.3.1, custom-agent-loop 1.4.0).
runtime_env	string	OPTIONAL	Execution environment the agent process ran in, name and version (e.g., python:3.11-slim, node:20-alpine).
sandbox_type	string	OPTIONAL	Confinement mechanism isolating the agent process (e.g., gvisor, firecracker, wasm, unconfined).
tool_version	string	OPTIONAL	Version or content digest of the tool package this action invoked, when the action involved a specific tool.
source	object	OPTIONAL	Field to source label mapping; see above for the omitted-entry default.

agent_type names the architectural pattern the agent process implements for this action, not the specific framework instance (that is framework's job) or a claim about correctness. The seeded values above are illustrative, not exhaustive or registry-governed: single_agent (one model, one decision loop), multi_agent_orchestrator (a coordinating process dispatching to one or more sub-agents for this action), react (interleaved reasoning-and-acting loop), plan_execute (a separate planning phase precedes execution), and supervisor_worker (a supervisor process dispatches to worker processes it does not itself execute as). A value outside this list follows the same namespacing discipline as constraint id/check_type in the base profile's Section "Namespacing convention": bare names are reserved for the values seeded here, and a party introducing a new value MUST namespace it with a URI or reverse-DNS prefix. A verifier treats an unrecognized agent_type value as informational, never as a validation failure — this field is descriptive metadata, not a graded claim, and carries no source-grading matrix of its own beyond the standard self-reported default. sandbox_type: "unconfined" is itself an informative claim, not an absent field: a producer that knows its agent process runs unconfined SHOULD say so rather than omit the field, since the omission and the honest disclosure of no confinement are otherwise indistinguishable to a verifier. As with every field in this document, sandbox_type and framework are self-reported unless graded otherwise by source or corroborated by an attestation_refs entry (); a verifier MUST NOT infer actual confinement strength from the label alone; gvisor and firecracker name mechanisms with different isolation properties, and this document does not rank them.

compute_attestation.invocation Commercial and self-hosted model APIs commonly return invocation metadata in addition to the text or tool output. This sub-object preserves such provider or runtime facts without standardizing any provider-specific response object. Every value here is a claim about what the serving side reported for this call; none of it is a measurement of the serving environment, which is what and carry. All fields below are OPTIONAL.

Field	Type	Permitted Sources	Meaning
requested_model_id	string	self_reported	Model identifier the caller asked for.
resolved_model_id	string	provider_reported, self_reported, attested	Model identifier reported as actually serving the call.
service_class	string	provider_reported, self_reported	Provider or runtime processing tier. Values are provider-defined unless registered by another profile.
backend_fingerprint	string	provider_reported	Opaque provider-issued deployment or configuration identifier. A change-detection value, not a hardware attestation.
reasoning	object	provider_reported, self_reported	Declared reasoning configuration (mode, effort, summary policy). Raw chain-of-thought MUST NOT appear here.
usage	object	provider_reported, self_reported	Non-content counters: input, output, cached, and reasoning tokens.
finish_status	string	provider_reported, self_reported	Termination status: completed, incomplete, failed, or a provider-namespaced finish reason.
response_ref	object	provider_reported	Digest-only or pairwise reference to a provider response identifier, for later correlation. Raw provider request and response identifiers SHOULD NOT be disclosed across parties by default.
reasoning_state_ref	object	provider_reported	Typed reference or digest of an opaque provider-issued reasoning-continuity artifact, when one is returned. Treated as opaque; this document neither defines nor requires disclosure of internal reasoning.
source	object	—	Field to source label mapping; see Conventions for the omitted-entry default.

reasoning MAY carry configuration metadata such as mode, effort, summary, or a provider-namespaced equivalent. It MUST NOT carry hidden chain-of-thought text, and a verifier MUST treat any text-valued member of reasoning as a profile violation of the base profile's data-admission tiers. A provider-issued opaque reasoning or thought signature MAY be referenced through reasoning_state_ref when the producer needs to bind the exact state token that was returned. The field names describe semantics, not a vendor API. An adapter MAY preserve additional provider fields under a provider-controlled namespace, subject to the base profile's data-admission rules. resolved_model_id complements, and never replaces, model_id at the model_attestation level: the former is what the provider said it served on this call, the latter is the identity the producer records for the epoch.

compute_attestation.hardware

Field	Type	Req	Meaning
platform	string	OPTIONAL	Platform enum (e.g., intel-tdx, amd-sev-snp, apple-silicon).
accelerator	string	OPTIONAL	Accelerator or GPU name as reported.
memory_bytes	integer	OPTIONAL	Unified or accelerator memory in bytes.
inventory	object	OPTIONAL	Coarse CPU/firmware topology details.
source	object	OPTIONAL	Field to source label mapping; see above for the omitted-entry default. Hardware is os_reported at best without a corroborating attestation_refs entry.

Never-enters. Device serial numbers, platform UUIDs, MAC addresses, and other stable device identifiers MUST NOT appear in hardware, in clear or as a digest: they are stable identifiers of small effective entropy and re-identify a person's machine (base profile, "Data-Admission Tiers"). A producer that must later show "this was my machine" MAY carry a salted digest of such an identifier under an explicitly opt-in, namespaced field whose salt the producer retains; this document does not define that field.

compute_attestation.attestation_refs This document defines no attestation format. Where hardware or platform attestation exists, the Capsule cites it by a typed digest reference — {type, purpose, digest_alg, digest} — where type resolves in the shared Artifact Type Registry to the foreign record's declared digest context: Verification of a cited attestation record is performed by the verifier that record's issuer publishes, never by a re-implementation in this profile's verifier. The result feeds this block as follows:

• If the cited record verifies and binds weights_digest, runtime_digest, or platform measurement values equal to those carried here, the verifier MAY report those fields at source attested, at the grade the foreign verifier reports. A foreign verifier's intermediate grades MUST be carried through, not collapsed to a boolean.
• If the cited record does not verify, is absent, or binds different values, no field in this block is upgraded, and the verifier SHOULD report the citation as present-but-not-verified with the reason.
• A cited record MUST be carried byte-identically; it is never re-minted or re-signed by the Capsule producer.

Formal CDDL Specification The following CDDL grammar formally specifies the payload schema: tstr, ? "provider" => tstr, ? "model_revision" => tstr, ? "weights_digest" => weights-digest-claim, ? "quantization" => tstr, ? "decoding" => decoding-params, ? "source" => source-map, ? "compute_attestation" => compute-attestation-container, ? "epoch_consistency" => "consistent" / "inconsistent" / "unknown", * tstr => any } source-label = "self_reported" / "provider_reported" / "os_reported" / "computed" / "attested" / tstr source-map = { * tstr => source-label } weights-digest-claim = { "digest_alg" => tstr, "digest" => tstr, "scope" => "file" / "tensors" / tstr } decoding-params = { ? "temperature" => float / int, ? "top_p" => float / int, ? "seed" => int, * tstr => any } compute-attestation-container = { ? "runtime" => runtime-claims, ? "agent_runtime" => agent-runtime-claims, ? "invocation" => invocation-claims, ? "hardware" => hardware-claims, ? "attestation_refs" => [* foreign-attestation-ref], * tstr => any } runtime-claims = { ? "name" => tstr, ? "runtime_digest" => tstr, ? "measurement_class" => measurement-class-label, ? "platform_integrity" => { * tstr => any }, ? "source" => source-map } agent-runtime-claims = { ? "agent_type" => tstr, ? "framework" => tstr, ? "runtime_env" => tstr, ? "sandbox_type" => tstr, ? "tool_version" => tstr, ? "source" => source-map } invocation-claims = { ? "requested_model_id" => tstr, ? "resolved_model_id" => tstr, ? "service_class" => tstr, ? "backend_fingerprint" => tstr, ? "reasoning" => { * tstr => tstr / int / float / bool }, ? "usage" => { * tstr => uint }, ? "finish_status" => tstr, ? "response_ref" => { * tstr => any }, ? "reasoning_state_ref" => { * tstr => any }, ? "source" => source-map } measurement-class-label = "self_measured" / "os_measured" / "tpm_measured" / "app_attested" / "mda_measured" / "tee_measured" / tstr hardware-claims = { ? "platform" => tstr, ? "accelerator" => tstr, ? "memory_bytes" => uint, ? "inventory" => { * tstr => any }, ? "source" => source-map } foreign-attestation-ref = { "type" => tstr, "purpose" => tstr, "digest_alg" => tstr, "digest" => tstr } ]]>

Relationship to Epochs The base profile's epoch-boundary Capsule records a macroscopic configuration shift across a registry or agent lifecycle. This block records the configuration in force for one action. The two MUST NOT contradict: a Capsule whose model_attestation names a model different from the one the prevailing epoch-boundary Capsule opened is either a producer defect or an unrecorded epoch change, and a verifier SHOULD report epoch_consistency: inconsistent regardless of what the producer stated. A producer that populates epoch_id SHOULD carry this block in the epoch-boundary Capsule with source labels, so the transition is commit-addressed as the base profile intends.

Verification This extension adds no additional verification semantics beyond the base profile's Class 1 and Class 2 verifier checks (Sections 6 and 8.2 of ) on the sealed AAC record. When this extension is implemented, a verifier MAY apply the checks below.

1. Validate field shapes against and the source map; a field without a source entry is self_reported per .
2. For each entry in attestation_refs, resolve type per ; if resolvable and the record is available, invoke the issuer's verifier and record its result and grade.
3. Derive per-field grades per , never exceeding the stated source and the foreign verifier's result.
4. Report epoch_consistency from the ledger context when available.
5. Report unknown measurement_class or source labels as unrecognized, never as equal to or higher than a known class or label.
6. Treat agent_runtime fields () as self-reported by default and never infer confinement strength from sandbox_type's value; this document ranks no sandbox mechanism against another.
7. Treat invocation fields () labelled provider_reported as the provider's claim preserved by the producer: a verifier MUST NOT report a provider_reported value as computed or attested, and MUST NOT report resolved_model_id as establishing model identity on its own.

Relationship to evidence stores and epistemic typing A local evidence store MAY preserve these fields as evidence about the execution environment. The source labels in this document describe how a specific field value was obtained and are intentionally narrower than a general evidence taxonomy. An implementation that maps them onto a wider taxonomy SHOULD do so without silently upgrading them, for example:

• self_reported: a producer claim;
• provider_reported: a claim returned by a remote provider or API and preserved by the producer;
• os_reported: an observation attributed to an operating-system source;
• computed: a deterministic derivation over identified bytes; and
• attested: a claim supported by a separately verified attestation record.

Tool-call content, tool-call result content, prompt and context material, intentionally emitted rationale artifacts, human reports, semantic judgments, outcome adjudications, and regulatory obligation results are outside this block even when they concern the same action. They belong to separate records or extensions and may be linked by typed references.

Security Considerations All claims in this block outside of an independently validated attestation_refs record are assertions made by the Capsule producer. The function of this profile is not to make those claims true but to make them specific, signed, and non-repudiable under the AAC verifier acceptance path. A producer that later serves a different model than it claimed has signed the discrepancy. Claims about which arithmetic ran (quantization, precision) cannot be verified from any record the producer alone signs; systems that need that assurance obtain it by redundancy or hardware attestation, outside this document. The same honesty-of-source discipline applies to agent_runtime (): sandbox_type: "unconfined" is exactly as signed and non-repudiable as any other value, which is what lets a forensic reviewer later distinguish an unconfined sandbox that was disclosed from one that was silently omitted. A verifier MUST NOT round up: an unknown measurement_class, an unresolvable attestation_refs.type, or a source label it does not know is reported as unrecognized, never treated as the highest grade the verifier knows. This rule exists because the failure it prevents — a forged grade string accepted by an old verifier — is otherwise cheap.

Privacy Considerations Every field in this block is subject to the base profile's data-admission tiers (clear-safe, digest-only, never-enters) and its default-deny posture: producers and adapters MUST classify each candidate field before admission, and MUST NOT admit a field merely because this document does not mention it. model_id, provider, and decoding.seed are deployment or run parameters and clear-safe: they describe the model and its configuration, not a person. weights_digest and runtime_digest are digests of software artifacts and carry no end-user privacy exposure on their own; a producer MUST still ensure the artifact digested does not itself embed tenant- or user-identifying material — a model fine-tuned on a single tenant's private corpus is itself a sensitive artifact, and digesting it does not launder that sensitivity, so model_id and weights_digest for such a model are tier-appropriate to the tenant's own data, not automatically clear-safe. agent_runtime.agent_type, .framework, .runtime_env, and .sandbox_type are ordinarily deployment constants and clear-safe. agent_runtime.tool_version is clear-safe only when the tool package identifier or digest does not itself encode end-user or tenant-identifying information (for example, a tenant-named internal tool, or a per-tenant container image tag); a producer whose tool naming does so MUST treat the field as digest-only or omit it. A producer for whom agent_type, framework, runtime_env, or sandbox_type varies per end-user request or per tenant (for example, per-tenant sandbox images keyed to a customer) MUST re-evaluate that field's tier rather than relying on the clear-safe default stated here, since a per-tenant value is then itself a tenant-correlation handle. hardware.inventory is intentionally constrained to prevent device fingerprinting: device serial numbers, MAC addresses, platform UUIDs, and other persistent hardware identifiers MUST NOT appear in compute_attestation, in clear or as a digest, per . No field defined in this block is an end-user or session identifier at any tier; none should be added without also updating this section.

Implementation Status This section records the status of known implementations of this block at the time of posting, per . It is to be removed before publication as an RFC. Mesh-LLM capsule plugin (Apache-2.0, Rust and Python): a producer at the inference boundary of a peer-to-peer model-serving network. It writes compute_attestation.runtime with a SHA-256 digest of the serving binary and a measurement_class of os_measured where the host operating system can report it and self_measured otherwise, and records serving provenance (serving node, requesting party, token usage, generation parameters) under a namespaced member of compute_attestation. Quantization and hardware facts the host does not expose are recorded as absent, never fabricated. A name hash is recorded under a field name that says it is a name hash, after an earlier field name that overclaimed a weights binding was renamed. Its reference library reads model_attestation in its verifier, ledger, disclosure, and viewer paths. capsule-emit (Apache-2.0, Python): the reference emitter and verifier treats model_attestation.compute_attestation as the extension container for runtime and compute facts, and other extensions (for example the OpenTelemetry correlation block of draft-palanisamy-scitt-aac-otel) are placed there today.

Conformance Vectors This is a tier-2 (per-profile) extension in the sense of : it defines its own semantics and must-fail cases on top of the tier-1 binding conformance that (CPB) defines for every AAC payload member. This document is not itself a binding-layer artifact and does not register a type in the CPB Artifact Type Registry; that registry governs the type field of a typed digest reference — used here only by attestation_refs entries () — a different and narrower thing than a named payload extension like model_attestation itself. As of this writing, the registry structure for tier-2 (per-profile) conformance artifacts is explicitly not yet specified — states plainly that this is "TBD in a future revision." This document therefore cannot cite a settled registration procedure for itself, and does not assert one. What it does provide now, so that registration is a formality once the tier-2 registry exists rather than a rewrite, is the two-sided conformance-vector set that document's discipline (Section 5) requires of any record profile: positive vectors with pinned values, and must-fail vectors that a conformant implementation MUST refuse rather than merely mismatch. Positive vector (MUST be accepted, and graded per and without exceeding the stated source): MUST-FAIL vectors (a conformant verifier MUST NOT grade the field above what these rules permit):

IANA Considerations This document has no IANA actions. model_attestation is a bare payload member name seeded by the base profile itself (), not a namespaced extension, so the base profile's namespacing convention does not apply to the member name. Source labels and measurement classes are closed vocabularies of this document (Conventions and ); a future revision may request IANA registries for either if independent extensions appear. Registration of this document as a conforming tier-2 profile awaits the registry work noted in .

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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. 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 identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be 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. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. 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. Informative References 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. Action State Group, Inc.

Fix to the base profile Revisions -04 and -05 of draft-mih-scitt-agent-action-capsule reference model_attestation in their epoch-boundary section and their security considerations without defining it, while producers and a registry entry already use the block. This document supplies the definition (, ). The authors recommend that -06 of the base profile (a) cite this document for the definition or fold in, and (b) name the two extension containers explicitly: namespaced top-level members for correlation/provenance extensions, and model_attestation.compute_attestation for runtime and compute extensions. Until (b) lands, implementations place namespaced extensions under model_attestation.compute_attestation as well (see ).

Complete Example The following is an example of a complete model_attestation object:

Acknowledgments The authors thank the maintainers of the Mesh-LLM capsule plugin, whose shipping runtime measurements fixed the first two measurement classes, and the reviewers of the RATS architecture whose grading discipline follows.