Records both sides can trust
When two businesses disagree about what happened, each side produces its own logs, and each side controls its own logs. Neither is evidence. Sigilbase holds the record in between: append-only, independently verifiable, and available to your counterparty as a scoped, permanent view neither of you can alter.
In your database your admins can rewrite it, and nothing shows the change.
Hash-chained in your app, tampering is detectable, but the party being audited still holds the keys.
In Sigilbase, a third party holds the record and anyone can verify it, with no one's word taken, including ours.
He-said-she-said records: when the relationship sours, each side's system tells its own version of the same events.
Proving basic facts after the fact (that notice was served, that an approval was given) costs more than the facts were ever worth.
Logs that were technically fine but not believable, because the party that produced them is the party they favour.
The Sigilbase event model, applied to a contractual notice.
Each moment that could be disputed is one event: an actor, an action, and a payload. A contractual notice, an approval, a permission change: here, serving a notice of breach, with the document bound in by its hash.
{
"actor": "org:acme-ltd",
"action": "notice.served",
"resource": "counterparty:acme/contract-2026-118",
"payload": {
"document_sha256": "c41b…7d02",
"method": "email+post",
"reference": "notice-of-breach-03"
}
}
The event lands in a ledger held by Sigilbase, not by either party. It is hashed, chained to the record before it, and sealed into a signed checkpoint within minutes of arriving.
Your counterparty holds a scoped, permanent view of the same record: the same sealed events, the same proofs. There is one history, not two.
Your logs, their logs, and the record in between.
| Question | Either party's own logs | The record in between |
|---|---|---|
| Who can alter the record? | Whoever holds it, and nothing would show | Neither party; any change fails verification at the exact entry |
| Can the other side verify it independently? | No; they must take your word | Yes; offline, with an open-source verifier, no account |
| Does it survive the vendor? | Only as long as your systems do | Yes; exported bundles verify without Sigilbase existing |
| What happens in a dispute? | Competing exports, and an argument about provenance | One sealed history both sides already hold and can check |
Nobody has to take anyone's word. Including ours.
Both parties can hold the evidence bundle and check it independently. A tampered copy fails verification on either desk, naming the exact sequence that broke.
The standalone verifier is open source and runs offline, depending on nothing from us. On the Business tier, checkpoint roots are anchored outside our reach entirely, so verification never depends on records we could later change.
Retention is forever on every plan, exports are always available, and a bundle taken today still verifies years from now: whoever holds it, whatever happened to the contract, the counterparty, or us.
How this works underneath: tamper-evident audit logs explained
Questions about records for disputes.
Does this replace a contract?
No. A contract says what the parties agreed; Sigilbase records what actually happened under it (the notice served, the approval given, the access changed) in a form neither party can quietly rewrite. The two work together: the contract sets the obligations, the record evidences the performance.
Is this legally binding?
An honest answer: Sigilbase evidences what was recorded and when. The record is append-only, held by neither party, and anyone can verify its integrity offline with an open-source tool. How that evidence is weighed in any legal process depends on the jurisdiction and the facts, and nothing here is legal advice.
How does my counterparty see the record?
Through a scoped, permanent, read-only view: you choose the streams or resources they can see, they get the events with their proofs and export, and neither of you can alter what it shows. Access to the view is itself recorded, and an exported bundle verifies offline without an account, without trusting you, and without trusting Sigilbase.
What if my counterparty does not use Sigilbase?
They do not need an account or any relationship with us. Verification uses a standalone open-source verifier that runs offline; hand over an evidence bundle, or the scoped view, and they check the record themselves. The proof does not rest on either party's good faith, or on ours.
What kinds of events should we record?
Any moment that could later be disputed: a contractual notice served, a deliverable submitted, an approval given, a permission changed, an SLA breach observed. Each is one event with an actor, an action and a payload, and a hash of an attached document binds the paperwork to the sealed record.
Start recording provable history
Chained, sealed, independently verifiable audit logs, from the first event. Free while Sigilbase is in beta.
Questions first? Write to hello@sigilbase.io.