Evidence

From runtime controls to customer-ready evidence.

Glacis writes a signed record for each decision it covers. For a particular review, those records can be put together by hand, with the context and the mappings that review calls for. Glacis doesn’t offer an automated export today.

Verify a record Talk to us
Workflow
Control
Decision
Record
Evidence pack
Clinical summary, agent action or model update
PHI boundary, tool permission, drift rule
Allowed, constrained, held or denied
Signed record with the policy hash, model version and event time it reported
Regulatory, security, audit or internal review artifact

An evidence pack is built out of three separate things: what the runtime records at the moment a control runs, the work of selecting and framing those records for a particular reviewer, and the boundary that decides which fields ever leave the deployment.

Runtime

The record shows what the control reported.

Each record carries the control that ran and its outcome, the policy hash, the model version, the event time and the signature. What a record does and doesn’t establish is set out under the record anatomy below.

Assembly

A pack answers one reviewer’s question.

Signed records can be put together by hand into a pack for a regulator, a customer’s security team, an auditor, an incident review or an internal review.

Verification

An explicit data boundary.

A record can leave the sensitive fields out and still carry what a reviewer outside your company needs to check it.

Sample record anatomy

What a signed record holds.

A record binds the event, the decision, the outcome, the event time, the policy version and the verification metadata, and it can leave the sensitive fields out. The verifier confirms the record is intact, shows which key signed it and what it links to, and reads back the decision it recorded. It doesn’t tell you whether the action was correct, whether every event was captured, or whether the system is safe or compliant, and it can’t confirm that events happened the way the record says.

Runtime event
Model call, tool call, drift signal or control decision.
Decision and outcome
Allowed, constrained, held or denied.
Verification metadata
Timestamp, policy hash and version, input and output hashes, runtime signals, the control that ran and its outcome, and the record ID. The record is Ed25519-signed by the operator and hash-chained. Records minted through the portal may also carry a Glacis service-operated witness countersignature and inclusion proof; SDK or self-hosted records may be operator-signed only.
Sensitive payload
A record can leave out prompts, outputs, PHI, customer data, code, credentials and proprietary context, keeping only the fields and hashes a verifier needs.

Evidence pack anatomy

What an evidence pack holds.

An evidence pack turns many records into a structured review artifact: what was assessed, which controls were in scope, what the records report, what was held or denied, and which gaps remain.

Workflow assessed
The named AI workflow, agent boundary, tool surface and delegated authority.
Controls and records
Control inventory, sample records, denied actions, holds and review decisions.
Review use case
Enterprise security reviews, audits, customer trust, insurance, regulated evidence and internal assurance.
Remaining gaps
Open control gaps, evidence gaps and next improvements for the workflow.

How a pack gets made

A pack is put together by hand.

The records come out of the runtime. The pack doesn’t. Glacis doesn’t offer an automated export today, so a pack is built for a particular review: someone picks the events that belong in it, writes the context around them, and adds the mappings that review calls for. That takes longer than an export would.

It also keeps the boundary clear. A reviewer can check the signatures and the integrity of the records, then weigh the rest for themselves. What was in scope, what was left out and what gaps remain are written out in the pack.

See a sample evidence pack Talk to us