Frequently asked questions

It’s our term for authority over the memory an AI workflow uses: where it lives, what each tool receives, which inferences are recorded, and when information stops being used.

Our design has five requirements: organization-held memory, task-specific disclosure, source-linked inferences, scoped erasure and verifiable records. These are goals we’re building toward, not a certification. The status page and evidence register explain the current stage and limits.

Start with a design-partnership conversation. Bring one workflow where sensitive information limits your use of AI. We’ll discuss the outcome, the context needed and the boundaries your team wants to control.

If there’s a fit, we can define an evaluation with an agreed scope, safeguards and terms. Our development roadmap explains the current stage and milestones.

Encryption, network protection and access controls all have roles in protecting information. Vivendur’s intended focus is choosing which context a particular AI tool receives for a particular task.

For example, a recruitment update may need aggregate progress and a review date, while participant notes stay in the vault. This is intended to work alongside an organization’s existing security controls, not replace them.

Vivendur’s architecture centers on memory vaults held by your organization, with key custody and access boundaries intended to limit our own access. We do not treat vault contents as a revenue source.

Key handling, recovery, support access and storage coverage are important parts of the deployment design. Read our architecture and verification notes for the intended boundary and the work needed to validate it.

We’re designing Vivendur to store inferences with source links, uncertainty and rules about whether they can be shared. A guess about a person should not silently become an established fact.

Our team reports prototype checks of source tracking, revision history and exclusion below a configured confidence threshold. The evidence register explains what is not yet published.

This covers inferences recorded and tracked by Vivendur. It does not reveal every conclusion inside an external model or erase provider-held copies.

Revocation is intended to stop future authorized requests through Vivendur. It cannot recall a conversation, cache, export or copy an external tool already received.

Erasure within the governed vault is a separate operation covering specified records and tracked derivations. Production coverage of backups, replicas and keys still needs validation. See the erasure boundaries and our note on revocation.

Healthcare, legal services, government, and research, where sensitive data most often holds AI back. Our Security Briefings are drawn from the same sectors. Azin’s own background is clinical and research; her note explains how the problem became personal.

We have not published standard design-partner pricing. Any pilot’s costs, responsibilities, data handling and scope would be discussed and agreed before it starts. An inquiry does not sign you up for a pilot or create a payment obligation.

Vivendur has a technical design and a reference implementation with internal checks of core memory and policy rules. Our next phase is the production core, public verification tools and independent security review.

We’re inviting organizations to help shape the workflows and evaluation priorities. See our development roadmap and verification approach.

Vivendur was founded by Azin Etemadi, whose experience as a doctor and researcher shaped the company’s focus on sensitive information. Read her background.

Our work brings together questions of memory, access policy and security. We welcome technical collaborators who want to challenge the design and help develop it.

Our focus is the memory and disclosure layer: how an organization holds knowledge, chooses what each AI tool receives and keeps a record of sharing.

Design partnerships help identify the workflows where that control is most useful and define a practical evaluation. Commercial scope and terms are agreed directly with each partner.

An independent security review of the production core is planned. We do not currently publish an independent assessment or claim security certifications. A review is not the same as a certification, and we have not committed to a certification timetable.

Our Architecture & verification page distinguishes planned verification from what is currently available.

We distinguish design goals, team-reported prototype checks and independently reviewed results. Passing prototype tests does not justify a claim of formal proof or production security.

Our status page uses those distinctions, while the evidence register identifies unpublished artifacts and important boundaries. We intend to link each published result to a version, test date, output and scope.