Skip to content
Sigilbase

For auditors#

Someone you are auditing has granted you direct, read-only access to their Sigilbase audit streams. This page tells you what that means and how to use it. It assumes nothing about your familiarity with Sigilbase and takes about two minutes.

What you were given#

Sigilbase is a tamper-evident record: events are hash-chained in order, sealed under signed checkpoints every few minutes, and verified nightly. The organisation being audited cannot silently edit, delete, backdate, or reorder anything after the fact — and neither can Sigilbase. How verification works explains the mechanics; it is written for you and prints cleanly on A4.

Your access is a grant, not an account:

  • No password. The email you received contains a sign-in link. Links work once and are valid for 30 minutes; request a fresh one any time from the auditor sign-in page by entering your email. There is nothing to enrol and nothing to remember.
  • Scoped. You see exactly the streams the grantor chose, and within them only events dated inside the granted window. Nothing else exists as far as your session is concerned.
  • Time-boxed. The grant expires on the date shown in the band at the top of every page — at most 90 days from issue. Expiry ends your session automatically. The grantor can also revoke at any time.
  • One session. Signing in from a new link ends any previous session. If you are signed out unexpectedly, that is usually why.
  • Visible. The organisation sees a record of what you viewed — grants, sign-ins, and page views land in their own tamper-evident system stream. Symmetry is the point: your review is itself evidenced.

What you can do#

  • Browse events, including full payloads. The grantor authorised this disclosure when they scoped your grant.
  • Inspect checkpoints and verification runs — the seals over the record and the history of chain checks, failures included.
  • See inclusion proofs on any sealed event: the arithmetic connecting that single event to a signed checkpoint.
  • Export evidence bundles covering your granted window, and download bundles that fall inside it — when your grant includes exports (most do; a browse-only grant omits the Evidence exports page, and the granting organisation exports ranges on your behalf instead).

You cannot change anything, and there is nothing you can click that changes anything. Settings, users, billing, and support belong to the tenant and do not render for you.

Do not take the portal's word for it#

The portal is a convenience. The product's claim is that you never have to trust a rendered page — including this one:

  1. From Evidence exports, export your granted window on a stream. You get a zip containing the raw events, the signed checkpoints, the public keys, and a standalone verifier.
  2. On any machine with PHP 8.2 or newer, unzip it and run php verify.php . — no network access is needed or used.
  3. PASS means every event in the bundle is byte-identical to what was sealed, nothing was removed, inserted, or reordered, and every seal's signature is valid. Any failure names the exact event or checkpoint that broke.

The verifier is developed in the open at github.com/sigilbase/verifier; you can run the published copy instead of the bundled one, or have your own specialists reimplement it from the format specification. Independence is the point.

If you encounter a redacted event#

You may see an event rendered as a tombstone — "payload redacted {date} · hash preserved" — and the verifier may report redactions in a bundle. This is the organisation's lawful-erasure mechanism (personal data recorded by mistake, for example): the stream's owner destroyed that payload's content, deliberately and on the record. Everything else survives — the sequence, the actor and action, the timestamps, the payload's hash, and the chain, which verifies straight through the tombstone. The act itself is a payload.redacted event in the same ledger, naming the sequences and the stated reason, and every evidence bundle must declare each redaction or the verifier fails it outright.

Treat a declared redaction as stronger evidence than a silently clean history, not weaker. A log that could be quietly emptied would show you nothing; this one shows you exactly what was destroyed, when, by whom, and why, while proving nothing else was touched — and the preserved hash still convicts any purported copy of the destroyed content that surfaces later. What a redaction cannot do is hide itself: sequences never close up, hashes never change, and the declaration cannot be removed. If the stated reason matters to your audit, that conversation is with the organisation — the ledger guarantees you will know to ask.

The honest limits#

Verification proves the record is intact since it was written. It does not prove events were true when written, and it does not prove the streams you were granted are the whole story — scoping the audit remains your job. What passing verification proves states both sides precisely.