Skip to content
Sigilbase

Documents & attestations#

"Every employee provably received and accepted the security policy, version-hashed, with the acknowledgement itself ledgered" is evidence ISO 27001 and SOC 2 auditors ask for — and evidence most companies still assemble from spreadsheets and screenshots. Documents & attestations turns it into a Sigilbase-shaped record: versioned documents, provable distribution, and acknowledgement or signature with a tamper-evident record.

Available on the Team plan and above. Signature mode, weekly auto-reminders, and campaign certificates are included with Business.

The registry of record#

A document here is a versioned artefact of record, not a working file: a policy, contract, handbook, or notice. Publishing a version stores the exact file (PDF, Markdown, or DOCX), records its SHA-256, and appends document.published to a stream of your choice — by default a governance stream created from the new template. The hash is the load-bearing idea: what was acknowledged is provably this file, byte for byte, forever.

Superseding is publishing a newer version. Nothing is ever deleted; retiring a document is itself an event. Every version is listed with its hash and its event's sequence — the version history is a chain of ledgered facts, shown as such.

The stored file is evidence referenced by the ledger, not part of the chain: if a stored file were ever altered, your stream would still verify — and the mismatch between the file's bytes and the ledgered sha256 is exactly what would expose the alteration. The document pages include a one-click check that recomputes the comparison.

Campaigns: provable distribution#

A campaign is one document version, a recipient list, a due date, and a mode (acknowledge or sign). Recipients are names and email addresses — team members or not. No accounts are created: each recipient gets an emailed signed link scoped to exactly one document version and one action, in the same spirit as auditor access.

Every step is an event in your stream:

  • attestation.requested — per recipient, at send.
  • attestation.viewed — the recipient's first open.
  • attestation.completed — the confirmation itself: recipient identity, the document's sha256, the mode, and the moment.
  • attestation.reminded — every reminder, manual or scheduled.

The campaign dashboard shows outstanding, viewed, and completed per recipient, with manual reminders on every plan and optional weekly auto-reminders (Business) until the due date.

Why this beats a signature platform's database#

A conventional e-signature tool records that a ceremony happened in its database — you trust the vendor, and your auditor trusts a PDF the vendor exported. Here, the document's hash, the request, the view, and the acknowledgement are events in your own tamper-evident stream: hash-chained, sealed into signed Merkle checkpoints, verifiable offline with the standalone verifier, exportable to any auditor as an evidence bundle, and covered by every existing property — retention forever, declared-not-silent redaction, operator blindness. The acknowledgement doesn't just exist; it verifies.

The campaign certificate (Business) renders the answer an audit binder wants as one page — "24 of 24 recipients acknowledged Security Policy v3 (sha256 …) between 1–14 August" — through the same Certificate of Evidence machinery, ledgered as certificate.issued like every other issuance.

Signature mode, honestly#

Sign mode adds an intent statement ("I agree to be bound by this document"), a typed full name, and a drawn or typed signature mark, stored as an image whose sha256 travels in the completion event.

What this is: a simple electronic signature with an independently verifiable record. Under English law simple electronic signatures are valid for most ordinary contracts, and our record of who signed what version, when is unusually strong — but we do not provide advanced or qualified electronic signatures (eIDAS AES/QES), we make no claim about enforceability in any particular case, and customers with statutory execution requirements (deeds, guarantees) need their own legal advice. The strongest claim we make, anywhere, is: a signature record you can prove.

Privacy and the operator boundary#

Document contents are payload-class data: platform operators see metadata (titles, hashes, counts) and never the file contents, the same boundary that covers your event payloads. Recipient names and emails appear in your own stream's events — they are your governance record, covered by retention and by the declared erasure machinery if a lawful erasure obligation ever requires it.