Summary

  • draft-sirkkavaara-vaara-receipt-12 can sign a per-boundary sequence number and runningCount, making a receipt omitted inside a held sequence detectable once a later record is present.
  • A contiguous prefix can still conceal an entire suffix. A terminal seal pins the expected total, but suppressing both suffix and seal leaves no contradiction inside the held set.
  • The draft assigns that residual to an RFC 3161 anchor over the closing count. Signature integrity, interior completeness, boundary closure, external time evidence and observed action outcome remain separate receipts.

Seven clean records and the wrong ending

Imagine an autonomous service producing one authorization receipt for each tool call. An auditor is handed records 0 through 6. Each carries a signed completeness block with the same boundary identifier. Each seq advances by one; each runningCount equals seq + 1. The last record says seven receipts have been issued. The set contains seven. Nothing fails.

Now suppose the service actually issued three more records. If receipt 4 alone disappears while 5 and 6 remain, the omission is visible. The highest count says seven records should exist, yet one sequence number is missing. If instead the holder removes 7, 8 and 9, the prefix 0..6 still describes itself perfectly. Its latest count is seven because that was true when receipt 6 was signed. The verifier has checked continuity, not finality.

Revision 12 of the Vaara Receipt draft is unusually explicit about this boundary. Its authorization profile can bind a decision to a named observation surface and add a monotonic sequence. That is useful. It turns a silent hole in the middle into a named absence. It does not let the remaining bytes announce that later bytes once existed.

Coverage comes before counting

The sequence is optional because the observation boundary is optional. A coverage block names the chokepoint, fingerprints the capability surface or command in scope and says that only calls routed through that point were observed. A call using another path is outside the claim.

This matters before anyone counts receipts. Ten perfect records from one gateway cannot prove that another gateway, local shell or direct service endpoint saw no action. An absent refusal means no refusal was recorded within the declared boundary; without such a boundary it means only “not observed.” The format can make the scope recomputable, but it cannot enlarge the scope after the fact.

Inside a declared boundary, seq begins at zero and runningCount equals the total issued through that record. Holding a later record creates leverage over earlier omissions. The later count becomes a claim about how many records should precede it. That is the strong part of the design: completeness is no longer a dashboard impression but a signed relationship among the held records.

The seal closes one tail, not every tail

The optional sealing record adds {sealed: true, total: N} for the boundary. If the audit set includes that seal, a suffix omission becomes visible because the holder must account for N records. The seal may also name a maximum action class, allowing a verifier to bound the worst class a missing record could have authorized.

But the seal is itself a record. A holder able to suppress the suffix may suppress the seal with it. The earlier prefix remains consistent, and no retained byte points past its end. Revision 12 calls this residual irreducible from the held set alone.

That is not a defect peculiar to this proposal. It is an information boundary. No collection can derive an unseen later event solely from an earlier prefix that was valid at the time. The control has to cross into another custody domain.

The draft proposes an RFC 3161 timestamp anchor over the running count. In operational terms, an authority attests that by time T a particular signed payload representing count N existed. A later holder who presents only count k has to reconcile that claim with the externally retained N. The authority, its key, validation policy and retention are therefore part of the completeness story.

A self-hosted Time-Stamp Authority can produce a conforming token, but it is not independent merely because the syntax is RFC 3161. Independence comes from custody and incentives. The same operator controlling the action log, seal and timestamp service has three cryptographic artifacts and one institutional point of suppression.

A transparency receipt answers a different question

The draft also discusses registering a receipt with a SCITT Transparency Service. That can provide a separately verifiable registration receipt for a signed statement. It travels beside the Vaara receipt rather than inside timestampAnchors.

The distinction should survive procurement language. A timestamp binds a digest to a time assertion. A transparency receipt binds a statement to a registration event and service policy. A sequence count identifies interior omissions relative to a later held record. A seal states the intended final total. They can reinforce one another, but none silently performs the others' job.

RFC 9162's transparency-log machinery illustrates the same discipline: inclusion evidence and consistency evidence are different objects. The attractive word “logged” is not enough. Operators need to say which object was registered, which tree or service accepted it, which checkpoint was retained and which party can still produce proof after the issuer is offline.

Recomputable does not mean self-explanatory

Vaara receipts use RFC 8785 JCS so another implementation can reconstruct the same bytes, recompute the evidence digest and verify the signature. The draft's conformance vectors are a meaningful running-code claim: they test signatures, evidence bindings, back links, result commitments and selected completeness cases without importing issuer code.

That evidence stays inside its layer. A matching hash proves that the held evidence record is the one committed to. It does not prove the record is truthful or exhaustive. A valid signature proves that the selected key signed unchanged content. The draft itself says it defines no key-revocation mechanism and no freshness rule. A verifier must bring its own key-resolution path and acceptable staleness.

The same separation applies to action results. A decision receipt says what was allowed, blocked or escalated. It does not say the action ran. An execution receipt can link back to the decision and sign executed or refused plus a result commitment. That pairing prevents substitution of an unrelated outcome, but independent operational truth still depends on who observed the result and whether the external system actually changed.

Lu Heng's reality layers make the governance error visible. A signature is not a sequence; a sequence is not a closed boundary; a seal is not an independent witness; a witness is not the action; and the action is not its durable outcome. Minimum Initial Specification supports a common envelope precisely because local institutions must still own those later decisions. Running-Code Primacy gives the conformance vectors their proper weight without promoting them into deployment or outcome proof.

Sources and limits

These sources establish an active Individual Submission and related public specifications, not IETF consensus, an RFC for Vaara Receipt, working-group adoption, independent audit, broad deployment, complete coverage, a trustworthy timestamp authority, a closed decision boundary or an observed action result. This Article owns only revision 12's interior-gap, tail-seal and external-anchor boundary.