Software and storage architecture

On this page 4 sections

The compliance map explains what each component serves. This diagram shows where the supporting software runs and where its information is kept.

All eight packs

Start with one job or combine several. Each pack below opens its place in the setup library. The software diagram that follows shows their shared infrastructure.

Build, browser and optional backend

Technical architecture and storage

Where the software and records live

The frontend can stand alone. Add a recording backend when the selected workflow needs durable evidence; the adopter supplies authorization and operations.

Your build

Reviewed inputs → pinned output

Build inputsInventory & authored contentPublic processing facts, reviewed wording and optional Markdown/MDX sources.notabenda / authoringCompile & releaseValidate configuration, render documents and pin the released content and runtime settings.Site deploymentStatic public assetsServe legal pages, selected runtime configuration and retained public revisions with the site.

Visitor browser

Information, controls and local state

Visitor interfaceDocuments & controlsDisplay notices; keep cookie choices, form permissions, agreements and order actions separate.localStorage / IndexedDBPreferences & recoveryBrowser storage remembers choices or objections; optional IndexedDB journals retain pending actions. The selected module determines storage.Host integrationManaged service lifecyclesStart only allowed work and stop owned producers and declared markers on restriction.

Optional host backend

Authorize before reaching storage

Host application / WorkerHost authorization & admissionResolve the site, person or session context, authorize access and validate bounded recording requests.notabenda-cf / SQLite DODurable records & archivesUse scoped Durable Objects for evidence, released wording, private source and applicable delivery jobs.Authorized operatorOperator workspace & lifecycleSearch and compare evidence, grant exports separately, and apply host retention, holds and erasure policy.

The build serves public assets to the browser. Configured host transports connect selected actions to scoped backend recording.

Browser preferences are distinct from durable evidence. Public documents, private archives and operator access have different boundaries. Recording, scheduling, delivery and retention require explicit host integration.

Arrows show configured integration paths, not automatic data collection. Static documents need no browser runtime or backend. A host can use its existing recording transport instead of the optional Cloudflare package.

Storage boundaries

Location	Contents	Who controls it
Public deployment	Rendered legal pages, public facts, selected runtime settings and retained public revisions.	The site's build and deployment. Private notes and source archives stay outside these assets.
Visitor browser	Local preference memory and, for selected modules, objection or pending-action journals.	The browser and host integration. Unavailable or invalid state keeps managed work blocked; fresh-state behavior depends on the selected module.
Scoped Durable Object	Registered releases, selected evidence ledgers and optional private source or job archives.	The host chooses the object/context and authorizes recording and inspection.
Host application and providers	Accounts, submissions, fulfillment, payment or delivery state.	The adopter's application. Notabenda records do not perform those operations.

Browser storage and server evidence have separate lifetimes. In particular, expiring a permission does not determine when its evidence must be erased, and retaining an event does not keep that permission active.

Operator access and operations

The optional worker receives a host-authorized scope before accessing storage. The backoffice can search retained records and compare document revisions. Private source and export access require separate grants. The package provides no account or login system.

The host owns access policy, identity/contact binding, write admission, deployment secrets, scheduling, provider delivery, retention, holds and erasure eligibility. The Cloudflare starter and evidence lifecycle guide describe the implemented hooks and remaining host work. Discovery and CI remain optional adopter tooling.