Skip to content
Sigilbase

Certificates of Evidence#

An evidence bundle is the full, machine-verifiable export. A Certificate of Evidence is the one-page companion for humans: a PDF answering a specific evidential question — this event, this range, these filtered records — that a professional can attach to a letter or an evidence pack. It summarises what the mathematics prove about the record; the bundle remains the thing that proves it.

Certificates are available on every plan. Evidence delivery is never gated.

What a certificate covers#

One of three scopes, always within a single stream:

  • A single event, by sequence number.
  • A sequence range, from one sequence to another.
  • A filtered window: every event whose occurred_at falls in a stated window, optionally narrowed by actor or action — the same filters the events views use.

Only sealed events can be certified. If part of the scope has not yet been sealed into a checkpoint, the request is refused rather than certified without a seal (sealing runs every few minutes; retry shortly).

What it contains#

In order: the certificate id and generation time; the tenant and stream; the question answered in one sentence; the record's identifying data — sequence, occurred and received times, actor, action, resource, payload hash, and payload state; the containing checkpoint with its Merkle root, Ed25519 signature, and signing key; anchor details, naming the provider and — where the provider was configured as qualified at anchor time — its status, jurisdiction, token time, and certificate serial (see Qualified anchoring); the redaction state where applicable; a plain-language statement of what the certificate proves and does not prove; and instructions for verifying everything independently with the released verifier.

Payload contents travel only on explicit opt-in, and only for single-event certificates — certificates are made to travel, and content should leave with intent. Redacted or erased content no longer exists and is stated as such; content held in the PII vault stays there.

Reproducible, and itself evidence#

Everything a certificate states comes from append-only records, so regenerating the same scope later reproduces the document byte for byte, save for the generation timestamp and certificate id. Each issuance is recorded with the SHA-256 of the exact file, and appended to the tenant's own tamper-evident system stream as certificate.issued — issuing evidence is itself evidence.

Certificates covering events inside an exported range travel with evidence bundles (format 1.3) under certificates/, listed in the manifest with their hashes so the verifier can confirm they arrived intact. They are documents about the evidence, not evidence: the bundle's cryptographic verification never depends on them.

Who can issue one#

Tenant owners and admins, for any stream. Auditors with a granted window can issue certificates covering their granted scope — the grant's stream list and time window bound what a certificate may cover, and an out-of-scope request is simply not found, exactly as everywhere else in the auditor portal.

A qualified seal on the certificate itself#

A planned, strictly additive stage: where the operator's relationship with a qualified trust service provider supports it, the finished PDF can itself be sealed with a qualified electronic seal, giving the certificate document its own eIDAS Article 35 presumption of integrity and origin. This is configuration-gated and absent by default; certificates are complete and reproducible without it.

The honest limits#

A certificate states what the mathematics establish, in the words of How verification works:

What passing verification proves:

  • Integrity. No event in the exported range differs by even one byte from what was sealed. Every fingerprint was recomputed from the raw data and matched.
  • Completeness of the range. Within the exported range no event has been removed, none inserted, and none reordered. The sequence numbers are dense, the chain closes, and every sealed range rebuilds to the same fingerprint that was signed.
  • Continuity. The checkpoints themselves chain together, so a whole sealed period cannot be quietly dropped from the middle.
  • Authenticity. Every seal carries a valid signature from a listed signing key. If you have compared those keys against the ones Sigilbase publishes, the bundle is anchored to Sigilbase's identity, not merely internally consistent.

What it does not prove:

  • It does not prove events were true when written. If a system recorded that a backup succeeded when it did not, Sigilbase seals the false statement faithfully. Tamper-evidence starts at the moment of ingestion, not before.
  • It does not prove the exported range is the whole story. Verification covers the range in the bundle. Whether other relevant streams or periods exist is an audit-scoping question; the stream's checkpoint listing shows the full sealed extent if you need it.
  • It does not cover the gap before sealing. Events are sealed within minutes of arrival. Until an event's checkpoint exists, the cryptographic guarantee has not yet attached to it. The seal's timestamp tells you exactly when rigidity began.
  • It does not identify people. actor is whatever the writing system said it was. Sigilbase proves the record of the claim is unaltered, not that the claim's author was who they said.

How any authority, regulator, or tribunal weighs a certificate is a question for the professionals handling your matter, in their jurisdiction, on their facts. The certificate says what is proven and how to check it — nothing further.