Network Working Group                                L.J. Reilly
Internet-Draft                               Independent Submission
Intended status: Informational                       28 March 2026
Expires: 28 September 2026


   Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI
      Datasets, Training, Fine-Tuning, and Inference Provenance
                  draft-reilly-sentinel-protocol-01


Abstract

   The Reilly Sentinel Protocol (RSP) specifies an interoperable,
   multi-layer method for establishing integrity, provenance, and
   auditability across the artificial intelligence (AI) lifecycle.
   RSP defines a Sentinel Evidence Package (SEP) that binds payload
   digests, provenance metadata, signatures, blockchain timestamp
   proofs, and resolvable identifiers (DOIs).  This enables
   tamper-evident, independently verifiable receipts for datasets,
   data transformations, training jobs, checkpoints, fine-tuning
   runs, evaluations, inference outputs, and agentic AI action logs.

   This revision (-01) expands the protocol with a quantum-resistant
   triple-hash cross-chain architecture (SHA-256, SHA3-512, BLAKE3),
   formal cross-chain binding proofs, agentic AI provenance extensions,
   streaming inference provenance, federated learning provenance,
   expanded threat model covering post-quantum adversaries, integration
   with the Reilly EternaMark (REM) Protocol triple-layer permanence
   system, implementation status updates, and a conformance framework.

   RSP is transport-agnostic and serializable in JSON and CBOR.  It
   leverages existing IETF and industry building blocks, including
   COSE/CMS signatures, CBOR (RFC 8949), CDDL (RFC 8610), JSON
   (RFC 8259), and NTS-secured time (RFC 8915).  Anchoring is done
   via append-only blockchain receipts and identity/lineage is
   stabilized with a DOI registry.  The result is an evidence-grade,
   quantum-resilient audit trail for regulated and safety-critical
   AI deployments worldwide.


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


Table of Contents

   1.   Introduction
   2.   Conventions and Terminology
   3.   Architecture and Roles
   4.   Sentinel Evidence Package (SEP) Data Model
   5.   Quantum-Resistant Triple-Hash Architecture
   6.   Cross-Chain Binding and Composite Proof Objects
   7.   Serialization and Media Types
   8.   Anchoring and Proofs
   9.   DOI Registration and Metadata
   10.  REM Protocol Triple-Layer Permanence Integration
   11.  Protocol Operations
   12.  Verification Algorithm
   13.  Agentic AI Provenance Extensions
   14.  Streaming Inference Provenance
   15.  Federated Learning Provenance
   16.  Conformance Framework
   17.  Error Handling
   18.  Manageability and Telemetry
   19.  Privacy Considerations
   20.  Security Considerations
   21.  IANA Considerations
   22.  Implementation Status
   23.  References
        23.1.  Normative References
        23.2.  Informative References
   Appendix A.  CDDL for CBOR SEP (v1.1)
   Appendix B.  Example JSON SEP with Triple-Hash
   Appendix C.  Verification Report (JSON)
   Appendix D.  Example OpenTimestamps Receipt
   Appendix E.  Example DOI Metadata Mapping
   Appendix F.  Composite Proof Object (CPO) Format
   Appendix G.  Agentic Action Log Example
   Appendix H.  Change Log
   Acknowledgments
   Author's Address


1.  Introduction

   Artificial Intelligence (AI) systems are increasingly deployed in
   high-stakes contexts including defense, healthcare, finance, critical
   infrastructure, and autonomous systems.  Confidence in AI outcomes
   depends on the ability to demonstrate where data originated, how
   models were trained or adapted, when inferences were produced, by
   which agents actions were taken, and whether any of these artifacts
   have been altered after the fact.

   The emergence of agentic AI systems -- autonomous agents that execute
   multi-step tasks, invoke tools, and produce outputs without direct
   human supervision per step -- introduces new provenance requirements
   beyond static artifact integrity.  An agentic AI system may process
   thousands of actions per session; each action represents a provenance
   event that may affect downstream artifacts, decisions, and liability.

   Furthermore, the anticipated arrival of cryptographically relevant
   quantum computers (CRQCs) threatens the long-term integrity of
   provenance records anchored exclusively with classical hash
   algorithms.  SHA-256, the dominant anchoring hash, is vulnerable to
   Grover's algorithm which reduces its effective security from 256 bits
   to approximately 128 bits.  For provenance records intended to remain
   verifiable for decades -- as required by regulated industries and
   legal proceedings -- this represents a material risk.

   RSP addresses these needs by defining a minimal yet extensible
   evidence container -- the Sentinel Evidence Package (SEP) -- a
   quantum-resistant triple-hash cross-chain architecture, and a
   verification process that any independent party can execute without
   trusting the producer's infrastructure.  RSP is content- and model-
   agnostic: it does not dictate model architecture or task; it
   standardizes how integrity, time, identity, lineage, and quantum
   resilience are recorded and verified.

   RSP in this revision combines three complementary layers:

   *  Quantum-resistant triple-hash anchoring:  SHA-256, SHA3-512
      (post-quantum resilient), and BLAKE3 computed simultaneously
      and cross-chain bound via a Composite Proof Object (CPO).

   *  Multi-chain blockchain anchoring:  append-only proof of existence
      across heterogeneous consensus systems, reducing single-chain
      failure risk.

   *  DOI registration:  globally resolvable, citable identifiers with
      metadata, lineage, and retention semantics backed by
      institutional archival infrastructure.

   The REM Protocol (draft-reilly-rem-protocol-01) provides the
   underlying triple-layer permanence infrastructure on which RSP
   anchoring operations are built.


1.1.  Changes from -00

   This document supersedes draft-reilly-sentinel-protocol-00.
   Principal changes are summarized in Appendix H.  Key additions
   include:

   *  Section 5:  Quantum-resistant triple-hash architecture.
   *  Section 6:  Cross-chain binding and Composite Proof Objects.
   *  Section 10: REM Protocol integration.
   *  Section 13: Agentic AI provenance extensions.
   *  Section 14: Streaming inference provenance.
   *  Section 15: Federated learning provenance.
   *  Section 16: Conformance framework.
   *  Expanded threat model in Section 20.
   *  Updated implementation status in Section 22.


2.  Conventions and Terminology

   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.

   SEP:  Sentinel Evidence Package; the container defined by this
      document.

   CPO:  Composite Proof Object; a structure binding SHA-256, SHA3-512,
      and BLAKE3 chain hashes with a cross-chain binding hash.

   Artifact:  Any AI lifecycle asset -- dataset, data transform,
      training configuration, training log, model checkpoint, fine-
      tuning diff, evaluation artifact, inference record, or agentic
      action log.

   Digest:  A cryptographic hash of a payload or Merkle root over
      chunked payloads.

   OTS:  OpenTimestamps-style proof object or functionally equivalent
      blockchain timestamp receipt.

   DOI:  Digital Object Identifier; a resolvable identifier providing
      metadata and lineage stability (DataCite, Crossref, or internal
      Handle).

   COSE:  CBOR Object Signing and Encryption; RSP uses COSE signatures
      [RFC9052] [RFC9053].

   CMS:  Cryptographic Message Syntax [RFC5652].

   CRQC:  Cryptographically Relevant Quantum Computer; a quantum
      computer capable of breaking classical cryptographic algorithms
      at practical scale.

   REM:  Reilly EternaMark Protocol; the triple-layer permanence
      infrastructure used by RSP for anchoring operations.

   AAL:  Agentic Action Log; a structured record of autonomous agent
      actions, tool invocations, and decision events.

   SIP:  Streaming Inference Proof; a provenance record for streaming
      or real-time AI inference outputs.

   FLP:  Federated Learning Proof; a provenance record for federated
      model updates preserving participant privacy.


3.  Architecture and Roles

   Producer:  Creates artifacts, computes triple-hash digests, collects
      device and environment attestations, signs SEPs, and requests
      anchoring and DOI registration via the REM Protocol infrastructure.

   Registrar:  Provides two sub-services:
      (a) Anchoring Orchestrator that submits digests to public chains
          across multiple consensus systems and returns CPOs.
      (b) DOI Registrar that mints DOIs and stores metadata, lineage,
          and fixity records.

   Verifier:  Recomputes triple-hash digests, validates signatures,
      checks OTS receipts against independent nodes, resolves DOI
      metadata, and verifies cross-chain binding without trusting
      Producer or Registrar beyond their published signatures.

   Storage:  WORM (Write-Once-Read-Many) or equivalent immutable object
      storage for SEPs, CPOs, and payloads under retention policy.
      IPFS content-addressed storage is RECOMMENDED for decentralized
      redundancy.

   Time:  Authenticated time sources (NTS, RFC 8915) and monotonic
      counters to resist back-dating and rollback attacks.

   REM Infrastructure:  The deployed REM Protocol verification agent
      provides REMID assignment, chain integrity verification, and
      verification page generation for SEPs anchored through RSP.

   RSP does not mandate a specific trust relation among these roles;
   in many deployments, Producer and Registrar are separate entities.
   The REM Infrastructure MAY be operated by the Producer.


4.  Sentinel Evidence Package (SEP) Data Model

   An SEP is a self-describing manifest that binds digest(s), metadata,
   signatures, proofs, and identifiers.  Version 1.1 adds triple-hash
   fields, CPO references, and agentic extensions.

   Core fields:

   *  version:  Protocol version string.  MUST be "1.1" for this
      revision.

   *  artifact.type:  One of "dataset", "datatransform",
      "training.config", "training.log", "training.checkpoint",
      "fine-tune.diff", "evaluation", "inference", "inference.stream",
      "federated.update", "agentic.action.log", or an extension token.

   *  payloads[]:  Optional array with entries { cid, size, mime,
      chunking }; payload storage MAY be external.  'cid' MUST encode
      algorithm and value (e.g., "sha256:HEX").

   *  digests:  Object with sha256, sha3_512, and blake3 members
      (hex-encoded).  sha3_512 provides post-quantum resilience.
      blake3 provides high-performance verification.  For chunked
      payloads, digests.root is the Merkle root.

   *  cpo_ref:  Reference to the Composite Proof Object binding all
      three hash chains.  MUST be present when triple-hash anchoring
      is used.

   *  timestamps:  wallclock (RFC 3339) and monotonic counter.
      The 'source' SHOULD indicate NTS, Roughtime, or equivalent.

   *  authors[]:  Optional list of creators/operators; MAY include
      device IDs, certificate references, and ORCID identifiers.

   *  attestation:  Optional device/firmware/build attestation claims
      (see RATS, RFC 9334).

   *  rem:  Anchoring and identity sub-object:
        - rem.remid:       REMID assigned by REM infrastructure.
        - rem.ots_proof_ref: URN or locator to OTS proof file.
        - rem.doi:         DOI string.
        - rem.ipfs_cid:    IPFS content identifier for redundancy.
        - rem.lineage:     parent[], siblings[], supersedes[].
        - rem.quantum_resilient: Boolean.  MUST be true when CPO
                           includes SHA3-512 and BLAKE3 chains.

   *  agentic:  Optional sub-object for agentic AI provenance.
      See Section 13.

   *  class:  Optional classification/handling indicators (tokenized).

   *  policies:  Retention and access policy references.

   *  signatures[]:  One or more COSE_Sign1 or CMS signatures covering
      the manifest canonical form.  Certificate chains MUST be
      included.

   The manifest MUST be canonicalized prior to signing; canonical JSON
   (JCS, RFC 8785) or deterministic CBOR (RFC 8949 Section 4.2) MUST
   be used.


5.  Quantum-Resistant Triple-Hash Architecture

5.1.  Motivation

   SHA-256 alone is insufficient for provenance records requiring
   long-term verifiability in a post-quantum threat environment.
   Grover's algorithm reduces SHA-256's effective collision resistance
   from 256 bits to approximately 128 bits under a CRQC adversary.
   While 128-bit security is currently considered adequate, provenance
   records anchored today may need to remain verifiable for 20 to 50
   years, a time horizon in which CRQCs may become practical.

   RSP addresses this by mandating three simultaneous hash computations:

   *  SHA-256:  Classical standard; widely deployed and auditable.

   *  SHA3-512:  Post-quantum resilient.  SHA-3 is based on the Keccak
      sponge construction, which is structurally different from SHA-2.
      A quantum adversary cannot apply Grover's algorithm to SHA-3 with
      the same efficiency as SHA-2.  SHA3-512 provides 256-bit post-
      quantum security.

   *  BLAKE3:  High-performance, parallelizable hash function.
      Provides independent algorithmic diversity from both SHA-2 and
      SHA-3 families, ensuring that a break in either family does not
      compromise the overall proof chain.

5.2.  Triple-Hash Computation

   For each artifact, the Producer MUST compute:

      sha256_hash  = SHA-256(artifact_bytes)
      sha3_512_hash = SHA3-512(artifact_bytes)
      blake3_hash  = BLAKE3(artifact_bytes)

   All three values MUST be recorded in the SEP digests field.

5.3.  Security Properties

   An adversary seeking to forge an artifact's provenance record must
   simultaneously break SHA-256, SHA3-512, AND BLAKE3.  No known
   classical or quantum algorithm achieves this.  The three algorithms
   are from distinct design families with no known structural
   relationships, ensuring that a cryptanalytic break of one does not
   assist attacks on the others.

   This architecture provides:
   *  Classical security:  256-bit effective strength (SHA-256).
   *  Post-quantum security:  256-bit effective strength (SHA3-512).
   *  Algorithmic diversity:  Independent verification path (BLAKE3).


6.  Cross-Chain Binding and Composite Proof Objects

6.1.  Chain Architecture

   RSP defines three independent hash chains maintained across SEP
   records:

   *  SHA-256 chain:  Each record's SHA-256 chain hash is computed
      over the previous SHA-256 chain hash, the current artifact
      SHA-256 digest, record ID, REMID, and creation timestamp.

   *  SHA3-512 chain:  Analogous construction using SHA3-512.
      Post-quantum resilient.

   *  BLAKE3 chain:  Analogous construction using BLAKE3.

   Each chain is independent.  Tampering any single record invalidates
   its chain hash, which propagates forward through all subsequent
   records in that chain.

6.2.  Cross-Chain Binding Hash

   At each record, a cross-chain binding hash is computed as:

      cross_chain_hash = SHA3-512(
          sha256_chain_hash ||
          sha3_512_chain_hash ||
          blake3_chain_hash
      )

   This binds all three chain states simultaneously at the current
   block.  An adversary wishing to forge a record must simultaneously
   manipulate all three chains such that the cross-chain binding hash
   remains valid.  This requires simultaneously breaking SHA-256,
   SHA3-512, and BLAKE3 -- which is computationally infeasible under
   both classical and quantum threat models.

6.3.  Composite Proof Object (CPO)

   A CPO is a JSON or CBOR structure that encapsulates the triple-hash
   chain state at a given record.  See Appendix F for the CPO format.

   CPOs MUST be signed by the Producer and MAY be countersigned by the
   Registrar.  CPOs SHOULD be anchored to the blockchain alongside the
   SEP digest to provide timestamped evidence of chain state.


7.  Serialization and Media Types

   RSP SEPs MAY be emitted as JSON [RFC8259] or CBOR [RFC8949].
   This document defines four media types for IANA registration:

   *  application/rsp-ep+json  (unchanged from -00)
   *  application/rsp-ep+cbor  (unchanged from -00)
   *  application/rsp-cpo+json  (new: Composite Proof Object, JSON)
   *  application/rsp-cpo+cbor  (new: Composite Proof Object, CBOR)

   The "+" structured suffix follows RFC 6839.  See Section 21 for
   IANA templates.


8.  Anchoring and Proofs

   Producers submit digests (payload or roll-up Merkle roots) to the
   Anchoring Orchestrator.  The orchestrator MUST anchor to at least
   one public append-only chain and SHOULD support multiple chains for
   diversity and resilience.  Proofs MUST be exportable and
   independently checkable without trusting the orchestrator.

   For quantum-resilient deployments, the orchestrator MUST anchor the
   cross-chain binding hash (Section 6.2) in addition to individual
   algorithm hashes.  This provides a single anchored value that
   commits to all three algorithm states simultaneously.

   OpenTimestamps receipts are RECOMMENDED for Bitcoin anchoring.
   Anchoring to Ethereum via a smart contract event, or to another
   public chain with independently verifiable inclusion proofs, is
   also RECOMMENDED for multi-chain diversity.

   Roll-up anchoring:  Operators SHOULD periodically compute a Merkle
   tree over all new artifact digests and anchor the root to reduce
   per-artifact anchoring cost and to provide compact audit coverage.
   Roll-up trees SHOULD include all three hash values per leaf.


9.  DOI Registration and Metadata

   After anchoring, the Registrar mints a DOI and stores a metadata
   record containing at least: title or short label, creators,
   creation time, fixity (triple-hash digests), lineage links, REMID,
   IPFS CID, and policy URIs.

   DOIs for classified material MAY be internal Handles resolvable on
   private networks; unclassified artifacts SHOULD use public DOIs
   (e.g., DataCite/Zenodo).

   A DOI SHOULD be minted for each material evolution that changes
   fixity (e.g., new dataset version, fine-tune result, evaluation
   report).  Prior DOIs MUST NOT be deleted; instead, metadata MAY
   indicate "superseded-by".

   The DOI metadata record SHOULD include:
   *  rem_id:       The REMID assigned by the REM infrastructure.
   *  sha256:       Artifact SHA-256 digest.
   *  sha3_512:     Artifact SHA3-512 digest.
   *  blake3:       Artifact BLAKE3 digest.
   *  cross_chain:  Cross-chain binding hash.
   *  quantum_resilient: true


10.  REM Protocol Triple-Layer Permanence Integration

10.1.  Overview

   The Reilly EternaMark Protocol (REM) [REM01] provides a triple-layer
   permanence infrastructure used as the anchoring substrate for RSP.
   When RSP operates over REM, each SEP receives:

   *  A REMID:  A permanent identifier in the form
      REMID:YYYY.MMDD/xxxxxxxx.

   *  A Zenodo DOI:  Permanent academic archive backed by CERN.

   *  An IPFS CID:  Content-addressed decentralized storage.

   *  A Bitcoin OTS proof:  Blockchain timestamp via OpenTimestamps.

   *  A verification page:  Human and machine-readable proof page
      resolvable at the REM verification agent endpoint.

10.2.  Integration Requirements

   When RSP operates over REM, the following requirements apply:

   *  The SEP rem.remid field MUST be populated with the REMID
      assigned by the REM infrastructure.

   *  The CPO MUST be submitted to the REM infrastructure for
      REMID assignment and chain integrity verification.

   *  The SEP rem.quantum_resilient field MUST be set to true.

   *  The verification page URL MUST be included in SEP metadata
      as rem.verification_url.

10.3.  Chain Integrity

   The REM infrastructure maintains chain integrity across all
   submitted artifacts.  Agent 11 performs autonomous self-healing
   repair cycles that detect and flag chain integrity violations.
   Producers relying on REM for anchoring SHOULD monitor chain
   integrity reports and respond to any flagged records.


11.  Protocol Operations

   The following abstract operations are defined; concrete APIs are
   out of scope, but typical deployments use REST or gRPC.

   11.1  SEAL

      Inputs:  manifest draft (unsigned), triple-hash digests,
               optional attestation, optional agentic extension.
      Action:  Canonicalize (JCS or deterministic CBOR), sign
               (COSE/CMS), compute CPO, return signed SEP.

   11.2  ANCHOR

      Inputs:  cross-chain binding hash (from CPO).
      Action:  Anchor to one or more chains; return proof
               reference(s) and OTS receipts.

   11.3  REGISTER

      Inputs:  metadata including triple-hash fixity, lineage,
               IPFS CID.
      Action:  Mint DOI; bind DOI <-> SEP <-> CPO <-> proofs;
               assign REMID; return DOI and REMID.

   11.4  VERIFY

      Inputs:  DOI, REMID, or SEP URI (plus payload, if accessible).
      Action:  Recompute triple-hash digests; validate CPO; validate
               signatures; check time discipline; verify proofs;
               emit Verification Report.

   11.5  REVOKE

      Inputs:  SEP identifier and revocation reason.
      Action:  Append a signed revocation fact to the chain; the
               original SEP MUST NOT be deleted.  All subsequent
               verifications MUST surface the revocation status.


12.  Verification Algorithm

   Given a DOI, REMID, or SEP:

   1.  Resolve DOI or REMID to retrieve minimal metadata including
       triple-hash fixity, lineage, IPFS CID, and pointers to SEP,
       CPO, and payload (subject to policy).

   2.  Fetch SEP and CPO.  Parse and canonicalize per serialization.
       Verify that all three digests (sha256, sha3_512, blake3) match
       the payload (if accessible).

   3.  Verify CPO cross-chain binding hash by recomputing:
       SHA3-512(sha256_chain || sha3_512_chain || blake3_chain).

   4.  Validate signatures (COSE/CMS).  Check certificate validity
       and revocation (OCSP/CRL).  Attestation claims MAY be
       evaluated via a RATS verifier (RFC 9334).

   5.  Validate time: ensure wallclock is plausible (NTS/secure time)
       and monotonic counter continuity holds relative to adjacent
       SEPs.

   6.  Validate anchoring proofs independently using public chain
       data.  For OTS proofs, verify against Bitcoin block headers
       via an independent node.

   7.  Check IPFS CID by resolving the content-addressed payload.

   8.  Check revocation status against the chain record.

   9.  Emit a Verification Report with fields: hash_ok (all three
       algorithms), cpo_ok, sig_ok, attestation_ok, ots_ok, time_ok,
       doi_ok, remid_ok, ipfs_ok, revocation_status, and overall
       verdict.  The report SHOULD itself be signed.


13.  Agentic AI Provenance Extensions

13.1.  Motivation

   Agentic AI systems execute multi-step workflows autonomously.
   Each action -- tool invocation, API call, file write, model
   inference, decision branch -- represents a provenance event.
   Traditional SEP structures capture static artifact integrity;
   agentic provenance requires a structured log of action sequences
   that preserves causality, timing, and agent identity.

13.2.  Agentic Action Log (AAL)

   An AAL is an artifact.type "agentic.action.log" SEP extension.
   The SEP agentic sub-object MUST contain:

   *  session_id:       Unique identifier for the agent session.
   *  agent_id:         Identifier for the agent or agent version.
   *  model_id:         Identifier for the underlying model, with
                        DOI reference to the model checkpoint SEP.
   *  action_count:     Total number of logged actions.
   *  actions[]:        Ordered array of action records.
   *  merkle_root:      Merkle root over all action record digests,
                        providing compact integrity over the log.

   Each action record in actions[] MUST contain:

   *  seq:              Sequence number (monotonically increasing).
   *  timestamp:        RFC 3339 wallclock at action execution.
   *  action_type:      One of "tool_call", "inference", "read",
                        "write", "decision", "delegation", or
                        an extension token.
   *  input_digest:     SHA3-512 digest of action input.
   *  output_digest:    SHA3-512 digest of action output.
   *  tool_id:          Identifier of invoked tool (if applicable).
   *  parent_seq:       Sequence number of causal parent action.
   *  attestation_ref:  Optional reference to device attestation.

13.3.  AAL Anchoring

   The Merkle root over all action records MUST be anchored via the
   standard RSP ANCHOR operation.  For long-running agent sessions,
   intermediate Merkle roots MAY be anchored at configurable
   intervals to provide bounded recovery windows.

13.4.  Privacy in Agentic Logs

   Action inputs and outputs are identified by digest only; raw
   content is not included in the AAL.  Producers MAY encrypt
   payloads and include encrypted payload references in action
   records.  This enables selective disclosure: a party may prove
   that a specific action occurred without revealing the content
   of inputs or outputs.


14.  Streaming Inference Provenance

14.1.  Motivation

   Real-time AI systems produce inference outputs as streams.
   Standard SEP structures assume bounded artifacts; streaming
   inference requires provenance over unbounded token sequences
   or data streams.

14.2.  Streaming Inference Proof (SIP)

   A SIP is an artifact.type "inference.stream" SEP extension.
   The stream is chunked into fixed-size windows (default: 1000
   tokens or 30 seconds of data, whichever is smaller).

   For each window:
   *  Compute SHA3-512 digest of the window content.
   *  Append to a rolling Merkle tree.
   *  Record the window's position in the stream and the Merkle
      path at that position.

   At stream termination:
   *  Anchor the final Merkle root via ANCHOR.
   *  Issue a SEP with artifact.type "inference.stream" referencing
      all window digests.

   Verifiers MAY verify any individual window by checking its
   Merkle path against the anchored root, without retrieving the
   entire stream.

14.3.  Real-Time Monitoring

   For safety-critical inference (medical diagnosis, autonomous
   vehicle control), producers SHOULD maintain a live anchor feed
   submitting intermediate Merkle roots at configurable intervals
   (e.g., every 10 seconds).  This bounds the maximum provenance
   gap in the event of unexpected stream termination.


15.  Federated Learning Provenance

15.1.  Motivation

   Federated learning (FL) trains models across distributed clients
   without centralizing raw data.  Each client computes a local model
   update which is aggregated at a central server.  Provenance for
   FL must record the integrity of updates without revealing client
   data or update content, and must capture the aggregation operation.

15.2.  Federated Learning Proof (FLP)

   An FLP is an artifact.type "federated.update" SEP extension.
   The SEP agentic sub-object is unused; instead, the SEP MUST
   contain a federated sub-object with:

   *  round_id:         Federated learning round identifier.
   *  aggregation_id:   Identifier for the aggregation operation.
   *  participant_count: Number of clients contributing updates.
   *  update_root:      Merkle root over all client update digests,
                        computed by the aggregation server.
   *  global_model_doi: DOI reference to the resulting global model
                        checkpoint SEP.
   *  privacy_mechanism: One of "dp_gaussian", "dp_laplace",
                        "secure_aggregation", "none", or extension.

   Individual client update digests are included in the Merkle tree
   but individual client identities are NOT recorded in the FLP.
   The update_root provides aggregate integrity without revealing
   per-client contributions.

15.3.  FLP Anchoring

   The update_root MUST be anchored via the standard RSP ANCHOR
   operation.  The resulting SEP MUST be registered with a DOI.
   The global model checkpoint SEP MUST include a lineage reference
   to the FLP SEP, establishing a verifiable provenance chain from
   training data contributions through aggregation to the deployed
   model.


16.  Conformance Framework

16.1.  Conformance Levels

   RSP defines three conformance levels for implementations:

   RSP-Basic:
      *  SEP version 1.1 with SHA-256 digests.
      *  Single-chain OTS anchoring.
      *  DOI registration.
      *  Standard SEAL, ANCHOR, REGISTER, VERIFY operations.

   RSP-Quantum:
      *  All RSP-Basic requirements.
      *  Triple-hash digests (SHA-256, SHA3-512, BLAKE3).
      *  CPO generation and verification.
      *  Cross-chain binding hash.
      *  rem.quantum_resilient MUST be true.

   RSP-Full:
      *  All RSP-Quantum requirements.
      *  REM Protocol integration (REMID, IPFS CID).
      *  Agentic Action Log support (Section 13).
      *  Streaming inference provenance (Section 14) or
         federated learning provenance (Section 15).
      *  Multi-chain anchoring (minimum two independent chains).

16.2.  Conformance Testing

   Implementations claiming an RSP conformance level MUST pass
   the verification algorithm in Section 12 for all artifact types
   applicable to that level.  Test vectors for triple-hash
   computation and CPO verification are provided in Appendix F.


17.  Error Handling

   RSP defines abstract error conditions with suggested codes:

     ERR_PARSE            malformed SEP, CPO, or encoding
     ERR_DIGEST_MISMATCH  recomputed digest != manifest (any alg)
     ERR_CPO_INVALID      cross-chain binding hash mismatch
     ERR_SIG_INVALID      signature or chain invalid
     ERR_TIME_INVALID     unauthenticated or non-monotonic time
     ERR_PROOF_INVALID    proof not verifiable on stated chain
     ERR_DOI_RESOLVE      DOI metadata unavailable/inconsistent
     ERR_REMID_RESOLVE    REMID not found or chain violation
     ERR_IPFS_RESOLVE     IPFS CID not resolvable
     ERR_POLICY_DENIED    access denied by policy
     ERR_REVOKED          SEP has been revoked

   Implementations SHOULD map these to transport-specific error
   responses.  ERR_CPO_INVALID and ERR_REVOKED MUST surface as
   prominent verification failures; they MUST NOT be silently
   ignored.


18.  Manageability and Telemetry

   Deployments SHOULD monitor:

   *  Anchoring SLA (time to first chain inclusion per algorithm).
   *  Triple-hash coverage (% artifacts with all three digests).
   *  CPO generation success rate.
   *  Verification pass rate and dominant failure reasons.
   *  Chain integrity health (monitored by REM Agent 11 or equivalent).
   *  Key health (expiration, revocation events).
   *  Time-source health (NTS/stratum, Roughtime reachability).
   *  IPFS pin health (replication factor and retrieval latency).

   For agentic deployments, additional monitoring SHOULD include:

   *  AAL action count per session.
   *  AAL Merkle root anchor latency.
   *  Streaming inference window gap rate.


19.  Privacy Considerations

   SEPs record integrity metadata; payloads MAY be withheld.
   Where privacy is required, field-level encryption SHOULD be used
   for sensitive manifest attributes while keeping digests and proofs
   public.  DOI records for sensitive artifacts SHOULD minimize
   personally identifiable information.  Policy URIs SHOULD reflect
   access constraints.

   For agentic logs, action inputs and outputs are represented by
   digest only (Section 13.4).  Raw content MUST NOT be embedded
   in AAL records unless explicitly authorized by applicable policy.

   For federated learning, per-client identities MUST NOT appear
   in FLP records (Section 15.2).

   Blockchain anchoring publishes digest values to a public ledger.
   Producers MUST ensure that digest values alone do not reveal
   sensitive information.  Pre-image resistance of SHA3-512 provides
   strong protection against reverse-engineering payload content
   from anchored digests.


20.  Security Considerations

20.1.  Key Compromise

   Private keys used for COSE/CMS MUST be protected in HSMs or
   equivalent.  Short-lived device certificates and revocation
   (OCSP/CRL) are RECOMMENDED.  Compromised keys MUST NOT trigger
   data deletion; instead, append signed revocation facts and
   supersede with new signatures.  The immutability of prior
   records is a fundamental security property of RSP.

20.2.  Time Attacks

   Producers MUST use authenticated time (NTS, RFC 8915) and
   monotonic counters.  Multiple independent time sources are
   RECOMMENDED.  Large backward jumps MUST be flagged as
   ERR_TIME_INVALID.  Roughtime [ROUGHTIME] provides an additional
   authenticated time source with accountability for incorrect time.

20.3.  Quantum Threat Model

   RSP-Quantum and RSP-Full implementations are designed to resist
   the following quantum adversary capabilities:

   *  Grover's algorithm against SHA-256:  Mitigated by SHA3-512
      (post-quantum resilient, 256-bit effective security under
      Grover) and BLAKE3 (independent algorithmic family).

   *  Structural attacks on SHA-2 family:  Mitigated by SHA3-512
      (Keccak sponge construction, structurally independent of
      SHA-2) and BLAKE3.

   *  Cross-chain binding attack:  An adversary seeking to forge
      the CPO must simultaneously break SHA-256, SHA3-512, and
      BLAKE3 AND produce a valid cross-chain binding hash.  No
      known quantum algorithm achieves this.

   RSP-Basic implementations do not claim quantum resilience.
   Operators of long-term provenance systems (20+ year horizon)
   SHOULD deploy RSP-Quantum or RSP-Full.

20.4.  Proof Stability

   Anchoring to multiple independent chains (heterogeneous consensus)
   reduces correlation risk and single-chain failure.  Re-anchoring
   of historical Merkle roots over time is RECOMMENDED for longevity
   as new cryptographic standards emerge.

20.5.  Replay and Substitution

   Bind signatures to digests and policy context.  DOIs and REMIDs
   provide stable identity to detect artifact swaps.  Monotonic
   counters in AALs prevent action replay attacks in agentic
   deployments.

20.6.  Supply Chain

   Model and dataset supply chain attestations (e.g., SBOM-like
   metadata, RATS evidence) are RECOMMENDED but out of scope to
   normatively specify here.  The FLP structure (Section 15) provides
   aggregate supply chain provenance for federated training.

   Security considerations follow RFC 3552 guidance.


21.  IANA Considerations

   IANA is requested to register the following media types:

   21.1  application/rsp-ep+json   (unchanged from -00)
   21.2  application/rsp-ep+cbor   (unchanged from -00)

   21.3  application/rsp-cpo+json

     Type name:           application
     Subtype name:        rsp-cpo+json
     Required parameters: none
     Optional parameters: charset (per RFC 6838)
     Encoding considerations:  binary; JSON (RFC 8259)
     Security considerations:  see Section 20
     Published specification:  this document
     Applications:  AI provenance systems using RSP triple-hash
     File extension(s):  .rsp-cpo.json
     Person & email address:
       Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
     Intended usage:  COMMON

   21.4  application/rsp-cpo+cbor

     Type name:           application
     Subtype name:        rsp-cpo+cbor
     Required parameters: none
     Encoding considerations:  binary; CBOR (RFC 8949)
     Security considerations:  see Section 20
     Published specification:  this document
     Applications:  AI provenance systems using RSP triple-hash
     File extension(s):  .rsp-cpo.cbor
     Person & email address:
       Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
     Intended usage:  COMMON


22.  Implementation Status

   Note to RFC Editor:  Please remove this section before publication.

   This section documents the implementation status of RSP as of
   March 2026, per RFC 7942.

22.1.  REM Protocol Verification Agent

   Organization:  Lawrence John Reilly Jr., Independent
   Description:   Live deployment of the REM Protocol infrastructure
                  providing REMID assignment, triple-hash chain
                  integrity, IPFS pinning via Pinata, Bitcoin OTS
                  anchoring, and verification page generation.
   URL:           https://rem-protocol-agent-production.up.railway.app
   Coverage:      RSP-Full anchoring substrate.
   License:       Proprietary.
   Contact:       lawrencejohnreilly@gmail.com

22.2.  Reference SEP Records

   Multiple SEPs have been issued and anchored through the REM
   infrastructure, including:

   *  REMID: 2026.0328/e39dd6db
      DOI:   10.5281/zenodo.19299622
      Title: Spreadsheet AI Invention Declaration
      Anchored: 2026-03-28T22:08:38 UTC

   *  REMID: zenodo/19192612
      DOI:   10.5281/zenodo.19192612
      Title: Token config (RLT genesis)
      Anchored: 2026-03-23T19:07:09 UTC

22.3.  Planned Implementations

   Reference implementations for SEP creation, CPO generation,
   triple-hash computation, and verification are planned for public
   release under open-source license.  The Python implementation of
   the REM Multi-Algorithm Stack (REM-MAS) with 27/27 tests passing
   provides the cryptographic substrate for triple-hash operations.


23.  References

23.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON)
              Data Interchange Format", RFC 8259, December 2017.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise
              Data Definition Language (CDDL)", RFC 8610, June 2019.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020.

   [RFC8915]  Franke, D., "Network Time Security for the Network
              Time Protocol", RFC 8915, September 2020.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949, Dec 2020.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption
              (COSE): Structures and Process", RFC 9052, Aug 2022.

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption
              (COSE): Algorithms", RFC 9053, August 2022.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 5652, September 2009.

   [RFC9334]  Birkholz, H., et al., "Remote Attestation Procedures
              Architecture", RFC 9334, January 2023.

23.2.  Informative References

   [RSP00]    Reilly, L. J., "Reilly Sentinel Protocol (RSP) -00",
              draft-reilly-sentinel-protocol-00, September 2025.

   [REM01]    Reilly, L. J., "Reilly EternaMark (REM) Protocol",
              draft-reilly-rem-protocol-01, 2026.
              Zenodo: doi:10.5281/zenodo.17129012.

   [RBIP01]   Reilly, L. J., "Reilly Banking Integrity Protocol",
              draft-reilly-banking-integrity-01, 2026.

   [RRP01]    Reilly, L. J., "Reilly Resilience Protocol",
              draft-reilly-resilience-protocol-01, 2026.

   [CTS00]    Reilly, L. J., "Cognitive Trust Stack",
              draft-reilly-cts-00, 2026.
              Zenodo: doi:10.5281/zenodo.19098735.

   [SCITT]    IETF, "Supply Chain Integrity, Transparency, and
              Trust (SCITT) Working Group Charter", IETF Datatracker.

   [C2PA]     Coalition for Content Provenance and Authenticity,
              "C2PA Specification", 2023.

   [OTS]      OpenTimestamps community, "OpenTimestamps:
              Scalable Timestamping", online documentation.

   [DATACITE] DataCite Metadata Schema 4.x, DataCite.

   [BLAKE3]   O'Connor, J., et al., "BLAKE3: One Function, Fast
              Everywhere", 2020.

   [ROUGHTIME] Sleep, W., et al., "Roughtime",
              draft-ietf-ntp-roughtime, work in progress.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of
              Running Code: The Implementation Status Section",
              RFC 7942, July 2016.

   [RFC6839]  Hansen, T. and A. Melnikov, "Additional Media Type
              Structured Syntax Suffixes", RFC 6839, January 2013.


Appendix A.  CDDL for CBOR SEP (v1.1)

   sep = {
     version: tstr,               ; "1.1"
     artifact: {
       type: tstr
     },
     ? payloads: [* payload],
     digests: {
       sha256: tstr,              ; lowercase hex
       sha3_512: tstr,            ; lowercase hex (post-quantum)
       blake3: tstr,              ; lowercase hex
       ? root: tstr               ; Merkle root for chunked
     },
     ? cpo_ref: tstr,             ; Reference to CPO
     timestamps: {
       wallclock: tstr,           ; RFC3339
       ? monotonic: uint,
       ? source: tstr             ; "nts", "roughtime", etc.
     },
     ? authors: [* { name: tstr, ? id: tstr, ? orcid: tstr }],
     ? attestation: any,
     rem: {
       ? remid: tstr,             ; REMID:YYYY.MMDD/xxxxxxxx
       ots_proof_ref: tstr,
       doi: tstr,
       ? ipfs_cid: tstr,
       ? verification_url: tstr,
       lineage: {
         ? parent: [* tstr],
         ? siblings: [* tstr],
         ? supersedes: [* tstr]
       },
       ? quantum_resilient: bool
     },
     ? agentic: {
       session_id: tstr,
       agent_id: tstr,
       model_id: tstr,
       action_count: uint,
       merkle_root: tstr,
       ? actions: [* action_record]
     },
     ? federated: {
       round_id: tstr,
       aggregation_id: tstr,
       participant_count: uint,
       update_root: tstr,
       global_model_doi: tstr,
       privacy_mechanism: tstr
     },
     ? class: any,
     ? policies: any,
     signatures: [* any]
   }

   payload = {
     cid: tstr,
     size: uint,
     ? mime: tstr,
     ? chunking: tstr
   }

   action_record = {
     seq: uint,
     timestamp: tstr,
     action_type: tstr,
     input_digest: tstr,          ; SHA3-512
     output_digest: tstr,         ; SHA3-512
     ? tool_id: tstr,
     ? parent_seq: uint,
     ? attestation_ref: tstr
   }


Appendix B.  Example JSON SEP with Triple-Hash

   {
     "version": "1.1",
     "artifact": {"type": "training.checkpoint"},
     "digests": {
       "sha256":   "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4...",
       "sha3_512": "b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5...",
       "blake3":   "c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6..."
     },
     "cpo_ref": "urn:rem:cpo:YYYY.MMDD/xxxxxxxx",
     "timestamps": {
       "wallclock": "2026-01-01T00:00:00Z",
       "source": "nts"
     },
     "rem": {
       "remid": "REMID:YYYY.MMDD/xxxxxxxx",
       "ots_proof_ref": "urn:ots:btc:txid:example",
       "doi": "10.5281/zenodo.example",
       "ipfs_cid": "bafkreiexamplecidvalue...",
       "verification_url":
         "https://rem-protocol-agent-production.up.railway.app/
          verify/REMID%3AYYYY.MMDD%2Fxxxxxxxx",
       "lineage": {},
       "quantum_resilient": true
     },
     "signatures": [{"type": "COSE_Sign1", "value": "..."}]
   }


Appendix C.  Verification Report (JSON)

   {
     "doi": "10.5281/zenodo.example",
     "remid": "REMID:YYYY.MMDD/xxxxxxxx",
     "hash_ok": {
       "sha256": true,
       "sha3_512": true,
       "blake3": true
     },
     "cpo_ok": true,
     "sig_ok": true,
     "attestation_ok": true,
     "ots_ok": true,
     "time_ok": true,
     "doi_ok": true,
     "remid_ok": true,
     "ipfs_ok": true,
     "revocation_status": "not_revoked",
     "quantum_resilient": true,
     "overall": "VERIFIED",
     "verified_at": "2026-03-28T22:30:00Z"
   }


Appendix D.  Example OpenTimestamps Receipt (Non-normative)

   An OTS receipt includes commitment operations and attestations
   that enable independent reconstruction of inclusion in a public
   chain.  See [OTS].  For RSP, OTS receipts SHOULD cover the
   cross-chain binding hash (Section 6.2) rather than individual
   algorithm hashes, providing a single anchored commitment to all
   three chain states.


Appendix E.  Example DOI Metadata Mapping (DataCite)

   title:       "Example AI Training Checkpoint"
   creators:    [{"name": "Lawrence John Reilly Jr."}]
   created:     "2026-01-01T00:00:00Z"
   fixity:
     sha256:    "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4..."
     sha3_512:  "b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5..."
     blake3:    "c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6..."
     cross_chain: "d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1..."
   rem_id:      "REMID:YYYY.MMDD/xxxxxxxx"
   ipfs_cid:    "bafkreiexamplecidvalue..."
   quantum_resilient: true


Appendix F.  Composite Proof Object (CPO) Format

   A CPO binds three chain hashes and their cross-chain binding:

   {
     "cpo_version": "1.0",
     "record_id": "<uuid>",
     "remid": "REMID:YYYY.MMDD/xxxxxxxx",
     "created_at": "<RFC3339>",
     "chain": {
       "block_index": <uint>,
       "sha256_chain_hash": "<hex>",
       "sha3_512_chain_hash": "<hex>",
       "blake3_chain_hash": "<hex>",
       "cross_chain_hash": "<hex>",
       "prev_sha256_chain": "<hex>",
       "prev_sha3_512_chain": "<hex>",
       "prev_blake3_chain": "<hex>"
     },
     "quantum_resilient": true,
     "signatures": [{"type": "COSE_Sign1", "value": "..."}]
   }

   The cross_chain_hash MUST equal:
   SHA3-512(sha256_chain_hash || sha3_512_chain_hash ||
            blake3_chain_hash)

   Verifiers MUST recompute this value and reject CPOs where the
   computed value does not match the recorded cross_chain_hash.


Appendix G.  Agentic Action Log Example (Non-normative)

   {
     "version": "1.1",
     "artifact": {"type": "agentic.action.log"},
     "agentic": {
       "session_id": "sess-20260328-001",
       "agent_id": "spreadsheet-ai-v1.0",
       "model_id": "claude-haiku-4-5",
       "action_count": 13,
       "merkle_root": "sha3_512:abc123...",
       "actions": [
         {
           "seq": 1,
           "timestamp": "2026-03-28T21:06:00Z",
           "action_type": "inference",
           "input_digest": "sha3_512:input_hash_1...",
           "output_digest": "sha3_512:output_hash_1...",
           "tool_id": "spreadsheet-ai:rewrite",
           "parent_seq": null
         }
       ]
     }
   }


Appendix H.  Change Log

   Changes from draft-reilly-sentinel-protocol-00 to -01:

   H.1  Abstract
      Extended to cover quantum-resistant triple-hash architecture,
      agentic AI provenance, streaming inference, and federated
      learning provenance.

   H.2  Section 1 (Introduction)
      Added motivation for quantum resilience and agentic AI
      provenance.  Added Section 1.1 summarizing changes.

   H.3  Section 2 (Terminology)
      Added CPO, CRQC, REM, AAL, SIP, FLP definitions.

   H.4  Section 4 (SEP Data Model)
      Added sha3_512, blake3, cpo_ref, rem.remid, rem.ipfs_cid,
      rem.verification_url, rem.quantum_resilient, agentic, and
      federated sub-objects.  Version bumped to "1.1".

   H.5  Section 5 (new)
      Quantum-resistant triple-hash architecture.

   H.6  Section 6 (new)
      Cross-chain binding and Composite Proof Objects.

   H.7  Section 8 (Anchoring)
      Added requirement to anchor cross-chain binding hash.

   H.8  Section 9 (DOI)
      Added triple-hash fields and REMID to DOI metadata.

   H.9  Section 10 (new)
      REM Protocol triple-layer permanence integration.

   H.10 Section 11 (Operations)
      Added REVOKE operation.  Updated SEAL and ANCHOR for CPO.

   H.11 Section 12 (Verification)
      Added CPO verification, IPFS check, and revocation check.
      Expanded Verification Report fields.

   H.12 Section 13 (new)
      Agentic AI provenance extensions.

   H.13 Section 14 (new)
      Streaming inference provenance.

   H.14 Section 15 (new)
      Federated learning provenance.

   H.15 Section 16 (new)
      Conformance framework with RSP-Basic, RSP-Quantum, RSP-Full.

   H.16 Section 17 (Error Handling)
      Added ERR_CPO_INVALID, ERR_REMID_RESOLVE, ERR_IPFS_RESOLVE,
      ERR_REVOKED.

   H.17 Section 18 (Telemetry)
      Added agentic monitoring requirements.

   H.18 Section 20 (Security)
      Expanded threat model with quantum attack analysis.

   H.19 Section 21 (IANA)
      Added rsp-cpo+json and rsp-cpo+cbor media types.

   H.20 Section 22 (Implementation Status)
      Updated with live REM deployment and reference SEP records.

   H.21 Appendices
      Added Appendix F (CPO format), Appendix G (AAL example),
      Appendix H (this change log).
      Updated Appendices A, B, C, E for triple-hash fields.


Acknowledgments

   The author acknowledges the foundational work of the IETF SCITT
   working group, the OpenTimestamps community, and the DataCite
   consortium whose infrastructure and standards underpin RSP
   deployments.  The REM Protocol triple-layer permanence
   infrastructure described in this document was designed and
   implemented by the author.


Author's Address

   Lawrence John Reilly Jr.
   Independent Researcher

   Email: lawrencejohnreilly@gmail.com
   IETF Datatracker:
     https://datatracker.ietf.org/person/lawrencejohnreilly@gmail.com
   Zenodo Archive: https://zenodo.org/records/17103522
   REM Verification:
     https://rem-protocol-agent-production.up.railway.app
