Independent Submission L.J. Reilly Jr. Internet-Draft Independent Intended status: Informational 18 March 2026 Expires: 18 September 2026 Cognitive Trust Stack (CTS): A Framework for Verifiable AI Behavioral Provenance draft-reilly-cts-00 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: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 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. 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 18 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 30 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 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/record/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. cts_framework.json: The canonical CTS v1.0 alignment schema. SHA-256: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 CTS_Whitepaper_v1.0.docx.ots: The OpenTimestamps proof file anchoring the above SHA-256 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. 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. 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/record/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. 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. 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 cts_framework.json.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. 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 the finalized schema: sha256sum cts_framework.json 2. Upload the file to https://opentimestamps.org or use the OTS client [OTS-CLIENT]: ots stamp cts_framework.json 3. Download the resulting .ots proof file immediately. This file MUST be retained permanently and co- published with the Zenodo record. 4. Await Bitcoin transaction confirmation, typically within 24 hours. 5. Verify the 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: SHA-256: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 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 blockchain 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 schema file, the OTS proof file, and access to a Bitcoin block explorer. A complete CTS verification MUST include three checks: Schema Integrity Check: Compute the SHA-256 hash of the retrieved cts_framework.json and confirm it matches the hash in the provenance manifest: sha256sum cts_framework.json Expected for canonical CTS v1.0: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 OTS Verification: Verify the OTS proof file against the schema file: ots verify cts_framework.json.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. 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": "e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2", "ietf_draft": "draft-reilly-cts-00" }, "doi": { "identifier": "10.5281/zenodo.19097169", "url": "https://zenodo.org/record/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", "ots_proof_file": "CTS_Whitepaper_v1.0.docx.ots", "explorer_url": "https://blockstream.info/block/941168", "ots_service": "https://opentimestamps.org" }, "verification": { "schema_hash_command": "sha256sum cts_framework.json", "ots_verify_command": "ots verify cts_framework.json.ots", "expected_block": "941168", "expected_block_date": "2026-03-18" } } 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 The existence and priority of this framework are cryptographically established by the following records, each independently verifiable: Canonical Document SHA-256: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 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/record/19097169 IETF Draft: draft-reilly-cts-00 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. 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 admissible 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. 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 blockchain-anchored SHA-256 hash: any modified file produces a different hash that will not match the OTS proof, making post-hoc alteration cryptographically detectable. 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 the OTS proof file is lost, verification reverts to manual Bitcoin blockchain inspection. CTS REQUIRES the OTS proof file 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., "Reilly EternaMark Protocol (REM Protocol): Dual-Layer Digital Permanence via DOI and Blockchain Timestamping", Internet-Draft draft-reilly-rem, . [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). SHA-256: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2. 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, . [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, . 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/record/19097169 Cryptographic Anchor (Bitcoin): Block: 941168 Date: 2026-03-18 SHA-256: e915b5162422281e1c0185c9e2ee faf74b7f539996b878cb1e69e10533f24ac2 OTS: CTS_Whitepaper_v1.0.docx.ots Verify: ots verify CTS_Whitepaper_v1.0.docx.ots