Transformation Evidence and Coverage Reconciliation for Auditable Data Disclosure
draft-dogru-scitt-disclosure-evidence-00

SCITT                                                           E. Dogru
Internet-Draft                                      VERAX TEKNOLOJI A.S.
Intended status: Standards Track                          15 August 2026
Expires: 16 February 2027

 Transformation Evidence and Coverage Reconciliation for Auditable Data
                               Disclosure
                draft-dogru-scitt-disclosure-evidence-00

Abstract

   Audit receipts for automated data access attest to what a gateway
   recorded.  Two questions remain outside their reach: what was changed
   in the data before it was disclosed, and whether the set of receipts
   is complete with respect to the data source's own accounting of
   activity.  This document defines two evidence structures that answer
   those questions: Transformation Evidence, a per-disclosure statement
   of which classes of values were transformed and how, carrying counts
   and class names but never values; and Coverage Reconciliation, a
   procedure and result statement that compares a source's own activity
   counters against a receipt set over a time window and reports
   activity for which no receipt exists.  Both structures are designed
   to be registered as Signed Statements on a Transparency Service as
   described in the SCITT architecture.  This document defines evidence
   payloads; it does not define a new receipt format, a new transparency
   mechanism, or a new signature format.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 February 2027.

Dogru                   Expires 16 February 2027                [Page 1]
Internet-Draft             Disclosure Evidence               August 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  What these structures do not claim  . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Transformation Evidence . . . . . . . . . . . . . . . . . . .   5
     3.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Structure . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Serialization and digests . . . . . . . . . . . . . . . .   6
     3.4.  What Transformation Evidence does not prove . . . . . . .   6
   4.  Coverage Reconciliation . . . . . . . . . . . . . . . . . . .   6
     4.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Activity snapshots  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Reconciliation procedure  . . . . . . . . . . . . . . . .   7
     4.4.  Result statement  . . . . . . . . . . . . . . . . . . . .   8
     4.5.  Semantics of "not receipted"  . . . . . . . . . . . . . .   9
   5.  Registration on a Transparency Service  . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

Dogru                   Expires 16 February 2027                [Page 2]
Internet-Draft             Disclosure Evidence               August 2026

1.  Introduction

   Systems that place a policy gateway between an automated client (for
   example, an AI assistant) and a data source increasingly emit signed,
   hash-chained access receipts.  Several receipt formats exist.  They
   share a property that limits what they can prove: a receipt is
   evidence produced by the party that performed the access, about an
   event that party chose to record.

   Two gaps follow from that property.

   First, receipts typically state that access happened and under which
   policy decision, but not what happened to the data between the source
   and the client.  When a gateway masks, redacts, or tokenizes values
   before disclosure, that transformation is the substance of the
   privacy claim the operator makes — and it is precisely the part a
   conventional receipt does not describe.  An auditor reading such a
   receipt learns that a table was read, but not whether the protected
   columns in it left the gateway transformed or in the clear.

   Second, a set of receipts, however well chained and anchored, only
   covers the accesses for which receipts were produced.  A client that
   reaches the data source without passing through the gateway produces
   no receipt, and no property of the receipt chain reveals this.  Hash
   chains detect removal and reordering of records that exist; they are
   silent about records that were never created.  Establishing
   completeness requires a second account of activity, produced by a
   party other than the gateway: the data source itself.

   This document defines two evidence structures addressing these gaps:

   *  Transformation Evidence (Section 3): a statement, bound to a
      single disclosure, of which classes of values were transformed
      before disclosure, by which action, and in what count.  It never
      carries the values themselves.

   *  Coverage Reconciliation (Section 4): a procedure that compares
      snapshots of a data source's own activity counters, taken at the
      boundaries of a time window, against the receipt set for that
      window, and a signed result statement reporting activity patterns
      for which no receipt exists.

Dogru                   Expires 16 February 2027                [Page 3]
Internet-Draft             Disclosure Evidence               August 2026

   Both structures are payloads.  They are intended to be carried in
   Signed Statements and registered on a Transparency Service as
   described in the SCITT architecture [RFC9943], which supplies the
   append-only, third-party-auditable registration this document
   deliberately does not reinvent.  This document defines no new receipt
   format, no policy evaluation semantics, and no transparency
   mechanism.

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
   (Section 3.4).  A Coverage Reconciliation result reporting
   unreceipted activity is a statement about absent evidence; it is not,
   and MUST NOT be presented as, proof of intent or of a breach
   (Section 4.5).

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The following terms are used throughout:

   Data Source:  The system holding the data, with its own accounting of
      query or access activity (for example, a database's statement
      statistics).

   Gateway:  The component that mediates access between an automated
      client and a Data Source, applies policy, transforms results, and
      emits receipts.

   Disclosure:  A single delivery of data (possibly transformed) from
      the Gateway to a client.

   Receipt:  A signed record of a Disclosure produced by the Gateway.
      This document is agnostic to the receipt format in use.

   Protected Class:  A named category of values that policy subjects to
      transformation (for example, "email", "national-id", "phone").

   Window:  A time interval over which reconciliation is performed,
      bounded by two snapshots of the Data Source's activity counters.

Dogru                   Expires 16 February 2027                [Page 4]
Internet-Draft             Disclosure Evidence               August 2026

3.  Transformation Evidence

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.

Dogru                   Expires 16 February 2027                [Page 5]
Internet-Draft             Disclosure Evidence               August 2026

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.  It is proof of applied transformation, no more.  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.  Coverage Reconciliation

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.

Dogru                   Expires 16 February 2027                [Page 6]
Internet-Draft             Disclosure Evidence               August 2026

   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.

Dogru                   Expires 16 February 2027                [Page 7]
Internet-Draft             Disclosure Evidence               August 2026

   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 covers access to 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 fails the reconciliation
   with its own report.

   Each active pattern receives one of three outcomes:

   covered:  At least one Receipt in the Window covers the objects this
      pattern touches.

   not-receipted:  No Receipt in the Window covers this pattern's
      objects.

   unattributable:  The pattern's target objects could not be
      determined.

   The reconciliation as a whole succeeds only if every active pattern
   is covered.

4.4.  Result statement

   The reconciliation result is a JSON object:

   v:  coverage-reconciliation/1.

   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).

   outcome:  covered, unreconciled, or invalid-window.

   unreconciled:  When outcome is unreconciled: the list of pattern
      digests with outcome not-receipted or unattributable, each with
      its outcome.  Pattern digests, not pattern text, for the reasons
      in Section 4.2.

Dogru                   Expires 16 February 2027                [Page 8]
Internet-Draft             Disclosure Evidence               August 2026

   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.5.  Semantics of "not receipted"

   A not-receipted 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.  A result statement MUST
   NOT label unreceipted 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.

   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.

5.  Registration on a Transparency Service

   Both structures defined here are payloads for Signed Statements in
   the sense of the SCITT architecture [RFC9943].  An Issuer (the
   Gateway operator for Transformation Evidence; the reconciling party
   for a Coverage Reconciliation result) signs the serialized structure
   and registers the Signed Statement on a Transparency Service,
   obtaining a Receipt in the SCITT sense: proof of the statement's
   inclusion, at a position, in an append-only log operated by a party
   other than the Issuer.

   This layering is deliberate.  The structures in this document gain
   their audit value from being registered somewhere the Issuer cannot
   quietly rewrite; SCITT already defines that somewhere, together with
   its trust model and verification procedures.  This document therefore
   defines no countersignature, no anchoring, and no log format of its
   own.  Where this document's mechanisms speak of digests binding
   evidence to receipts, the binding survives registration unchanged:
   digests are over the payload, not the envelope.

6.  Security Considerations

   Same-operator collusion.  In many deployments the Gateway and the
      Data Source are operated by the same party.  Coverage
      Reconciliation's value against that party is reduced: an operator
      with administrative access to the source's accounting can suppress

Dogru                   Expires 16 February 2027                [Page 9]
Internet-Draft             Disclosure Evidence               August 2026

      the counters themselves.  The mandatory invalid-window rule
      (Section 4.3) turns counter resets into visible failures, and
      registration (Section 5) makes suppression of already-issued
      results detectable, but an operator who controls both accounts and
      never registers anything is outside this mechanism's reach.
      Deployments needing assurance against the operator itself require
      an accounting path the operator cannot write to; that is a
      deployment property, not a payload property.

   Counter manipulation.  An attacker who can reset or rewind source
      counters could otherwise hide activity between snapshots.  The
      MUST-fail rule exists for this case: a Window containing a
      regression is reported unreliable in its entirety.  Snapshot
      frequency bounds the exposure — shorter Windows mean a reset costs
      the attacker a visible failure sooner.

   Digest agility.  Digests are prefixed (Section 3.3); an
      implementation MUST reject unknown prefixes.  Accepting an unknown
      prefix as an opaque match would let an attacker route around
      comparison.

   Signature and key compromise.  Signing and registration are inherited
      from the SCITT layer; key management, revocation, and the
      consequences of Issuer key compromise are governed there, not
      here.  A compromised Issuer key voids the evidentiary value of
      statements under that key, as it does for any signed artifact.

7.  Privacy Considerations

   Every structure in this document was shaped by one rule: evidence
   about protected data must not itself become a disclosure channel.
   Transformation Evidence carries class names, action names, and counts
   — never values.  Request and pattern references are digests because
   query and pattern text can embed values and schema detail.  Class
   names and counts do reveal that data of a class was present in a
   result in a given quantity; deployments for which even that is
   sensitive can keep the payloads private and register only their
   digests, at the cost of making third-party audit a permissioned
   rather than public act.

8.  IANA Considerations

   This document, if progressed, will request registration of two media
   types: application/transformation-evidence+json and application/
   coverage-reconciliation+json, with the structures of Section 3.2 and
   Section 4.4 as their content.  No registrations are requested at this
   stage.

Dogru                   Expires 16 February 2027               [Page 10]
Internet-Draft             Disclosure Evidence               August 2026

9.  Implementation Status

   _This section is to be removed before publication as an RFC, per
   [RFC7942]._

   One implementation of both mechanisms exists: the Conarium gateway
   (TypeScript, MIT license, @conarium-ai/core on npm), in production at
   one site since July 2026.  Its receipts carry per-class masking
   counts as in Section 3; its conarium-reconcile tool implements the
   procedure of Section 4.3 against PostgreSQL statement statistics, as
   a single file with no dependency on the package, so that a third
   party can run the reconciliation without trusting the implementation
   under audit.  Its exit codes distinguish "covered", "unreconciled
   activity", and "window unreliable" exactly as Section 4.4 does.
   Conformance test vectors ship with the package.

10.  References

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>.

Dogru                   Expires 16 February 2027               [Page 11]
Internet-Draft             Disclosure Evidence               August 2026

   [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>.

Acknowledgments

   The discipline of stating what each structure does not prove is owed
   to every auditor who has been handed a green dashboard and asked to
   trust it.

Author's Address

   Emekcan Dogru
   VERAX TEKNOLOJI A.S.
   Email: dogrucanemek@gmail.com

Dogru                   Expires 16 February 2027               [Page 12]