AI decision logging that proves what your model decided.
Sigilbase is an AI decision log that records what an automated system saw and decided, then makes that record tamper-evident. Each decision event is hashed, chained to the one before it, and sealed into a signed checkpoint. Anyone can verify the record offline with a standalone verifier, without a Sigilbase account.
An agent acts, but the inputs it saw and the reason it decided are never captured as evidence.
The decision log sits in a database an operator can edit, so nothing proves it was not changed after the fact.
Regulators and customers ask what a model decided months ago, and a screenshot is not proof.
The Sigilbase event model, applied to an AI decision.
Sigilbase records each automated decision as one event: an actor, an action, and a payload. Here a credit policy model declines an application, logging a hash of its inputs rather than the raw data.
{
"actor": "model:credit-policy-v4",
"action": "decision.declined",
"payload": {
"subject": "application:9f21c",
"inputs_sha256": "7d3a…e10b",
"decision": "declined",
"reason_codes": ["DTI_TOO_HIGH", "THIN_FILE"],
"model_version": "credit-policy-v4",
"policy_version": "2026.06"
}
}
Sigilbase hashes each decision event with SHA-256 and chains it to the previous one, so altering an earlier decision breaks every hash after it.
Sigilbase seals recent events into a signed checkpoint every few minutes, and the standalone verifier recomputes the chain and signatures offline to confirm nothing was touched.
A log records events. Sigilbase makes them provable.
| Question | A standard log | Sigilbase |
|---|---|---|
| Can the operator rewrite history unnoticed? | Yes, with database access | No, it breaks the hash chain |
| Can a third party verify it independently? | No, they must trust your export | Yes, offline with the standalone verifier |
| Does the evidence survive the vendor disappearing? | No, it depends on the vendor's system | Yes, the evidence bundle verifies on its own |
| Is each record cryptographically sealed? | No | Yes, in a signed checkpoint |
Record-keeping obligations, stated plainly as of July 2026.
The EU AI Act places record-keeping obligations on providers and deployers of high-risk AI systems: such systems must technically allow the automatic recording of events across their lifetime, and deployers must keep those logs. Sigilbase does not interpret the Act for you. It provides the tamper-evident record-keeping layer the obligation assumes.
In the UK, the FCA expects firms using automated decisioning to explain and evidence individual decisions, and the Consumer Duty raises the bar on showing you acted to deliver good outcomes for customers. A signed, verifiable decision record is evidence a Sigilbase user can hand over.
The operational question is simpler than the regulation: an agent acted, so prove what it saw and decided, and prove the record has not been touched since. Sigilbase answers that with a chained, sealed, independently verifiable event per decision.
Questions about AI decision logging.
What is AI decision logging?
AI decision logging is the practice of recording what an automated system saw and decided as durable, reviewable events. Sigilbase makes each of those events tamper-evident by hashing, chaining and signing it. The result is a record you can prove was not altered after the decision was made.
Does this satisfy EU AI Act logging requirements?
Sigilbase provides the tamper-evident record-keeping layer that logging obligations assume; whether a given deployment satisfies the EU AI Act depends on what you choose to log, which remains the deployer's responsibility. We give you an append-only, verifiable record and a standalone verifier. We are not your compliance advisor, and we make no dated claim that using Sigilbase alone makes a system compliant.
What should an AI decision event contain?
An AI decision event should contain enough to reconstruct the decision: the model or actor identifier, the action taken, a hash of the inputs, the decision itself, and the reason codes. Sigilbase seals whatever fields you send in the event payload. Hashing the inputs lets you prove what the model saw without storing the underlying data in the log.
Can I prove a model decision was not changed later?
Yes. Each decision event is chained to the one before it and sealed into a signed checkpoint, so any later edit, deletion or reordering breaks verification. The standalone verifier names the sequence number that failed, so you can see exactly which record was touched.
Do I need to send Sigilbase my model inputs?
No, you do not have to send raw inputs. You can log a SHA-256 hash of the inputs instead, which proves what the model saw without placing the underlying data in the record. What each event contains is entirely under your control.
Join the waitlist
Building now. Early access for teams logging AI decisions.
Could not save your email. Try again or write to hello@sigilbase.io.
No spam, one email when it opens.