Skip to content
Sigilbase

Linking documents to events#

A document in Sigilbase does not live beside your audit trail — it can be bound into it. A finalised document version, a signature request, or a certificate can be linked to the events it concerns: a specific event, a whole stream, or a resource in the events namespace.

What a link is#

A link is itself an event. Creating one appends document.linked to the document's stream, carrying the document's SHA-256 and the target reference; dissolving one appends document.unlinked. The association and its entire history are provable facts in the tamper-evident record — a link can be dissolved, never erased.

Examples of what this makes possible:

  • This signed data-processing addendum is linked to the vendor-onboarding events for that counterparty.
  • This internal authorisation record is linked to the specific config.changed event it authorised — an auditor examining the change sees the authorisation; an auditor examining the authorisation sees the change.

Resource-anchored documents#

A document may declare a resource exactly as events do (e.g. counterparty:acme/agreements/msa), so it sits in the same namespace as the events it concerns — one coherent evidential view of everything touching that counterparty, agreement, or system.

Links travel and verify#

Links survive into evidence bundles (format 1.4's links.json) and are checked by the standalone verifier: each link must resolve to its document.linked / document.unlinked event carrying the same SHA-256, entirely offline. A bundle can prove "this signed document, this hash, was linked to these events, all within this tamper-evident stream".

The honest boundary#

A link asserts that your workspace associated this document with these events at a provable time. It does not assert that the document caused, authorised, or governs them — that meaning is yours to make. The link records the association; its effect, if any, is a question for the people and agreements involved, never for the tooling.