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 and 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 and signer names and emails are your governance record, and they live in two places with different erasure properties, stated exactly:

• In your stream's events, as payload fields (recipient or signer, each with name and email). The actor on those events is an opaque, stable reference (recipient:<id> or signer:<id>), never the email, because the actor is an input to the entry hash and can never be redacted. The payload can: the owner's hash-preserving redaction destroys the identity in a named event while every hash, sequence and checkpoint survives. Events recorded before 7 September 2026 carried the email in the actor field itself; that field is immutable by construction and no tool, ours included, can remove it.
• In the working rows the dashboards read (name, email, typed name, the stored image of a drawn mark, the personal link). Signer identity erasure replaces them with markers, deletes the mark image, kills the link and declares the act, in one operation across the workspace.

What neither removes: a campaign certificate or countersigned copy already rendered (published versions are immutable, hashed artefacts, and the names on them are the record as it was made), the sha256 of the mark, and the times and hashes that prove the act happened.