Prove what every model did

Answer an auditor’s “what did the AI actually do” with proof, not a log line they have to trust.

When an auditor, an investigator, or a customer asks what an AI system actually did, plain logs are a weak answer. They can be edited or deleted, and a single line gives nobody a way to independently verify what a model was asked or what it returned. As AI reaches regulated workflows, that gap turns into a liability.

What you can do

  • Choose to record every interaction on a surface, only blocked interactions, or blocked and failed interactions, so that you hold a transcript of what entered, how it was processed, and what left.
  • Capture per-call cost, latency, tokens, and each guardrail verdict so that you can show who called what, and why it passed or was blocked.
  • Sign every record as a Verifiable Credential and chain it by content hash so that deletion or tampering is detectable, not just individual forged records.
  • Export the signed trail to your SIEM or observability stack so that security and finance work from one source of truth.

How it works

EACH RECORDED CALLPromptStage verdictsCompletionCost · tokens · latencyAUDIT & EXPORTAuditorsSecurityFinanceOTel · SIEM · webhookGovernance RecordsSIGN AS VCW3C Verifiable Credentialappliance DID keyPROTECTEDencrypted at rest · hashed caller idbodies kept by default (or digests only)Record 1hash: H1Record 2prev: H1hash: H2Record 3prev: H2hash: H3Verify chain → pass / faildeleting or reordering a recordbreaks the chain

Governance recording is switched on per surface with Record signed governance records, and is off on a new surface. Once on, each interaction the surface’s Record setting covers is written into a Governance Record, with streamed interactions included while Record streamed interactions is on. A record holds an ordered list of the processing stages that ran, each with its verdict, plus the prompt and the completion, or their digests, and the metrics for the call. Each record is wrapped in a W3C Verifiable Credential and signed with the appliance’s own key, tied to its Decentralised Identifier, and every record embeds the content hash of the previous record on the same surface, forming a per-surface hash chain. Records are encrypted at rest. The caller identity is stored as a one-way hash rather than a raw identifier, and each signed record can also be exported to OpenTelemetry, or through an integration such as a webhook or a streaming bus to a security information and event management (SIEM) tool.

A surface’s chain can be verified on demand: verification checks every record’s signature and content hash and walks the links, returning a pass or fail with the number of records checked, so a deleted or reordered record is detectable rather than silent. Prompt and completion bodies are kept for every recorded interaction by default. With Keep prompt & completion bodies set to Never (digests only), the appliance keeps cryptographic digests only, still proving what content flowed without storing the raw text.

  • Governance records: The record contents, per-record signature, and hash-chain verification in full.
  • Observability: The operational telemetry and rejection taxonomy that sit alongside the signed trail.
  • Telemetry and exports: How to route traces, metrics, and records to your own stack.
  • Security and access control: How source authentication establishes the caller identity that a record stores as a one-way hash.