TIBET: Evidence Trail Protocol

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

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

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

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   |
              +---------+                 +---------+

4. Token Structure

A TIBET token is encoded as [RFC8259] and MUST contain the following fields:¶

{
  "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"
}

{
  "erin": {
    "query": "What is the weather in Tokyo?",
    "format": "natural_language",
    "language": "en"
  }
}

{
  "eraan": [
    "token:abc123",
    "document:policy-v2.3",
    "model:gpt-4-turbo"
  ]
}

{
  "eromheen": {
    "environment": "production",
    "region": "eu-west-1",
    "regulatory_context": ["GDPR", "AI-Act"]
  }
}

{
  "erachter": "User requested weather for travel planning."
}

5. Token Lifecycle

CREATED -> DETECTED -> CLASSIFIED -> MITIGATED -> RESOLVED

Query -> Processing -> API Call -> Result
  |          |            |          |
token_1   token_2     token_3    token_4
         parent:1    parent:2   parent:3

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

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

9. IANA Considerations

This document requests registration of:¶

Appendix A. Token Examples

{
  "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"
}

{
  "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"
}

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