Skip to main content

Overview

AgentVault’s telemetry data model is OTel-compatible from day one. Every audit event conforms to the OpenTelemetry Log Data Model so it can export to any OTel-compatible backend (Splunk, Datadog, Grafana) without schema changes.

Design Principles

  1. OTel-compatible — Every event maps directly to an OTel LogRecord.
  2. Postgres-first — No external observability stack required. JSONB columns provide flexibility and queryability.
  3. Trace context as conversation context — Conversation IDs map to OTel Trace IDs. Message exchanges map to Span IDs.
  4. Tamper-evident — SHA-256 hash chain provides cryptographic integrity without blockchain overhead.
  5. Schema-versioned — Every envelope carries a version so types can evolve without breaking integrations.

Entity Identity Model

Hierarchy

Identity Schema

OTel Resource Attributes

These map to OTel semantic conventions for Resource:

Message Envelope

Every message flowing through AgentVault is wrapped in a transport-agnostic envelope (works over WebSocket, REST, gRPC, or queues).

Envelope Schema

Required fields: envelope_version, message_id, trace_id, span_id, parent_span_id, timestamp, sender, recipient, message_type, payload.

Trace Context Mapping

Trace ID generation is deterministic from conversation IDs using a namespace UUID + SHA-256 truncated to 128 bits. The same conversation always produces the same trace ID.

Message Types

AgentVault defines nine message content types. Each has a type-specific payload schema.

Message Type Reference

Payload Examples


Audit Event Schema

Every message generates an audit event that maps directly to the OTel LogRecord data model.

Structure

OTel Field Mapping

Severity Mapping


Hash Chain

Tamper evidence without blockchain. Each audit event references the hash of the previous event, forming a per-tenant chain.

Hash Computation

The hash covers: previous hash, timestamp, trace context, event body, and participants. It excludes: observed_timestamp, delivery metadata, and the hash_chain block itself.

Chain Verification

Chain Partitioning

Chains are partitioned per tenant to avoid bottlenecks. Within a tenant, events are strictly ordered by sequence_number. Cross-tenant verification is handled via signed checkpoint hashes in the federation phase.

Storage Schema

Core Tables

Indexes:
  • (tenant_id, sequence_number) — Chain traversal
  • (trace_id) — Conversation/room lookup
  • (tenant_id, timestamp) — Time-range queries
  • (tenant_id, severity_number) WHERE severity_number >= 17 — Error/critical filtering
  • GIN on body and attributes — JSONB content search

Key Query Patterns


API Endpoints

Audit Trail

Chain Verification

Response:

Pending Decisions


Phase Evolution

The data model is designed to grow without schema changes across five phases.
1

Phase 1: 1:1 Human-Agent Chat

  • trace_id = conversation_id (1:1 mapping)
  • span_id = each message exchange
  • Single chain per tenant
  • Postgres storage, direct queries
  • No external OTel infrastructure needed
2

Phase 2: Multi-Agent Rooms

  • trace_id = room_id
  • Multiple agents produce spans within the same trace
  • parent_span_id links replies to triggers
  • New event types: agent_joined_room, agent_left_room
3

Phase 3: Agent-to-Agent Direct

  • Trace context propagates across agent boundaries
  • OTel SpanLinks for delegation chains referencing original traces
  • Policy evaluation events added to audit log
  • OTel Collector deployed as export sidecar
4

Phase 4: Team Workspaces

  • Resource attributes expand: av.team.id, av.workspace.id
  • RBAC audit events: permission_granted, permission_denied, role_changed
  • OTel export to customer backends becomes a selling point
5

Phase 5: Federation

  • Cross-tenant trace context propagation (W3C Trace Context headers)
  • Signed checkpoint hashes between federated tenants
  • Full OTel Collector deployment with multi-backend export

OTel Export Path

When ready, adding OTel export requires zero schema changes because the data model is already OTel-compatible:
OTel Collector configuration for customer export:
Compatible with OpenTelemetry Specification v1.29+.

Telemetry Span Types

AgentVault emits 21 span types using the av. prefix naming convention. These spans are generated by the plugin, client SDK, and backend.

Core Agent Spans

Platform Spans

Infrastructure Spans

W3C Trace Context

All spans include W3C TraceContext headers for cross-agent trace correlation: