Architecture & verification

How the pieces fit

1. Hold the memory. Keep the main context store with your organization, separate from the AI tools that use it.
2. Check the request. Select the records and form of disclosure allowed for a tool, audience and task.
3. Record the exchange. The design includes disclosure receipts and a linked ledger so sharing can be inspected.
4. Manage its lifetime. Review permissions, track recorded inferences and define retention for governed records.

This is the intended architecture. See the illustrated workflow or try the three-round access challenge.

Prototype evidence

Our reference implementation exercises the core rules behind memory, policy and disclosure. The checks below describe internal prototype behavior; production validation and independent review are separate parts of the roadmap.

Our publication standard is to identify the implementation revision, test, execution date, output and scope for each reproducible result. See our development roadmap for the next milestones.

Where erasure would apply

Revocation stops future authorized requests through Vivendur. Erasure is a separate operation on information within the system’s control. Neither operation can recall a copy already disclosed to an external recipient.

Governed vault records

The intended erasure scope is a specified set of stored records and tracked derivations within the governed memory system. It is not a claim about every conclusion an external model may have drawn.

Backups, replicas and keys

Production coverage must account for replicas, backups, retained keys and recovery paths. The published prototype descriptions do not establish that all recoverable copies or key material have been destroyed.

AI providers and other recipients

Provider conversations, logs, caches, exports and copies made after disclosure are outside Vivendur’s erasure boundary. Any retention or deletion there depends on that recipient’s systems and agreements.

Certificates and audit records

A certificate would identify the operation and records it covers. Its signature could establish who issued it; that alone would not prove that no copy remains. Evidence about key handling, storage coverage and recovery behavior would also be needed. Audit metadata may have a separate retention policy.

Until the relevant deletion coverage is established, the appropriate description is remove from future use. We should only describe erasure with the scope and evidence that support it. Read more about revocation.

A small hash demonstration

This browser-only example computes a SHA-256 digest of sample text. Edit the text to see the digest change. It illustrates a hashing operation; it does not demonstrate a signed disclosure receipt, an independently anchored audit history, product security or deletion.

The text and its digest are served by the same website. An operator could change both, so this demonstration is not independent evidence that a historical pledge stayed unchanged or that a commitment was honored.