Governance records
Governance records are the field-level detail behind Governance records →: the recording settings 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
Recording is off on a new surface. Record signed governance records, in the surface’s Governance recording section, is the master switch, and the settings below it appear once it is on, so recording can be paused 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.
- Record sets which interactions are recorded. Keep Every interaction for a complete trail, or narrow it to blocked interactions, or to blocked and failed interactions.
- Keep prompt & completion bodies gives you a full audit trail of exactly what a caller sent and what the model returned. For surfaces handling regulated or otherwise sensitive data, choose For blocked interactions only or Never (digests only): 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: a streamed completion is reassembled before recording, so streaming traffic gets the same coverage as buffered traffic. Turn it off when you deliberately want streamed traffic left out of 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.
| Field | Default | Description |
|---|---|---|
| Record signed governance records | Off | Master switch in the surface’s Governance recording section. Turning it off stops recording and keeps the surface’s recording settings. |
| Record | Every interaction | Which interactions are recorded: Every interaction, Blocked interactions only, or Blocked and failed interactions. |
| Keep prompt & completion bodies | For every recorded interaction | Which recorded interactions keep the full prompt and completion bodies: For every recorded interaction, For blocked interactions only, or Never (digests only). A record without bodies keeps digests and stage evidence only. |
| Record streamed interactions | On | Record streamed interactions too, reassembling the streamed completion before recording. When off, streamed requests on this surface are left out. |
| Local retention (days, 0 = keep indefinitely) | Keep indefinitely (0 days) | How many days records stay on the appliance. See Retention. |
| Integrations | Local store only | Where each record is exported in addition to the local store: the OpenTelemetry exporter switch and the integration checkboxes. See Export sinks. |
Viewing a record
The Governance Records page, under Monitoring → Governance, lists the 100 most recent records for the surface chosen in Surface, newest first. Each list entry shows a badge with the record’s overall outcome: block, error, flag, or allow. Selecting a record opens its detail:
| Section | What it shows |
|---|---|
| Header | The surface name, the time recorded, the record ID, the provider and model, and one line combining total tokens, cost, and latency (for example “12,345 tokens · $0.0123 · 842 ms”). |
| Surface | Name, Description, Surface ID, and Recorded. The name is the one captured in the record, so it stays readable after the surface is renamed or deleted. |
| Identity & chain | Trace, Caller (hashed), Content hash, and Previous hash. |
| Processing stages | Every stage that ran, in order, each with its outcome (allow, block, flag, observed, or error), its reason, any model call’s provider, model, and tokens, and the stage’s input and output, or their digests when bodies weren’t kept. |
| Prompt and Completion | The caller’s prompt and the model’s output. Shown only when the record kept bodies. |
| Signed credential | Show signed VC expands the complete record as raw, signed JSON. |
The signed credential is the authoritative view. It also holds fields the detail sections leave out, such as the member and teams the request was attributed to and the cost of each stage.
Recording covers buffered and streamed responses (subject to Record streamed interactions), successful, blocked, and failed interactions (subject to Record), and both live traffic and sandbox test runs. A request refused by the team gate or a surface usage limit is recorded as blocked.
Signature and tamper evidence
Each finalised record is wrapped in a signed credential (a W3C Verifiable Credential) using the appliance’s own key, tied to its DID. The credential is signed with the eddsa-jcs-2022 cryptosuite, shown in the raw credential under Show signed VC. Records signed before this cryptosuite was adopted carry an eddsa-rdfc-2022 proof, and Verify chain still verifies them. 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.
Verify chain on the Governance Records page checks the selected surface’s records in order: each record’s signature, its content hash, and the links between records. It reports “Chain valid” with the number of records verified, or “Chain verification failed” with the reason.
Export sinks
Beyond the local append-only store (the source of truth, encrypted at rest), 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, or a Kafka/Kinesis/Pulsar/Redis stream for downstream processing.
- Combining both keeps the record visible in your trace timeline and durably archived somewhere outside the appliance.
| Target | Configured via |
|---|---|
| OpenTelemetry | The OpenTelemetry exporter switch sends each record as an audit log record carrying the record ID, surface ID, content hash, previous-record hash, and the full signed credential. It reaches your collector only when Enable Log Export is also on; see Telemetry and exports. |
| Any configured integration | The Integrations list in the surface’s Governance recording section. Each entry can name a webhook, Slack, email, or a Kafka / Kinesis / Pulsar / Redis stream integration, the same integration types documented in Notifications and alerts →. |
Export runs in the background: a delivery failure is logged and leaves the request and the local record untouched. The dispatched payload carries the record ID, surface ID and 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.
| Field | Default | Description |
|---|---|---|
| OpenTelemetry exporter | Off | Send each signed record to your OpenTelemetry collector as an audit log record. |
| Integrations | None | Integrations to dispatch each signed record to. The dashboard lists only active integrations in the LLM Governance category, each as its own checkbox labelled with the integration’s name and type. See Export sinks. |
Encryption and access
- Encrypted at rest. Governance records are encrypted at rest.
- Hashed caller identity. The caller’s identity is stored as a one-way hash in place of the raw identifier.
- 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 sets how long each surface keeps its records on the appliance. 0 keeps them indefinitely. With any other value, records older than that many days are removed within about two hours of passing it. Each removal leaves a signed chain anchor, so Verify chain still passes on the records that remain. A deleted surface’s records are kept under its last retention window.
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) governance records export through.
- Backup and encryption: The Backup action that includes governance records.
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.