Witness records
A witness record is what Asenion AI Guardian produces every time it is consulted: a tamper-evident record of what was consulted and what guidance was returned, cryptographically chained so that tampering is evident and the record can be verified afterward. It is the mechanism behind runtime evidence — introduced here, where it is explained, rather than used as a label to navigate by.
This page is conceptual: what the record holds and why it can be trusted. For the tools that produce it and how to call them, see Integrating Asenion AI Guardian.
The record is the point
Most compliance evidence is attestation: someone signs a statement — “I attest that the control is operating” — and the statement is accepted on the signer’s authority. A witness record is a different kind of evidence. It is produced at the moment of action, not recalled afterward; it is chained so that tampering is evident; and it can be verified by someone who trusts no one involved. You don’t have to take anyone’s word for what your AI consulted or was told — you can check.
That contrast is the whole point of the mechanism. An attestation asks you to trust the signer. A witness record asks you to trust nothing: it is made as the work happens and carries its own proof.
| Attestation | Witness record | |
|---|---|---|
| Made | Afterward, on recall | At the moment of action |
| Rests on | The signer’s authority | Its own cryptographic chaining |
| To trust it you | Trust the signer | Trust no one — you can check |
What a witness record contains
Conceptually, a witness record holds the two facts a later reader needs to reconstruct the moment of consultation:
- What was consulted — the policies and guidance Guardian surfaced for the bounded action in question.
- What guidance was returned — the guidance the consultation produced.
It does not contain a verdict. A consultation “never returns a verdict”; the record proves what guidance was surfaced, and when — not a ruling on whether to proceed. What to do with the guidance belongs to your integration, and the record stands as evidence of what was on the table when that choice was made.
Tamper-evident chaining
A witness record is cryptographically chained so that any later alteration is evident. That property is what lets the record be verified by a party who trusts no one involved: because the record is made in the course of the work and chained, an auditor, a regulator, or a customer’s security team can check what was consulted and what guidance was returned without taking anyone’s word for it.
This page stays at the level of the property, not its construction: the record is tamper-evident and chained, and that is the guarantee it offers. The internal implementation is not published here.
Paired records: a consultation and its evaluation
Guardian’s evidence comes in two shapes:
- A consultation before a bounded action produces one witness record.
- An evaluation of the agent’s response after that action can produce a second, paired witness record, cryptographically linked to the prior consultation.
The pairing is itself hash-committed: the paired record carries a paired_event_id that commits to the event_id of the consultation it belongs to, so the two records are bound together and the binding cannot be altered without detection. The result is a verifiable before-and-after — what guidance applied at the moment of the action, and what the response was evaluated against afterward.
Not every call is paired. A consultation stands on its own; the paired record exists only when your integration evaluates a response. Enumerating the policies in the loaded bundle produces no witness record at all. Which call does what is covered in Integrating Asenion AI Guardian.
Why this is verifiable evidence
Across Asenion, evidence is made in the course of the work rather than assembled for an occasion: controls carry citations and versioned history, assessments carry review trails, tests carry results tied to the system they tested, and runtime consultations carry witness records. The runtime record completes that pattern at the moment of action — when someone asks you to show what your AI consulted and was told, the record already exists, and it can be checked rather than taken on trust.
For how this fits the reviewer’s evidence model end to end, see Trust & Security.
Where to go next
- Integrating Asenion AI Guardian — the three tools that produce these records, and when to call each.
- Asenion AI Guardian — the consult, guidance, and witness-record loop in context.
- Trust & Security — the platform-wide evidence model.
- Glossary — witness record, consultation, and attested defined in one place.