Network Working Group                                             S. Mih
Internet-Draft                                  Action State Group, Inc.
Intended status: Informational                            3 October 2026
Expires: 6 April 2027


                             Evidence Layer
                   draft-mih-agent-evidence-layer-00

Abstract

   This document defines the evidence layer: the conformance
   requirements for a local evidence store that records evidence and the
   relationships between records, keeps digests committed while payloads
   are separately referenced, and preserves how each record came to be
   known well enough that a later reader can tell an observation from a
   claim.  This document defines the record model, typed links between
   records, disclosure and retention semantics, the three classes of
   index a store may maintain, and the minimum interface any commitment
   substrate must supply for a store to conform to this layer.  It
   exists so that a request for evidence can be answered honestly from
   what a store actually holds, and so that an evidence bundle assembled
   in response is assembled from committed material rather than
   assembled and then made to look committed.  Conformance to this layer
   MUST NOT require any particular implementation or commitment
   substrate: a Checkpointed Local Log is one conforming profile;
   registration with a SCITT Transparency Service is another; any other
   append-only transparency log, or an implementer's own authenticated
   log, also qualifies.  This document defines neither evidence
   sufficiency policy, request routing, settlement, nor any specific
   host-identity, signing, payload-storage, or replication mechanism.

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 6 April 2027.



Mih                       Expires 6 April 2027                  [Page 1]

Internet-Draft               Evidence Layer                 October 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
   2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   4.  The Record Model  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Epistemic Type  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Typed Links . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Record/Payload Separation, Retention, and Disclosure  . . . .   9
     6.1.  Retention States  . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Disclosure Records  . . . . . . . . . . . . . . . . . . .  10
   7.  Index Classes . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  The Commitment-Substrate Interface  . . . . . . . . . . . . .  11
   9.  Answering a Request . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Three Kinds of "No" . . . . . . . . . . . . . . . . . . .  13
   10. Reconcile and Close . . . . . . . . . . . . . . . . . . . . .  14
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
     12.1.  What a Checkpoint Reveals  . . . . . . . . . . . . . . .  16
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     13.1.  Evidence Layer Epistemic Types . . . . . . . . . . . . .  18
     13.2.  Evidence Layer Link Types  . . . . . . . . . . . . . . .  19
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     14.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  22
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22










Mih                       Expires 6 April 2027                  [Page 2]

Internet-Draft               Evidence Layer                 October 2026


1.  Introduction

   A request for evidence ([I-D.mih-agent-evidence-request]) says how to
   ask.  An evidence bundle ([I-D.mih-zhang-agent-disclosure-bundle])
   says what a granting answer looks like.  Neither says what a
   responder must have held, and preserved, beforehand for that answer
   to be honest rather than assembled to order.  A responder that can
   produce a byte-identical artifact for any requester, refuse with a
   citable reason, or truthfully report that it has nothing needs a
   local substrate with specific properties: records that do not change
   meaning after the fact, a place to say how one record relates to
   another without editing either, and a way to distinguish "I have
   never had this" from "I once had this and no longer do" from "I have
   this and will not show you."

   This document names that substrate an *evidence store*, defines the
   *evidence layer* a store must conform to, and states nothing about
   how a store is implemented beyond that.  Conformance to the evidence
   layer MUST NOT require any particular implementation or commitment
   substrate: a Checkpointed Local Log
   ([I-D.mih-scitt-checkpointed-local-log]) is one mechanism satisfying
   the interface in Section 8; registration with a SCITT Transparency
   Service [RFC9943] is another; any other append-only transparency log,
   or an implementer's own authenticated log, also qualifies.

2.  Non-Goals

   This document deliberately does not define:

   *  *Evidence sufficiency, requirements, or verdicts.* Whether a set
      of records satisfies a requirement, and what a contract requires
      in the first place, is a policy layer that consumes what a store
      can produce.  It is out of scope here.

   *  *Request routing or transport policy.* How a request reaches a
      store, and what a store's operator decides to answer, are
      deployment and policy questions this document does not reach.

   *  *Settlement.* Any obligation, payment, or remedy that follows from
      a recorded fact is outside this document; a store records that
      something is true of its own history, never what should happen as
      a result.  Records of a settlement, such as those of
      [I-D.mih-agent-settlement-records], are ordinary records to a
      store.







Mih                       Expires 6 April 2027                  [Page 3]

Internet-Draft               Evidence Layer                 October 2026


   *  *A host-identity scheme.* What a principal_ref (Section 4) names,
      and how a party's key relates to any role or standing, is host- or
      deployment-defined.  This document states only what a
      principal_ref cannot be taken to mean (Section 11).

   *  *A signing, payload-storage, or replication mechanism.* How a
      record or a checkpoint is signed, how payload bytes are stored and
      retrieved by digest, and how records travel between stores,
      delivery intermediaries, or fleets are implementation seams a host
      plugs in beneath a conforming store.  This document does not
      define any of the three, and a store's conformance to this
      document does not depend on which implementation of any of them it
      uses.

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

   *Evidence layer:* the conformance requirements this document defines
   for a local evidence store — the record model, typed links,
   disclosure and retention semantics, the index classes, and the
   commitment-substrate interface.  Conformance to the evidence layer
   MUST NOT require any particular implementation or commitment
   substrate.

   *Evidence store (a "store"):* a local store that conforms to the
   evidence layer: it records evidence and typed links between records
   (Section 5), keeps a durable, append-ordered commitment to what it
   has recorded, and can answer a request against that commitment.  The
   subject of this document.

   *Record:* one committed entry in a store: a header (Section 4) and,
   optionally, digests referencing payload bytes held or resolved
   separately (Section 6).  A record MAY be an Agent Action Capsule
   [I-D.mih-scitt-agent-action-capsule]; this document does not require
   it.

   *Digest:* unless a deployment's evidence format states otherwise, the
   lowercase-hexadecimal SHA-256 digest of a value's canonical form —
   for a JSON [RFC8259] value, UTF8(JCS(value)) per [RFC8785].

   *Link:* a typed, directed reference from one record to another,
   itself part of a committed record and never a mutation of either
   record it relates (Section 5).



Mih                       Expires 6 April 2027                  [Page 4]

Internet-Draft               Evidence Layer                 October 2026


   *Commitment substrate:* the mechanism a store uses to assign append
   order to records and to produce checkpoints against which inclusion
   and consistency are checkable by a party other than the store
   (Section 8).

   *Checkpoint:* a value, produced by the commitment substrate, naming
   one committed state of a store's history at one point in time.

   *Epistemic type:* a closed value naming how a record's content came
   to be known or asserted, preserved end to end regardless of what is
   later signed or checkpointed about the record (Section 4).

   *Retention state:* a value naming whether, and how, a record's
   payload can currently be resolved to bytes (Section 6).

   *Transparency Service, Registration Policy, Receipt:* as defined in
   [RFC9943].  A Receipt [RFC9942] proves that a statement is included
   in a Transparency Service's log.  It proves nothing else: not
   consistency between two states of that log, and not that the
   statement is true.

   *Witness:* a party other than the store that receives the store's
   checkpoints and checks that each one extends the previous one it saw.
   A Transparency Service whose Registration Policy admits a checkpoint
   only when it is consistent with the previously registered one is one
   kind of witness.  "Witness" is not a term defined by [RFC9943].

   *Countersignature:* a signature over a record, or over a set of
   records, by a party other than its producer, made after that party
   independently recomputed named checks, in the manner of an Auditor
   [RFC9943].  It is not a Receipt and not a Transparency Service
   function.

   *Self-attested:* signed only by the record's own producer, with
   neither a witness nor a countersignature.

4.  The Record Model

   A record's durable header carries at least:












Mih                       Expires 6 April 2027                  [Page 5]

Internet-Draft               Evidence Layer                 October 2026


   record:
     seq: <substrate-assigned append position>
     record_id: <content-derived or profile-assigned identifier>
     record_type: <open token, e.g. "observation", "claim", "close">
     epistemic_type: <one of the eight values below>
     committed_at: <time this store committed the record>
     event_time_claim: <claimed time of the underlying event, if any>
     payload_commitments: [ <digest>, ... ]
     retention_state: <AVAILABLE|PARTIAL|WITHHELD|DELETED|LEGAL_HOLD>
     links: [ { type: <link type>, target: <digest> }, ... ]
     subject_ref: <opaque correlation identifier>
     principal_ref: <opaque identifier, scheme host-defined>

   seq, record_id, record_type, and epistemic_type are REQUIRED.
   retention_state is REQUIRED whenever payload_commitments is present.
   links is REQUIRED to be present, possibly empty, on any record that
   carries no separate representation of its typed links.  All other
   fields are OPTIONAL.  A profile or deployment MAY add further header
   fields; this document takes no position on their semantics, except
   that no additional field may change the meaning of record_id,
   epistemic_type, retention_state, or any committed link once the
   record exists.

   record_type is an open, deployment-extensible token describing what
   kind of thing a record is. epistemic_type is closed and is this
   document's central classification: it states how the record's content
   came to be known, independent of what the record is about.

   principal_ref is an opaque reference; the scheme that gives it
   meaning is host-defined and out of scope here (Section 2,
   Section 11). committed_at is this store's own local time of
   commitment and is never a substitute for event_time_claim, which is
   itself only a claim: nothing in this document verifies that an
   event_time_claim is accurate.

4.1.  Epistemic Type

    +=======================+=========================================+
    | Value                 | Meaning                                 |
    +=======================+=========================================+
    | observed_event        | directly observed by the recording      |
    |                       | system or actor                         |
    +-----------------------+-----------------------------------------+
    | system_of_record_fact | asserted by an external system of       |
    |                       | record                                  |
    +-----------------------+-----------------------------------------+
    | producer_claim        | asserted by the record's own producer,  |
    |                       | unverified by the store                 |



Mih                       Expires 6 April 2027                  [Page 6]

Internet-Draft               Evidence Layer                 October 2026


    +-----------------------+-----------------------------------------+
    | human_report          | asserted by a human, not machine-       |
    |                       | observed                                |
    +-----------------------+-----------------------------------------+
    | semantic_judgment     | a judgment or classification reached by |
    |                       | interpretation, not direct observation  |
    +-----------------------+-----------------------------------------+
    | derived_metric        | a value computed or aggregated from     |
    |                       | other records                           |
    +-----------------------+-----------------------------------------+
    | adjudication          | a ruling on a matter that was disputed  |
    |                       | or required judgment                    |
    +-----------------------+-----------------------------------------+
    | obligation_reference  | a reference to an obligation the record |
    |                       | does not itself discharge               |
    +-----------------------+-----------------------------------------+

                                  Table 1

   *epistemic_type is assigned once, at commit, and is never upgraded.*
   No signature, checkpoint, Receipt, witnessing, or countersignature
   attached to a record after it is committed changes what kind of
   statement it was when it was made, and neither does the assurance a
   record later reaches (self-attested, witnessed, or countersigned).
   Those attach to a record; they attest to who signed it and when it
   was committed.  They do not attest to how its content was known,
   which is what epistemic_type alone states.  A record misclassified at
   commit is corrected only by a later record (Section 6); the
   original's epistemic_type does not change.

   The registry for this value set is established in Section 13.

5.  Typed Links

   A link is a typed, directed reference from a record to a target
   record, identified by the target's digest:

   link:
     type: cites|adjudicates|supersedes|acknowledges|rebuts|closes
     target: <digest of the target record>











Mih                       Expires 6 April 2027                  [Page 7]

Internet-Draft               Evidence Layer                 October 2026


   *A link is itself part of a committed record and MUST NOT mutate its
   target.* The target's own header and commitment stand unchanged; a
   link adds a new, separately committed fact about a relationship
   between two records.  Multiple links, of the same or different types,
   MAY name the same target.  A link's carrying record has whatever
   epistemic_type (Section 4.1) accurately describes what asserting the
   link is; a record carrying an adjudicates link MUST have
   epistemic_type adjudication.

   The six link types are:

   *cites:* the carrying record's claim depends on, or is intelligible
   only with reference to, the target's committed content.  A cites link
   lifts nothing about the target beyond the target's own committed
   claim: it does not inherit whatever the target record itself cites,
   and a reader that wants to know what the target's own citations say
   must resolve them independently.

   *adjudicates:* the carrying record — necessarily epistemic_type
   adjudication — renders a judgment about the target's claim.  The
   judgment covers exactly the target's own committed claim.  It does
   not extend to claims made inside records the target itself cites; a
   citing record's adjudication is not an adjudication of what is cited
   two hops away.

   *supersedes:* the carrying record replaces the target's content for
   current use, without mutating the target.  The target's original
   commitment stands as part of the store's history; supersedes is how a
   store represents a correction as a new fact rather than an edit
   (Section 6).

   *acknowledges:* the carrying record states that its author has seen
   and holds the target — establishing receipt, not agreement.

   *rebuts:* the carrying record disputes the target's claim.

   *closes:* the carrying record — a Close record (Section 10) — binds a
   stated range or set of records as reconciled.

   A link type is closed vocabulary, registered in Section 13.  A
   deployment that needs a relationship this list does not name
   registers a new link type; it MUST NOT overload an existing token to
   mean something else for some of its records.

   These link types relate records of an evidence store.  They are
   distinct from the chain.relation and citation_purpose vocabularies of
   [I-D.mih-scitt-agent-action-capsule], which govern fields inside a
   Capsule.  The token supersedes appears in both this registry and



Mih                       Expires 6 April 2027                  [Page 8]

Internet-Draft               Evidence Layer                 October 2026


   chain.relation; the two are separate registrations, and neither
   defines the other.  When a store's records are Capsules, how each
   link type is carried in a Capsule's fields is not defined by this
   revision.

6.  Record/Payload Separation, Retention, and Disclosure

   A record's commitment — its presence in the store's committed
   history, its record_id, its digest — is permanent once committed and
   is never mutated.  Payload bytes are a separate, possibly-absent
   resource that payload_commitments point at by digest; a store's
   durable header commits to digests, never to storage locations, and
   losing or withholding payload bytes never un-commits the record that
   referenced them.

   A correction to a record's content is represented by a later record
   carrying a supersedes link (Section 5), or, where the change is to
   availability rather than content, by a lifecycle record changing
   retention_state.  Neither ever rewrites what was already committed.

6.1.  Retention States

    +=================+===============+===============================+
    | retention_state | Meaning       | Resolving the payload         |
    +=================+===============+===============================+
    | AVAILABLE       | the payload   | returns bytes                 |
    |                 | can be        |                               |
    |                 | resolved      |                               |
    |                 | under current |                               |
    |                 | policy        |                               |
    +-----------------+---------------+-------------------------------+
    | PARTIAL         | only some     | returns the remaining fields; |
    |                 | fields or     | the record's own digest still |
    |                 | preimages     | verifies against what existed |
    |                 | remain        | at commit time even though    |
    |                 |               | full reproduction is no       |
    |                 |               | longer possible               |
    +-----------------+---------------+-------------------------------+
    | WITHHELD        | the payload   | returns nothing; a policy     |
    |                 | may exist but | refusal, not a claim the      |
    |                 | the requester | payload is gone               |
    |                 | is not        |                               |
    |                 | authorized    |                               |
    +-----------------+---------------+-------------------------------+
    | DELETED         | the payload   | returns nothing; commitment   |
    |                 | was           | integrity survives, semantic  |
    |                 | intentionally | reproducibility does not      |
    |                 | destroyed or  |                               |



Mih                       Expires 6 April 2027                  [Page 9]

Internet-Draft               Evidence Layer                 October 2026


    |                 | has expired   |                               |
    +-----------------+---------------+-------------------------------+
    | LEGAL_HOLD      | deletion is   | behaves as AVAILABLE or       |
    |                 | suspended by  | PARTIAL per the payload's     |
    |                 | policy or     | actual state; the hold blocks |
    |                 | legal         | a future transition to        |
    |                 | requirement   | DELETED, it does not itself   |
    |                 |               | change resolvability          |
    +-----------------+---------------+-------------------------------+

                                  Table 2

   *WITHHELD MUST NOT be conflated with DELETED.* Both currently return
   no bytes; only one of them is permanent.  A party that needs to
   distinguish "ask again under different authorization" from "the bytes
   are gone" reads retention_state, never a resolution failure alone.  A
   responder answering an Evidence Request
   ([I-D.mih-agent-evidence-request]) for a WITHHELD payload MUST NOT
   refuse it with reason no_such_subject or retention_expired; those
   reasons state that the subject does not resolve or that retention has
   lapsed, which is the DELETED case.

6.2.  Disclosure Records

   A *disclosure record* documents an act of disclosing payload material
   — for example, when a store assembles the artifact response to a
   request ([I-D.mih-agent-evidence-request]) or the disclosures overlay
   of an evidence bundle ([I-D.mih-zhang-agent-disclosure-bundle]).  Its
   epistemic_type is producer_claim: it is the store's own statement of
   what it chose to reveal.  It carries:

   disclosure:
     payloads: all|selected
     suppressed_fields: [ <field name>, ... ]

   payloads states whether the disclosure carried all payload material
   the store chose to consider, or only a selected subset.
   suppressed_fields names fields intentionally not carried by this
   disclosure.  For any suppressed field the store chooses to
   acknowledge exists at all, the disclosure record MAY carry that
   field's committed digest rather than nothing: a withheld field
   disclosed with its digest is never reported as blank and never as if
   it did not exist, mirroring the target record's own WITHHELD handling
   above.







Mih                       Expires 6 April 2027                 [Page 10]

Internet-Draft               Evidence Layer                 October 2026


   For one Capsule, the Disclosure Envelope
   ([I-D.mih-agent-disclosure-envelope]) carries disclosed values beside
   the Capsule that commits to their digests.  A disclosure record is
   the store's own record that such a disclosure was made; it does not
   replace the envelope's own verification.

   A disclosure record carries a cites link to each record whose payload
   it discloses.  It states what was revealed about those records; it
   does not change their own retention_state, and it is not itself
   evidence that the underlying record is more, or less, available than
   its own retention_state says.

7.  Index Classes

   A store MAY maintain any or all of three classes of index over its
   committed records.  Each makes a different claim, and none MAY be
   substituted for another:

   1.  *Operational index.* Fast local query support — by record_id,
       subject_ref, or any other field.  Rebuildable from committed
       history at any time.  Carries no independent trust value: a
       result from an operational index is only as trustworthy as the
       store producing it, and is not itself checkable by a party that
       does not trust the store.

   2.  *Authenticated index.* A deterministic structure whose root is
       committed into the store's commitment substrate (Section 8).
       Supports membership, range, non-membership, and completeness
       properties that a party other than the store can check against a
       checkpoint, independent of trusting the store's own operational
       query results.

   3.  *Semantic or vector index.* Approximate discovery only, always
       rebuildable, and never proof of anything.  A result from a
       semantic index MUST NOT be cited as proof of completeness, and
       MUST NOT be cited as proof that a matched record is true — it is
       a way to find candidates, never a statement about what exists or
       what is correct.

8.  The Commitment-Substrate Interface

   A conforming store's commitment substrate MUST supply four
   properties, regardless of mechanism:

   1.  *Append order.* Each record receives a position in a monotonic
       order the substrate itself assigns and fixes; the store does not
       renumber positions after the fact.




Mih                       Expires 6 April 2027                 [Page 11]

Internet-Draft               Evidence Layer                 October 2026


   2.  *Inclusion.* For any committed record, the substrate can produce
       a proof that it occupies its stated position — checkable by a
       party that does not trust the store.

   3.  *Consistency / continuity.* The substrate can produce a proof
       that one checkpoint's committed state is a well-defined extension
       of an earlier checkpoint's, never a silent rewrite of history
       already committed.

   4.  *Checkpoint identity.* A checkpoint names one committed state by
       a value independent of the store that produced it, so a
       checkpoint obtained from any source — the store, a peer, a
       witness — identifies the same state.

   This document requires these four properties and no specific
   mechanism.  A Checkpointed Local Log
   ([I-D.mih-scitt-checkpointed-local-log]) is the worked example used
   throughout the evidence family: append, a Merkle Mountain Range, and
   periodic signed checkpoints supply all four locally.  Registration
   with a SCITT Transparency Service [RFC9943] is an alternate profile.
   The Transparency Service's log supplies append order and checkpoint
   identity, in place of a log the store itself maintains.  A Receipt
   [RFC9942] proves inclusion of a registered statement, and only
   inclusion.  Consistency comes from consistency proofs between two
   states of the Transparency Service's log, never from a Receipt.
   *Conformance to this document MUST NOT require any particular
   implementation or commitment substrate.* A Checkpointed Local Log,
   registration with a SCITT Transparency Service, any other append-only
   transparency log, or an implementer's own authenticated log all
   qualify: a store conforms by satisfying the four properties above
   under whichever substrate it uses, and states which substrate that
   is.

9.  Answering a Request

   [I-D.mih-agent-evidence-request] defines six subject forms and three
   mutually exclusive interaction outcomes.  This section states, for
   each subject form, the store-level capability that answers it — it
   does not restate that document's own rules about coverage anchors or
   refusal reasons.











Mih                       Expires 6 April 2027                 [Page 12]

Internet-Draft               Evidence Layer                 October 2026


   +==============+===================================================+
   | Subject      | Store capability                                  |
   +==============+===================================================+
   | record       | resolve one record by record_id/digest —          |
   |              | operational or authenticated index                |
   +--------------+---------------------------------------------------+
   | range        | resolve records at stated positions under the     |
   |              | substrate's append order, with an inclusion or    |
   |              | range proof from the authenticated index          |
   +--------------+---------------------------------------------------+
   | correlation  | resolve every record whose subject_ref (or an     |
   |              | equivalent correlation field) matches —           |
   |              | operational index                                 |
   +--------------+---------------------------------------------------+
   | exchange     | resolve every record carrying a cites link        |
   |              | (Section 5) whose target is the named exchange    |
   |              | half's digest                                     |
   +--------------+---------------------------------------------------+
   | full_history | the store's entire evidence body, subject to      |
   |              | whatever disclosure policy governs the            |
   |              | interaction (Section 6)                           |
   +--------------+---------------------------------------------------+
   | checkpoints  | the commitment substrate's checkpoints and any    |
   |              | Receipts or witness records for them (Section 8), |
   |              | requiring no record-level resolution              |
   +--------------+---------------------------------------------------+

                                 Table 3

9.1.  Three Kinds of "No"

   A store capable of producing these answers distinguishes three
   different things that could be reported as "no evidence for this
   subject":

   1.  *Non-membership:* a proof, from an authenticated index
       (Section 7), that no record occupies the stated position or
       carries the stated identity.  This is the only one of the three
       that is itself checkable by a party other than the store.

   2.  *Withheld:* a record or its payload exists but is not disclosed
       under current policy (Section 6).  This is a policy refusal, not
       an absence, and MUST NOT be reported as if the record did not
       exist.







Mih                       Expires 6 April 2027                 [Page 13]

Internet-Draft               Evidence Layer                 October 2026


   3.  *Asserted absence:* the store's own unproven claim that it holds
       no such record, offered when no authenticated index covers the
       subject.  This is a producer_claim about the store's local state;
       it is not proof, and it is not a claim about anything on the
       requester's side.

   None of the three is the "recorded absence" outcome of
   [I-D.mih-agent-evidence-request], which is the requester's own record
   that no response arrived.  A store that holds no such record answers
   with a signed refusal carrying reason no_such_subject; a store that
   withholds answers with a policy refusal.  Neither is ever reported as
   a recorded absence.

   A no_such_subject refusal ([I-D.mih-agent-evidence-request]) MAY be
   backed by a non-membership proof where the store's authenticated
   index supports one.  Where it does not, the refusal is honest only if
   the store does not present its own asserted absence as if it carried
   the same weight.

10.  Reconcile and Close

   Two independently held stores are compared under a declared contract
   or profile external to this document.  Comparing corresponding
   candidates assigns each pairing one of six states:

   *  MATCHED: both sides hold a corresponding record, and the records
      agree under the declared contract or profile.

   *  A_ONLY, B_ONLY: a corresponding record was found on one side only.

   *  CONFLICTING: both sides hold a corresponding record, and the
      records disagree.

   *  INSUFFICIENT: a candidate was found, but it lacks what the
      declared contract or profile needs in order to compare it.

   *  UNRESOLVED: the comparison was not, or could not be, decided.

   The precise rules for each state are those of the declared contract
   or profile.  These are per-pairing states.  They are not a judgment
   over the reconciliation as a whole, which is a policy layer this
   document does not define (Section 2).

   *One half unavailable is not disagreement.* A_ONLY and B_ONLY state
   that a corresponding record was not found on the other side — it may
   not yet be committed there, may be withheld, or may never have
   existed for that side.  CONFLICTING states that both sides hold a
   corresponding record and the records disagree.  A reconciliation



Mih                       Expires 6 April 2027                 [Page 14]

Internet-Draft               Evidence Layer                 October 2026


   process MUST NOT report A_ONLY or B_ONLY as CONFLICTING, and MUST NOT
   infer a substantive dispute from the mere absence of a counterpart
   record.

   A *Close* is a record — record_type close, epistemic_type
   producer_claim — carrying a closes link (Section 5) to the range or
   set of records it binds, together with the period's inputs and the
   contract/profile versions used to reach the state population above.
   Close status is read from the links other records make to it, not
   from a field the Close itself sets.

   Only a counterparty record counts: a record committed by the
   counterparty's store and signed under a key other than the Close's.
   A link from any record of the Close's own store, or from a third
   party, never changes Close status.  How a reader establishes which
   store committed a record, and under which key, is profile-defined;
   the record header of Section 4 names neither.

   *  *CONTESTED:* a counterparty record carries a rebuts link to this
      Close.  While such a link stands, the Close is not AGREED,
      whatever else links to it.

   *  *AGREED:* the Close is not CONTESTED, and a counterparty record
      carries an acknowledges link to this Close.

   *  *UNILATERAL:* neither.

   Whether a later counterparty record can withdraw an earlier rebuts is
   not defined by this revision.

   *A Close is never rewritten.* Later evidence, or a correction to a
   Close's own population, is a new record carrying a supersedes link to
   the prior Close and stating the adjustment; the prior Close's
   committed content stands unchanged, exactly as Section 6's rule for
   any other correction.

11.  Security Considerations

   *A self-consistent fabricated history is possible until an external
   party pins a checkpoint.* A store that both produces and consumes its
   own checkpoints can present a byte-for-byte consistent, provably
   append-only history that never happened as its author intends a
   reader to believe.  Internal consistency proves that the store has
   not silently rewritten what it already committed to a witness; it
   does not prove that what it committed the first time was true, and it
   does nothing for a checkpoint no external party has ever seen.  The
   commitment-substrate properties of Section 8 close the rewrite path
   once a checkpoint has left the store's control; they do nothing for



Mih                       Expires 6 April 2027                 [Page 15]

Internet-Draft               Evidence Layer                 October 2026


   one that has not.

   *Key control is not authority.* That a signature over a record
   verifies against the key named by principal_ref establishes only that
   the signer controlled that key at signing time.  It establishes
   nothing about whether the signer held any role, standing, or
   authority a relying party cares about; any such binding is host
   policy this document does not define (Section 2).

   *Non-membership is checkable; asserted absence is not.* A relying
   party that cannot tell the two apart (Section 9.1) can be handed a
   fabricated "no evidence" with no way to check it.  Recording which of
   the three kinds of "no" a store actually returned matters as much as
   recording the digest of whatever it did return.

   *epistemic_type is assigned once and is load-bearing.* A record
   misclassified at commit — a producer_claim recorded as an
   observed_event, for instance — is not corrected by anything happening
   later: no signature, checkpoint, or countersignature changes what
   kind of statement a record was when it was made.  Any correction is a
   new record; the miscategorized original stands and remains readable
   as what it was.

   *Signing, payload storage, and replication are out of scope, and that
   is itself a boundary.* This document takes no position on how a
   record is signed, how payload bytes are stored, or how records travel
   between stores (Section 2).  A relying party's trust in a record
   obtained through any of these mechanisms is exactly its trust in the
   signature and the commitment substrate checkpoint it verifies against
   — never in the fact that a particular mechanism was used to produce
   or move it.

12.  Privacy Considerations

   The durable record header (Section 4) MUST be privacy-minimized: it
   carries what the store's own operation requires — identifiers,
   digests, and typed references — and no low-entropy sensitive value
   beyond that.  A low-entropy value MUST NOT be treated as safe to
   carry merely because it has been hashed; a small input space makes a
   digest invertible by exhaustive search, so hashing alone is not
   minimization.

12.1.  What a Checkpoint Reveals

   A store hands checkpoints (Section 8) to parties outside its control:
   witnesses, and counterparties receiving a record with an inclusion
   proof.  A checkpoint carries no record content, but it is not free of
   information.



Mih                       Expires 6 April 2027                 [Page 16]

Internet-Draft               Evidence Layer                 October 2026


   *What a checkpoint reveals.* Every checkpoint states the size of the
   store's committed history: the number of records appended since the
   store's first record, not since the previous checkpoint (in a
   Checkpointed Local Log ([I-D.mih-scitt-checkpointed-local-log]), its
   log_size).  A party holding two checkpoints from one store therefore
   learns how many records the store committed between them, across
   every subject and counterparty the store records, not only those it
   shares with that party.  A checkpoint also carries a time, and the
   times at which a store issues checkpoints reveal its activity
   pattern.

   *What a checkpoint does not reveal.* A checkpoint and an inclusion
   proof reveal no record content.  The sibling values in an inclusion
   proof are digests over other records; they reveal nothing about those
   records only if those records cannot be guessed and confirmed by
   recomputing a digest.  To make that hold, every record MUST include,
   within the bytes from which its commitment-substrate entry is
   derived, a value of at least 128 bits drawn from a cryptographically
   secure random source, generated by the store for that record alone
   and never reused.  A value supplied by or known to another party
   (such as a client- or counterparty-supplied nonce), a time, a
   sequence number, or a digest of content does not satisfy this
   requirement.

   *Mitigations.* A store SHOULD, before a checkpoint leaves its
   control, append *padding records* so that the checkpoint's size falls
   on a bucket boundary: for example, the next multiple of a configured
   bucket size.  Two such checkpoints then reveal the count between them
   only to within the bucket size.  This document reserves the
   record_type value padding for this purpose.  A padding record has
   epistemic_type producer_claim; its only content is a freshly
   generated random value meeting the requirement above; and it carries
   no payload_commitments, no links, no subject_ref, and no
   principal_ref.  A padding record MUST NOT be the target of any link.
   It is appended like any other record and changes none of the
   properties of Section 8.

   A store SHOULD coarsen every time value that leaves its control
   inside signed or committed bytes, such as a checkpoint's time or a
   disclosed record's committed_at, to a granularity no finer than one
   minute.  Such a value is covered by a signature or a commitment, so
   it is coarsened when those bytes are produced; coarsening a copy
   afterwards invalidates the signature or the record's inclusion.  A
   store MAY keep finer-grained times in local state that is neither
   committed nor disclosed.






Mih                       Expires 6 April 2027                 [Page 17]

Internet-Draft               Evidence Layer                 October 2026


   A store operator MAY keep separate stores, each with its own
   commitment substrate and checkpoints, for separate scopes (for
   example, per counterparty), so that a checkpoint shown within one
   scope reveals nothing about record volume in another.

   A verifier MUST treat a padding record as an ordinary record when it
   checks inclusion, consistency, or a checkpoint, and MUST NOT reject a
   checkpoint, proof, or range because it contains padding records.  A
   reader that counts, lists, or summarizes records MUST NOT count a
   padding record as a record, and a store MUST NOT return one as
   responsive to a record, correlation, or exchange subject (Section 9).

13.  IANA Considerations

   IANA is requested to create the "Evidence Layer Parameters" registry
   group with the two registries below.  For both, the registration
   policy is Specification Required ([RFC8126], Section 4.6), and the
   change controller is the IETF.  Each entry consists of a token
   (lowercase ASCII, underscore-separated), a one-line description, and
   a reference.

   Until IANA creates these registries, the interim registry of record
   is REGISTRY.md in the source repository of
   [I-D.mih-scitt-agent-action-capsule].  It records the same values and
   policy, and the same designated-expert criteria it applies to its
   other registries.

   Neither registry duplicates an existing one.  "Evidence Layer Link
   Types" is not the chain.relation or citation_purpose registry of
   [I-D.mih-scitt-agent-action-capsule], which govern fields inside a
   Capsule (Section 5).  "Evidence Layer Epistemic Types" is not that
   document's domain registry, which states what kind of act a Capsule
   records, not how its content came to be known.

13.1.  Evidence Layer Epistemic Types

   Initial contents, from Section 4.1:














Mih                       Expires 6 April 2027                 [Page 18]

Internet-Draft               Evidence Layer                 October 2026


   +=======================+==============================+===========+
   | Token                 | Description                  | Reference |
   +=======================+==============================+===========+
   | observed_event        | directly observed by the     | This      |
   |                       | recording system or actor    | document  |
   +-----------------------+------------------------------+-----------+
   | system_of_record_fact | asserted by an external      | This      |
   |                       | system of record             | document  |
   +-----------------------+------------------------------+-----------+
   | producer_claim        | asserted by the record's own | This      |
   |                       | producer, unverified by the  | document  |
   |                       | store                        |           |
   +-----------------------+------------------------------+-----------+
   | human_report          | asserted by a human, not     | This      |
   |                       | machine-observed             | document  |
   +-----------------------+------------------------------+-----------+
   | semantic_judgment     | a judgment or classification | This      |
   |                       | reached by interpretation,   | document  |
   |                       | not direct observation       |           |
   +-----------------------+------------------------------+-----------+
   | derived_metric        | a value computed or          | This      |
   |                       | aggregated from other        | document  |
   |                       | records                      |           |
   +-----------------------+------------------------------+-----------+
   | adjudication          | a ruling on a matter that    | This      |
   |                       | was disputed or required     | document  |
   |                       | judgment                     |           |
   +-----------------------+------------------------------+-----------+
   | obligation_reference  | a reference to an obligation | This      |
   |                       | the record does not itself   | document  |
   |                       | discharge                    |           |
   +-----------------------+------------------------------+-----------+

                                 Table 4

13.2.  Evidence Layer Link Types

   Initial contents, from Section 5:













Mih                       Expires 6 April 2027                 [Page 19]

Internet-Draft               Evidence Layer                 October 2026


     +==============+===================================+===========+
     | Token        | Description                       | Reference |
     +==============+===================================+===========+
     | cites        | the carrying record depends on    | This      |
     |              | the target's committed content    | document  |
     +--------------+-----------------------------------+-----------+
     | adjudicates  | the carrying record renders a     | This      |
     |              | judgment about the target's claim | document  |
     +--------------+-----------------------------------+-----------+
     | supersedes   | the carrying record replaces the  | This      |
     |              | target's content for current use, | document  |
     |              | without mutating it               |           |
     +--------------+-----------------------------------+-----------+
     | acknowledges | the carrying record states its    | This      |
     |              | author has seen and holds the     | document  |
     |              | target                            |           |
     +--------------+-----------------------------------+-----------+
     | rebuts       | the carrying record disputes the  | This      |
     |              | target's claim                    | document  |
     +--------------+-----------------------------------+-----------+
     | closes       | the carrying record binds a range | This      |
     |              | or set of records as reconciled   | document  |
     +--------------+-----------------------------------+-----------+

                                 Table 5

   This document makes no other requests of IANA.  The record_type value
   padding (Section 12.1) is reserved by this document; record_type is
   an open token and has no registry.

14.  References

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

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




Mih                       Expires 6 April 2027                 [Page 20]

Internet-Draft               Evidence Layer                 October 2026


   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

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

14.2.  Informative References

   [I-D.mih-agent-disclosure-envelope]
              Mih, S., "Disclosure Envelope Profile for Agent Action
              Capsules", Work in Progress, Internet-Draft, draft-mih-
              agent-disclosure-envelope-00, September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-agent-
              disclosure-envelope-00>.

   [I-D.mih-agent-evidence-request]
              Mih, S., "An Interaction Model for Requesting Verifiable
              Evidence", Work in Progress, Internet-Draft, draft-mih-
              agent-evidence-request-00, September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-agent-
              evidence-request-00>.

   [I-D.mih-agent-settlement-records]
              Mih, S., "Two-Party Settlement Records for Agent
              Payments", Work in Progress, Internet-Draft, draft-mih-
              agent-settlement-records-00, October 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-agent-
              settlement-records-00>.

   [I-D.mih-scitt-agent-action-capsule]
              Mih, S., "An Agent Action Capsule Profile for SCITT", Work
              in Progress, Internet-Draft, draft-mih-scitt-agent-action-
              capsule-05, September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-scitt-
              agent-action-capsule-05>.

   [I-D.mih-scitt-checkpointed-local-log]
              Mih, S., "The Checkpointed Local Log (CLL)", Work in
              Progress, Internet-Draft, draft-mih-scitt-checkpointed-
              local-log-01, September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-scitt-
              checkpointed-local-log-01>.





Mih                       Expires 6 April 2027                 [Page 21]

Internet-Draft               Evidence Layer                 October 2026


   [I-D.mih-zhang-agent-disclosure-bundle]
              Mih, S. and Y. Zhang, "AAC Evidence Bundle", Work in
              Progress, Internet-Draft, draft-mih-zhang-agent-
              disclosure-bundle-00, September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-zhang-
              agent-disclosure-bundle-00>.

   [RFC9942]  Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
              Fournet, "CBOR Object Signing and Encryption (COSE)
              Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
              <https://www.rfc-editor.org/rfc/rfc9942>.

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

Appendix A.  Acknowledgments

   This document distills operational experience running local evidence
   stores against the interaction model of
   [I-D.mih-agent-evidence-request] and the presentation format of
   [I-D.mih-zhang-agent-disclosure-bundle] into the substrate layer both
   depend on.

Author's Address

   Steven Mih
   Action State Group, Inc.
   Email: spec@actionstate.ai




















Mih                       Expires 6 April 2027                 [Page 22]