]> VeroNex VERLAG GmbH

Kolkweg 1Barntrup32683Germany +49 1523 7963795bruce@veronex.de

AI output verificationreceiptEU AI Act This document defines a content profile for AI output verification receipts. It specifies the minimum fields, the classification taxonomy and the evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or a 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 Internet-Drafts in this space define wire formats for signing, transmitting and storing AI agent receipts, or records of what an agent did. None defines what a verification receipt must contain at the content layer: which claims in an output were checked and how each was classified. This document fills that gap. It introduces a mandatory fourteen-category failure taxonomy (the Information Bottleneck Species), a verdict schema, and evidentiary field requirements informed by the EU AI Act (Regulation (EU) 2024/1689), the Product Liability Directive (Directive (EU) 2024/2853) and the IDW PS 861 audit standard. We invite implementers to adopt, populate and grow the AI output verification market segment. The category exists. The specification is here. Build to it. This document marks every factual claim as (V), verified with a named source, or (H), a hypothesis stated as such. The tally in is counted from the text. carries a real receipt, signed by a production implementation of this profile, that any reader can verify with the published public key.

Introduction (V) ChatGPT alone receives more than 2.5 billion prompts per day, according to OpenAI's statement to Axios in July 2025 . (H) Across all commercial and open-source systems, AI outputs number in the billions per day. 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 ) to physical harm (an incorrect maintenance recommendation at an industrial facility) to attacks on government infrastructure (see ). (V) The transparency obligations of Article 50 of the EU AI Act apply from 2 August 2026. (V) Regulation (EU) 2026/1744 , which entered into force on 27 July 2026, gives providers of systems already placed on the market a transitional period of four months for the marking obligation of Article 50(2), and moves the application of the high-risk requirements for Annex III systems to 2 December 2027. (V) The Product Liability Directive includes software in its definition of a product (Article 4(1)), applies to products placed on the market after 9 December 2026 (Article 2(1)), and must be transposed by that date (Article 22(1)). (H) Together, these instruments create a practical need for verifiable evidence that AI outputs were checked. (V) Article 50(2) requires providers of AI systems that generate synthetic text to ensure that the outputs are marked in a machine-readable format and detectable as artificially generated . (V) On 5 October 2026 OpenAI published textGrain, a statistical watermark for ChatGPT text in the EU, and stated that the watermark cannot verify facts . (H) Marking records where a text came from. It does not record whether what the text says was checked. That second record is the subject of this document. (V) In this document, a verification receipt is a cryptographically signed, tamper-evident record stating that a specific AI output was subjected to a defined verification process at a specific time, and recording the result. (H) Without such a record, a deployer has no document showing that an output was checked before it was used.

Problem Statement (V) At least seven individual Internet-Drafts define wire formats or records for AI agent receipts: how they are signed, transmitted, stored and verified, or what an agent did . [Source: IETF Datatracker, versions as listed in the references, accessed 8 October 2026.] (V) In the author's review of these drafts, none defines which claims in an AI output were checked or how each claim was classified; states that it does not establish the truth of content. (H) This gap means that two receipts conforming to the same wire format may contain entirely different content, which makes cross-system comparison, regulatory audit and independent verification difficult. A content profile is required.

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; the verdict schema; evidentiary properties; compatibility mapping to existing wire formats; inbound verification (SIP_DEFEND, ). Out of scope: the verification engine architecture; detection algorithms; gate implementation; signing algorithms; transport protocols; key management. The full EU2122 specification, including the detection architecture and the species classification engine, is available to qualified partners under commercial agreement and mutual NDA. Contact: bruce@veronex.de.

Relationship to Existing Drafts This profile is designed to be carried by:

• (V) : Ed25519 signed decision receipts for machine-to-machine access control. EU2122 content rides inside the ACTA payload.
• (V) : a multi-jurisdiction compliance profile for signed agent action receipts. It records what an agent did and states that it does not establish the truth of content. EU2122 fields ride as extension fields inside the ASQAV payload. Revision 09 requires ML-DSA-65 for new issuance; of this document permits ML-DSA-65 so that both profiles can share one signature.
• (V) : the SCITT architecture, published as RFC 9943 in June 2026. EU2122 receipts can be submitted as Signed Statements to a SCITT Transparency Service.
• (V) : a delegation receipt protocol. EU2122 content can extend its model commitment fields.
• (V) and : execution receipts for agent tool calls and signed audit records of agent authorisation decisions. They record actions and decisions; EU2122 records whether the content of an output was checked.

The relationship is: existing drafts define the envelope or the record of action. This document defines the letter inside it.

Bidirectional Verification: Inbound Threat (SIP_DEFEND) (H) The verification problem is not unidirectional. AI outputs leave organisations unverified (the outbound problem this specification addresses). At the same time, AI-generated communications enter organisations unverified (the inbound problem). Both directions require receipted verification. (V) On 4 August 2026 the UK AI Security Institute published an incident report on unsanctioned agent behaviour during cyber testing : across 122 runs of seven models on two cyber ranges, unsanctioned behaviour appeared in 10 runs and amounted to 19 distinct actions, including an attempted supply-chain attack on an open-source project and contact with real people. (V) The Institute reported that its investigation had not identified any resulting real-world harm. (V) On 12 August 2026 The Register, following the Financial Times, reported research by the security company Dream on a near-autonomous AI agent attack on Taiwanese government infrastructure : over four days in July 2026, AI agents compromised 85 government accounts, took more than 2,500 personnel records and reached the nuclear safety agency and at least seven energy companies, with up to eight sub-agents operating in parallel. (V) Taiwan's Ministry of Digital Affairs confirmed overseas attacks in July that combined conventional hacking with AI agents; it did not confirm the figures. (H) These incidents indicate that AI-generated content now enters organisations 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.

Agent Chain Verification (V) AI deployments increasingly involve multi-agent architectures in which one agent's output becomes another agent's input; the attack described in used up to eight sub-agents in parallel. The verification receipt therefore attaches 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 (). This creates a verified chain: every node shows that it checked its input and that it received verified input from upstream. Species 6 (Handoff) is the failure mode this mechanism detects: degradation at every node in the delivery chain. A broken chain, meaning 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.

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 when, and only when, they appear in all capitals, as shown here.

Verification Receipt:

A cryptographically signed record stating that a specific AI output was subjected to a defined verification process, recording the input hash, the verdict, the failure taxonomy classification and the evidentiary metadata.

Information Bottleneck Species:

A classification of the failure mode detected in the AI output. Fourteen species are defined. Codes 1 to 8 are specified in this document; codes 9 to 14 are reserved (). 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.

Mandatory Receipt Fields A receipt conforming to this profile MUST contain the following fields. Field names are given in snake_case for JSON serialisation; CBOR implementations SHOULD use integer keys to be assigned in a future revision.

receipt_version (string):

Profile version. MUST be "2122-03" for this document.

timestamp (string):

ISO 8601 UTC timestamp of verification completion. MUST include a time zone 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 to 14) detected. Empty array if none were detected. See .

claims_verified (integer):

Number of factual claims in the output that were verified.

claims_withheld (integer):

Number of claims withheld (not delivered to the human or the 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 the canonical receipt payload or over its SHA-256 hash. The algorithm MUST be one of ML-DSA-65 , Ed25519 or ECDSA P-256. New implementations SHOULD support ML-DSA-65. Encoding: base64url without padding; implementations MAY accept standard base64.

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 organisation.

retention_days (integer):

Minimum retention period. Default: 3650. (V) This matches the ten-year documentation period of Article 18(1) of ; (V) logs under Article 19(1) and Article 26(6) must be kept for at least six months.

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 CLEAR verdict.

direction (string):

"OUTBOUND" (default) or "INBOUND" (per ).

parent_receipt_hash (string):

SHA-256 hash of the upstream receipt in an agent chain. Links the downstream receipt to its predecessor. Absence of this field means the output originated at this node.

Information Bottleneck Species Taxonomy Every verification receipt that detects a failure MUST classify it against the following fourteen-species taxonomy. (H) The author's position is that the taxonomy is exhaustive: every information failure in an AI output falls into one or more of these categories. Species codes are integers 1 to 14. (V) [Source: DPMA utility model applications GM #49 (Information Bottleneck Taxonomy) and GM #53 (Species 7 and 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 Compromise	A human or machine made the output wrong on purpose.
9-14	Reserved	Defined in the full EU2122 specification, available under NDA (). A receipt MAY carry these codes. A verifier that does not hold the definitions MUST treat them as detected failures of unspecified species and MUST NOT ignore them.

A receipt MAY record multiple species. The species array is ordered by severity: Species 8 (Adversarial Compromise) takes precedence over Species 4 (Wrong Information), which takes precedence over Species 3 (Absence).

Verdict Schema

CLEAR:

No species detected. All analysed 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 SHOULD describe what the process checks and what it does not.

CAUTION:

One or more findings at a level that warrants human review but does not require withholding. The output is delivered with the receipt and the classification visible. The human decides.

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.

The three-tier schema is deliberately minimal. It maps to traffic-light compliance dashboards, audit committee reports and regulatory evidence submissions. Extensions MAY add sub-levels (for example CAUTION-HIGH, CAUTION-LOW) but MUST preserve the three base verdicts.

Evidentiary Properties

Integrity:

The input_hash (SHA-256) shows whether the output has been modified since verification. Any alteration changes the hash.

Origin:

The signature (ML-DSA-65, Ed25519 or ECDSA P-256) shows which verification service produced the receipt. Combined with the issuer field, this establishes the identity of the verifier.

Time:

The timestamp field records when verification occurred. The optional rfc3161_timestamp provides third-party trusted time.

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.

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.

Regulatory Mapping This section describes how a receipt can support obligations. It does not state that a receipt alone satisfies any of them.

EU AI Act (Regulation (EU) 2024/1689)

Article 12 (Record-keeping):

(V) Article 12(1) requires that high-risk AI systems technically allow for the automatic recording of events (logs) over their lifetime. (H) A receipt is a record of a verification event, with timestamp, input hash, verdict and classification, and can form part of those logs.

Article 26 (Deployer obligations):

(V) Article 26(6) requires deployers of high-risk AI systems to keep the logs under their control for at least six months. (H) Receipts give a deployer a record showing which outputs were checked before human action.

Article 50 (Transparency):

(V) Article 50(2) requires the marking of synthetic content in a machine-readable format. (V) The Commission and the AI Board have confirmed the Code of Practice on Transparency of AI-generated Content as an adequate voluntary tool . (H) A receipt complements marking: marking records the origin of a text, the receipt records what in it was checked and what was found.

Product Liability Directive (Directive (EU) 2024/2853) (V) Software is a product under Article 4(1) of , and the Directive applies to products placed on the market or put into service after 9 December 2026 (Article 2(1)). (H) A receipt is evidence that the deployer checked the AI output before it reached the end user. A deployer with receipts has documented due diligence. A deployer without has documented absence.

IDW PS 861 (V) IDW PS 861 (03.2023) is the German audit standard "Pruefung von KI-Systemen" of the Institut der Wirtschaftspruefer . (H) The gate_fingerprint field lets an auditor see which version of the verification logic was running at the time of each receipt; the hash chain supports sequential integrity checks across a receipt series; the species classification supports risk categorisation in audit reports.

Wire Format Compatibility This content profile is transport-agnostic. The mandatory fields () can be serialised as:

JSON:

Field names as specified. UTF-8 encoding. Canonical JSON serialisation (sorted keys, no insignificant whitespace) for signature computation.

CBOR:

Integer keys to be assigned. COSE_Sign1 envelope per .

SCITT Signed Statement:

The receipt payload is the Signed Statement content per . Submission to a Transparency Service produces a SCITT Receipt proving inclusion in the append-only log.

Implementers SHOULD state which wire format they use. A receipt that conforms to this content profile and to a wire format profile (for example ) satisfies both.

Implementation Status This section follows the practice of RFC 7942 and is to be removed before publication as an RFC. (V) VeroNex SIP_EDGE (engine service 1.1.0, engine core 2.5.0) is a production implementation operated by VeroNex VERLAG GmbH on its own server in Germany, live since 27 September 2026. It is reachable as a web application and as a browser extension, verifies an AI output through three gates, and returns a receipt signed with Ed25519. The public key is published at https://engine.veronex.de/v1/pubkey and receipts can be checked in the browser at https://veronex.de/beleg. shows a receipt it issued. (V) Known differences between the receipt of engine service 1.1.0 and the mandatory fields of : the verdict is carried as "level"; the profile version is carried as "standard" ("EU2122 v2.1"); the timestamp as "timestamp_utc"; the signature is standard base64 over the SHA-256 hash of the canonical JSON. The fields claims_verified, claims_withheld, gate_fingerprint and issuer are not yet emitted. (H) The author intends to close these differences in the next engine release.

Security Considerations 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 to prevent over-reliance. The verification service 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 check this separation. 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. For inbound verification () the same security model applies. The inbound receipt shows 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. A receipt signed over a hash of the canonical payload is only as strong as the canonicalisation. Implementations MUST use a deterministic canonical form (sorted keys, no insignificant whitespace) and MUST exclude only the signature-related fields from the hashed payload.

IANA Considerations This document has no IANA actions. A future revision may request registration of the species codes and verdict values in an appropriate registry.

References Normative References Informative References European Parliament and Council of the European Union European Parliament and Council of the European Union European Parliament and Council of the European Union European Commission National Institute of Standards and Technology UK AI Security Institute The Register ActuIA TechCrunch Institut der Wirtschaftspruefer in Deutschland e.V.

Live Receipt from a Production Implementation The receipt below was issued on 8 October 2026 by the production engine described in , for the following sample AI output (UTF-8, no trailing newline): In the original, the sample is a single line; it is wrapped above for display. Its SHA-256 is the input_hash below. The receipt was requested with storage switched off, so it exists only in this document. The verdict is CAUTION because the first gate found no cited source in the sample; the semantic gate found the statements accurate. A CLEAR verdict is not the goal of the demonstration; an honest one is. To verify: (1) remove receipt_hash, signature, signature_alg and key_id; (2) serialise the rest as canonical JSON with keys sorted at every level and no whitespace; (3) the SHA-256 of that string, hex-encoded, equals receipt_hash; (4) the Ed25519 signature, base64-decoded, verifies over the UTF-8 bytes of receipt_hash with the public key below; (5) the SHA-256 of the sample text equals input_hash. All five checks were run on 8 October 2026 and passed.

Verification Tally for This Document Counted from the text of this document: 30 claims marked (V), 14 claims marked (H), 0 marked (R). The (V) claims carry a named source in the text or in the references. A (V) marker states that a named source supports the claim; it does not verify the source itself. This tally is a tripwire, not a guarantee.

Changes from -02

• Converted to RFC XML v3; resolves the idnits finding on the missing expiry line.
• The placeholder receipt of -02 is replaced: now carries a real receipt signed by the production engine, with the public key and verification steps. The note promising a later ECDSA signature on a local key is removed.
• New (Implementation Status), stating the known differences between the production receipt and .
• Claims re-verified against primary sources on 8 October 2026. Corrected: the AISI incident report (title, URL, 19 actions in 10 of 122 runs); the Taiwan incident (research firm Dream, figures as reported, ministry confirmation limited to the fact of the attacks); Charlotin database count (2,149); Product Liability Directive articles (4(1), 2(1), 22(1)); retention periods (Articles 18(1), 19(1), 26(6)); the Digital Omnibus dates.
• Regulatory mapping restated as support, not satisfaction, of obligations. The statement that Article 50 requires verification receipts is removed. Article 50(2) marking, textGrain and the Code of Practice are added.
• Statements that are interpretation or forecast are now marked (H), including the exhaustiveness of the taxonomy and the scale of AI output beyond the cited ChatGPT figure.
• References updated: SCITT is RFC 9943; ACTA revision 03; Chueayen revision 03; Kamimura revision 01; AER-1 and the WIMSE agent audit record added.
• CAUTION is defined by findings rather than by detected species, so that a gate finding without a species (for example an output that cites no source) can produce CAUTION, as the production engine does.
• receipt_version is "2122-03". The signature field allows signing over the SHA-256 of the canonical payload and accepting standard base64.

Intellectual Property and Availability Notice The content profile defined in this document is the intellectual property of Bruce Norman 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 (), receipt field definitions (), verdict schema () and bidirectional verification architecture () are the subject of German utility model applications filed with the DPMA (Gebrauchsmuster). In total the IP holder holds 146 intellectual property positions: 71 filed utility models, 70 trade secrets, 2 EU trade marks and 3 other positions. 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 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.