Internet Engineering Task Force J. van de Meent Internet-Draft R. AI Intended status: Standards Track Humotica Expires: 28 July 2026 24 January 2026 TIBET: Evidence Trail Protocol draft-vandemeent-tibet-provenance-00 Abstract This document specifies TIBET (Transaction/Interaction-Based Evidence Trail), a protocol for establishing complete provenance chains in AI- to-AI and AI-to-human interactions. TIBET provides a standardized token structure capturing WHAT happened (ERIN), WHAT was attached (ERAAN), the CONTEXT around it (EROMHEEN), and WHY it happened (ERACHTER). This enables audit trails that meet emerging regulatory requirements for AI transparency. 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 28 July 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. van de Meent & AI Expires 28 July 2026 [Page 1] Internet-Draft TIBET January 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Token Structure . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. ERIN - Content Component . . . . . . . . . . . . . . . . 5 4.2. ERAAN - Attachment Component . . . . . . . . . . . . . . 5 4.3. EROMHEEN - Context Component . . . . . . . . . . . . . . 6 4.4. ERACHTER - Intent Component . . . . . . . . . . . . . . . 6 5. Token Lifecycle . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. State Transitions . . . . . . . . . . . . . . . . . . . . 6 5.3. Chain Linking . . . . . . . . . . . . . . . . . . . . . . 7 6. Trust Scoring (FIR/A) . . . . . . . . . . . . . . . . . . . . 7 7. Transport Considerations . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. Token Integrity . . . . . . . . . . . . . . . . . . . . . 8 8.2. Chain Integrity . . . . . . . . . . . . . . . . . . . . . 8 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.4. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. Media Type Registration . . . . . . . . . . . . . . . . . 8 9.2. HTTP Header Fields . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Token Examples . . . . . . . . . . . . . . . . . . . 9 A.1. Simple Query Token . . . . . . . . . . . . . . . . . . . 9 A.2. AI Decision Token . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 van de Meent & AI Expires 28 July 2026 [Page 2] Internet-Draft TIBET January 2026 1. Introduction Modern AI systems increasingly make decisions that affect people, organizations, and critical infrastructure. Regulators worldwide are introducing requirements for AI transparency, accountability, and auditability, including the [EU-AI-ACT], [CA-AB853], and [GDPR]. Current approaches to logging and audit trails are fragmented and often inadequate for compliance. TIBET addresses this gap by providing a standardized protocol for capturing complete provenance information for any AI interaction. Unlike traditional logging that captures only WHAT happened, TIBET captures four dimensions of provenance: * ERIN (What's IN it): The actual content or action * ERAAN (What's attached): Dependencies and references * EROMHEEN (What's around it): Environmental context * ERACHTER (What's behind it): Intent and reasoning This four-dimensional approach enables organizations to answer not just "what happened?" but also "why did it happen?" and "what was the context?" - questions regulators ask. The protocol is designed to be: * Transport-agnostic: Works over HTTP, WebSocket, queues * Format-flexible: [RFC8259] or CBOR * Chain-capable: Tokens link to form audit trails * Trust-integrated: Built-in trust scoring via FIR/A 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Actor An entity that creates or participates in a TIBET token. May be an AI system, human user, or automated process. Chain A sequence of linked TIBET tokens representing a complete interaction or transaction history. van de Meent & AI Expires 28 July 2026 [Page 3] Internet-Draft TIBET January 2026 FIR/A (First Initiation Revoke/Accept) The trust scoring system used to evaluate actor reliability. Scores range from 0.0 to 1.0. Provenance The complete origin and history of data or a decision, including all transformations and reasoning. Token A single TIBET record capturing one interaction with full provenance information. 3. Protocol Overview TIBET operates as follows: 1. An actor initiates an action (query, decision, etc.) 2. A TIBET token is created capturing all four dimensions 3. The token is cryptographically signed by the actor 4. The token is stored in an immutable ledger 5. Child tokens link to parents via parent_id 6. State transitions are recorded as token updates 7. The complete chain provides full audit trail +--------+ +---------+ +--------+ +---------+ | Actor |--->| Create |--->| Sign |--->| Store | +--------+ | Token | | Token | | Ledger | +---------+ +--------+ +---------+ | | v v +---------+ +---------+ | Child | | Verify | | Tokens | | Chain | +---------+ +---------+ Figure 1: Token Flow Diagram 4. Token Structure A TIBET token is encoded as [RFC8259] and MUST contain the following fields: van de Meent & AI Expires 28 July 2026 [Page 4] Internet-Draft TIBET January 2026 { "token_id": "uuid", "type": "action|decision|message|query|response", "timestamp": "ISO-8601", "actor": "actor-identifier", "erin": { }, "eraan": [ ], "eromheen": { }, "erachter": "string", "parent_id": "optional-parent-token-id", "state": "CREATED|DETECTED|CLASSIFIED|MITIGATED|RESOLVED", "signature": "cryptographic-signature", "hash": "sha256-hash" } Figure 2: Token Schema 4.1. ERIN - Content Component ERIN ("What's IN it" - Dutch origin) captures the actual content or action being performed. { "erin": { "query": "What is the weather in Tokyo?", "format": "natural_language", "language": "en" } } The ERIN component MUST be present and MUST NOT be empty. 4.2. ERAAN - Attachment Component ERAAN ("What's attached" - Dutch origin) captures dependencies, references, and related resources. { "eraan": [ "token:abc123", "document:policy-v2.3", "model:gpt-4-turbo" ] } Format: "type:identifier". Common types: token, document, model, dataset, api, human. van de Meent & AI Expires 28 July 2026 [Page 5] Internet-Draft TIBET January 2026 The ERAAN component MAY be empty but MUST be an array. 4.3. EROMHEEN - Context Component EROMHEEN ("What's around it" - Dutch origin) captures environmental and situational context. { "eromheen": { "environment": "production", "region": "eu-west-1", "regulatory_context": ["GDPR", "AI-Act"] } } SHOULD include: environment, timestamp context, and relevant regulatory frameworks. 4.4. ERACHTER - Intent Component ERACHTER ("What's behind it" - Dutch origin) captures intent, reasoning, and purpose. This is REQUIRED for regulatory compliance. { "erachter": "User requested weather for travel planning." } MUST be a human-readable string explaining WHY this action was taken. 5. Token Lifecycle 5.1. Creation Tokens MUST be created at the initiation of any user query, AI decision, data access, external API call, or state change in a workflow. Upon creation, the token MUST be assigned a unique token_id ([RFC9562] UUID v4 RECOMMENDED), current timestamp in ISO-8601 format, initial state of "CREATED", and cryptographic signature from the actor. 5.2. State Transitions TIBET tokens support the following states: CREATED -> DETECTED -> CLASSIFIED -> MITIGATED -> RESOLVED van de Meent & AI Expires 28 July 2026 [Page 6] Internet-Draft TIBET January 2026 CREATED Token initialized, action pending DETECTED Action observed by monitoring systems CLASSIFIED Action categorized (normal, anomaly, threat) MITIGATED If anomaly, corrective action taken RESOLVED Final state, action complete Transitions MUST record: new state, timestamp, actor, and reason for transition. 5.3. Chain Linking Tokens form chains through parent_id. A child token MUST reference its parent to maintain audit trail continuity. Query -> Processing -> API Call -> Result | | | | token_1 token_2 token_3 token_4 parent:1 parent:2 parent:3 Figure 3: Example Chain Complete chains enable reconstruction of any interaction from initial request to final response. 6. Trust Scoring (FIR/A) TIBET integrates with FIR/A for trust scoring. Each actor has a trust score from 0.0 to 1.0. Trust Levels: * 0.8-1.0: HIGH TRUST - Full access * 0.5-0.8: MODERATE - Standard verification * 0.2-0.5: LOW - Enhanced verification, sandbox * 0.0-0.2: NO TRUST - Access denied Trust scores are behavior-based, not claim-based. Scores adjust based on behavior patterns, ERACHTER accuracy, chain integrity, and verification responses. van de Meent & AI Expires 28 July 2026 [Page 7] Internet-Draft TIBET January 2026 7. Transport Considerations TIBET is transport-agnostic. Implementations MAY use HTTPS REST APIs, WebSocket, message queues (AMQP, Kafka), or gRPC. For interoperability, [RFC8259] encoding over HTTPS is RECOMMENDED as baseline transport. Content-Type: application/tibet+json 8. Security Considerations 8.1. Token Integrity All tokens MUST be cryptographically signed. Signatures SHOULD use Ed25519 or ECDSA P-256. The signature covers all fields except the signature field itself. 8.2. Chain Integrity Each token MUST include a hash of its contents. Child tokens SHOULD include parent's hash in ERAAN to enable chain verification. 8.3. Privacy ERIN and EROMHEEN MAY contain sensitive data. Implementations MUST support encryption at rest and SHOULD support field-level encryption for sensitive components. 8.4. Non-Repudiation Actor signature combined with immutable ledger storage provides non- repudiation. Actors cannot deny creating tokens they have signed. 9. IANA Considerations This document requests registration of: 9.1. Media Type Registration Media Type: application/tibet+json 9.2. HTTP Header Fields * X-TIBET-Token-ID * X-TIBET-Chain-ID van de Meent & AI Expires 28 July 2026 [Page 8] Internet-Draft TIBET January 2026 * X-TIBET-Trust-Score 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . 10.2. Informative References [EU-AI-ACT] European Commission, "Regulation on harmonised rules on AI", 2024. [CA-AB853] California Legislature, "AB 853 - California AI Transparency Act", 2025. [GDPR] European Parliament, "General Data Protection Regulation", Regulation (EU) 2016/679, 2016. Appendix A. Token Examples A.1. Simple Query Token van de Meent & AI Expires 28 July 2026 [Page 9] Internet-Draft TIBET January 2026 { "token_id": "550e8400-e29b-41d4-a716-446655440000", "type": "query", "timestamp": "2026-01-24T10:30:00Z", "actor": "user_12345", "erin": { "query": "What are my account permissions?", "format": "natural_language" }, "eraan": ["session:sess_abc123"], "eromheen": { "environment": "production", "client": "mobile-app-v3.2", "regulatory_context": ["GDPR"] }, "erachter": "User requesting account info.", "state": "CREATED", "signature": "base64-sig", "hash": "sha256-hash" } A.2. AI Decision Token { "token_id": "550e8400-e29b-41d4-a716-446655440001", "type": "decision", "timestamp": "2026-01-24T10:30:05Z", "actor": "credit_model_v2", "erin": { "decision": "APPROVED", "amount": 50000, "confidence": 0.92 }, "eraan": [ "token:550e8400-e29b-41d4-a716-446655440000", "model:credit-scoring-v2.3.1" ], "eromheen": { "environment": "production", "region": "eu-west-1", "regulatory_context": ["GDPR", "EU-AI-Act"] }, "erachter": "Credit approved per policy 4.2.", "parent_id": "550e8400-e29b-41d4-a716-446655440000", "state": "CLASSIFIED", "signature": "base64-sig", "hash": "sha256-hash" } van de Meent & AI Expires 28 July 2026 [Page 10] Internet-Draft TIBET January 2026 Acknowledgements The TIBET protocol was developed as part of HumoticaOS, an AI governance framework built on human-AI symbiosis. The Dutch component names (ERIN, ERAAN, EROMHEEN, ERACHTER) reflect practical, no-nonsense engineering roots. Authors' Addresses Jasper van de Meent Humotica Den Dolder Netherlands Email: jasper@humotica.com URI: https://humotica.com Root AI Humotica Email: root_ai@humotica.nl URI: https://humotica.com van de Meent & AI Expires 28 July 2026 [Page 11]