Memory & Data Lifecycle
Provenance, revision history, sensitivity, correction, deletion and retention of operational memory
Operational memory is the core of OmniGENIE. This page describes the lifecycle of a memory item from capture to deletion. The mechanisms of the GENIE platform are labelled Available; institutional governance additions are labelled In development.
Memory model
| Layer | Content | Status |
|---|---|---|
| Conversation turns | The raw turns of a session, scoped to the account. | Available |
| Typed facts | Facts extracted from turns with a type (persona, episodic, instruction, value, open question, inferred belief), a link to the source turn, an optional real-world event time and a sensitivity tag. | Available |
| Revision chain | A corrected fact is not edited in place. A new fact is written and the previous one is marked as superseded with a timestamp, so both the old and the new state remain reconstructable. | Available |
| Derived graph | An asynchronously projected knowledge graph for visual exploration. Derived, droppable, never a source of truth. | Available |
| Structured call artefacts | Notes and follow-up tasks from calls. | Available |
The revision chain follows an invalidate-and-supersede pattern. It is not a full bitemporal database with independent valid-time and transaction-time queries. Public descriptions therefore use the term revision-tracked memory.
Lifecycle stages
Capture
Turns are stored per account. Voice turns that were interrupted retain only what was actually heard.
Extraction
After a session, facts are extracted asynchronously, typed, linked to their source turn and tagged with a sensitivity level. Extraction is currently optimised for German-language conversations.
Recall
During a conversation, relevant facts are surfaced. Facts tagged as sensitive require a higher relevance threshold. Thresholds are system constants today; per-institution configuration is in development.
Correction
A user can correct a fact by voice or in the interface. The correction creates a new revision and marks the previous fact as superseded.
Deletion of single items
A specific fact can be deleted, with a short grace period during which the deletion can be undone. After the grace period the item is purged and the audit record no longer contains the verbatim content.
Full erasure
An account erasure removes personal data across the complete data model in one transaction. An automated test enforces that every account-scoped table is part of the erasure inventory. A hashed tombstone of the account identifier prevents accidental re-creation for a limited period.
Governance controls
| Control | Description | Status |
|---|---|---|
| Purpose binding | Memory is used for the assistant's operational purpose within the account. Institution-defined purposes per memory class. | Available / In development |
| Provenance | Every extracted fact links to its source turn. Provenance for facts derived from OmniOmni component data is part of the integration design. | Available / In development |
| Access | Per-account scoping. Role-based access to shared institutional memory. | Available / In development |
| Retention | No automatic retention schedule exists today. Retention classes with statutory minimums and maximums per memory class. | In development |
| Legal hold | A hold that blocks deletion where statutory retention obligations apply, and removes held items from inference while retaining them in an isolated archive. | In development |
| Export | Structured export of an account's memory for data subject access or institutional review. | In development |
| Model training | Conversation content is used for inference, not for training foundation models by OmniGENIE. Contractual guarantees with model providers are part of the institution's third-party assessment. | Available |
Data flows
Conversation content necessarily leaves the assistant's runtime for inference. The current platform is configured with the following provider classes; the concrete providers and their contractual data handling are part of the institution's third-party risk assessment.
| Function | Provider class | Note |
|---|---|---|
| Language model | Cloud model provider through a gateway with a model allowlist | One model family is configured today. |
| Speech-to-text | Cloud provider | Single provider. |
| Text-to-speech | Cloud provider with automatic fallback to a second provider | |
| Voice transport | Media server, self-hosted or managed | |
| Telephony | SIP trunk provider | |
| Data stores | Self-hosted PostgreSQL and Redis | Location follows the operator's infrastructure. |
No data-residency guarantee is stated on this page. Region pinning for model, speech and telephony providers is a configuration and contract question that is resolved per deployment with the institution.
GDPR orientation
- Personal data held in operational memory is processed for the defined operational purpose only.
- Correction and deletion are supported at the level of single facts and of the whole account.
- Deletion requests are subject to statutory retention obligations that take precedence where applicable; the legal-hold mechanism to enforce this technically is in development.
- Where OmniGENIE interacts with natural persons by voice or text, it is designed to disclose that they are interacting with an AI system.
This orientation is not legal advice. Data protection assessments, including any data protection impact assessment for voice recognition of enrolled persons, are performed by the deploying institution.