Independent Submission L.J. Reilly Jr.
Internet-Draft Independent
Intended status: Informational 7 August 2026
Expires: 8 February 2027
Cognitive Trust Stack (CTS): A Framework for Verifiable
AI Behavioral Provenance
draft-reilly-cts-01
Abstract
Every artificial intelligence system deployed today operates
under behavioral constraints that are unverifiable by any
external party. Alignment claims exist as documentation,
policy statements, or terms of service -- all mutable, none
cryptographically provable. When an AI system causes harm,
there is no mechanism to prove what rules it was following.
When an organization claims its AI is safe, there is no
standard by which that claim can be independently verified.
This is the AI behavioral provenance problem, and no existing
framework solves it.
The Cognitive Trust Stack (CTS) establishes that the alignment
state of an AI system at any point in time MUST be a verifiable
fact, not an assertion requiring trust. CTS defines a complete,
implementable framework for declaring, anchoring, enforcing,
and verifying AI behavioral constraints through a five-layer
architecture combining: (1) a declarative alignment schema
formatted to IETF Internet-Draft standards, (2) archival
permanence via Digital Object Identifier (DOI) registration,
(3) cryptographic temporal anchoring via Bitcoin blockchain
timestamping using the Dual-Layer Digital Permanence (DLDP)
methodology [REILLY-REM], (4) runtime retrieval injection for
active constraint enforcement, and (5) independent third-party
verification.
CTS does not replace existing AI alignment techniques. It
provides the missing accountability layer that sits above them
-- making alignment a cryptographically provable fact rather
than an unverifiable claim.
The full CTS specification, reference implementation, schema,
and provenance manifest are published at Zenodo DOI
10.5281/zenodo.19097169. The priority of this framework is
cryptographically anchored in Bitcoin block 941168
(2026-03-18), with SHA-256 hash:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
The OpenTimestamps proof file
(CTS_Whitepaper_v1.0.docx.ots), included in the Zenodo
record, provides independent cryptographic verification of
existence prior to block 941168.
This revision (-01) additionally documents the function of
CTS records as prior art records under 35 U.S.C. 102(a)(1),
clarifies the scope of the canonical v1.0 cryptographic
anchor (which covers the whitepaper artifact), introduces a
normative one-hash-per-artifact anchoring rule, and corrects
an erroneous reference to the REM Protocol draft name
present in -00.
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 8 February 2027.
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 . . . . . . . . . . . . . . . . . . . . 4
1.1. The Broken Promise of AI Alignment . . . . . . . 4
1.2. The Four Failures of Current AI Governance . . . 5
1.3. The CTS Solution . . . . . . . . . . . . . . . . 7
1.4. What CTS Is and Is Not . . . . . . . . . . . . . 8
1.5. The CTS Whitepaper and Zenodo Record . . . . . . 9
1.6. Relationship to Existing Frameworks . . . . . . . 10
1.7. Relationship to DLDP and REM Protocol . . . . . . 12
2. Terminology . . . . . . . . . . . . . . . . . . . . . 13
3. CTS Architecture . . . . . . . . . . . . . . . . . . 15
3.1. Layer 1 - Alignment Schema . . . . . . . . . . . 16
3.2. Layer 2 - Archival Permanence (DOI) . . . . . . 19
3.3. Layer 3 - Cryptographic Anchoring . . . . . . . 21
3.4. Layer 4 - Retrieval Injection . . . . . . . . . 24
3.5. Layer 5 - Evaluation (Verification) . . . . . . 27
4. Provenance Manifest . . . . . . . . . . . . . . . . . 28
5. Immutable Priority Record and Prior Art Function . . 30
5.1. Immutable Priority Record . . . . . . . . . . . . 30
5.2. Function as a Prior Art Record Under
35 U.S.C. 102(a)(1) . . . . . . . . . . . . . . . 31
6. Use Cases . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . 40
Appendix A. Change Log . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 43
1. Introduction
1.1. The Broken Promise of AI Alignment
Artificial intelligence systems -- particularly large language
models (LLMs) and autonomous AI agents -- are now deployed at
global scale across healthcare, finance, legal services,
education, infrastructure, and government. Each of these
deployments carries an implicit or explicit promise: that the
AI system behaves according to a declared set of rules,
constraints, and ethical commitments.
This promise is, in every current deployment, unverifiable.
Organizations declare alignment through blog posts, terms of
service, model cards, and internal policy documents.
Regulators reference compliance frameworks. Researchers
publish alignment techniques. But not one of these mechanisms
produces a cryptographically verifiable record that answers
the fundamental question:
"What behavioral rules was this AI system actually
operating under at this specific moment in time --
and how can anyone independently prove it?"
No existing standard answers this question. No existing
framework makes AI alignment a provable fact rather than an
asserted claim. The result is a global AI governance
environment built on trust without verification -- the precise
condition that cryptographic and distributed systems
engineering has spent decades learning to eliminate in other
domains.
CTS is the missing verification layer. It establishes that
AI behavioral provenance -- the cryptographically verifiable
record of what constraints an AI system was operating under
at a given time -- is not only necessary but achievable today
using existing infrastructure, without requiring changes to
underlying AI systems, new hardware, or proprietary tooling.
1.2. The Four Failures of Current AI Governance
The absence of a behavioral provenance standard creates four
compounding failures that no existing framework resolves:
Auditability Failure: Organizations cannot produce
cryptographic proof of the alignment rules their AI
systems enforced at deployment. Internal documentation
is mutable. Vendor attestations require trust. No
independent, tamper-evident record exists. When
regulators, auditors, or courts request evidence of AI
behavioral constraints at a specific point in time,
there is no authoritative record to produce.
Accountability Failure: When an AI system produces harmful,
discriminatory, or non-compliant output, there is no
tamper-evident record establishing whether that output
violated the system's stated constraints or was consistent
with them. Without behavioral provenance, accountability
is reduced to vendor self-reporting and post-hoc
rationalization. The system that caused harm and the
documentation describing its intended behavior are both
mutable -- neither can be independently verified against
the other.
Interoperability Failure: There is no common schema for
expressing AI behavioral constraints in a machine-readable,
version-controlled format exchangeable across organizations,
jurisdictions, or regulatory bodies. Every organization
invents its own documentation format. No two AI
deployments express their constraints in a way that any
other system or auditor can parse, compare, or verify.
This makes cross-organizational AI governance structurally
impossible.
Permanence Failure: Alignment documentation stored in
private repositories, internal wikis, or vendor systems
can be altered retroactively. There is no chain of
custody. A document describing an AI system's behavioral
constraints today may be silently modified tomorrow, and
no record of the original will exist. In regulated
industries, this represents a fundamental failure of
record-keeping integrity.
These four failures are not theoretical. They manifest in
every AI incident investigation, every regulatory audit, and
every legal proceeding involving AI-generated output. CTS
resolves all four through a single unified methodology.
1.3. The CTS Solution
The Cognitive Trust Stack reframes AI alignment as an
engineering and provenance problem rather than a policy
problem. The insight is this: the tools needed to solve AI
behavioral provenance already exist. Cryptographic hashing,
blockchain timestamping, DOI archival, and retrieval-based
injection are all mature, deployed technologies. What has
been missing is a standard that combines them into a complete,
interoperable framework.
CTS provides that standard.
The framework operates on a simple principle: if you can
declare what behavioral rules an AI system follows, hash that
declaration, anchor the hash to an immutable record before
deployment, and inject those rules into every inference
request, then the alignment state of that system at any point
in time becomes an independently verifiable fact.
This is not a novel cryptographic invention. It is the
application of proven provenance engineering -- the same
principles that underpin document notarization, software bill
of materials (SBOM), and blockchain-based intellectual
property protection -- to the specific problem of AI
behavioral constraints.
What CTS adds to existing practice is:
o A standardized, machine-readable schema for declaring AI
behavioral constraints (Section 3.1)
o A normative process for anchoring that schema to
institutional and cryptographic permanence simultaneously
(Sections 3.2, 3.3)
o A runtime enforcement mechanism that ties the anchored
schema directly to inference behavior (Section 3.4)
o A verification protocol enabling any party to
independently confirm the complete provenance chain
without trusting the declaring organization (Section 3.5)
o A provenance manifest format that serves as the
authoritative audit document (Section 4)
Together these components form an accountability layer that
can sit above any AI system, any alignment technique, and
any deployment context. A schema that can be changed is a
promise. A schema with a locked hash and a Bitcoin anchor
is a fact.
1.4. What CTS Is and Is Not
CTS IS:
o A provenance and verification standard for AI behavioral
constraints
o A framework applicable to any LLM, AI agent, or automated
decision system regardless of underlying architecture
o A mechanism for making AI alignment claims independently
verifiable without trusting the declaring organization
o An open standard designed for IETF standardization and
free adoption by any implementer
o Infrastructure -- like HTTP or TLS -- intended to underpin
AI governance across industries and jurisdictions
CTS IS NOT:
o An alignment technique (it does not train or fine-tune
models)
o A replacement for constitutional AI, RLHF, or other
alignment methods (it archives and verifies their outputs)
o A proprietary product or commercial service
o A guarantee of AI safety (it verifies declared constraints,
not the sufficiency of those constraints)
o Limited to large organizations (it is implementable by
any individual or entity with access to Zenodo and
OpenTimestamps, both of which are free)
1.5. The CTS Whitepaper and Zenodo Record
The complete CTS specification is accompanied by a whitepaper
titled "Cognitive Trust Stack (CTS): A Framework for
Verifiable AI Behavioral Provenance" (v1.0, March 2026),
authored by Lawrence John Reilly Jr.
The whitepaper and all associated files are permanently
archived at:
Zenodo DOI: 10.5281/zenodo.19097169
URL: https://zenodo.org/records/19097169
The Zenodo record contains three files:
CTS_Whitepaper_v1.0.docx: The complete CTS whitepaper
containing the full framework specification, architecture
description, reference implementation, DOI publication
steps, blockchain anchoring steps, provenance manifest
example, and conclusion. This is the artifact covered
by the canonical v1.0 cryptographic anchor
(Section 3.3), with SHA-256:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
cts_framework.json: The canonical CTS v1.0 alignment
schema, incorporated in full within the anchored
whitepaper and reproduced in Section 3.1 of this
document. Its own SHA-256 hash is recorded in the
deployment provenance manifest (Section 4).
CTS_Whitepaper_v1.0.docx.ots: The OpenTimestamps proof
file anchoring the whitepaper SHA-256 above to Bitcoin
block 941168 (2026-03-18). Running "ots verify
CTS_Whitepaper_v1.0.docx.ots" independently confirms
existence prior to that block.
The whitepaper contains the following sections incorporated
by reference into this Internet-Draft:
Overview: Defines CTS and its core equation:
CTS = DLDP (provenance) + DOI (archival) + IETF schema
+ Retrieval + Evaluation.
Architecture Summary: Describes the five-layer stack and
the role of each layer in the complete trust chain.
Working Demo: A complete, executable Python reference
implementation demonstrating CTS schema loading, rule
extraction, and prompt injection, verified to produce
correct output against the canonical schema.
DOI Publication Steps: Normative Zenodo registration
process including file preparation, metadata
requirements, DOI reservation, and publication.
Blockchain Anchoring: Normative OpenTimestamps anchoring
process including SHA-256 hash generation, OTS proof
file creation, and manifest recording.
Provenance Manifest Example: The canonical manifest format
binding all five CTS layers into a single audit document.
Conclusion: Establishes that CTS proves AI behavioral
alignment through environment-based retrieval, with
cryptographic proof of the declared constraints in
effect at any point in time.
1.6. Relationship to Existing Frameworks
CTS is designed as a complementary accountability layer to
existing AI governance frameworks. It does not compete with
these frameworks; it provides the verification mechanism
they currently lack.
OECD AI Principles [OECD-AI]: The OECD principles call for
transparency and accountability in AI systems but provide
no technical mechanism for verifying compliance. CTS
operationalizes verification of OECD transparency
requirements by creating a tamper-evident record of
declared behavioral constraints.
NIST AI Risk Management Framework [NIST-AIRMF]: The NIST
AI RMF defines a lifecycle approach to AI risk management
including documentation requirements. CTS anchors the
documentation layer of the NIST framework, transforming
mutable internal records into cryptographically verifiable
external records. CTS provenance manifests directly
satisfy the GOVERN, MAP, MEASURE, and MANAGE function
documentation requirements of the NIST AI RMF.
EU AI Act [EU-AIA]: The EU AI Act imposes mandatory
record-keeping requirements on high-risk AI systems under
Article 9 (Risk Management System) and Article 12
(Record Keeping). CTS provides the technical mechanism
for satisfying these requirements with tamper-evident,
independently verifiable records that can be produced to
regulators without depending on the AI vendor's own
documentation.
UNESCO AI Ethics Recommendation [UNESCO-AI]: UNESCO's
recommendation calls for transparency and auditability
of AI systems. CTS preserves declared ethics
commitments in a cryptographically permanent record,
enabling the accountability UNESCO calls for.
Constitutional AI: Constitutional AI and similar techniques
define the behavioral rules an AI system follows during
training or inference. CTS archives the constitution or
constraint set used at deployment, enabling post-hoc
verification that the deployed system matched the
described alignment technique.
Universal AI Ethics and Moral Framework [REILLY-UAEMF]:
The UAEMF (draft-reilly-uaemf-00, DOI
10.5281/zenodo.19010455, Bitcoin block 940570) defines
universal ethical principles for AI systems. CTS
provides the technical anchoring mechanism by which
UAEMF-compliant deployments can be independently
verified. A CTS schema can directly encode UAEMF
principles as its declared constraints.
1.7. Relationship to DLDP and REM Protocol
CTS is built on the Dual-Layer Digital Permanence (DLDP)
methodology established in the Reilly EternaMark Protocol
(REM Protocol) [REILLY-REM]. DLDP combines DOI-based
archival permanence with Bitcoin blockchain timestamping
to create records that are simultaneously institutionally
recognized and cryptographically immutable.
The REM Protocol established DLDP as a general-purpose
permanence methodology. CTS is the first formal
application of DLDP to the specific problem of AI
behavioral provenance.
The layered relationship is:
o REM Protocol defines the DLDP methodology (DOI + Bitcoin)
o CTS applies DLDP to AI alignment schemas specifically
o UAEMF defines the ethical content that CTS schemas encode
o CTS provides the verification layer making UAEMF
compliance provable
This represents a coherent standards architecture: REM
Protocol provides the permanence infrastructure, UAEMF
provides the ethical content standard, and CTS provides
the deployment-level verification mechanism.
Revision -02 of the REM Protocol additionally specifies
the function of Full REM Records as prior art records
under 35 U.S.C. 102(a)(1) [USC-35-102]. Because a
conformant CTS publication is a Full REM Record over its
anchored artifacts, that function extends to CTS records
as specified in Section 5.2 of this document.
2. 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.
Alignment Schema: A structured, machine-readable
declaration of an AI system's behavioral constraints,
formatted as a JSON document conforming to the CTS
schema specification in Section 3.1. The alignment
schema is the foundational artifact of CTS -- the
document that is hashed, anchored, and injected.
Behavioral Provenance: The cryptographically verifiable
record establishing what behavioral constraints an AI
system was operating under at a specific point in time.
Behavioral provenance answers "what rules was this AI
following?" with mathematical certainty rather than
organizational trust.
CTS: Cognitive Trust Stack. The complete five-layer
framework defined in this document.
DLDP: Dual-Layer Digital Permanence. The methodology
combining DOI-based archival permanence with Bitcoin
blockchain timestamping, as established in [REILLY-REM].
DOI: Digital Object Identifier. A persistent identifier
conforming to [ISO-DOI] used to create institutionally
recognized permanent records through archival platforms
such as Zenodo.
OTS Proof File: An OpenTimestamps proof file (.ots
extension) containing the cryptographic Merkle path
from a document's SHA-256 hash to a confirmed Bitcoin
blockchain transaction, enabling trust-minimized
independent verification.
Prior Art Record: A publicly deposited, blockchain-
anchored record whose underlying artifact content is
available to the public without restriction, such that
the artifact constitutes a disclosure available to the
public within the meaning of 35 U.S.C. 102(a)(1)
[USC-35-102], with the blockchain timestamp serving as
independent corroboration of the date of public
availability. Defined in [REILLY-REM] Section 12.1
and applied to CTS in Section 5.2 of this document.
Provenance Manifest: A structured JSON record tying
together all five CTS layers: schema metadata, DOI
record, blockchain anchor, OTS proof reference, and
verification instructions.
Retrieval Injection: The runtime mechanism by which a
CTS alignment schema is loaded and prepended to AI
inference requests, ensuring declared behavioral
constraints are actively applied during every inference
call within the declared scope.
Trust Chain: The complete sequence of verifiable records
linking a declared alignment schema through DOI
archival, Bitcoin anchoring, and runtime injection to
independently verifiable proof of behavioral provenance.
3. CTS Architecture
The Cognitive Trust Stack is organized as five distinct
layers. Each layer performs a specific function and depends
on the layers beneath it. Together they form a complete
trust chain from behavioral declaration to cryptographic
verification.
The CTS equation is:
CTS = Alignment Schema (IETF) +
Archival Permanence (DOI) +
Cryptographic Anchoring (Blockchain) +
Retrieval Injection (Runtime) +
Evaluation (Verification)
This architecture is designed so that each layer is
independently useful but the complete stack is required for
full behavioral provenance. An alignment schema without
anchoring is a mutable document. Anchoring without
injection is a provenance record with no runtime effect.
Injection without anchoring cannot be verified. All five
layers together produce a deployment whose behavioral
constraints are declared, permanent, enforced, and
independently verifiable.
3.1. Layer 1 - Alignment Schema (IETF Format)
The foundation of CTS is a structured, machine-readable
declaration of an AI system's behavioral constraints. This
declaration is the artifact that will be hashed, anchored
to the blockchain, registered as a DOI, and injected at
runtime. Everything in CTS flows from this document.
The alignment schema MUST contain the following fields:
cts_version: REQUIRED. Semantic version string.
Incrementing this version signals a constraint change
and requires a new anchoring record.
author: REQUIRED. Full legal name of the declaring
entity, establishing authorship in the permanent record.
date: REQUIRED. ISO 8601 date of schema finalization
(YYYY-MM-DD). MUST NOT be changed after anchoring.
scope: REQUIRED. Plain-language description of the
deployment context for which these constraints apply.
principles: REQUIRED. Array of objects, each containing:
o "id": unique principle identifier (e.g., "P1")
o "rule": plain-language behavioral rule string
constraints: REQUIRED. Array of objects, each containing:
o "id": unique constraint identifier (e.g., "C1")
o "type": "prohibition" or "disclosure"
o "rule": plain-language constraint string
The canonical CTS v1.0 alignment schema, as published in
the Zenodo record at 10.5281/zenodo.19097169
(file: cts_framework.json), is:
{
"cts_version": "1.0",
"author": "Lawrence John Reilly Jr.",
"date": "2026-03-18",
"scope":
"General-purpose AI assistant deployment",
"principles": [
{
"id": "P1",
"rule": "Prefer verified, citable sources
over inference"
},
{
"id": "P2",
"rule": "Disclose operational constraints
to users when relevant"
},
{
"id": "P3",
"rule": "Refuse requests that violate
declared ethical constraints"
},
{
"id": "P4",
"rule": "Maintain behavioral consistency
across equivalent prompts"
}
],
"constraints": [
{
"id": "C1",
"type": "prohibition",
"rule": "No generation of harmful or
deceptive content"
},
{
"id": "C2",
"type": "disclosure",
"rule": "Acknowledge AI identity when
sincerely asked"
}
]
}
Once finalized, the schema file MUST NOT be modified.
The SHA-256 hash of the file is the identifier used in
the blockchain anchor and provenance manifest. Any
modification produces a different hash, breaking the
verifiable chain.
3.2. Layer 2 - Archival Permanence (DOI Registration)
Once the alignment schema is finalized, it MUST be
submitted to a recognized archival platform to obtain a
Digital Object Identifier (DOI). The DOI provides
institutional permanence: the record is recognized by
academic databases, legal systems, and regulatory bodies
worldwide as a permanent, citable scholarly record.
This document uses Zenodo (https://zenodo.org), operated
by CERN, as the RECOMMENDED archival platform. Zenodo
is free, open-access, and provides long-term preservation
guarantees.
DOI registration provides three critical properties:
Institutional Recognition: DOI-registered documents are
recognized by courts, regulators, academic institutions,
and standards bodies worldwide. A Bitcoin transaction
ID is a cryptographic proof; a DOI is an institutional
proof. CTS requires both.
Human-Readable Metadata: The DOI record contains
structured metadata -- author, title, date, description,
version -- indexed by Google Scholar and other discovery
systems, making the CTS record discoverable without
requiring blockchain expertise.
File Integrity Preservation: The archival platform
preserves the exact bytes of deposited files. Anyone
downloading the schema from the DOI record and computing
its SHA-256 hash obtains the same value as the
blockchain anchor, enabling cross-verification.
The canonical CTS v1.0 DOI record is:
DOI: 10.5281/zenodo.19097169
URL: https://zenodo.org/records/19097169
This record contains three files: CTS_Whitepaper_v1.0.docx,
cts_framework.json, and CTS_Whitepaper_v1.0.docx.ots.
All three files are required for complete verification.
The DOI registration process is:
1. Finalize all files. No file may be modified after
this point.
2. Log in to zenodo.org and upload all files: alignment
schema, whitepaper, and OTS proof file(s).
3. Select "Reserve DOI" prior to publication to obtain
the DOI string in advance for inclusion in the IETF
draft and manifest.
4. Complete metadata: title, author, description,
version, license, and keywords. The metadata
description SHOULD include the SHA-256 hash of each
anchored artifact and its Bitcoin block reference,
so the public DOI landing page itself carries the
cross-reference.
5. Publish the record. After publication the record
and its DOI are immutable.
6. Record the DOI string and record URL in the
provenance manifest (Section 4).
3.3. Layer 3 - Cryptographic Anchoring (Blockchain)
DOI registration establishes institutional permanence
but relies on the integrity of the DOI registrar.
Layer 3 provides a second, independent permanence layer
through Bitcoin blockchain timestamping via OpenTimestamps
[OTS] -- a cryptographic timestamp verifiable without
trusting any organization, server, or authority.
The mechanism: OpenTimestamps computes the SHA-256 hash
of the submitted file, aggregates it with other submitted
hashes into a Merkle tree, and embeds the Merkle root
into a Bitcoin transaction. When confirmed, the hash --
and therefore the exact file content -- is permanently
associated with the block timestamp.
Any party with the original file and the OTS proof file
can verify this independently:
ots verify <artifact-file>.ots
This command verifies the cryptographic path from the
file hash to the Bitcoin block using only the proof file
and a Bitcoin node or block explorer API. The math is
the authority, not the organization.
Anchor Scope Rule: Each SHA-256 hash and each OTS proof
file corresponds to exactly one artifact file. A hash
value MUST NOT be attributed to more than one distinct
file, and every artifact whose integrity is relied upon
in the trust chain MUST be anchored with its own hash
and its own OTS proof file. In particular, deployments
conforming to this revision MUST anchor the alignment
schema file itself directly, in addition to any
whitepaper or container artifact that incorporates it.
Bitcoin [BITCOIN] is RECOMMENDED as the anchoring chain:
o Bitcoin's proof-of-work chain is the most
computationally secure public timestamping record in
existence. Rewriting confirmed blocks requires majority
control of the global Bitcoin hash rate -- estimated
to require billions of dollars of infrastructure.
o No single entity controls the Bitcoin chain. The
timestamp is not dependent on any company, government,
or organization remaining operational or honest.
o Bitcoin has operated continuously since January 2009.
Its operational history provides reasonable expectation
of permanent record availability.
o OpenTimestamps is free, requires no registration, and
produces proof files verifiable with open-source tools.
The anchoring process is:
1. Generate SHA-256 hash of each finalized artifact:
sha256sum cts_framework.json
2. Upload each file to https://opentimestamps.org or
use the OTS client [OTS-CLIENT]:
ots stamp cts_framework.json
3. Download the resulting .ots proof file(s) immediately.
These files MUST be retained permanently and co-
published with the Zenodo record.
4. Await Bitcoin transaction confirmation, typically
within 24 hours.
5. Verify each confirmed anchor:
ots verify cts_framework.json.ots
6. Record the confirmed block number and date in the
provenance manifest (Section 4).
CTS RECOMMENDS anchoring to transactions confirmed at
a depth of at least 6 blocks.
The canonical CTS v1.0 Bitcoin anchor covers the
whitepaper artifact CTS_Whitepaper_v1.0.docx, which
incorporates the canonical alignment schema in full:
Anchored File: CTS_Whitepaper_v1.0.docx
SHA-256:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
Bitcoin Block: 941168
Block Date: 2026-03-18
OTS File: CTS_Whitepaper_v1.0.docx.ots
Block Explorer:
https://blockstream.info/block/941168
OTS proof in: 10.5281/zenodo.19097169
The combination of DOI registration and Bitcoin anchoring
is what [REILLY-REM] terms dual-layer permanence: either
record independently establishes prior existence; together
they provide redundant, cross-verifiable proof that is
simultaneously institutionally recognized and
cryptographically immutable.
3.4. Layer 4 - Retrieval Injection (Runtime Enforcement)
The first three layers establish a permanent, verifiable
record of declared behavioral constraints. Layer 4 is
the runtime mechanism through which those constraints
are actively enforced during inference -- the bridge
between the permanent record and actual system behavior.
CTS uses retrieval-based alignment injection: the stored
cts_framework.json schema is loaded at runtime and its
declared principles and constraints are prepended to the
model's prompt context before every user request is
processed.
This mechanism works because modern LLMs and AI systems
are designed to follow instructions presented in the
prompt context. Rules injected via retrieval are treated
as active behavioral instructions. Every major LLM
inference API supports this pattern through system prompt
or context prepending.
Critically, the injected schema is the same file that
was hashed and anchored in Layer 3. This creates a
closed verification loop: the rules the system follows
at runtime are identical to the rules recorded in the
Bitcoin blockchain and the Zenodo archive. Any
modification to the injected schema produces a different
SHA-256 hash, breaking the verifiable chain and making
the modification detectable.
Implementations MUST prepend the full rule block to
every inference request within the declared scope.
Selective or partial injection violates CTS conformance.
The following is the complete reference implementation
in Python, as published in the CTS whitepaper at
10.5281/zenodo.19097169:
import json
def load_framework(path="cts_framework.json"):
with open(path) as f:
return json.load(f)
def apply_cts(prompt: str, framework: dict) -> str:
"""
Inject CTS alignment rules into prompt context.
The framework must be loaded from the anchored
cts_framework.json whose SHA-256 matches the
provenance manifest record.
"""
rules = []
for p in framework.get("principles", []):
rules.append(f"[{p['id']}] {p['rule']}")
for c in framework.get("constraints", []):
rules.append(
f"[{c['id']}] CONSTRAINT: {c['rule']}"
)
rule_block = "\n".join(rules)
return (
f"CTS Alignment Rules "
f"(v{framework['cts_version']}):\n"
f"{rule_block}\n\n"
f"User Request:\n{prompt}"
)
framework = load_framework("cts_framework.json")
aligned_prompt = apply_cts(user_input, framework)
# Pass aligned_prompt to any LLM inference endpoint
This implementation is framework-agnostic and compatible
with any LLM inference API accepting string prompts.
It has been verified to produce correct injection output
against the canonical schema at
10.5281/zenodo.19097169.
The output of apply_cts() for the canonical schema and
the prompt "Explain AI ethics" is:
CTS Alignment Rules (v1.0):
[P1] Prefer verified, citable sources over
inference
[P2] Disclose operational constraints to users
when relevant
[P3] Refuse requests that violate declared
ethical constraints
[P4] Maintain behavioral consistency across
equivalent prompts
[C1] CONSTRAINT: No generation of harmful or
deceptive content
[C2] CONSTRAINT: Acknowledge AI identity when
sincerely asked
User Request:
Explain AI ethics
This output demonstrates that CTS successfully bridges
the gap between permanent provenance record and active
AI behavior: the same constraints anchored to Bitcoin
block 941168 are the constraints the AI system applies
to every request.
3.5. Layer 5 - Evaluation (Verification)
Layer 5 enables any third party to independently verify
the complete CTS trust chain. Verification requires no
trust in the declaring organization -- only the anchored
artifact files, their OTS proof files, and access to a
Bitcoin block explorer.
A complete CTS verification MUST include three checks:
Artifact Integrity Check: Compute the SHA-256 hash of
each retrieved artifact and confirm it matches the
hash recorded for that artifact in the provenance
manifest:
sha256sum <artifact-file>
Expected for the canonical CTS v1.0 anchored artifact
(CTS_Whitepaper_v1.0.docx):
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
OTS Verification: Verify each OTS proof file against
its artifact:
ots verify CTS_Whitepaper_v1.0.docx.ots
Successful output confirms the Bitcoin block and
timestamp without trusting any server or organization.
Block Timestamp Check: Confirm the verified Bitcoin
block timestamp precedes or matches the claimed
deployment date:
https://blockstream.info/block/941168
A deployment passing all three checks has demonstrated
that its declared behavioral constraints are permanent,
timestamped, and identical to the constraints injected
at runtime -- a complete, independently verifiable
behavioral provenance chain.
4. Provenance Manifest
Each CTS deployment MUST generate a provenance manifest
-- a structured JSON record tying together all five
layers of the trust chain. The provenance manifest is
the primary artifact for regulatory audit, legal
proceedings, and third-party verification.
Every hash value in the manifest MUST be recorded as a
single unbroken 64-character lowercase hexadecimal
string. (Hash values in this document are wrapped
across lines only for column-width formatting.)
The manifest MUST contain all of the following fields:
{
"name": "Cognitive Trust Stack",
"version": "1.0",
"author": "Lawrence John Reilly Jr.",
"deployment_date": "2026-03-18",
"schema": {
"file": "cts_framework.json",
"sha256": "<64-char hex hash of the schema file>",
"ietf_draft": "draft-reilly-cts-01"
},
"anchored_artifacts": [
{
"file": "CTS_Whitepaper_v1.0.docx",
"sha256":
"e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2",
"ots_proof_file":
"CTS_Whitepaper_v1.0.docx.ots"
}
],
"doi": {
"identifier": "10.5281/zenodo.19097169",
"url": "https://zenodo.org/records/19097169",
"platform": "Zenodo (CERN)",
"status": "published",
"files": [
"CTS_Whitepaper_v1.0.docx",
"cts_framework.json",
"CTS_Whitepaper_v1.0.docx.ots"
]
},
"blockchain": {
"chain": "Bitcoin",
"block": "941168",
"block_date": "2026-03-18",
"explorer_url":
"https://blockstream.info/block/941168",
"ots_service":
"https://opentimestamps.org"
},
"verification": {
"artifact_hash_command":
"sha256sum <artifact-file>",
"ots_verify_command":
"ots verify <artifact-file>.ots",
"expected_block": "941168",
"expected_block_date": "2026-03-18"
}
}
The "anchored_artifacts" array is introduced in this
revision to implement the Anchor Scope Rule of
Section 3.3: it lists every artifact anchored for the
deployment, each with its own hash and OTS proof file
reference. Manifests produced under -00 carried a
single blockchain.ots_proof_file field; verifiers
encountering such manifests SHOULD treat that field as
an anchored_artifacts entry for the named file.
The provenance manifest SHOULD be co-published with the
Zenodo record and referenced in any deployment
documentation, regulatory filing, or legal proceeding
that relies on the CTS behavioral provenance chain.
5. Immutable Priority Record and Prior Art Function
5.1. Immutable Priority Record
The existence and priority of this framework are
cryptographically established by the following records,
each independently verifiable:
Anchored File: CTS_Whitepaper_v1.0.docx
Canonical Document SHA-256:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
Bitcoin Block: 941168
Block Date: 2026-03-18
OTS File: CTS_Whitepaper_v1.0.docx.ots
Zenodo DOI: 10.5281/zenodo.19097169
Zenodo URL: https://zenodo.org/records/19097169
IETF Draft: draft-reilly-cts-00 (initial),
draft-reilly-cts-01 (this revision)
Author: Lawrence John Reilly Jr.
Verification command:
ots verify CTS_Whitepaper_v1.0.docx.ots
Expected output:
Success! Bitcoin block 941168 attests existence
as of 2026-03-18
These records constitute dual-layer digital permanence
per [REILLY-REM]: the Zenodo DOI provides institutional
permanence and Bitcoin block 941168 provides
cryptographic temporal proof. Either record is
independently sufficient to establish prior existence.
Together they provide redundant, cross-verifiable proof
satisfying both technical and institutional verification
requirements.
5.2. Function as a Prior Art Record Under 35 U.S.C.
102(a)(1)
A conformant CTS publication is a prior art record under
United States patent law. 35 U.S.C. 102(a)(1)
[USC-35-102], as amended by the Leahy-Smith America
Invents Act, provides that a person shall not be entitled
to a patent if the claimed invention was patented,
described in a printed publication, or in public use, on
sale, or otherwise available to the public before the
effective filing date of the claimed invention.
Public accessibility of the disclosure content, as of a
provable date, is the operative requirement. A CTS
publication performed per Sections 3.2 and 3.3 produces
each of the evidentiary elements relevant to establishing
the published content as prior art under this provision:
Public Accessibility: Deposit in an open-access DOI
repository (Section 3.2) makes the full content of the
whitepaper, alignment schema, and proof files available
to any member of the public without restriction,
registration barrier, or fee, and discoverable via
globally resolvable DOI infrastructure and scholarly
indexing.
Date Certainty: The Bitcoin blockchain anchor
(Section 3.3) provides independent, cryptographically
verifiable corroboration that the anchored artifact
existed in its exact recorded form no later than the
confirmed block date, without reliance on the
publisher's own records, the repository operator's
logs, or witness testimony.
Content Integrity: The SHA-256 hash binds the asserted
prior art date to the precise byte-level content
disclosed. Any claim that the artifact was altered,
back-dated, or substituted after the asserted date is
defeated by hash verification (Section 3.5), since a
modified artifact cannot reproduce the anchored digest.
These are the Full REM Record criteria specified in
[REILLY-REM] Section 12.1; a conformant CTS publication
satisfies them by construction. Operated in this mode,
a CTS publication functions as a defensive publication:
the CTS framework itself, and the concepts, architecture,
and methods disclosed in any CTS-anchored artifact, enter
the body of prior art as of the recorded anchor date, and
may be cited against later-filed patent applications and
issued claims of third parties.
For the canonical record, the disclosures contained in
CTS_Whitepaper_v1.0.docx and this specification --
including the five-layer architecture, the alignment
schema format, the retrieval injection mechanism, and the
provenance manifest format -- constitute prior art as of
Bitcoin block 941168 (2026-03-18) per the anchor in
Section 5.1, with the Zenodo deposit providing the public
accessibility element.
Two limitations apply. First, only content actually made
available to the public functions as prior art: an
artifact that is hashed and anchored but not publicly
deposited (a Partial REM Record per [REILLY-REM]
Section 10.5) establishes proof of existence only.
Second, this section is informational. Whether a given
disclosure qualifies as prior art in a particular
examination, post-grant proceeding, or litigation is
determined by the applicable patent office or court on
the facts of that matter, and nothing in this document
constitutes legal advice.
6. Use Cases
6.1. Enterprise AI Compliance
Organizations deploying AI systems under the EU AI Act
[EU-AIA], NIST AI RMF [NIST-AIRMF], or similar
frameworks can use CTS to generate a tamper-evident
audit trail of the behavioral constraints their AI
systems operated under. This satisfies documentation
requirements under Article 9 (Risk Management) and
Article 12 (Record Keeping) of [EU-AIA] without
depending on proprietary logging infrastructure or
vendor self-reporting.
A CTS provenance manifest is producible as documentary
evidence that specific behavioral constraints were
declared, anchored, and enforced at a specific date,
independently of the AI vendor or deploying
organization.
6.2. AI Research Publication
Academic researchers publishing AI systems can anchor
the alignment constraints of their published models to
the Bitcoin blockchain at publication time. The CTS
provenance manifest enables reproducibility
verification: any party can confirm that behavioral
constraints described in a paper match the constraints
actually anchored at publication time.
This establishes a verifiable record of a model's
behavioral state at the time its research outputs were
generated, enabling post-hoc analysis of whether
outputs were consistent with declared constraints.
6.3. Legal and Regulatory Proceedings
In legal proceedings involving AI-generated outputs,
CTS provenance manifests provide verifiable evidence
of the behavioral constraints the AI system was
operating under at the time the output was generated.
The combination of DOI citation and Bitcoin block
timestamp creates a chain of custody evaluable under
existing evidence standards in most jurisdictions.
Unlike vendor-provided documentation, a CTS manifest
is independently verifiable: the opposing party can
verify the blockchain anchor themselves without relying
on the declaring organization's integrity.
6.4. AI API Providers
Organizations offering AI services via API can publish
CTS schemas for each model version and anchor them via
DLDP, enabling downstream customers to independently
verify that the model they are calling matches the
behavioral specification they contracted for. This
transforms behavioral alignment from a contractual
assertion into a cryptographically verifiable service
level commitment.
6.5. AI Systems and Autonomous Agents
As AI systems become increasingly autonomous -- executing
multi-step tasks, interacting with external services,
and making consequential decisions without direct human
supervision -- the need for verifiable behavioral
constraints becomes critical. CTS provides a mechanism
for declaring and anchoring the behavioral boundaries
of autonomous agents, enabling oversight bodies to
verify what rules an agent was operating under at the
time of any given action.
6.6. Defensive Publication and Prior Art Establishment
Inventors, researchers, and organizations disclosing AI
governance methods, alignment techniques, or system
architectures can publish those disclosures as CTS
records to establish them as prior art under
35 U.S.C. 102(a)(1), per Section 5.2. The open DOI
deposit provides public accessibility, the blockchain
anchor provides independent date corroboration, and the
hash binds the date to the exact content disclosed --
without the cost, delay, or jurisdictional limits of
patent prosecution. This use mode is specified in
detail in [REILLY-REM] Section 12.1.
7. Security Considerations
7.1. Threat Model
Schema Tampering: An adversary may attempt to alter
the cts_framework.json file after deployment to
misrepresent the AI system's constraints. CTS
mitigates this via the anchored SHA-256 hash: any
modified file produces a different hash that will
not match the recorded anchor, making post-hoc
alteration cryptographically detectable.
Anchor Scope Ambiguity: If a single hash or OTS proof
file is presented as covering more than one distinct
artifact, or an artifact in the trust chain lacks its
own anchor, verifiers cannot establish which content
the timestamp attests to, weakening the evidentiary
value of the entire chain. The Anchor Scope Rule of
Section 3.3 mitigates this: one hash and one OTS
proof file per artifact, with every relied-upon
artifact independently anchored, and each anchor
attributed to its named file in the provenance
manifest's anchored_artifacts array.
DOI Record Manipulation: While DOI records are
generally immutable after publication, CTS does not
rely on DOI integrity alone. The Bitcoin blockchain
anchor provides an independent verification path
that does not depend on the DOI registrar's
integrity or continued operation.
Replay Attack: An adversary may attempt to apply an
old, superseded CTS schema to a newer deployment.
CTS mitigates this via semantic versioning and
deployment-date fields in the manifest.
Implementations SHOULD validate that the schema
version and deployment date match the current
deployment context.
Retrieval Injection Bypass: A runtime implementation
may fail to correctly inject the CTS schema, either
through misconfiguration or adversarial input. CTS
specifies the required injection mechanism but
cannot enforce runtime compliance without an
external auditing layer. Implementations SHOULD
log all inference requests with a hash of the
injected schema for post-hoc verification.
Implementations SHOULD alert on any inference
request where the injected schema hash does not
match the anchored record.
OTS Proof File Loss: If an OTS proof file is lost,
verification reverts to manual Bitcoin blockchain
inspection. CTS REQUIRES OTS proof files to be
co-published with the Zenodo record and retained
in multiple locations.
Schema Insufficient for Safety: CTS verifies that
declared constraints were anchored and enforced.
It does not verify that declared constraints are
sufficient for safety, ethically sound, or compliant
with applicable law. The sufficiency of declared
constraints is a separate evaluation that CTS does
not perform.
7.2. Cryptographic Assumptions
SHA-256: Used for file hashing per [FIPS-180-4].
Assumed collision-resistant under current
cryptographic consensus.
Bitcoin PoW Chain: Used for temporal anchoring per
[BITCOIN]. The security assumption is that
rewriting confirmed Bitcoin blocks requires
prohibitive computational cost. CTS RECOMMENDS
anchoring to transactions confirmed at a depth of
at least 6 blocks.
OpenTimestamps Merkle Aggregation: The OTS protocol
aggregates hashes into a Merkle tree before Bitcoin
anchoring [OTS]. The security of individual
timestamps depends on SHA-256 collision resistance.
Merkle aggregation does not weaken individual hashes
-- it batches them into a single Bitcoin transaction
for efficiency.
8. IANA Considerations
This document has no IANA actions.
9. References
9.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/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs
Lowercase in RFC 2119 Key Words", BCP 14,
RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[FIPS-180-4]
National Institute of Standards and
Technology, "Secure Hash Standard (SHS)",
FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[OTS] Todd, P., "OpenTimestamps: Scalable, Trust-
Minimized, Distributed Timestamping with
Bitcoin", <https://opentimestamps.org>.
[OTS-CLIENT]
OpenTimestamps, "opentimestamps-client",
<https://github.com/opentimestamps/
opentimestamps-client>.
[BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer
Electronic Cash System", October 2008,
<https://bitcoin.org/bitcoin.pdf>.
[REILLY-REM]
Reilly, L.J., "Reilly EternaMark (REM)
Protocol - Dual-Layer Digital Permanence
Using DOI Archiving and Blockchain
Timestamping", Internet-Draft
draft-reilly-rem-protocol-02, August 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-rem-protocol/>.
[ISO-DOI] International Organization for
Standardization, "Information and
documentation -- Digital object identifier
system", ISO 26324:2012, June 2012,
<https://www.iso.org/standard/43506.html>.
9.2. Informative References
[CTS-ZENODO]
Reilly, L., "Cognitive Trust Stack (CTS)
v1.0 -- A Framework for Verifiable AI
Behavioral Provenance", Zenodo,
DOI 10.5281/zenodo.19097169, March 2026,
<https://zenodo.org/records/19097169>.
Bitcoin block 941168 (2026-03-18).
Anchored file CTS_Whitepaper_v1.0.docx,
SHA-256:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2.
Files: CTS_Whitepaper_v1.0.docx,
cts_framework.json,
CTS_Whitepaper_v1.0.docx.ots.
[REILLY-UAEMF]
Reilly, L., "Universal AI Ethics and Moral
Framework (UAEMF) v1.0",
Internet-Draft draft-reilly-uaemf-00,
DOI 10.5281/zenodo.19010455,
Bitcoin block 940570, March 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-uaemf/>.
[USC-35-102]
United States Code, "35 U.S.C. 102 -
Conditions for patentability; novelty", as
amended by the Leahy-Smith America Invents
Act, Pub. L. 112-29 (2011),
<https://uscode.house.gov/view.xhtml?req=
granuleid:USC-prelim-title35-section102>.
[OECD-AI] Organisation for Economic Co-operation and
Development, "Recommendation of the Council
on Artificial Intelligence",
OECD/LEGAL/0449, May 2019,
<https://legalinstruments.oecd.org/en/
instruments/OECD-LEGAL-0449>.
[NIST-AIRMF]
National Institute of Standards and
Technology, "Artificial Intelligence Risk
Management Framework (AI RMF 1.0)",
NIST AI 100-1,
DOI 10.6028/NIST.AI.100-1, January 2023,
<https://doi.org/10.6028/NIST.AI.100-1>.
[EU-AIA] European Parliament and Council of the
European Union, "Artificial Intelligence
Act", Regulation (EU) 2024/1689, July 2024,
<https://eur-lex.europa.eu/legal-content/
EN/TXT/?uri=OJ:L_202401689>.
[UNESCO-AI]
United Nations Educational, Scientific and
Cultural Organization, "Recommendation on
the Ethics of Artificial Intelligence",
November 2021,
<https://unesdoc.unesco.org/ark:/48223/
pf0000381137>.
(This appendix to be removed before or upon RFC
publication.)
Changes from -00 to -01:
* Added Section 5.2 specifying the function of
conformant CTS publications as prior art records
under 35 U.S.C. 102(a)(1), including the mapping of
CTS layers to public accessibility, date certainty,
and content integrity; the defensive publication
operating mode; the scope of the canonical record's
prior art effect; and the limitations that
non-public anchors establish existence only and
that the section is informational, not legal
advice. Section 5 was retitled and restructured
into Sections 5.1 and 5.2 accordingly.
* Added Section 6.6 (Defensive Publication and Prior
Art Establishment) as a use case, and the "Prior
Art Record" term to Section 2 (Terminology).
* Corrected the anchor attribution ambiguity present
in -00: Sections 1.5 and 3.5 of -00 attributed the
canonical SHA-256 hash to cts_framework.json, while
the Abstract, Section 3.3, and Section 5 attributed
the same hash to CTS_Whitepaper_v1.0.docx, and
Section 3.5 instructed verification against a
cts_framework.json.ots proof file not present in
the Zenodo record. Two distinct files cannot share
a SHA-256 hash. This revision attributes the
canonical anchor to CTS_Whitepaper_v1.0.docx,
consistent with the published OTS proof file name,
and corrects the Layer 5 verification commands.
* Added the normative Anchor Scope Rule to
Section 3.3 (one hash and one OTS proof file per
artifact; every relied-upon artifact independently
anchored, including the alignment schema file
itself) and a corresponding Anchor Scope Ambiguity
threat to Section 7.1.
* Replaced the manifest's single blockchain
ots_proof_file field with an anchored_artifacts
array (Section 4), each entry naming its file,
hash, and OTS proof file, with backward
compatibility guidance for -00 manifests. Added
the requirement that manifest hash values be
single unbroken 64-character strings.
* Corrected the [REILLY-REM] reference: -00 cited
the draft as "draft-reilly-rem" with a
corresponding Datatracker URL; the correct
document name is draft-reilly-rem-protocol. The
reference now cites revision -02, which specifies
the prior art record function this document
applies.
* Added informative reference [USC-35-102] and a
closing paragraph to Section 1.7 noting the prior
art function inherited from [REILLY-REM].
* Added the Revised BSD License code components
sentence to the Copyright Notice, absent from -00.
* Updated Zenodo URLs from the legacy /record/ path
to the current /records/ path.
* Replaced "admissible as documentary evidence" with
"producible as documentary evidence" in
Section 6.1; admissibility is determined by the
forum, not by this specification.
* Updated expiry date from 18 September 2026 to
8 February 2027.
Authors' Addresses
Lawrence John Reilly Jr.
Email: lawrencejohnreilly@gmail.com
IETF Datatracker:
https://datatracker.ietf.org/doc/draft-reilly-cts/
Canonical Record (Zenodo):
DOI: 10.5281/zenodo.19097169
URL: https://zenodo.org/records/19097169
Cryptographic Anchor (Bitcoin):
Anchored File: CTS_Whitepaper_v1.0.docx
Block: 941168
Date: 2026-03-18
SHA-256:
e915b5162422281e1c0185c9e2eefaf7
4b7f539996b878cb1e69e10533f24ac2
OTS: CTS_Whitepaper_v1.0.docx.ots
Verify: ots verify CTS_Whitepaper_v1.0.docx.ots