]> Council of AI (CSOAI Ltd)

London United Kingdom nicholas@csoai.org

Security SCITT transparency measurement agents This document defines the measurement capsule: a small, deterministic JSON record in which a party that is neither the subject of a claim nor a participant in the action it concerns records what the subject declared, what the measuring party observed, and the difference between the two. A capsule carries digests of its evidence, a measurement state in which "could not be checked" is a first-class outcome, and no decision, approval or authorisation. Capsules are identified by the SHA-256 of their JCS serialisation and batched under an RFC 9162 Merkle Tree Hash. The document describes their registration as SCITT Signed Statements (RFC 9943), how they refer to rather than restate receipts issued under other profiles, its encoding as a COSE_Sign1 Signed Statement with test vectors, and one implementation, including where it does not yet match this profile.

Introduction Several individual drafts define receipts for automated actions. binds an enrolled approver key to one canonical action before execution; profiles signed action receipts, including decision receipts carrying a policy digest; defines signed, hash-chained action receipts and carries such receipts as SCITT Signed Statements; records categorical screening outcomes in agentic-payment flows; and defines signed decision receipts for access control at the MCP transport layer. These readings are the author's; corrections from their authors will be adopted. Those receipts are issued by a party in the path of the action and answer "was this permitted, and by whom?". They are not designed to answer a different question: does what a subject publicly declares about itself (a protocol version in a registry, a signing key in an agent card, a token's deployments, an evaluation result) match what an unaffiliated reader can observe? A measurement capsule records one such comparison. It differs from an action receipt in three ways. First, its Issuer is neither the subject nor a participant in the action, and it grants no authority; where the Issuer measures itself, the capsule should say so. Second, it carries the declaration, the observation and an explicit differential, and its state may be UNCHECKABLE, which is never recorded as a pass, a failure, a zero or an absence. Third, it may reference a receipt issued under another profile by digest () but never copies its outcome, so an approver's receipt and an independent measurement of the same effect can sit in one Transparency Service without either restating the other. The closest work, , reconciles a decider's signed Decision Records against an authenticated extract of effects; a capsule records one comparison and draws no conclusion about any decision. specifies declared canonicalisation and typed digest references for Signed Statements; capsule_id () is its derived identifier under algorithm jcs with the exclusion set {capsule_id}. This document profiles content, not the SCITT architecture. The terms Issuer, Signed Statement, Transparency Service and Receipt are used as defined in , and registration follows unchanged. The author's organisation does not operate a Transparency Service. The document is Experimental because its requirements on decision fields and UNCHECKABLE () have not been shown useful by more than one implementation ().

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.

Declared:

What the subject, or a registry or manifest speaking for it, states about a claim, as read from bytes the measurer retrieved.

Observed:

What the measurer read from a source other than the declaring one: a live protocol exchange, a ledger's state, a signature verification or a rerun on different hardware.

Differential:

The structured difference between the two. It is data, not a judgement: "these two statements disagree" does not say which is true.

Measurer:

The Issuer of a capsule; neither the subject nor a participant in the action the claim concerns, except in a self-measurement, which the capsule SHOULD mark as such.

Evidence ladder:

An ordered vocabulary recording how strong an observation is, as distinct from what it found: STATE_PROOF_VERIFIED (a proof checked against a block header's state commitment, the header not checked against consensus), STATE_PROOF_RECORDED (kept, did not verify), OPERATOR_API (an operator's answer, no proof), UNCHECKABLE and REJECTED (an identity check did not pass). A label MUST NOT be upgraded; an Issuer MUST refuse to build a capsule from a source record whose label claims more than its evidence shows.

The Capsule A capsule is a JSON object with the structure below, in CDDL using the .cat control of . The inner structure of the open maps depends on kind.

Capsule structure any }, "declared": open-map, "observed": open-map, "differential": open-map, "sources": sources, "measurement_state": tstr .size (1..64), "authority_state": authority-none, "effect_reference": effect-reference / null, "observed_at": tdate, "correction_pointer": correction-pointer / null, "limitations": [* tstr], ? "runtime_declared": open-map, ? "runtime_observed": open-map, "capsule_id": sha256-hex } open-map = { * tstr => any } sources = { * tstr => source-value } source-value = digest / null / [* source-value] / sources digest = tstr .regexp "(sha256:)?[0-9a-f]{40,128}" sha256-hex = tstr .regexp "[0-9a-f]{64}" authority-none = "NONE: measurement only; this capsule grants" .cat " and records no execution authority" effect-reference = { "profile": tstr, "statement_digest": digest, ? "transparency_service": tstr, ? "entry_id": tstr, * tstr => any } correction-pointer = { "record_schema": tstr, "record_version": tstr, "record_sha256": digest, "supersedes_record_sha256": digest / null, "from": any, "to": any, ? ("why" / "cause"): tstr, * tstr => any } ]]>

kind fixes the inner structure of the open maps and the vocabulary of measurement_state. The grammar above admits measurement.* kinds only; the capsules the implementation publishes under the operations.* kinds do not match it, which is where the implementation does not yet match this profile ( and ). subject_id is an identifier (an endpoint URL, asset:product:ledger:address), not a resolvable reference. claim.statement can be true or false of the subject. differential SHOULD name the items that differ, not only a count. sources holds digests of the artefacts the capsule was derived from (signed source record, fetched documents, responses, proofs, commits) and MUST NOT carry evidence bytes, URLs or free text; any other value makes the capsule invalid. authority_state is the only member whose name concerns authority, with one permitted value. observed_at is the time of the observation, not of the build. limitations states what the measurement does not show; a capsule SHOULD carry at least one, and it is covered by capsule_id. In runtime_declared and runtime_observed (reproducibility claims), values not recorded at the time are UNRECORDED, never omitted or inferred. This profile describes seven comparison kinds, not registered here. They compare: an MCP endpoint's registry, mcp.json, server-card and payment-manifest declarations with its live initialize and tools/list answer (contract_parity); an agent card's signatures with their verification under its declared protocol version (a2a_card_signature); an issuer's list of a tokenised asset's deployments with each ledger's state (cross_ledger_supply); external indexes' listings of the measurer's own offerings with its live bytes (self_parity); a signed evaluation result with a re-run on a second runtime (cross_runtime_reproduction); and an endpoint's advertised tools at two times (tool_drift). The seventh, public_signal, records one reading of a public counter and is observation-only (). This is not a list of every kind the implementation publishes: the same implementation also publishes capsules under measurement.claim_watch and the five operations.* sub-kinds, neither of which this revision defines. Two gaps follow. The grammar above admits measurement.* only, so the 236 operations.* capsules do not match it. The one measurement.claim_watch capsule does match the grammar, but the kind is undefined here, so it is outside this profile as well. Open issue 9 in records both gaps: whether those kinds belong to this profile, or the grammar widens.

Canonicalisation and Identifier capsule_id is the SHA-256 digest, as 64 lowercase hexits, of the JSON Canonicalization Scheme (JCS) serialisation of the capsule with capsule_id removed. Issuers MUST NOT place non-finite numbers or integers whose magnitude exceeds 2^53 in a capsule; such quantities (token supplies in base units are the common case) MUST be carried as strings. Issuers SHOULD avoid floating-point values. A capsule file stores each capsule as exactly its JCS bytes, so that a verifier can recompute capsule_id from the stored line.

Batches, Merkle Root and Index A batch is a capsule file and a batch record that commits to it. The capsule file holds one capsule per line, each followed by a single LF, sorted by capsule_id, with no duplicates. The batch Merkle root is the Merkle Tree Hash of , Section 2.1.1, with SHA-256, over the capsule_id values as 32-byte strings sorted in ascending byte order. Sorting makes the root a commitment to a set: reordering the file does not change it, so a changed root always means changed membership or content. Inclusion of one capsule is shown by an RFC 9162 audit path (Section 2.1.3), which existing tooling can verify. The batch record is a JSON object carrying at least schema, as_of, kind, n_capsules, per-state counts, merkle_root, the construction in words, the capsule file's SHA-256 and authority_state. It SHOULD state its inclusion rule and count, by reason, the source rows the rule excluded (for example, a dimension on which only one public surface spoke, where nothing was compared), so a reader sees what was not measured. An index lists each batch's record digest, root, count, signature state and timestamp state, and carries two roots under the same rule: one over the union of all capsule_id values (a duplicate across batches is an error) and one over the batch roots. The index is signed and timestamped. The implementation also chains daily indexes: each names the previous day's index by SHA-256 and root and states the number of days without an index.

Registration as a SCITT Signed Statement A batch record or an index is registered as the payload of a COSE_Sign1 message , tagged 18. Capsules are not registered one by one: a capsule reaches the log through the batch root that commits to it ().

Protected Header The protected header is a map in the core deterministic encoding of . It carries:

• alg (1): -19, Ed25519 , with an Ed25519 key . The polymorphic EdDSA identifier (-8), which deprecates, MUST NOT be used.
• kid (4): the UTF-8 bytes of the signing key's verification method, a DID URL . requires kid when neither x5t nor x5chain is present.
• CWT Claims (15) : iss (1), the Issuer's DID; sub (2), the batch's kind, or the fixed string measurement-capsule-index for an index; iat (6), the signing time.
• With an attached payload: content type (3), one of the media types in . The payload is the JCS serialisation of the record.
• With a COSE Hash Envelope : payload_hash_alg (258) set to -16 (SHA-256), payload_preimage_content_type (259) set to the media type, and optionally payload_location (260). The payload is the 32-byte SHA-256 of the record's JCS serialisation. Content type (3) MUST NOT be present, as requires; -00 of this document said otherwise.

The unprotected header is empty when the statement is signed. Receipts obtained later are carried under label 394, as in .

Signing and Verification The Issuer signs the Sig_structure ["Signature1", protected, h'', payload] of . A verifier decodes the message, rejects a protected header that is not deterministically encoded, rebuilds the Sig_structure, and verifies the signature under the key that kid resolves to. For an attached payload it then checks that the payload is exactly the JCS serialisation of the record it parses to; for a hash envelope, that the SHA-256 of the retrieved record equals the payload. A COSE statement is a new artefact over unchanged content. The capsule identifiers, batch roots and index roots it commits to do not change, and the JSON signatures an implementation already published over the same records stay verifiable; the two are published side by side. gives vectors for both encodings. No published batch record or index carries a COSE_Sign1 statement: the Issuer's signing service does not yet sign a Sig_structure. The published records are wrapped in a signed-artifact envelope instead, schema csoai.signed-artifact/0.1, whose signature object carries the did did:web:csoai.org#board-attestation-1, the alg Ed25519, the signature sig_ed25519, the digest payload_sha256 and the time signed_at. The record read on 27 October 2026 is at: The a2a_card batch measures JOSE agent-card signatures (ES256, EdDSA and RS256) in its subject; that is the subject being measured, not a signature carried by a capsule or a record.

Receipts Registration follows . The Receipt is a COSE Receipt whose verifiable data structure is set by the Transparency Service; for a service built on CCF it is the profile in . Inclusion of one capsule is shown in two steps: capsule to batch root by an RFC 9162 audit path under the Issuer's tree, then batch record or index to the log by the Receipt. A Receipt shows that the Transparency Service registered the statement at a time. It does not show that any measurement in it is correct. No Receipt has been obtained. As of 27 October 2026 there is no Transparency Service registration for any batch or index, no COSE Receipt , no entry identifier, no Receipt's SHA-256 and no verifier, because no Receipt exists. The estate publishes a separate aggregate payment-receipt feed at https://councilof.ai/api/receipts/latest, schema (csoai.receipts.latest/0.2), as_of 2026-10-27T15:40:31.490Z, count 26, covering at most the 50 most recent stored receipts: 4 demand-eligible, 17 internal and 5 zero-value (read 27 October 2026). Those are payment receipts. They are not Receipts as defined in this document, and neither is the feed.

Measurement States and the Absence of Decisions measurement_state is one string from a vocabulary defined per kind. The vocabularies in use, with the family each state belongs to (agreement, verification, reproduction, reading, and absence and inability), are listed in . For every kind:

• UNCHECKABLE and each absence-and-inability state MUST be recorded as such and MUST NOT be mapped to a pass, failure, zero or omission; a capsule MUST be issued for it when the batch's inclusion rule covers the subject.
• A state asserting absence (such as NOT_LISTED) MUST be used only where the read that established it was complete; a partial read yields UNCHECKABLE, and a total MUST NOT be recorded over a partial read.
• INCONSISTENT says two statements disagree, not which is true, and a state MUST NOT be stronger than its evidence.

No decision or authorisation field A capsule MUST NOT carry a decision about any party's action. Apart from authority_state, no member at any depth may be named decision, allow, allowed, allowlist, hold, reject, approve, approved, approval, admit, admission, authority, authorization, authorisation, permit, permission, grant, enforce, enforcement, action, recommended_action, gate or gate_result, or an inflection of these; and no string value at any depth may be exactly ALLOW, HOLD, REJECT, DENY, APPROVE, APPROVED, ADMIT, ADMITTED, BLOCK, PERMIT or GRANT. The rule exists so that a capsule cannot be consumed as a gate; an allow or deny outcome comes from the party holding that authority. The implementation enforces it at construction and verification (renaming a source's verdict field to agreement, for example). A denylist is incomplete (REFER, an outcome in , is not on it); it is a floor, and a per-kind allowlist of member names is an open issue.

Effect reference effect_reference, when not null, names a Signed Statement issued under another profile about the same effect: the profile and revision (for example draft-schrock-ep-authorization-receipts-13), the digest of the statement, and optionally where it can be retrieved. The digest MUST be computed over the octets as registered, since a re-encoded statement has a different digest under the same signature . The referenced statement's fields, in particular its outcome, are not copied. The implementation has not yet populated this member, so this composition is a proposal, not a report.

Corrections and Supersession A capsule is never edited; any change produces a different capsule. A correction is a new capsule, in a new batch, whose correction_pointer records the schema, version and SHA-256 of the source record in which the change was made, the SHA-256 of the record it supersedes, the state before (from) and after (to), and the reason, with the fixing commit where there was one. The superseded capsule remains valid and retrievable. A change of canonicalisation or Merkle construction changes identifiers and roots without changing any measurement, and MUST be published as a new batch, leaving earlier batches in place.

Privacy Considerations sources carries only digests; the evidence stays with whoever holds it. A digest of a public document is meant to be re-identifiable. A digest of a non-public, low-entropy artefact can be recovered by guessing, so Issuers SHOULD NOT place one in sources without blinding, which the implementation does not provide; its sources are all public or its own records. subject_id can identify a service run by one person. Issuers SHOULD measure only surfaces published for machine consumption, SHOULD NOT send credentials or go beyond discovery (the MCP measurements stop at initialize and tools/list), and SHOULD offer subjects a route to request correction or exclusion. Registration is append-only, so a capsule registered in error can be superseded but not withdrawn; Issuers SHOULD review batches before registering them.

Security Considerations A valid signature on a batch record shows only that the holder of the key signed those bytes, not that any value is correct, that the instrument is sound or that the subject agrees with the measurement. A verifier SHOULD recompute every capsule_id, the batch root, the record and file digests and the signature, and SHOULD reject a batch in which any capsule carries a forbidden member or value. The implementation signs with one Ed25519 key, held by a signing service reached by an authenticated request; it is not a threshold key and no claim is made about hardware protection. Compromise of the key or of the request credential allows valid signatures over false records, including a re-signed chain of daily indexes. Such a rewrite is detectable only against an anchor dated before it (a Bitcoin-attested timestamp, a Rekor entry or a Receipt), so verifiers SHOULD check anchors as well as signatures. The key is published through did:web, so its authenticity rests on DNS and the Web PKI; retired verification methods SHOULD remain resolvable. An OpenTimestamps calendar commitment shows only that calendars received a digest; only a proof upgraded to a Bitcoin attestation dates the bytes. SHA-1 Git commit identifiers in sources are locators on which no integrity claim rests. The measurer reads from one location at one time, and surfaces that should agree may be read hours apart (recorded in limitations). A VERIFIED card signature does not show who controls the key. A measurer chooses what to measure, and a batch of subjects likely to disagree would be accurate capsule by capsule and misleading in aggregate; hence the inclusion rule in batch records, and consumers SHOULD NOT aggregate state counts across batches with different inclusion rules.

IANA Considerations This document has no IANA actions. It uses three media types in the vendor tree, application/&wj;vnd.csoai.measurement-capsule+json, application/&wj;vnd.csoai.measurement-capsule-batch+json and application/&wj;vnd.csoai.measurement-capsule-index+json, which can be registered without IETF action. None of the three has been registered: the IANA media type registry listed no csoai entry when it was read on 27 October 2026 (https://www.iana.org/assignments/media-types/application.csv). Their names are open issue 4.

Implementation Status This section records the status of known implementations at the time of posting, following . RFC Editor: please remove this section before publication. This is also where the implementation does not yet match this profile. The kind grammar of admits measurement.* only. Of the 10,737 capsules the signed index lists, 236 carry an operations.* kind and do not match that grammar; the index records those 236 together under the kind operations. One further capsule carries the kind measurement.claim_watch, which this revision does not define. The state vocabularies of both are in . CSOAI measurement capsule builder (Council of AI, contact nicholas@csoai.org). Every count, root, commit and URL in this section is read from the live artefacts on the day of posting and given with the time of reading; none is carried over from -00.

• Index: schema csoai.measurement-capsule-index/0.3, version 0.2, 10,737 capsules in 10 batches, index root 9631cc00b91ce9d1e37e517851eab126be6ca1a4dc6b66a26d86352aada5b562, the RFC 6962 Merkle Tree Hash over the sorted capsule_id leaves of all the batches together (leaf = SHA-256(0x00 || capsule_id), node = SHA-256(0x01 || left || right)). The index is at https://councilof.ai/measurement-capsules/v0.2/index.json, as_of 2026-10-01T08:11:31Z; its signature verifies under did:web:csoai.org#board-attestation-1, signed_at 2026-10-01T08:11:32.035Z. Published at https://councilof.ai/measurement-capsules/v0.2/ (index.signed.json, index.json, anchors.json), with a copy at https://huggingface.co/datasets/csoai/evidence-index/tree/main/measurement-index/2026-10-01; read 27 October 2026.
• COSE: see . No capsule and no published record carries a COSE_Sign1 statement; the published records carry an Ed25519 csoai.signed-artifact/0.1 envelope under did:web:csoai.org#board-attestation-1 instead (read 27 October 2026).
• Receipt: see . No Receipt has been obtained, so there is no Transparency Service registration, no entry identifier and no Receipt digest (read 27 October 2026); the aggregate payment-receipt feed at https://councilof.ai/api/receipts/latest is not a Receipt in the sense of this document.
• Anchors: the OpenTimestamps state of each record's proof (calendar commitment or Bitcoin attestation) and the Rekor log indexes. Neither is a SCITT Transparency Service or issues Receipts. Read 27 October 2026 from the index (as_of 2026-10-01T08:11:31Z) and https://councilof.ai/measurement-capsules/v0.2/anchors.json (as_of 2026-10-01T08:52:55Z): the five batches a2a_card (33), contract_parity (9,148), mill_cross_runtime batch 1 (14), mill_cross_runtime batch 2 (140) and tool_drift (497) are BITCOIN_ATTESTED, each with one Bitcoin block-header attestation and three pending calendar attestations; the five batches claim_watch (1), cross_ledger (383), operations (236), public_signals (119) and self_parity (166) are PENDING_CALENDAR_COMMITMENT, each with pending calendar attestations only (two each, three for public_signals). At index level the proof is (measurement-index-v0.2-2026-10-01.json.ots), SHA-256 1f8d2994895a74ff384a1a1331e398abdd98d4df8f59850c91436c823b350360, state PENDING_CALENDAR_COMMITMENT with no Bitcoin block height; a calendar commitment alone dates nothing. The estate has since published an upgraded proof for the same index file, re-read from the calendars, carrying a Bitcoin block-header attestation at height 969421 (block time 1790842779), SHA-256 671b14f1a24dbe5757a15416954e540f7fa0a4e38ca6f7e873b5d7c0a70763ab (https://huggingface.co/datasets/csoai/evidence-index/tree/main/ots-upgraded/2026-10-01). One Rekor entry is published for this index and none per batch; its state is INCLUDED and its inclusion proof verifies: No per-batch Rekor log indexes are published. Earlier daily indexes and chain heads carry entries of their own, the 2026-09-30 index among them with logIndex 3014901172; an entry dated before a rewrite is what detects a re-signed daily-index chain. The XRP Ledger anchor is PREPARED_NOT_SUBMITTED: memo drafts exist and nothing has been submitted to the XRP Ledger.
• Capsules by kind and state, the number of self-measurements, and the number carrying a correction pointer or an effect reference. Read from the published capsule bodies on 27 October 2026, not from the index's summary fields: 10,737 bodies in the ten batches, counting to the index's 10,737. By kind: measurement.a2a_card_signature 33 (VERIFIED 13, UNCHECKABLE 12, FAILED 8); measurement.claim_watch 1 (QUARANTINED 1); measurement.contract_parity 9,148 (CONSISTENT 5,570, INCONSISTENT 2,905, UNCHECKABLE 673); measurement.cross_ledger_supply 383 (CONSISTENT 124, STATE_PROOF_VERIFIED 58, OPERATOR_API 89, LISTED_NOT_READ 36, UNCHECKABLE 32, STATE_PROOF_RECORDED 12, TOTAL_COMPLETE 15, PERMISSIONED_NOT_READABLE 6, NOT_A_SUPPLY_CLAIM 3, ISSUER_LIST_UNAVAILABLE 2, INCONSISTENT 1, TOTAL_PARTIAL 5); measurement.cross_runtime_reproduction 154, in two batches of 14 and 140 (REPRODUCED_ITEMWISE 54, REPRODUCED_AGGREGATE_ONLY 11, NOT_REPRODUCED 89); measurement.public_signal 119 (MEASURED 101, UNCHECKABLE 16, PARTIAL 2); measurement.self_parity 166 (NOT_LISTED 65, UNCHECKABLE 48, CONSISTENT 41, INCONSISTENT 11, NOT_DECLARED 1); measurement.tool_drift 497 (UNCHANGED_AT_NAME_GRANULARITY 418, UNCHECKABLE 57, TOOLS_ADDED 17, TOOLS_ADDED+TOOLS_REMOVED 3, TOOLS_REMOVED 2); operations 236 (PRESENT_SHA256_UNRECORDED 169, LANDED_NOT_SHIPPED 54, BITCOIN_ATTESTED 7, TIME_TO_CORRECT_UNMEASURED 3, PENDING_CALENDAR_COMMITMENT 1, INCLUDED_PROOF_VERIFIES 1, UNCHECKABLE 1). The 236 operations capsules carry five operations.* sub-kind values, which the index records together as the kind operations; 12 capsules carry a correction_pointer and none carries an effect_reference. 324 capsules are self-measurements, counted from the subject because no capsule carries an explicit self-measurement member (open issue 7): the 166 capsules of the self_parity batch, whose subjects are the Issuer's own doors; the 154 cross_runtime_reproduction capsules, whose subjects are the Issuer's own local models; and the 4 contract_parity capsules that claim the Issuer's own endpoint.
• Test vectors: , with a generator and a checker on a second code path (cbor2, rfc8785 and the RFC 9162 Section 2.1.3.2 inclusion check). The checker is written by the same organisation, so it is not the independent implementation the experiment asks for. Published at https://raw.githubusercontent.com/CSOAI-ORG/councilof-ai/master/docs/ietf/measurement-capsule-01/test-vectors/vectors.json, with gen_vectors.py and check_vectors.py in the same directory (read 27 October 2026).

The Experiment The experiment asks whether an unaffiliated, authority-free declared-versus-observed record is useful alongside actor-issued receipts in a SCITT deployment. It is judged by four outcomes: (1) an implementation written by another party from this text recomputes the identifiers and roots of a published batch; (2) a batch is registered with a Transparency Service operated by another party and its Receipt is verified by a third; (3) a capsule carries an effect_reference to a Signed Statement from a different Issuer; (4) the open issues are resolved and published as corrections without loss of existing batches. If none occurs within two revisions, the author will withdraw the draft.

Open Issues (1) COSE_Sign1 encoding: specified in this revision (). (2) The superseded capsule_id in correction_pointer: open. (3) A per-kind allowlist of member names in place of the denylist: open; lists state vocabularies only. (4) Neutral names for the csoai.-prefixed identifiers and media types: open; a rename changes every identifier and would be published as new batches. (5) Blinded digests for non-public sources: open. (6) Whether observation-only kinds belong here: open. (7) An explicit self-measurement member: open. (8) Transparency Services differ in the Issuer identities their registration policies accept (for example did:x509 rather than did:web); which forms a measurer needs is open. (9) The kind grammar of admits measurement.* only, but the implementation publishes 236 capsules under five operations.* kinds that it does not admit, recorded in the index together as the kind operations; it also publishes one capsule under measurement.claim_watch, which the grammar admits and this revision does not define. Whether those kinds belong to this profile or the grammar widens: open.

References Normative References Informative References ScopeBlind (Veritas Acta) Fraunhofer SIT Bowball Technologies Ltd Microsoft Research Action State Group, Inc. Tyche Institute EMILIA Protocol, Inc. Asqav kriya native AlgoVoi NordenSoft VERAX TEKNOLOJI LIMITED SIRKETI Council of AI (CSOAI Ltd) W3C Credentials Community Group OpenTimestamps Sigstore

Test Vectors These vectors are synthetic. The signing key is the TEST 1 key of , whose secret is published there, so nothing it signs means anything. Subjects are under .example, and source digests are SHA-256 values of labelled placeholder strings. The full vectors, their generator and a checker that shares no code with the generator are published at https://raw.githubusercontent.com/CSOAI-ORG/councilof-ai/master/docs/ietf/measurement-capsule-01/test-vectors/vectors.json (vectors.json, SHA-256 33d1545489f880b6beb84bb0086cc18ec9495f429783216afa9be60df36c6a55), with gen_vectors.py and check_vectors.py in the same directory at https://github.com/CSOAI-ORG/councilof-ai/tree/master/docs/ietf/measurement-capsule-01/test-vectors, read 27 October 2026. Public key (hex): d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a. kid: did:web:measurer.example#test-key-1.

One Capsule The first of five capsules, as its JCS bytes. Line breaks are added for display only; the bytes contain none. capsule_id (SHA-256 of the JCS bytes without capsule_id):

Batch and Audit Path Five capsule_id leaves, sorted ascending: RFC 9162 Merkle Tree Hash (SHA-256): Audit path for leaf index 2 of 5, verifiable with : SHA-256 of the batch record's JCS bytes:

COSE_Sign1 with an Attached Payload Protected header (EDN, then the deterministic encoding in hex): Signature over the Sig_structure:

COSE_Sign1 with a Hash Envelope Protected header (EDN, then hex). Label 3 is absent. Payload (SHA-256 of the batch record's JCS bytes) and signature:

Controls Each control is built to be rejected and names the one rule it breaks. A verifier counts a control only when it is rejected for that rule. For each rule, relaxing that rule alone in the checker changes the result of the control that names it and of no other vector.

Control	Rule	Why it is rejected
N1-forbidden-member	no-authority-member	a member named decision is forbidden at any depth
N2-source-not-a-digest	sources-digest-only	sources carries a URL where only digests are allowed
N3-stored-line-not-jcs	stored-bytes-are-jcs	the stored line is indented JSON, so it is not the JCS bytes the identifier covers
N4-payload-byte-flipped	cose-signature	one payload byte of V3 changed; the signature no longer verifies
N5-hash-envelope-with-label-3	rfc9995-no-label-3	RFC 9995: label 3 (content_type) MUST NOT be present with a hash envelope payload
N6-duplicated-last-leaf	leaf-set-no-duplicates	the leaf list repeats its last member; its root differs from V2 and n no longer equals n_capsules

State Vocabularies This appendix is generated at build time from the implementation's vocabulary file: for each kind, each state, the family it belongs to and a one-line meaning. It is not written by hand, so that the text and the implementation cannot drift apart. The families are the five named in : agreement, verification, reproduction, reading, and absence and inability. The kinds and the states are those published in the capsule bodies read on 27 October 2026. A state records what the measurement established and nothing more, so no entry below says that a measurement is good, bad, correct or incorrect.

measurement.a2a_card_signature

State	Family	Meaning
VERIFIED	verification	The card's signatures verified under the protocol version the card declares.
FAILED	verification	The card's signatures did not verify under the protocol version the card declares.
UNCHECKABLE	absence and inability	The signature could not be checked, so the capsule records no outcome for it.

measurement.claim_watch

State	Family	Meaning
QUARANTINED	absence and inability	A watched claim was quarantined; the sealed subject's claims and evidence are withheld until the owner publishes the claim record, and only digests are carried.

measurement.contract_parity

State	Family	Meaning
CONSISTENT	agreement	The declarations read and the live answer agree on the compared dimension.
INCONSISTENT	agreement	The declarations read and the live answer differ; the state does not say which is right.
UNCHECKABLE	absence and inability	The live read did not answer the compared dimension, so the two were not compared.

measurement.cross_ledger_supply

State	Family	Meaning
CONSISTENT	agreement	The issuer's listing and the ledger's deployment agree.
INCONSISTENT	agreement	The issuer's listing and the ledger's deployment differ; the state does not say which is right.
STATE_PROOF_VERIFIED	verification	A proof checked against a block header's state commitment, the header not checked against consensus.
STATE_PROOF_RECORDED	verification	The state proof was kept and did not verify.
OPERATOR_API	verification	The figure came from an operator's answer, no proof.
LISTED_NOT_READ	absence and inability	The deployment is listed and was not read; not read is not zero and not absent.
PERMISSIONED_NOT_READABLE	absence and inability	The issuer's listing is readable only with permission that was not given, so nothing was read.
ISSUER_LIST_UNAVAILABLE	absence and inability	The issuer's list of deployments could not be obtained, so nothing was read.
UNCHECKABLE	absence and inability	Nothing was read, so nothing was compared.
NOT_A_SUPPLY_CLAIM	reading	The issuer's entry states no supply figure for the deployment, so there is nothing to compare.
TOTAL_COMPLETE	reading	Every deployment the issuer lists was read with a supply figure, so a total is given.
TOTAL_PARTIAL	reading	Some deployments the issuer lists were not read with a supply figure, so no total is given.

measurement.cross_runtime_reproduction

State	Family	Meaning
REPRODUCED_ITEMWISE	reproduction	The re-run on the second runtime gave the same grade for every item.
REPRODUCED_AGGREGATE_ONLY	reproduction	The re-run gave the same aggregate, but the grades of some items differed.
NOT_REPRODUCED	reproduction	The re-run's aggregate differed from the signed evaluation result's aggregate.

measurement.public_signal

State	Family	Meaning
MEASURED	reading	The public counter was read once and returned a value.
PARTIAL	reading	The read returned only part of the signal, a named list rather than the whole population.
UNCHECKABLE	absence and inability	The read returned no value, so nothing is recorded about the signal.

measurement.self_parity

State	Family	Meaning
CONSISTENT	agreement	The index's listing of the offering agrees with the live bytes.
INCONSISTENT	agreement	The index's listing of the offering differs from the live bytes; the state does not say which is right.
NOT_LISTED	absence and inability	A complete read of the index found no listing of the offering.
NOT_DECLARED	absence and inability	The offering's own surface declares no such field; this is recorded so the surface can be completed, and it is not a contradiction.
UNCHECKABLE	absence and inability	The index could not be read completely, so no listing could be established.

measurement.tool_drift

State	Family	Meaning
UNCHANGED_AT_NAME_GRANULARITY	agreement	The tool names advertised at the second read are the same as at the first.
TOOLS_ADDED	agreement	The second read lists tools the first did not.
TOOLS_REMOVED	agreement	The second read omits tools the first listed.
TOOLS_ADDED+TOOLS_REMOVED	agreement	The second read both lists tools the first did not and omits tools the first listed.
UNCHECKABLE	absence and inability	The first read was incomplete or unsuccessful, so the two tool lists could not be compared.

operations The 236 operations capsules carry five sub-kind values, which the index records together as the kind operations.

operations.anchor

State	Family	Meaning
BITCOIN_ATTESTED	verification	The anchored bytes carry an OpenTimestamps proof with a Bitcoin block-header attestation.
PENDING_CALENDAR_COMMITMENT	absence and inability	The anchored bytes carry an OpenTimestamps proof with pending calendar attestations only; a calendar commitment alone dates nothing.
INCLUDED_PROOF_VERIFIES	verification	The artefact's signed preimage is in the log and its inclusion proof verifies.

operations.correction

State	Family	Meaning
TIME_TO_CORRECT_UNMEASURED	absence and inability	The correction was recorded, but the time from detection to correction was not recorded, so it is not measured.

operations.deploy

State	Family	Meaning
UNCHECKABLE	absence and inability	The deploy source could not be read for the window, so its events are not recorded.

operations.landing

State	Family	Meaning
LANDED_NOT_SHIPPED	agreement	The change landed on the branch; the release covering the window does not carry it.

operations.publication

State	Family	Meaning
PRESENT_SHA256_UNRECORDED	absence and inability	The files are present at the commit, but no SHA-256 was recorded for them, so none was checked.

Changes from -00

• Specified the COSE_Sign1 encoding: header parameters, deterministic encoding, what is signed and how it is verified.
• Corrected the hash envelope rule: content type (3) is absent and the media type goes in label 259, as RFC 9995 requires.
• Registration is per batch record and index, not per capsule.
• Added the Receipts section, and moved RFC 9995 to the normative references; added RFC 8949 and RFC 9942.
• Added test vectors and controls.
• Moved the state vocabularies to a generated appendix.
• Implementation Status is re-read from live artefacts; no figure is carried over.
• Stated where the implementation does not yet match this profile: the kind grammar admits measurement.* only, and 236 of the published capsules carry operations.* kinds it does not admit; the one measurement.claim_watch capsule matches the grammar but the kind is undefined here; open issue 9 records both.
• Added the MCP access-decision receipt draft to the survey in the introduction, and open issue 8.
• The rfc tag no longer declares a submissionType. The Datatracker records this draft as an individual submission with no stream, and a declared stream made its own submission check report SUBMISSION_TYPE_UNEXPECTED. RFC 7991 makes IETF the default for the attribute, so the declared stream is unchanged and no section of the document changes; only this change log records it.
• REFERENCES: re-read each cited draft's current revision on 27 October 2026, against the Datatracker. The date carried for each cited revision is the date the Datatracker records it as posted, not the date in its own header. Three cited drafts were re-read and are cited here at their live revisions: draft-dogru-cedulon-decision-profile-04 (4 October 2026), draft-mih-sokolov-scitt-payload-binding-06 (25 October 2026) and draft-templeman-scitt-framing-space-01 (26 September 2026). The other seven cited drafts were re-read and are current at the revision cited: draft-ietf-scitt-scrapi-11, draft-schrock-ep-authorization-receipts-13, draft-marques-asqav-compliance-receipts-09, draft-hopley-x402-compliance-receipt-02, draft-noa-scitt-ai-agent-receipt-01, draft-sahu-agent-action-receipts-00 and draft-farley-acta-signed-receipts-03. This revision supersedes -00, which was re-read as well. The one draft that arrives through the bibliography was re-read and is current: draft-ietf-scitt-receipts-ccf-profile-06.

Acknowledgments The drafts cited in the introduction sharpened the distinction this document draws. Any mischaracterisation of them is the author's.