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 .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 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 ", "ots_verify_command": "ots verify .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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [OTS] Todd, P., "OpenTimestamps: Scalable, Trust- Minimized, Distributed Timestamping with Bitcoin", . [OTS-CLIENT] OpenTimestamps, "opentimestamps-client", . [BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", October 2008, . [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, . [ISO-DOI] International Organization for Standardization, "Information and documentation -- Digital object identifier system", ISO 26324:2012, June 2012, . 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, . 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, . [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), . [OECD-AI] Organisation for Economic Co-operation and Development, "Recommendation of the Council on Artificial Intelligence", OECD/LEGAL/0449, May 2019, . [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, . [EU-AIA] European Parliament and Council of the European Union, "Artificial Intelligence Act", Regulation (EU) 2024/1689, July 2024, . [UNESCO-AI] United Nations Educational, Scientific and Cultural Organization, "Recommendation on the Ethics of Artificial Intelligence", November 2021, . Appendix A. Change Log (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