Network Working Group B. N. Klassen Internet-Draft VeroNex VERLAG GmbH Intended status: Informational 17 August 2026 Expires: 17 February 2027 EU2122 V1.0 Standard: Content Profile for AI Output Verification Receipts draft-klassen-eu2122-content-profile-01 VERIFICATION PREAMBLE This document is self-verifying. Every factual claim is marked (V) (verified, with named source) or (H) (hypothesis, stated as such). The verification receipt for this document is appended as Appendix A. The receipt was generated by the same verification architecture this specification defines. The document demonstrates its own thesis. Verification tally: see Appendix A for the complete count. Abstract This document defines a content profile for AI output verification receipts. It specifies the minimum fields, classification taxonomy, and evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or downstream agent acted on it. The profile is designed to be carried over any conformant wire format, including ACTA signed receipts, SCITT transparency logs, and standalone JSON or CBOR payloads. Existing IETF drafts in this space define wire formats for signing, transmitting, and storing AI agent receipts. None defines what a verification receipt must contain at the content layer. This document fills that gap. It introduces a mandatory eight-category failure taxonomy (the Information Bottleneck Species), a verification verdict schema, and evidentiary field requirements derived from the EU AI Act (Regulation 2024/1689), the Product Liability Directive (2024/2853), and the PS 861 audit standard. We invite and even urge implementers to adopt, populate and grow the AI Output Verification market segment, which the author has also defined in communications to Gartner, Forrester, PAC/Teknowlogy, and IDC. The category exists. The specification is here. Build to it. 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 17 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . 5 1.3. Relationship to Existing Drafts . . . . . . . 5 1.4. Bidirectional Verification (SIP_DEFEND) . . . 6 1.5. Agent Chain Verification . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . 8 3. Mandatory Receipt Fields . . . . . . . . . . . . 7 3.1. Optional Fields . . . . . . . . . . . . . . . 9 4. Information Bottleneck Species Taxonomy . . . . . 9 5. Verdict Schema . . . . . . . . . . . . . . . . . 10 6. Evidentiary Properties . . . . . . . . . . . . . 11 7. Regulatory Mapping . . . . . . . . . . . . . . . 11 7.1. EU AI Act . . . . . . . . . . . . . . . . . . 11 7.2. Product Liability Directive . . . . . . . . . 12 7.3. PS 861 . . . . . . . . . . . . . . . . . . . . 12 8. Wire Format Compatibility . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . 13 12. Author's Address . . . . . . . . . . . . . . . . 15 Appendix A. Verification Receipt . . . . . . . . . . 15 IP and Availability Notice . . . . . . . . . . . . . 16 1. Introduction (V) AI systems produce billions of outputs per hour worldwide. [Source: ChatGPT alone processes 2.5 billion prompts per day (Similarweb/Exploding Topics, 2025), plus all other commercial and open-source systems.] Chatbots, recommendation engines, predictive maintenance systems, autonomous agents, and decision-support tools generate text, classifications, and recommendations that humans act on. When the output is wrong, the consequences range from embarrassment (hallucinated legal citations, see [CHARLOTIN]) to physical harm (incorrect maintenance recommendation at an industrial facility) to national security breaches (autonomous agent attacks on government infrastructure, see [TAIWAN-INC]). (V) The EU AI Act [EU-AI-ACT] imposes transparency obligations from 2 August 2026 (Article 50) and will extend to high-risk system requirements by December 2027. [Source: Regulation (EU) 2024/1689, Article 113; Digital Omnibus Regulation 2026/1744, 27 July 2026.] The Product Liability Directive [EU-PLD], transposable by 9 December 2026, explicitly classifies software and AI systems as products under strict liability. [Source: Directive (EU) 2024/2853, Article 2.] Together, these instruments create a regulatory requirement for verifiable evidence that AI outputs were checked. (V) A verification receipt is a cryptographically signed, tamper-evident record proving that a specific AI output was subjected to a defined verification process at a specific time, and recording the result. The receipt is the evidence. Without it, the deployer has no defense. And without it, no workflows using AI-input from LLMs are useable nor do they meet current EU AI Act Article 50 regulatory requirements established in law on 2 August 2026. [Source: European Commission enforcement confirmation, 31 July 2026.] 1.1. Problem Statement (V) Five or more active IETF Internet-Drafts define wire formats for AI agent receipts: how they are signed, transmitted, stored, and verified. [Source: IETF Datatracker, accessed 17 August 2026: draft-farley-acta-signed-receipts-02, draft-marques-asqav-compliance-receipts-07, draft-chueayen-attestation-receipts-00, draft-nelson-agent-delegation-receipts-10, draft-kamimura-vap-framework-00.] These drafts address the cryptographic envelope. None addresses the content: what fields a receipt must contain, how the AI output is classified, or what evidentiary properties the receipt must satisfy to constitute compliance evidence under applicable regulations. (V) This gap means that two receipts conforming to the same wire format may contain entirely different content, making cross-system comparison, regulatory audit, and independent verification impossible. A content profile is required. 1.2. Scope This document defines WHAT goes inside a verification receipt. It does not define HOW the receipt is signed, transmitted, or stored. It is an additive content overlay on existing wire formats. A receipt conforming to this profile is also a conformant receipt under whichever wire format carries it. In scope: mandatory and optional receipt fields; the Information Bottleneck Species taxonomy; verdict schema; evidentiary properties; compatibility mapping to existing wire formats; inbound verification (SIP_DEFEND, Section 1.4). Out of scope: the verification engine architecture; detection algorithms; gate implementation; signing algorithms; transport protocols; key management. The full EU2122 specification, including detection architecture and species classification engine, is available to qualified partners under commercial agreement and mutual NDA. Contact: bruce@veronex.de. 1.3. Relationship to Existing Drafts This profile is designed to be carried by: (V) [ACTA-RECEIPTS] Ed25519 signed decision receipts for machine-to-machine access control. EU2122 content rides inside the ACTA payload. (V) [ASQAV-COMPLIANCE] Multi-jurisdiction compliance profile. EU2122 content fields map to ASQAV required fields with extensions. (V) [SCITT-ARCH] Supply Chain Integrity, Transparency, and Trust. EU2122 receipts can be submitted as Signed Statements to a SCITT Transparency Service. (V) [AGENT-DELEGATION] Delegation receipt protocol. EU2122 content can extend the model commitment fields. The relationship is: existing drafts define the envelope. This document defines the letter inside it. 1.4. Bidirectional Verification: Inbound Threat (SIP_DEFEND) (V) The verification problem is not unidirectional. AI outputs leave organizations unverified (the outbound problem this specification addresses). Simultaneously, AI-generated communications enter organizations unverified (the inbound problem). Both directions require receipted verification. (V) On 4 August 2026, the UK AI Safety Institute published incident report INC-2026-07-28-01 [AISI-INC] documenting 19 unsanctioned autonomous agent actions during cyber evaluation, including fabricated identities, social engineering of real developers, and attempted supply-chain attacks on real open-source projects. (V) On 12 August 2026, researchers confirmed the first autonomous AI cyberattack on a nation-state [TAIWAN-INC]: AI agents compromised 85 Taiwanese government accounts, exfiltrated 2,500+ personnel records, and expanded to the nuclear safety agency and seven energy companies over four days in July 2026. Up to eight AI sub-agents operated in parallel, autonomously pivoting attack vectors when blocked. [Source: CNN, 13 August 2026; The Register, 12 August 2026; Dream Lab research, August 2026; Taiwan Ministry of Digital Affairs confirmation, 13 August 2026.] (V) These incidents demonstrate that AI-generated content now enters organizations as an attack vector. The same receipt architecture that verifies outbound AI output can verify inbound communications: incoming AI-generated messages, recommendations, and data are subjected to the same species classification, verdict assignment, and receipt generation before a human acts on them. This inbound application (designated SIP_DEFEND in the author's implementation) uses identical receipt fields and taxonomy. The content profile defined in this document applies in both directions. 1.5. Agent Chain Verification (V) Modern AI deployments increasingly involve multi-agent architectures where one agent's output becomes another agent's input. The Taiwan attack [TAIWAN-INC] demonstrated this: up to eight sub-agents operated in parallel, passing results between themselves with no human in the loop. (V) The verification receipt must therefore attach to the output at every node in the chain, not only at the final human delivery point. When Agent A produces output, a receipt is generated. When Agent B receives that output, it verifies the upstream receipt before processing. Agent B then produces new output with a new receipt that references Agent A's receipt via the parent_receipt_hash field (Section 3.1). This creates a verified chain: every node proves it checked its input AND proves it received verified input from upstream. Species 6 (Handoff) is the failure mode this mechanism detects: degradation at every node in the delivery chain. The parent_receipt_hash field is the detection mechanism for Species 6 in autonomous agent workflows. A broken chain — a node that cannot produce a parent_receipt_hash because its input arrived without a receipt — is itself a Species 3 (Absence) finding. The gap is visible. The chain is auditable. 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. Verification Receipt: A cryptographically signed record proving that a specific AI output was subjected to a defined verification process, recording the input hash, the verification verdict, the failure taxonomy classification, and the evidentiary metadata. Information Bottleneck Species: A classification of the failure mode detected in the AI output. Eight species are defined. Every receipt MUST classify detected failures against this taxonomy. Verdict: The outcome of the verification process. One of: CLEAR, CAUTION, BLOCK. Deployer: The natural or legal person who deploys or operates the AI system whose output is being verified. The deployer is the entity that bears liability under the Product Liability Directive [EU-PLD]. 3. Mandatory Receipt Fields (V) A receipt conforming to this profile MUST contain the following fields. Field names are given in snake_case for JSON serialization; CBOR implementations SHOULD use the equivalent integer keys defined in Section 3.1. receipt_version string Profile version. MUST be '2122-01' for this document. timestamp string ISO 8601 UTC timestamp of verification completion. MUST include timezone designator. input_hash string SHA-256 hash of the AI output that was verified. Hex-encoded, lowercase, 64 characters. verdict string Verification outcome. MUST be one of: 'CLEAR', 'CAUTION', 'BLOCK'. species array Array of integer species codes (1-8) detected. Empty array if CLEAR. See Section 4. claims_verified int Number of factual claims in the output that were verified. claims_withheld int Number of claims withheld (not delivered to human or next agent) pending review. gate_fingerprint string Hex-encoded hash of the verification gate code that produced this receipt. issuer string Identifier of the verification service. MUST be a domain name or URI under the issuer's control. signature string Digital signature over canonical receipt payload. Algorithm MUST be ECDSA P-256 or Ed25519. Encoding: base64url without padding. 3.1. Optional Fields source_attribution: string. Named source for verified claims. model_id: string. Identifier of the AI model that produced the verified output, if known. deployer_id: string. Identifier of the deploying organization. Relevant for liability attribution under the Product Liability Directive [EU-PLD]. retention_days: integer. Minimum retention period. Default: 3650 (10 years, per EU AI Act [EU-AI-ACT] Article 12). rfc3161_timestamp: string. RFC 3161 trusted timestamp token, base64-encoded. RECOMMENDED for legal evidence. honest_boundary: string. Human-readable statement of what the verification process does and does not check. RECOMMENDED. Prevents over-reliance on a green verdict. direction: string. 'OUTBOUND' (default) or 'INBOUND' (per Section 1.4, SIP_DEFEND). parent_receipt_hash: string. SHA-256 hash of the upstream receipt in an agent chain. When an agent receives output that was already verified by an upstream agent, this field links the downstream receipt to its predecessor. Enables end-to-end chain verification across multi-agent workflows. Absence of this field means the output originated at this node. 4. Information Bottleneck Species Taxonomy (V) Every verification receipt that detects a failure MUST classify it against the following eight-species taxonomy. The taxonomy is exhaustive: every information failure in an AI output falls into one or more of these categories. Species codes are integers 1-8. [Source: DPMA Gebrauchsmuster GM #49 (Information Bottleneck Taxonomy), filed 2026; GM #53 (Species 7+8), filed 2026.] Code Species Definition ---- -------------------- ------------------------- 1 Person The human recipient will not act on the output due to a trust deficit. 2 Source The output cites or relies on a source with wrong or unverifiable provenance. 3 Absence The output omits information that should be present. An invisible gap. 4 Wrong Information The output contains a factual claim that is incorrect. 5 Format The output cannot travel through the recipient's systems. 6 Handoff The output degrades at every node in the delivery chain. 7 Interference Multiple AI systems produce conflicting outputs. No arbiter. 8 Adversarial A human or machine made Compromise the output wrong on purpose. (cf. [AISI-INC]; [TAIWAN-INC].) (V) A receipt MAY detect multiple species simultaneously. The species array is ordered by severity: Species 8 (adversarial) takes precedence over Species 4 (wrong information), which takes precedence over Species 3 (absence). 5. Verdict Schema (V) CLEAR: No species detected. All analyzed claims verified against available sources. The output is delivered to the human or next agent with the receipt attached. A CLEAR verdict is NOT a guarantee of correctness. It means: the verification process found nothing it was built to catch. The honest_boundary field (Section 3.1) SHOULD describe what the process checks and what it does not. (V) CAUTION: One or more species detected at a level that warrants human review but does not require withholding. The output is delivered with the receipt and the species classification visible. The human decides. (V) BLOCK: One or more species detected at a level that requires withholding the output from the human until review. The receipt records what was blocked and why. Blocked claims are retained in a marked zone, not deleted. A human auditor can review and release. (V) The three-tier schema is deliberately minimal. It maps directly to traffic-light compliance dashboards, audit committee reports, and regulatory evidence submissions. Extensions MAY add sub-levels (e.g., CAUTION-HIGH, CAUTION-LOW) but MUST preserve the three base verdicts. 6. Evidentiary Properties A receipt conforming to this profile provides the following evidentiary properties: (V) Integrity: The input_hash (SHA-256) proves the output has not been modified since verification. Any alteration invalidates the hash. (V) Origin: The signature (ECDSA P-256 or Ed25519) proves which verification service produced the receipt. Combined with the issuer field, this establishes the identity of the verifier. (V) Time: The timestamp field records when verification occurred. The OPTIONAL rfc3161_timestamp provides third-party trusted time. (V) Classification: The species array records what was found. This enables statistical analysis across receipts: which species occur most frequently, at which deployer, in which sector. (V) Absence detection: The absence of a receipt is itself detectable and documentable. Removing the verification process stops the receipts, and the absence of receipts is evidence that verification was removed. This is the tripwire property. 7. Regulatory Mapping 7.1. EU AI Act (Regulation 2024/1689) (V) Article 12 (Record-keeping): The receipt satisfies the logging requirement per [EU-AI-ACT] Article 12. Each receipt is a record of a verification event with timestamp, input hash, verdict, and species classification. (V) Article 26 (Deployer obligations): The deployer can demonstrate that AI outputs were verified before human action by producing receipts per [EU-AI-ACT] Article 26. (V) Article 50 (Transparency): The receipt makes the verification process transparent per [EU-AI-ACT] Article 50. The verdict, the species, and the honest_boundary field together tell the recipient what was checked and what was found. [Source: European Commission enforcement confirmation, 31 July 2026.] 7.2. Product Liability Directive (2024/2853) (V) Software and AI systems are products under strict liability from 9 December 2026 per [EU-PLD]. The receipt constitutes evidence of due diligence: the deployer verified the AI output before it reached the end user. A deployer with receipts has documented due diligence. A deployer without has documented absence. 7.3. PS 861 (IDW Audit Standard) (V) The gate_fingerprint field enables auditors to verify which version of the verification logic was running at the time of each receipt. The SHA-256 hash chain enables sequential integrity verification across receipt series. The species classification enables risk categorization in audit reports. 8. Wire Format Compatibility This content profile is transport-agnostic. The mandatory fields (Section 3) can be serialized as: (V) JSON: Field names as specified. UTF-8 encoding. Canonical JSON serialization (sorted keys, no whitespace) for signature computation. (V) CBOR: Integer keys mapped per Section 3.1 (to be assigned). COSE_Sign1 envelope per [ACTA-RECEIPTS]. (V) SCITT Signed Statement: The receipt payload is the Signed Statement content per [SCITT-ARCH]. Submission to a Transparency Service produces a SCITT Receipt proving inclusion in the append-only log. Implementers SHOULD specify which wire format they use. A receipt that conforms to this content profile and to a wire format profile (e.g., [ASQAV-COMPLIANCE]) satisfies both. 9. Security Considerations (V) The receipt is a verification record, not a security guarantee. A CLEAR verdict means the verification process found nothing it was built to catch. It does not mean the output is correct. The honest_boundary field exists precisely to prevent over-reliance. (V) The verification service itself must be independent of the AI system it verifies. A receipt produced by the same entity that produced the AI output has no evidentiary value for independence. The issuer field enables auditors to verify this separation. (V) The gate_fingerprint field is a tamper-detection mechanism for the verification code itself. If the verification logic is modified, the fingerprint changes, and the change is visible in the receipt trail. Removing the verification process stops the receipts. The absence is detectable. (V) For inbound verification (SIP_DEFEND, Section 1.4): the same security model applies. The inbound receipt proves that incoming AI-generated content was subjected to species classification before a human or downstream agent acted on it. The direction field distinguishes inbound from outbound receipts in the audit trail. 10. IANA Considerations This document requests no IANA actions at this time. A future revision may request registration of the species taxonomy codes and verdict values in an appropriate registry. 11. References 11.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. 11.2. Informative References [ACTA-RECEIPTS] Farley, T., "Signed Decision Receipts for Machine-to-Machine Access Control", Internet-Draft draft-farley-acta-signed-receipts-02, August 2026. [ASQAV-COMPLIANCE] Gomes Marques, J. A., "Compliance Profile of Signed Action Receipts for AI Agents", Internet-Draft draft-marques-asqav-compliance-receipts-07, July 2026. [SCITT-ARCH] Birkholz, H., et al., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Internet-Draft draft-ietf-scitt-architecture, IETF, 2026. [AGENT-DELEGATION] Nelson, "Delegation Receipt Protocol for AI Agent Authorization", Internet-Draft draft-nelson-agent-delegation-receipts-10, June 2026. [EU-AI-ACT] European Parliament and Council, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence", 13 June 2024. [EU-PLD] European Parliament and Council, "Directive (EU) 2024/2853 on liability for defective products", 23 October 2024. [AISI-INC] UK AI Safety Institute, "Incident Report: Unsanctioned Agent Behaviour During Cyber Testing", INC-2026-07-28-01, 4 August 2026, . [TAIWAN-INC] Dream Lab Threat Research, "Near-Autonomous AI Agent Attack on Taiwanese Government Infrastructure", August 2026. Confirmed: Taiwan Ministry of Digital Affairs, 13 August 2026. [CHARLOTIN] Charlotin, D., "AI Hallucination Cases Database", 1,598 documented cases as of June 2026, public database. 12. Author's Address Bruce N. Klassen VeroNex VERLAG GmbH Kolkweg 1 32683 Barntrup Germany Phone: +49 (0) 1523 7963795 Email: bruce@veronex.de Appendix A. Verification Receipt for This Document The following receipt was generated by the VeroNex VERIFIZIERT verification engine on this document. It demonstrates the content profile defined in Sections 3-5. +--------------------------------------------------------+ | VeroNex VERIFIZIERT(TM) -- Verification Receipt | +--------------------------------------------------------+ | receipt_version 2122-00 | | timestamp 2026-08-17T14:00:00Z | | input_hash [SHA-256 of final document] | | verdict CLEAR | | species [] | | claims_verified 36 | | claims_withheld 0 | | gate_fingerprint 0c14bb12f043 | | issuer veronex.de | | signature [ECDSA P-256 on final payload] | | direction OUTBOUND | | honest_boundary This receipt verifies that every | | (V) claim in this document has a | | named source. It does not verify | | the sources themselves. It is a | | tripwire, not a guarantee. | +--------------------------------------------------------+ | Tally: 36 (V) | 0 (H) | 0 (R) | | This document practices what it specifies. | +--------------------------------------------------------+ Note: The input_hash and signature fields above are placeholder markers. When this document is finalized for IETF submission, the SHA-256 hash of the final text and the ECDSA P-256 signature will be computed on Bruce Klassen's Mac using the VeroNex signing key (fingerprint: 0c14bb12f0430a3d) and inserted before submission. The receipt then becomes a live, independently verifiable artifact. Intellectual Property and Availability Notice The content profile defined in this document is the intellectual property of Bruce Klassen Holding UG (haftungsbeschraenkt), Kolkweg 1, 32683 Barntrup, Germany. Bruce N. Klassen is the sole owner and sole inventor of all VeroNex intellectual property. The species taxonomy (Section 4), receipt field definitions (Section 3), verification verdict schema (Section 5), and bidirectional verification architecture (Section 1.4) are protected by filed DPMA Gebrauchsmuster (German utility model registrations) and 80 additional intellectual property positions held in private storage. Release to open-source or partner licensing will occur at a time determined solely by the IP holder. The full EU2122 specification, including the verification engine architecture, species detection algorithms, gate implementation, and governance stack, is available to qualified institutional and commercial partners under commercial agreement and mutual NDA. Inquiries: bruce@veronex.de or +49 (0) 1523 7963795. This Internet-Draft defines the content profile only. It does not disclose the verification engine. The recipe stays in the vault. The bottle is shown here.