Summary

  • draft-templeman-scitt-measurement-capsule-00 proposes a third-party record that keeps the declaration, observation, differential, evidence digests and limitations together without granting execution or decision authority.
  • UNCHECKABLE is not failure, success, zero or absence; a partial read cannot justify a complete negative claim, and a signed differential still does not establish which side is true.
  • Hashes, Merkle inclusion, signatures, transparency receipts and timestamps make different propositions. A consumer that blocks, admits or remediates must supply its own principal, policy, scope, appeal and outcome record.

The capsule says an endpoint declared twelve tools and the observer found eleven. Its bytes are canonical. Its identifier recomputes. Its batch proof is valid. The issuer's signature verifies. A transparency log can show that the batch record was registered.

Should the endpoint now be blocked?

The proposed format answers with a deliberate refusal. It can preserve the disagreement. It cannot decide what the disagreement means, which side is right, whether the read was complete, whether the missing tool matters, or who is entitled to exclude the endpoint. The party that owns admission must make that decision under a separate policy and accept the consequences.

That refusal is the most consequential feature of Declared-versus-Observed Measurement Capsules: A Profile for Third-Party Measurement Statements in SCITT. On 2 October 2026, the IETF Datatracker listed revision 00 as an active Individual Submission filed on 27 September and expiring on 31 March 2027. The text is intended to be Experimental. It has no IETF stream or responsible Area Director. It is work in progress, not an RFC, working-group adoption, IETF consensus, endorsement or evidence of deployment.

The draft defines a compact JSON record for a measurer that is neither the subject of a claim nor a participant in the action concerned. It separates what a subject or registry declared from what the measurer observed elsewhere, then stores a structured differential. It can refer to another action or authorisation receipt by digest, but it does not copy that receipt's outcome. It can be signed, batched under an RFC 9162 Merkle root and registered as a SCITT Signed Statement. None of those operations changes the measurer into the principal.

A comparison needs two acquisition receipts

“Declared” and “observed” sound like stable categories. Operationally, each is a chain of choices.

The declaration has a location, retrieval time, media type, identity, version and digest. A manifest may speak for a service, but only within the scope its publisher controls. A registry entry may be current, stale, delegated or copied. The draft sensibly says a declaration is read from bytes retrieved by the measurer. That keeps the claim attached to an artefact instead of treating a label as timeless truth.

The observation has a different acquisition record. It may come from a live protocol exchange, a ledger proof, a signature verification or a rerun on different hardware. The observer chooses a network location, credentials, request, timeout, parser, clock and sampling moment. Two surfaces that should agree may be read hours apart. A live answer from one vantage point does not establish what every client could see.

A useful capsule therefore needs more than two values. The reader should be able to recover the declared source and version; observation method and vantage; authentication posture; read completeness; clock and freshness; parser and profile; evidence-strength label; retries and failures; and limitations. Without those receipts, the differential can be exact while its interpretation is wrong.

The draft's evidence ladder helps. STATE_PROOF_VERIFIED means a proof was checked against a block header's state commitment, but the header was not necessarily checked against consensus. STATE_PROOF_RECORDED keeps the proof without verifying it. OPERATOR_API is the operator's answer without a proof. REJECTED means an identity check failed. The label cannot be upgraded simply because a downstream consumer wants a cleaner score.

This is the reality-layer discipline in practical form. The record should say what was actually read and checked, not what an institution wishes the evidence to authorise.

UNCHECKABLE protects the denominator

Most automated evaluation systems want a small set of outcomes. Pass and fail fit dashboards. Zero fits a metric. Missing values are easy to drop. The draft resists all four shortcuts.

UNCHECKABLE is a first-class state. If a source cannot be read, a proof cannot be evaluated or a response is partial, the capsule must not convert that inability into failure, success, zero or silence. An absence state such as NOT_LISTED is permitted only after a complete read. A partial listing yields UNCHECKABLE; a total cannot be computed over an incomplete population.

This is not pedantry. Suppose an observer checks ten ledger deployments named by an issuer, reaches eight, finds matching state on seven and cannot read one permissioned ledger. Reporting “seven of ten verified” hides two different gaps: two were never observed, and one was reached but unreadable. Reporting the unreadable deployment as zero fabricates a fact. Omitting it improves the rate by changing the denominator.

The same danger appears at batch level. The measurer chooses which subjects to include. A batch made mostly of endpoints likely to disagree may be accurate capsule by capsule and still misleading as an aggregate. The draft therefore asks batch records to state their inclusion rule and count excluded rows by reason. Consumers should not compare state totals across batches with different selection rules.

Every operational use should retain three denominators: eligible subjects, attempted observations and complete observations. It should also expose who selected each population. A signed percentage without that ledger is presentation, not measurement governance.

A differential is not a truth oracle

The capsule can say that two statements disagree. It does not say which statement is true.

The declaration may be stale. The observation may be stale. The subject may expose different views by region, credential, version or time. The observer may have selected the wrong endpoint or misunderstood the profile. A registry and a live server can both be internally correct about different scopes. Even a deterministic differential only proves that the encoded inputs differ under the specified comparison.

This is why the draft requires limitations and fixes authority_state to one meaning: measurement only; no execution authority is granted or recorded. It also forbids decision-shaped field names and exact outcome strings throughout the object. A capsule may not smuggle in allow, deny, approve, admit, permit, gate or their equivalents and then claim to remain neutral.

The denylist is not complete. The draft admits that a novel synonym could escape it and lists per-kind field allowlists as an open issue. That limitation is useful. Schema hygiene can make accidental authority inflation harder, but no vocabulary filter can prevent a consumer from treating INCONSISTENT as an automatic block outside the capsule.

The control belongs at the integration boundary. A policy engine should accept the capsule as evidence, preserve its exact profile and limitations, and then issue a separate decision record. That record should name the authorised principal, policy version, protected interest, threshold, scope, exceptions, appeal route, expiry and action taken. The measurement issuer should not inherit those powers merely because its record is machine-readable.

Five cryptographic receipts prove five different things

The profile is intentionally deterministic. capsule_id is SHA-256 over RFC 8785 JSON Canonicalization Scheme bytes with the identifier field removed. Very large integers must be strings, non-finite numbers are forbidden, and exact JCS bytes are retained. This lets another verifier reproduce the content identifier.

Capsules are sorted by identifier and committed into an RFC 9162 Merkle Tree Hash. An audit path can prove that one capsule belongs to the batch. The batch record commits to the file, count, states and inclusion rule. An index can commit to capsules and batch roots across time.

A COSE_Sign1 wrapper can identify the issuer key and bind protected headers to a payload or COSE Hash Envelope. A SCITT Transparency Service can register that Signed Statement and return a receipt. An external timestamp can supply a time-related claim when its own proof is complete.

Those receipts are cumulative, not interchangeable:

  1. JCS and the content hash show which bytes form the capsule.
  2. The audit path shows membership in one issuer-defined batch.
  3. The signature shows that the key holder signed the protected bytes.
  4. The SCITT receipt shows registration according to a Transparency Service's policy.
  5. A completed time proof can bound when a commitment existed.

None proves that the instrument was calibrated, the source was complete, the observer was independent, the subject endorsed the result, the batch population was fair or the differential justified an operational response. The draft says this plainly: a valid signature is not correctness.

The effect receipt must remain outside the measurement

The profile allows an effect_reference to name a Signed Statement issued under another profile about the same effect. The digest is over the exact registered octets. The referenced fields—especially an outcome—are not copied.

That design prevents a subtle authority merger. An approver may issue an authorisation receipt before an action. An executor may issue an action receipt. A third party may later compare declared and observed effects. A transparency service may register each statement. The records can be joined without pretending that they came from one issuer or answered one question.

The join must preserve missing legs. A capsule that says an effect looked different does not retroactively invalidate an approval. An approval does not establish that the effect occurred. A shared log does not reconcile the two. The consumer can correlate them by explicit identifiers and time windows, then issue a bounded decision with visible uncertainty.

The author reports that the prototype has not yet populated effect_reference. The composition is therefore a proposal, not implementation evidence.

Corrections preserve history and liability

A capsule is never edited. A correction creates a new capsule in a new batch and points to the record it supersedes, preserving the before and after states and reason. The earlier capsule remains valid and retrievable. A change to canonicalisation or Merkle construction also creates new identifiers and roots even when the underlying measurement meaning has not changed.

This is the right model for accountability. Erasing an earlier claim would erase what consumers actually saw. Supersession lets readers reconstruct who knew what and when, whether an automated action occurred before correction, and whether the corrected record propagated.

Append-only retention also creates obligations. A false or privacy-sensitive capsule cannot simply be withdrawn after registration. Subjects need a correction or exclusion route. Consumers need a policy for superseded evidence and cache invalidation. Decision records need to state which capsule version they used. A correction without downstream reconciliation leaves the operational harm in place.

Digest-only sources do not make private evidence safe

The draft keeps evidence bytes and URLs out of the capsule, storing only digests. That reduces disclosure but does not guarantee confidentiality. A hash of a public document is intentionally re-identifiable. A hash of a small private value—one of a few status strings, a short configuration or a predictable identifier—can be guessed by enumerating candidates.

The text recommends blinding for non-public, low-entropy artefacts and says the prototype does not implement it. This is another reason not to elevate “digest present” into “privacy solved.” The issuer must classify the source, assess entropy and linkability, govern retention and decide whether the evidence can ever be disclosed to a challenger.

Privacy also tests independence. The draft recommends measuring machine-published surfaces, avoiding credentials and stopping MCP observation at discovery. Those limits protect subjects but may leave important claims uncheckable. The proper result is an explicit boundary, not a more aggressive probe performed without authority.

One prototype is running code, not ecosystem proof

The draft reports a Python builder and verifier operated by the author's organisation. Section 12 says its published index bound 13,184 capsules in eight batches across seven kinds as of 26 September. It reports OpenTimestamps and Rekor commitments, a browser verifier and a checker that shared no code with the builder.

These are author-supplied implementation-status claims. The checker is from the same organisation, and the draft explicitly says it is not the independent implementation required by the experiment. The prototype does not yet encode COSE_Sign1, register with a SCITT Transparency Service, populate effect references or blind digests. Rekor and OpenTimestamps are not represented as SCITT receipts.

The experiment sets harder tests: another party should implement the text and reproduce identifiers and roots; another party's Transparency Service should register a batch; a third party should verify its receipt; a capsule should reference a different issuer's effect statement; and open issues should be corrected without losing old batches. The author says the draft will be withdrawn if none occurs within two revisions.

That is a healthy falsifiability condition. Leadership should watch those outcomes instead of promoting the current counts into adoption. Running code is evidence of one implementation. Independent reproduction, cross-operator registration and live correction are different receipts.