Transformation Evidence and Coverage Reconciliation for Auditable Data Disclosure

1.1. What these structures do not claim

Both structures are designed around a discipline of stating the limits of their own evidence. Transformation Evidence describes the disclosure surface; it does not claim a value is unlearnable, and it is the Issuer's signed assertion that a transformation was applied rather than proof that it was (Section 3.4). A Coverage Reconciliation result reporting activity without a receipt is a statement about absent evidence; it is not, and MUST NOT be presented as, proof of intent or of a breach (Section 4.7).¶

Neither structure reports a bare pass. A reconciliation computed against an operator-declared correspondence cannot yield an outcome stronger than that declaration (Section 4.4), and an outcome the evidence does not decide is reported as undecided rather than folded into a proportion.¶

1.2. Relationship to coverage attestation

A record can be intact and silent about what is missing from it. A report can be complete and silent about what it examined. These are two failures rather than one, and they are closed in different places.¶

This document is about the first. It states what a mediator recorded, what its record leaves open, and refuses to let the second question be answered by the shape of the first: a chain that verifies says nothing about the entries that were never written, and the vocabulary here exists so that a record can say so in its own terms rather than by omission.¶

The second belongs to coverage attestation, where an examination declares the population it drew from, the basis on which that population was determined, and an individual accounting for every unit it did not examine. Work on that layer is under way on this list.¶

The two compose in one direction and substitute in neither. A coverage attestation states what was examined; the structures here state what the examination's mediator recorded of it. An attestation over a mediated examination inherits whatever the mediator's record leaves open, and inherits it silently unless the record says so, which is the failure this document names. In the other direction, a complete and honest access record over an examination whose population was chosen after the results were known is an exact record of a question that was already decided.¶

Neither layer rescues the other. A reader given one has half an answer to a question they were not told had two halves.¶

3.1. Purpose

Transformation Evidence answers, for one Disclosure: which Protected Classes were transformed in the disclosed result, by which action, and in what count. It exists so that the transformation claim is a first-class, signed, registrable artifact rather than prose in an operator's documentation.¶

3.2. Structure

Transformation Evidence is a JSON object with the following members:¶

v:

Structure version string. For this document: transformation-evidence/1.¶

disclosure:

A digest binding this evidence to exactly one Disclosure, computed over the receipt for that Disclosure (or, where the receipt format defines a canonical record hash, that hash). Digest form is defined in Section 3.3.¶

request:

A digest of the request that produced the Disclosure. The digest of the request, never the request text: query text can itself contain protected values.¶

policy:

An object with id (an identifier of the policy version applied) and decision (the policy outcome under which disclosure proceeded).¶

classes:

An array of objects, one per Protected Class that the applied policy recognizes and that occurred in the disclosed result, each with:¶

class:

The Protected Class name, as named by the policy.¶

action:

One of mask, redact, tokenize, truncate, or none. The value none states that the class occurred and was disclosed untransformed — an honest statement some deployments need to make.¶

count:

The number of values of this class in the disclosed result to which the action was applied.¶

The structure MUST NOT carry data values, transformed or otherwise. Only class names, action names, counts, digests, and identifiers appear. An implementation encountering a value in a field defined here MUST reject the structure.¶

3.3. Serialization and digests

For digesting and signing, the structure is serialized with the JSON Canonicalization Scheme [RFC8785]. Digests in this document are SHA-256 and are written as strings prefixed with sha256: followed by lowercase hexadecimal. Future documents may register alternative digest prefixes; an implementation MUST reject a digest whose prefix it does not recognize rather than guessing.¶

A CBOR/COSE serialization [RFC9052] of the same data model is expected to be specified once the JSON model has received review; nothing in the model depends on JSON specifically.¶

3.4. What Transformation Evidence does not prove

Transformation Evidence describes the disclosure surface of one result. It does not state that a protected value is unlearnable by the client. In particular, where the request language permits predicates over protected columns, an allowed request can answer questions about a masked value without the value ever being disclosed (a result-count of one versus zero is one bit of the value). Transformation Evidence for such a Disclosure is accurate — the value was transformed in the result — and still compatible with the client having learned something about the value.¶

Consumers MUST NOT present Transformation Evidence as proof of non-exposure. Nor is it proof that the transformation was applied: the payload is a signed assertion by the Issuer that it was. Unless a Verifier independently establishes that the disclosed bytes carry the transformation the Issuer describes, the evidence available is evidence of what the pinned Issuer asserted. Where the Issuer is the Gateway that performed the transformation, that assertion is self-attested, and a consumer who treats it as verified has removed the Issuer from the trust statement without replacing it with anything. A deployment whose requirement is that a class be unlearnable rather than hidden must enforce that requirement in policy (for example, by not allowing the objects that carry the class at all); no evidence structure substitutes for that enforcement.¶

The classes array is bounded by what the applied policy recognizes. A value belonging to a class the policy does not name is not counted. The absence of a class from the array is therefore a statement about the policy's vocabulary as much as about the data, and MUST be read that way.¶

4.1. Purpose

Coverage Reconciliation answers, for one Window: did the Data Source's own accounting record activity for which no Receipt exists? It is the mechanism by which "the gateway was bypassed" or "the receipt sink failed" becomes detectable, rather than invisible.¶

The essential property is that the two accounts being compared originate from different components: the receipt set from the Gateway, the activity counters from the Data Source. A Gateway cannot make bypassed activity disappear from an account it does not produce.¶

4.2. Activity snapshots

A snapshot is a JSON object capturing the Data Source's cumulative activity counters at a point in time:¶

v:

Snapshot version string. For this document: activity-snapshot/1.¶

ts:

The time the snapshot was taken (ISO 8601).¶

source:

An identifier of the Data Source and the accounting scope within it (for example, the database role whose activity is counted). Both snapshots of a Window MUST carry the same source; a mismatch invalidates the Window.¶

entries:

An array of objects, one per activity pattern the source's accounting distinguishes, each with:¶

pattern:

A digest of the normalized activity pattern (for example, a normalized statement with constants removed). The digest, not necessarily the text: pattern text can embed protected values and schema detail. Deployments MAY retain pattern text privately for diagnosis; only the digest is required here.¶

count:

The cumulative counter value for this pattern at ts.¶

4.3. Reconciliation procedure

Given a start snapshot, an end snapshot, and the receipt set for the Window, a reconciler proceeds as follows.¶

Window validity is checked first. The two snapshots MUST carry the same v and source, the end ts MUST be later than the start ts, and no pattern's counter may be lower at the end than at the start. A counter regression means the source's accounting was reset or altered inside the Window; the Window is then unreliable, and the reconciler MUST report failure for the Window as a whole rather than reconciling the surviving patterns. An attacker who can reset counters must gain an error, not a clean report.¶

Window membership is itself a bound, and it is decided across two clocks. The snapshot timestamps are taken by the Data Source; a Receipt's timestamp is written by the Gateway. Admitting Receipts on an exact comparison between them makes the failure asymmetric: a Gateway clock trailing the Data Source moves a Receipt that names the object out of the Window, and the object it would have accounted for becomes activity for which no Receipt exists. That outcome is the one whose semantics name gateway bypass (Section 4.7), so a clock difference of seconds can produce the accusation rather than any real gap. The difference measured where this was found was three seconds; nothing in the procedure sets a floor below which it stops happening, and a smaller one is correspondingly harder for a reader to suspect.¶

A Mapping Profile therefore declares the clock source on each side and the skew bound between them, as it declares multiplicity (Section 4.4), and both are covered by the profile digest as every other part of it is. Where the bound is undeclared, the rule below applies and the affected items are indeterminate rather than absent evidence. Where it is declared and a Receipt falls further outside the Window than the bound allows, the boundary does not explain it: the item takes the outcome it would have had, and a reconciler MUST report which bound it applied to reach that.¶

For each pattern whose counter increased during the Window, the reconciler attributes the pattern to the data objects it touches and checks whether any Receipt in the Window names those objects. Matching is per pattern and per data object, not per call count: one client-level request may legitimately produce more than one source-level statement, so call counts and receipt counts MUST NOT be compared one-to-one. A pattern whose target objects cannot be determined MUST NOT be silently ignored; it receives the indeterminate outcome below.¶

The comparison is between two populations — source-level activity and Receipts — and neither population is assumed complete. Each item in either population receives exactly one of the following outcomes:¶

matched:

The item corresponds to an item in the other population within the bounds of the applicable Mapping Profile (Section 4.4), and within the Window. The profile's two kinds of bound do not act alike here: a multiplicity bound admits items to this outcome, and the skew bound does not. A Receipt outside the Window is never matched, however small the declared skew — the bound qualifies how far the boundary can be trusted, not where the boundary is.¶

observed-without-receipt:

The Data Source recorded activity against an object that no Receipt in the Window names.¶

receipted-without-observation:

A Receipt in the Window names an object for which the Data Source's counters record no activity.¶

excluded:

The item was removed from comparison before matching by a rule stated in the Mapping Profile (Section 4.5).¶

indeterminate:

The evidence or the Mapping Profile does not determine an outcome — the pattern's objects could not be attributed, a required multiplicity or skew bound is undeclared, the item's only naming Receipt falls outside the Window, or the Window's evidence is insufficient to decide.¶

An implementation MUST NOT report an item as matched when the outcome is indeterminate; the absence of a decision is not a decision. In particular, where a Mapping Profile does not declare the multiplicity bound that the comparison requires, the affected items are indeterminate and not clean coverage.¶

The same rule binds the temporal bound, in the opposite direction. Where every object an item leaves unaccounted for is named by a Receipt that falls outside the Window, the item is indeterminate, and an implementation MUST NOT report it as observed-without-receipt. A reconciler cannot distinguish a Gateway clock that trails the Data Source from a Receipt written late, and reporting absent evidence asserts a distinction it did not make. An item that leaves even one object named by no Receipt at all is not affected by this rule: that is a genuine absence, and a neighbouring object's clock does not make it undecidable.¶

indeterminate here is not a weaker pass. The comparison did not come out clean, and a result statement MUST carry the outcome and the offset that produced it. What the implementation is forbidden to do is state the cause.¶

A reconciliation with no observed-without-receipt items establishes that each observed source-level item is attributable to a Receipt naming the same object, under the declared correspondence. It does not establish that every source-level statement was itself receipted, and a result MUST NOT be stated in terms that assert it. Where one Receipt naming an object clears an unbounded number of further statements against that object inside the Window, the procedure has established object attribution and nothing stronger.¶

4.4. Mapping profiles

One client-level operation may produce several source-level statements. The multiplicity is not a property of the Gateway; it is a property of the deployment — the version of the intermediary in front of the Data Source, a connection pooler, an object-relational mapper. A Gateway cannot measure a correspondence it does not produce.¶

A Mapping Profile is therefore declared by the operator. It states, for each client-level operation it covers, the expected bounded set of source-level patterns, the bound on their multiplicity, and the exclusion rules applied before comparison (Section 4.5). It carries a version identifier and is serialized and digested as in Section 3.3.¶

The profile also declares the temporal correspondence, for the same reason it declares the multiplicity one: the operator knows it and the Gateway cannot measure it. It states the clock source on each side — the one the Data Source stamps snapshots with, and the one the Gateway stamps Receipts with — and the skew bound between them. Both are operator statements and carry that standing under the rule below, including a declaration that the two sides read one clock and the bound is therefore zero. That declaration is still a declaration: one clock read twice is not read at the same instant, and whether the residue matters is a judgement about the deployment. What the rule below forbids is presenting it as measured, and what this document refuses is the third case — zero because nobody looked, declared by nobody, and read by the reconciler as agreement.¶

The temporal correspondence is declared in three fields, under a clocks member of the profile. They are given here with their encoding so that a specification defining a different mapping structure can adopt the same shape rather than a second one:¶

clocks.observation:

String. An identifier for the clock that stamps the activity snapshots — the Data Source side.¶

clocks.receipt:

String. An identifier for the clock that stamps Receipts — the Gateway side.¶

clocks.skew:

Duration. The bound on how far those two clocks may differ. A duration is a decimal integer with a unit suffix of ms, s, m, or h, or a bare decimal integer read as milliseconds: 500ms, 5s, 2m, 1h, 5000. A duration that does not parse is an error, not a default.¶

An implementation MUST reject a clocks member carrying any key other than these three, and SHOULD name the key it rejected. A profile whose fourth field is silently ignored declares less than its author believes it declares, and the difference surfaces as an outcome the operator cannot account for.¶

A declaration that both sides read one clock writes all three fields: the two identifiers may be the same string, and skew may be 0ms. A declared zero is a statement someone is accountable for; an assumed zero is the condition the rule below forbids.¶

Where the skew bound is declared twice — in the profile and through an interface of the reconciler's own — an implementation MUST NOT select between them. Two declarations that parse to the same number of milliseconds are one declaration and proceed. Two that do not are an operator error and MUST fail, because which declaration prevailed would not be visible on the result, and a bound whose origin cannot be read from the result is not usefully declared at all.¶

A reconciliation result computed against a Mapping Profile MUST bind that profile's digest, and MUST state, for each bound it relies on, whether the bound is protocol-defined, measured, operator-declared, or undeclared. A result MUST NOT present an operator-declared bound as a measured one.¶

The consequence is a ceiling: a coverage outcome computed against a declared correspondence cannot be stronger than the declaration. Where the declaration is an operator statement, the outcome inherits that standing and the result statement is required to show it. This is the same discipline this document applies to absent evidence in Section 4.7, one layer up: a declaration presented as a measurement is an overclaim regardless of whether the declaration happens to be true.¶

Where a required multiplicity bound is undeclared, the affected items are indeterminate (Section 4.3). An implementation MUST NOT substitute a default bound of one; a one-to-one rule reports false observed-without-receipt items on any deployment with a pooler in front of the Data Source, and a silent default would make that error look like a finding.¶

An undeclared skew bound is treated the same way, and for the same reason. An implementation MUST NOT substitute a default of zero: zero asserts that the two clocks agree, which is the assumption that produces the false accusation this document now guards against. It MUST NOT substitute a bound of its own choosing either, which would decide the operator's question with a number the operator never saw. Absent the declaration, items whose only naming Receipt sits outside the Window are indeterminate and the result reports the offset, leaving the reader to compare it against clocks the reader knows and the reconciler does not.¶

An implementation MAY, absent a declared bound, decline to offer the boundary as the explanation for an offset larger than the Window itself, on the ground that a boundary artefact cannot exceed the interval it bounds. This is a reporting choice about what an implementation is willing to suggest, not a change of outcome: the item is indeterminate either way.¶

4.5. Exclusions

Exclusion differs from the other outcomes in kind. matched, observed-without-receipt, receipted-without-observation, and indeterminate are produced by the comparison. excluded is a decision taken before it, about what will be compared at all. It is therefore the outcome through which a reconciliation can be made to come out clean, and it requires the tightest reporting rules of the five.¶

Exclusion rules MUST be stated in the Mapping Profile and are therefore covered by its digest. A result statement MUST report the count of excluded items and the rule that excluded each of them. An implementation MUST NOT exclude items by a rule that is not in the profile.¶

Without these constraints, a clean result and a result cleaned by exclusion are indistinguishable to a reader, and the digest that is supposed to pin what was compared does not cover the step that decided what was compared. Session or catalog housekeeping is a legitimate exclusion; the requirement is not that exclusions be rare, but that they be visible and pinned.¶

The boundary of what pinning achieves is worth stating, because it is easy to read as more. Carrying the rule identifier makes the exclusion reproducible: a reader can see which rule removed each item and confirm that the rule was in the profile the digest covers. It does not establish that the exclusion was correct. A rule that removes session housekeeping and a rule that removes the very statements an auditor came to examine are pinned identically and verify identically; the mechanism reproduces the decision, it does not judge it. Consumers MUST NOT read a pinned exclusion as a justified one, and a result statement MUST NOT present the digest as evidence that the exclusions were appropriate. This is the same distinction this document draws between a declared bound and a measured one (Section 4.4), applied to the step that decides what is compared at all.¶

4.6. Result statement

The reconciliation result is a JSON object:¶

v:

coverage-reconciliation/2. The outcome vocabulary of coverage-reconciliation/1 is not a subset of this one: a /1 result reporting covered asserts more than the procedure establishes, and is not re-expressible here. A consumer MUST NOT read a /1 result as a /2 result.¶

window:

Object with start and end (the two snapshot ts values).¶

source:

The common source identifier of the two snapshots.¶

snapshots:

Object with start and end digests of the two snapshot structures.¶

receipts:

A digest identifying the receipt set that was compared (for chained receipt formats, the chain head digest and the sequence range are RECOMMENDED as the identifying material).¶

A result SHOULD state whether that identifying material was obtained independently of the Issuer or read from the receipt set itself. The two are not equivalent evidence, and a Consumer cannot tell them apart from the digest (Section 6.1).¶

profile:

The digest and version identifier of the Mapping Profile the comparison was computed against (Section 4.4), or null when none was declared. When null, every item whose outcome depends on a multiplicity bound is indeterminate, and so is every item whose only naming Receipt falls outside the Window: with no profile there is no declared skew bound either.¶

bounds:

For each bound the comparison relied on, its source: protocol-defined, measured, operator-declared, or undeclared. A result whose bounds are operator-declared states an outcome of that standing, no stronger.¶

outcome:

invalid-window when the Window is unreliable (Section 4.3); otherwise no-exceptions when every item is matched or excluded, and exceptions when any item is observed-without-receipt, receipted-without-observation, or indeterminate.¶

The name states what the comparison left open, not what it proved. A result MUST NOT carry an outcome name that asserts coverage of the source activity, and no-exceptions is not such an assertion: it says the comparison produced no open item under the declared correspondence, which is bounded by that correspondence (Section 4.4) and by the fact that neither population is assumed complete.¶

items:

The list of items whose outcome is not matched, each with its outcome and, for excluded, the profile rule that excluded it. Pattern digests, not pattern text, for the reasons in Section 4.2.¶

counts:

The number of items in each outcome, including matched and excluded. An implementation MUST NOT aggregate indeterminate items into a proportion of coverage: an outcome that does not decide cannot be averaged into one that does, and reporting it as a percentage restores precisely the overclaim this vocabulary exists to prevent.¶

A result carries matched as a count while carrying every other outcome as an accounting, and the asymmetry is deliberate. A count a reader cannot reconstruct is an assertion about a population the producer alone can see. This one is not that: the result digests both activity snapshots and the receipt set it compared (Section 4.2, Section 3.3), and a reader holding those inputs recomputes the matched set exactly rather than being told its size. The count is a convenience over material the reader already has.¶

That property fails in one identified case, and it is the case this document already names. Where the identifying material for the receipt set was read from the receipt set itself rather than obtained independently of the Issuer (Section 6.1), a reader recomputing from material the Issuer chose recomputes the Issuer's answer. The digest is then a check on transcription and not on completeness, and the matched count inherits that standing.¶

The result statement is serialized and digested as in Section 3.3 and is intended to be signed by the reconciling party and registered (Section 5). The reconciler SHOULD be operationally independent of the Gateway; where it is not, registration on a Transparency Service at least makes the result's existence and timing third-party-visible.¶

4.7. Semantics of the outcomes

An observed-without-receipt outcome is a statement that evidence is absent, not a statement about why. Gateway bypass, receipt sink failure, and accounting scope mismatch all produce it. So does a Receipt that exists and names the object but carries a timestamp the Window's own two clocks put outside it — which is why Section 4.3 removes that case from this outcome rather than listing it as one more cause. It is named here because the earlier revision of this document listed the mirror condition under receipted-without-observation and not this one, and a reader comparing the two lists should see that the omission was corrected rather than assume the boundary distorts only one direction. A result statement MUST NOT label such activity as an intrusion, a breach, or an intentional act, and consumers MUST NOT present it as such. The value of the mechanism is precisely that it surfaces the condition; attributing cause is investigation, not reconciliation.¶

A receipted-without-observation outcome is likewise a statement about evidence, and it is not by itself a fault. A counter reset at the Window boundary, an intermediary that collapses statements, and an increment that lands outside the snapshot pair all produce the same shape as a receipt describing activity that did not occur. An implementation MAY treat it as a failure condition under a policy of its own; this document does not define it as one, because the shape does not distinguish the cases.¶

An indeterminate outcome is a result, not a degraded pass. It MUST NOT be resolved by assumption in either direction: neither counted as matched because nothing contradicts it, nor reported as missing activity because nothing confirms it. An implementation under pressure to produce a single number will be tempted to fold indeterminate into a coverage proportion; that operation destroys the only property that distinguishes this vocabulary from a bare pass, and MUST NOT be performed.¶

Verification of receipt signatures and chain integrity is out of scope for reconciliation and is assumed to have happened first, under the rules of the receipt format in use. Reconciliation compares an already-verified receipt set against source accounting; it does not re-verify.¶

6.1. Receipt set completeness and where the expected count comes from

A receipt set whose most recent entries have been removed is internally consistent. Every remaining link verifies, every signature checks, and nothing in the file states how many entries it should have contained. Reconciliation does not close this: it compares the receipt set against source accounting, and an operator who can truncate the one can generally suppress the other. Detecting the removal requires a count, a head digest, or an equivalent quantity that does not come from the truncated file.¶

What matters to a Consumer is not that such material exists but where it arrives from, and the two available constructions differ in a way a digest does not reveal.¶

An implementation may accept the expected quantity as an input to its verifier. The check then works exactly as well as the input is trustworthy, and an auditor holding only the receipt file has no source for it except the Issuer — the party whose behaviour is being examined. The verification is real; its independence is supplied by whoever ran it, and is not a property of the artifacts.¶

An implementation may instead carry the quantity inside the signed material, so that the set testifies to its own extent. This closes the gap the first construction leaves open, at a cost that should be stated: the Issuer is now signing an assertion about a population it has not finished producing, and a counter carried per entry constrains only the entries that were kept unless the format also seals a total. A running count that is derived from the sequence number it accompanies adds no information at all — it restates the position of a record that is present, and says nothing about one that is absent. The property worth having is a sealed quantity over a set held by someone, not a per-record decoration.¶

This document requires neither construction. It requires that a result identifying a receipt set be readable as to which one it relied on, because a Consumer who cannot tell the difference will read an externally supplied pin as though the receipt set had proved its own completeness, which is the strongest claim in this area and the one least often actually made.¶

10.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

10.2. Informative References

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.