Governance records

Governance records are the field-level detail behind Governance records →: the recording toggle a surface opts into, what gets captured for each interaction, and how the signature and hash chain let anyone verify a record hasn’t been altered.

Surface recording toggle

Absent means recording is off for the surface; when present, its own enabled field is the actual master switch, so the block can be temporarily disabled without deleting the configuration. Turning it on converts a surface’s traffic into a signed, tamper-evident audit trail: the evidence you’d hand to an auditor, a customer, or your own compliance team to show exactly what a caller sent, what the model returned, and which guardrail stages ran. Recorded surfaces are reviewed on the Governance Records page, under Monitoring → Governance.

• Any surface whose interactions you may ever need to reconstruct or prove should have recording on. Production surfaces handling real traffic are the common case.
• Capture full prompt & completion bodies gives you a full audit trail of exactly what a caller sent and what the model returned. Switch it off for surfaces handling regulated or otherwise sensitive data: the record still keeps digests and stage evidence, so you can prove what happened without retaining the sensitive content itself.
• Record streamed interactions should stay on for most surfaces, since the SSE completion is reassembled server-side before recording and streaming surfaces get the same coverage as buffered ones. Turn it off only if you have a specific reason to exclude streamed traffic from the audit trail.
• Set Local retention to how long records need to stay reachable locally. 0 (indefinite) is the safe default when disk space isn’t a constraint, and a fan-out integration (below) can carry records further into a longer-lived system regardless of this setting.

Viewing a record

Selecting a record on the Governance Records page shows a structured summary. Only a handful of fields render directly on screen:

Everything else the record captures (every processing stage and its verdict, prompt/completion text or digests, the caller’s hashed identity, and every other recorded field) is available by expanding Show signed VC. This reveals the complete record as raw, signed JSON: the same data an independent verifier checks the record’s signature against, so it’s the authoritative source whenever you need more detail than the summary above.

Recording covers every path a surface serves: buffered and streamed responses alike (a stream is reassembled before recording), successful/blocked/failed interactions (whichever stage stopped a request is recorded), and both live traffic and sandbox test runs.

Signature and tamper evidence

Each finalized record is wrapped in a signed credential (a W3C Verifiable Credential) using the appliance’s own key, tied to its DID. Expanding Show signed VC on the Governance Records page renders this credential as raw JSON, exactly as signed. Anyone holding the appliance’s public DID document can independently verify the credential’s signature and confirm the appliance issued it unaltered.

Records for a surface also form a hash chain: each record’s hash includes the previous record’s hash, so altering or removing any earlier record breaks the chain from that point forward, visibly. Together, the signature and hash chain let a third party, not just the appliance itself, trust that a record is genuine and complete. That turns what would otherwise be an internal log you take on faith into evidence you can hand to an outside auditor or counterparty. The Verify chain button on the Governance Records page checks a surface’s entire chain in order and reports either a pass (with the count of records checked) or the exact record where verification failed.

Export sinks

Beyond the encrypted local append-only store (the source of truth), a record can fan out to other systems for longer-term storage, alerting, or analysis.

• The OpenTelemetry exporter fits a team that already runs a tracing pipeline and wants governance events alongside its other observability signals.
• Integrations push records somewhere purpose-built for review or archival: a webhook into your own system, a Slack channel for visibility, a Kafka/Kinesis/Pulsar/Redis stream for downstream processing, or Langfuse for LLM-specific analysis.
• Combining both keeps the record visible in your trace timeline and durably archived somewhere outside the appliance.

Export is best-effort and asynchronous: a delivery failure is logged and swallowed, and never affects the request or the local record. The dispatched payload carries the record id, surface id/name, content hash, previous-record hash, timestamp, the signed credential, and the raw record JSON as template variables, so an integration’s content template can emit any of them.

An empty export block (OpenTelemetry off, no integrations) is equivalent to leaving Integrations unset.

Encryption and access

• Encrypted at rest. Every stored record is encrypted (AES-256-GCM, with either a local key or an AWS KMS per-value envelope), regardless of whether Capture full prompt & completion bodies is on.
• No raw caller identifiers. The caller’s identity is stored as a salted/peppered hash, never the raw identifier value.
• Dedicated read permission. Reading governance records is gated by its own permission, separate from the general application-log permission, and restricted to Administrators by default. See RBAC → for how permission-to-role defaults work.

Retention

Local retention is the only retention knob at the record level: 0 keeps records indefinitely; any other value is the local rotation window, per surface.

Related

• Governance records concept: Why records exist, the trust model, and what they’re used for.
• Guardrails: The Prompt Guard, Judge, and Jury stages whose verdicts populate the stage transcript.
• RBAC: Its own dedicated permission, restricted to Administrators by default.
• Telemetry and exports: The same integration types (webhook, Slack, email, stream, Langfuse) governance records export through.
• Backup and encryption: The same encryption-at-rest guarantee covering appliance storage.