# A Scalable Database Management System for Long-Term Institutional Memory, Human-AI Knowledge Sharing, and Contextual Recall **Authors:** Edward Honour, Joseph Lehman, Mohsin Ali, Chadi Abi Fadel, Otman Mechbal, Arjun Nadar, Mohammed Khan, Alan Nadal, Rishab Jolly, Eben Rey **DOI:** **Version:** 1.0 **Publication venue:** Zenodo **Resource type:** Working paper **Recommended citation:** Honour, E., Lehman, J., Ali, M., Abi Fadel, C., Mechbal, O., Nadar, A., Khan, M., Nadal, A., Jolly, R., & Rey, E. (2026). *A Scalable Database Management System for Long-Term Institutional Memory, Human-AI Knowledge Sharing, and Contextual Recall* (Version 1.0) [Working paper]. Zenodo. # Abstract Organizations store large amounts of information, but they often lose the story behind it. Records, tickets, messages, logs, documents, and dashboards may show what happened, while the reasons, assumptions, evidence, and later lessons remain scattered across tools. This paper proposes a unified Memory DBMS, a database management system for long-term institutional memory based on large enterprise databases that are durable and can scale over time. It stores Memory Objects with links to source material, supporting evidence, permissions, validity for a known time period, and provenance, meaning the evidence trail behind the memory. The proposed architecture supports retrieval with source links, shared working context for humans and AI agents, and workflow learning from repeated work. It allows useful patterns to become controlled by policy, permissions, and audit before they are reused as procedures, Skill Packages, or other operational guidance. The goal is safer reuse of organizational knowledge over time. By preserving original sources and rebuildable generated summaries, indexes, workflows, and other outputs, the system can remain useful as models, tools, policies, and organizational needs change. # Executive Summary Organizations already store enormous amounts of information, but storage alone does not create institutional memory. Records, tickets, messages, logs, documents, dashboards, and knowledge-base pages preserve fragments of work. The harder problem is keeping the reason behind a decision, the source that supported it, the period when it was true, the people or systems allowed to use it, and the lessons that should guide future work. When teams change, projects age, systems migrate, or policies evolve, people repeatedly rebuild that context from partial traces. Existing data platforms solve parts of this problem. Relational databases preserve structured state. Document systems preserve source material. Vector search and retrieval-augmented generation find similar text. Knowledge graphs connect entities. Temporal databases model change over time. Process-mining systems analyze workflows. These capabilities are useful, but they usually leave the meaning of institutional memory in application code. That application-layer approach creates long-term risk. Software outside the database often decides what a source asserted, what has been verified, which evidence supports an answer, when the answer is still valid, who may retrieve it, and how repeated work becomes a reusable procedure. The result is a memory layer that can be hard to audit, hard to rebuild, and hard to share safely across teams and tools. AI agents make the problem more urgent in everyday operational terms. An agent may answer support questions, write code, call tools, operate infrastructure, or coordinate with other agents. If it receives stale, unsupported, or unauthorized context, it may act on the wrong assumptions and repeat that error quickly across real workflows. Larger context windows help only if the context is current, permitted, source-linked, and appropriate for the task. This paper proposes a Memory DBMS: a database management system that manages institutional memory as a native data model. The minimum viable architecture includes a durable Enterprise Memory Core, optional Local Memory Nodes, Active Memory Pools for task-scoped collaboration, a Security-Aware Retrieval Coordinator, a Native Model Execution Engine, and an LLM Tool-Calling Access Surface. The database system maintains the catalog, object identities, permissions, derivation records, temporal state, validation policies, retrieval routing, audit trail, and rebuild procedures. Storage engines, embedding indexes, graph traversal engines, model providers, tool protocols, and application frameworks remain replaceable mechanisms attached through controlled interfaces. The object model starts with plain distinctions. A preserved source is a Source Package. A statement extracted from a source is a Claim. A verified assertion is a Fact. The remembered meaning around Facts and Claims is a Memory Object. Concrete events are represented as Episode Objects, while Memory Detail Objects preserve reusable steps, commands, decisions, exceptions, and validation checks. This structure keeps original evidence separate from interpretation and keeps accepted knowledge separate from unverified statements. Retrieval is therefore more than similarity search. A Memory DBMS plans recall using identity, authorization, subject, action class, Semantic Frame, Relationship Edges, validity time, confidence, precision, lifecycle state, and evidence requirements. It returns retrieval packages rather than only ranked text chunks, so users and agents can inspect the Facts, Memory Objects, source links, workflow steps, and policy state behind an answer. Active Memory Pools extend this into shared working spaces where collaborators can load context, publish observations, mark pending Claims, refresh stale context, and promote validated knowledge into durable records. The same model supports workflow learning. Repeated Episode Objects and Memory Detail Objects can produce Workflow Traces. Similar traces can be compared, validated, and generalized into Generalized Workflows. With enough evidence, current validity, review status, and safety controls, those workflows can contribute to Procedural Memory Objects and Skill Packages that guide repeatable tasks. A Skill Package is not an untracked prompt; it is procedural knowledge linked to source material, preconditions, validation checks, exception handling, security policy, and audit requirements. Security must be part of retrieval and use, not only a final filter on the answer. Semantic search can leak information if authorization is applied after candidate retrieval or summarization. Graph traversal can expose restricted Relationship Edges. Active Memory Pools can carry cached context between tasks if isolation is weak. Tool calls can reach outside authorized partitions. The system must apply access control during candidate generation, graph expansion, context assembly, summarization, model invocation, tool-call validation, promotion, and audit. Bitemporal validity, staleness, supersession, confidence calibration, precision metadata, and provenance records help distinguish what was true, what was recorded, what remains current, and what requires review. The intended contribution is a defensible category boundary and architecture for memory-native database management. The proposal unifies capabilities normally distributed across multiple systems, but its novelty is the organization of those capabilities around memory-specific database objects rather than around any single storage primitive, model, vendor, or protocol. By preserving source evidence and derivation records, the architecture allows future models, indexes, workflows, and tools to be upgraded or rebuilt without severing provenance. The result is a proposed foundation for long-term institutional memory shared across human and AI work. The next section frames the systems gap that motivates treating memory as a DBMS concern. # 1. The Systems Gap Current systems each solve part of the institutional-memory problem. Databases, document stores, search tools, knowledge graphs, temporal systems, and workflow tools all preserve useful pieces of work. Memory requires these responsibilities to work together: evidence, claims, facts, time, relationships, retrieval, security, workflow learning, and recovery. The table below shows which responsibilities are usually left to custom application code and which ones a Memory DBMS must build in as database capabilities. | Capability | How existing systems usually handle it | Memory DBMS requirement | |---|---|---| | Source evidence preservation | Some systems preserve parts of the evidence record; vector/RAG applications often leave it to custom application code. | Built in and policy-controlled | | Claim/Fact/Memory Object separation | Most systems do not separate assertions, accepted facts, and contextual memories; knowledge graphs may provide a partial model. | Built in | | Provenance and derivation | Existing systems provide partial provenance or leave derivation tracking to custom application code. | Built in and policy-controlled | | Valid time and transaction time | Temporal databases support this directly; conventional DBMSs and knowledge graphs may provide partial support; vector/RAG applications generally do not. | Built in | | Confidence and precision | Most systems treat confidence and precision as metadata handled by custom application code. | Built in and policy-controlled | | Relationship Edge-aware retrieval | Knowledge graphs support graph relationships; other systems usually provide partial support or rely on custom application code. | Built in and policy-controlled | | Workflow derivation | Process-mining systems support workflow discovery; vector/RAG applications and knowledge graphs usually provide partial support. | Built in and policy-controlled | | Active shared agent context | Existing categories generally do not provide shared working memory for humans and agents. | Built in and policy-controlled | | Security-aware semantic retrieval | Vector/RAG applications and knowledge graphs may provide partial controls, but retrieval policy is usually not part of the database layer. | Built in and policy-controlled | | Model/tool governance | Existing systems usually leave model calls and tool controls outside the database or handle them in custom application code. | Built in and policy-controlled | | Operational recovery and rebuilds | Conventional and temporal DBMSs support recovery for stored data; AI summaries, indexes, and workflows are usually only partially recoverable. | Built in and policy-controlled | The pattern is the important point. The proposed category is not defined by adding vector search to a database or adding graph edges to a RAG application. It is defined by making provenance, validity, retrieval planning, workflow derivation, active context, and governance part of the database boundary. Existing systems that attempt to preserve and retrieve organizational memory usually assemble several specialized technologies. Relational databases handle structured records. Vector databases support semantic search. Graph databases represent Relationship Edges. Document stores preserve source material and time-series databases record events and operational history. This polyglot approach can be useful, but it pushes the core semantics of memory into application logic. That push from the database layer to the application layer creates long-term operational risk. Important storage and search behavior moves into application code, creating technical debt for long-term maintenance. As the system grows, this approach creates challenges for scale, performance, recovery, security, and lifecycle management. The central problem is that memory behavior becomes distributed across multiple products instead of governed inside a single coherent DBMS. This is especially important for AI engineers building AI agents. Understanding the internal mechanics of a Memory DBMS or piecing together disparate technologies to manage memories must not be the responsibility of AI engineers. Their primary concern is how to use the system's memory interfaces to retrieve, update, and maintain shared context across agents. A Memory DBMS therefore provides a dependable abstraction layer that lets agent builders coordinate context while the database system manages the durable memory structures underneath. In AI systems, context is the working information available to a model or agent when it performs a task. The context window is the bounded space in which that information is supplied, including prompts, retrieved knowledge, instructions, tool outputs, conversation history, and task state. Because AI agents depend on having a working context to reason, coordinate, and act reliably, context engineering has become a top priority for AI adoption. A core principle of context engineering is designing systems that manage the right context at the right time. A Memory DBMS supports context engineering by making durable institutional memory available across humans and AI agents. A database of memories requires these capabilities to operate together around a shared model. Common system services must govern Claims, Facts, documents, embeddings, Relationship Edges, and other stored object types. The same services must also govern the memory-specific structures introduced in this paper: Relationship Edges, workflows, Procedural Memory Objects, and Active Memory Pools. Those services include a system catalog, access-control model, and multiple mechanisms for humans and AI agents to query memories and data. The goal is to define a single database system for representing, maintaining, retrieving, and operationalizing memories and workflows over time. This single database system becomes the foundation for Model Context Protocol (MCP) tool access for LLMs, device driver and application programming interface (API) access for traditional systems, and structured query language (SQL) access for humans (Model Context Protocol, 2025). As developed in Section 3, Memory Objects are contextual structures rather than stored Facts alone. In the end, the ability for humans or AI agents to use memory in future work becomes a primary motivation. A Memory DBMS needs multi-model capabilities, but those capabilities must be organized around Memory Objects rather than around separate storage products. The next section defines the proposed Memory DBMS boundary before the paper turns to the object model. # 2. What Is a Memory DBMS? A Memory DBMS is a database system for storing not only what an organization knows, but also where that knowledge came from, when it was valid, who may use it, and how it can be reused safely. Formally, it treats Memory Objects as database objects with identity, source evidence, validity periods, permissions, lifecycle state, and links to Claims, Facts, workflows, and audit records. For example, instead of storing only "Server X was installed," the system stores the source evidence, the accepted fact, the related memory, the time period when it was true, and the procedure that may have been learned from it. The proposed category is not defined by one storage primitive. It may use relational, document, graph, vector, temporal, workflow, and provenance mechanisms, but those mechanisms are organized around durable Memory Objects and DBMS-managed governance. The defining boundary is that Claims, Facts, Memory Objects, Episode Objects, workflows, Context Packages, and Skill Packages are not loose application records; they are governed database objects with identity, provenance, temporal validity, confidence, precision, security policy, lifecycle state, and audit records. This matters because institutional memory must survive model changes, schema evolution, personnel turnover, and shifts in operational tooling. A Memory DBMS must preserve evidence and derivation paths so that future extraction models, embedding models, workflow-mining tools, and AI agents can reinterpret or rebuild derived artifacts without losing traceability to the original source material. The system supports both retrospective memory formation and active use. It ingests historical sources, continuously receives new sources and observations, lets humans and AI agents retrieve governed context, and allows validated patterns of work to become reusable procedural knowledge. The minimum viable capability table below defines what must be present before a system belongs in this category. It is not a full implementation roadmap. The first group names the memory objects and derivation structures; the second group names the governance, context, and operational behaviors that make those objects usable over time. **Minimum Viable Memory DBMS Capabilities: Core Objects and Derivation** | Capability | Minimum requirement | |---|---| | Source Packages | Keep source evidence, metadata, trust labels, retention state, and source links. | | Claims | Store what a source says before it is accepted as true. | | Facts | Store accepted assertions with scope, evidence, confidence, precision, and validity windows. | | Memory Objects | Keep the institutional meaning around Claims, Facts, sources, and relationships. | | Episode Objects | Record concrete events with participants, time, evidence, Semantic Frame data, and lifecycle state. | | Memory Detail Objects | Store reusable steps, parameters, decisions, checks, exceptions, and evidence. | | Derivation Ledger | Record how sources become Claims, Facts, Memory Objects, workflows, summaries, embeddings, and Skill Packages. | | Relationship Edges | Link objects with typed relationships such as supports, contradicts, supersedes, derived_from, depends_on, and part_of. | | Workflow Traces | Capture observed steps, actors, tools, inputs, outputs, evidence, and exceptions from specific episodes. | | Procedural Memory Objects | Store reusable how-to knowledge with preconditions, steps, checks, exceptions, and supporting evidence. | | Skill Packages | Package approved procedural knowledge for human or AI use with policy, validation, and audit controls. | These object types establish the vocabulary of the DBMS. They let the architecture distinguish source evidence from interpretation, accepted Facts from contextual memories, and observed work from reusable procedural knowledge. Many of the elements of the list are never visible to AI engineers or end-users, but they are critical to the design and implementation of the proposed system. **Minimum Viable Memory DBMS Capabilities: Governance, Context, and Operations** To be a viable memory DBMS, the system requires a minimum level of capabilites that cover time validity, confidence and precision, security, and memory / context sharing. The table below shows the minimum requirement for each necessary capability. | Capability | Minimum requirement | |---|---| | Bitemporal validity | Track both when something was true and when the database recorded it. | | Confidence and precision metadata | Store scores, policy versions, calibration state, and evidence basis. | | Security-aware retrieval | Apply permissions, partitions, validity, evidence, and lifecycle controls during retrieval. | | Active Memory Pools | Provide task-scoped working memory for humans, agents, tools, observations, and pending Claims. | | Context Packages | Assemble compact, permission-filtered context for AI use while preserving source links. | | Governed model/tool access | Manage model calls, tool definitions, protocol adapters, validation, permissions, and audit records. | | Backup, recovery, and rebuild of derived artifacts | Preserve durable sources and metadata so summaries, embeddings, indexes, and workflows can be rebuilt. | The second group prevents the object model from becoming a passive catalog. A Memory DBMS must govern when memories are valid, who may retrieve them, how they become usable context, and how derived artifacts can be rebuilt without losing source evidence. ![Figure 1: Memory Object Lifecycle](Figure-1.pdf) *Figure 1: Memory Object Lifecycle: Source → Claim → Fact → Memory → Workflow → Skill.* ![Figure 2: Memory DBMS Reference Architecture](Figure-2.pdf) *Figure 2: Memory DBMS Reference Architecture.* The system ingests and reconciles material from many sources, including documents, conversations, tickets, logs, databases, and time-series data. To keep that material useful over time, it maintains indexes, Relationship Edges, provenance records, confidence, precision, validity state, and lifecycle state. The principal objectives are concise. First, define native data structures for the full memory lifecycle from sources and Claims to Facts, Memory Objects, workflows, Procedural Memory Objects, and Skill Packages. Second, support both retrospective and continuous memory formation from legacy artifacts and active work. Third, make AI-dependent artifacts modular, versioned, reevaluable, and replaceable without losing source evidence or changing the core memory model. Fourth, expose stable extension points so application developers can add connectors, Skill Packages, and tool definitions while staying inside the same catalog, permission, provenance, validation, and audit framework. This paper does not prescribe a single vendor, foundation model, embedding model, retrieval algorithm, or cloud provider as the implementation choice. It also does not propose a vector-only architecture or treat AI-generated outputs as authoritative truth without evidence, policy, verification, and auditability. The Memory DBMS uses AI and vector retrieval as components, not as substitutes for provenance, temporal reasoning, access control, and human judgment. The proposed system is also not intended to replace authoritative source systems such as email platforms, ticketing systems, source control, observability systems, or transactional databases. Those systems remain sources of record for their own domains; the Memory DBMS preserves, links, interprets, and recalls institutional knowledge derived from them. The initial design also does not attempt to solve full high-availability clustering, active-active replication, or every form of distributed failover. Those capabilities may be added later, but they are intentionally out of scope while the core memory, provenance, retrieval, and model-maintenance architecture is being defined. Finally, the system is not intended to preserve every transient message, intermediate thought, or temporary artifact as durable institutional memory without curation, validation, and lifecycle policy. Nor does the paper assume that all institutional reasoning can or should be automated. Human judgment, organizational governance, verification, and policy remain necessary parts of the architecture. With the system boundary established, the next section defines the core object model. # 3. Core Object Model ## 3.0 Running Example: Server Installation Memory This section uses one running example throughout the object model. The example begins with an email saying, "I am installing the server today." By itself, that email is not enough to prove that the server was installed. Later evidence, including a ticket closure, a log entry, meeting notes, and a migration document, can strengthen the evidentiary chain and allow the DBMS to derive Facts, Memory Objects, workflow knowledge, and task-ready context. That single example is traced across the major object types. It is a derivation path, not a claim that every source will always produce every object. | Object type | Example content | What the DBMS stores | Why it matters | |---|---|---|---| | Source Package | Email: "I am installing the server today"; ticket closure; server log showing the server online at 12:34 PM; meeting notes; later migration document | Verbatim source where permitted, source metadata, authorship or system identity, timestamps, trust label, retention state, and source links | Preserves inspectable evidence and allows later reprocessing with improved extraction models or policies. | | Claim | "The sender stated an intention or expectation to install the server on that day." | Extracted assertion, source span, extraction run, confidence, precision, actor, source time, and review state | Prevents an intention in an email from being prematurely accepted as an operational Fact. | | Fact | "Server X was installed on March 12, 2019." | Accepted assertion, supporting Claims, ticket and log evidence, valid-time window, transaction-time record, verification state, confidence, and precision | Gives the organization an evidence-backed assertion with explicit scope and auditability. | | Memory Object | "Server X was installed in March 2019 as part of the Project Y production migration." | Contextual memory summary, linked Facts and Claims, purpose, outcome, confidence, precision, temporal validity, and source links | Explains why the event mattered rather than only recording that it occurred. | | Episode Object | The specific server-installation episode for Server X | Episode identity, actors, systems, Semantic Frame, event time, Relationship Edges, lifecycle state, evidence links, and Derivation Ledger links | Creates a governed, replayable unit for inspection, retrieval, and later workflow extraction. | | Memory Detail Object | Steps such as selecting the host, configuring networking, installing dependencies, validating connectivity, and documenting the environment | Addressable steps, substeps, parameters, commands, checks, exceptions, ordering, evidence links, and reusable detail identifiers | Allows the DBMS to expand only the detail needed for troubleshooting, review, or Skill Package execution. | | Workflow Trace | The observed sequence followed during this installation | Ordered steps, actors, tools, inputs, outputs, evidence, exceptions, timestamps, and confidence | Turns one episode into a source-backed execution trace rather than an informal narrative. | | Generalized Workflow | A candidate production-server installation pattern derived from multiple similar traces | Common steps, variants, exception paths, supporting and contradicting traces, validation state, confidence, and precision | Lets repeated episodes contribute to reusable process knowledge without replacing the source episodes. | | Procedural Memory Object | How the organization installs, validates, and troubleshoots production servers | Preconditions, required inputs, ordered guidance, validation checks, exception handling, applicability conditions, and supporting workflows | Converts validated workflow knowledge into operational know-how for humans and AI agents. | | Skill Package | Governed package for guiding a production-server installation task | Procedural Memory Object links, execution policy, input and output contracts, security policy, model/tool requirements, validation checks, and audit rules | Packages reusable knowledge for controlled use while preserving provenance and policy. | | Active Memory Pool | Deployment task pool for Project Y infrastructure work | Authorized Memory Objects, current Facts, relevant workflows, Skill Packages, pending observations, pool members, and audit log | Gives humans and agents a shared, permission-filtered working context for the current task. | | Agent Retrieval Package | Response to "What should I know before installing this server?" | Selected Facts, Memory Objects, workflow steps, Skill Package references, evidence links, confidence, precision, validity state, and filtered objects | Provides task-ready context without hiding the evidence, permissions, or freshness checks behind the answer. | The important movement is from evidence to governed use. Each later object depends on preserving the source basis, review state, relationships, and policy controls behind it, which is why a Memory DBMS needs more than a stored summary. A native database management system for long-term institutional memory must distinguish between **Facts**, **Claims**, **evidence**, **Memory Objects**, and **context**. These concepts are closely related, but they are not interchangeable (Walsh & Ungson, 1991; Stein & Zwass, 1995). A conventional database may store records as discrete values, rows, documents, or objects. A database of memories must also preserve how knowledge became known, when it was true, and how reliable it is. It must provide a clear path to becoming usable context for humans and AI agents. This distinction is essential because institutional knowledge is often derived from imperfect sources. Emails, meeting notes, chat messages, tickets, documents, system logs, and human recollections may each contain useful information, but they do not all carry the same evidentiary weight (Argote & Ingram, 2000; Buneman et al., 2001; Ko et al., 2007; Moreau & Missier, 2013). A message may state an intention, a ticket may indicate completion, a log may record an event, and a later document may reinterpret the significance of that event. A database of memories must therefore avoid treating every extracted statement as a Fact. Instead, it must model the path from source material to Claim, from Claim to Fact, and from Fact to Memory Object (Buneman et al., 2001; Moreau & Missier, 2013). The subsections below define the core object types used by the proposed DBMS. This relationship may be summarized as follows: > Sources provide evidence. Evidence supports Claims. Claims may be verified into Facts. Facts and Claims may be organized into Memory Objects. Memory Objects can then be assembled into context. Context provides task-specific recall and operational guidance for humans and AI agents. ## 3.1 Source Package Many memories will not be entered directly by humans. They will be derived from existing information. A Memory DBMS must therefore support memory construction from documents, conversations, tickets, logs, databases, and other historical artifacts (Stein & Zwass, 1995; Buneman et al., 2001; Moreau & Missier, 2013). The system must preserve the original source artifact in verbatim form whenever policy, law, and retention constraints permit. A document, work order, ticket, transcript, or log capture must remain addressable as the authoritative Source Package from which later Claims, Facts, and Memory Objects can be derived. This allows every derived memory to be traced back to the exact source evidence that supported it. It also preserves the option to revisit the source later and extract information that was not considered during the first ingestion pass (Buneman et al., 2001; Moreau & Missier, 2013; Consultative Committee for Space Data Systems, 2024). Section 4.1 gives a derivation example using Source Packages. This core-level archive requirement corresponds to the Verbatim Source Archive introduced in Section 3.1. The archive keeps timestamped raw inputs available for later extraction, embedding, summarization, and workflow-mining passes when policy permits. ## 3.2 Claim Claims are necessary because most institutional knowledge begins as an assertion rather than as a verified Fact. A Claim preserves the original meaning of a source without prematurely converting that source into institutional truth. For example, an email may state: > "I am installing the server today." This statement must not immediately be stored as the Fact: > "The server was installed today." The email supports a more limited Claim: > "The sender stated an intention or expectation to install the server on that day." Additional evidence may later support a stronger Fact. A completed ticket, server log, configuration record, monitoring entry, or follow-up message may allow the system to derive: > "The server was installed on March 12, 2019." The distinction is important because a Claim may represent an intention, belief, or plan that may have never been implemented. Not all Claims become Facts. Some may remain unverified. Others may be contradicted. Others may be partially true but imprecise. Claims must therefore include explicit references to their sources. A Claim must be connected to one or more documents, messages, transcripts, logs, database records, or other evidentiary artifacts. These references must include enough detail for humans and AI agents to inspect the original basis for the Claim. Relevant details may include document identifiers, timestamps, authorship, page numbers, message identifiers, transcript offsets, or line numbers where applicable (Buneman et al., 2001; Cheney et al., 2009; Moreau & Missier, 2013). ## 3.3 Fact A Fact is an assertion that the system accepts as true within a defined scope. Facts are usually more atomic than Memory Objects. They may describe a specific event, property, Relationship Edge, status, measurement, identity, or timestamp. Examples include: - "Server X was installed on March 12, 2019." - "Alice was the project manager for Project Y." - "The production database was migrated from Server A to Server B." - "The customer approved the revised contract on July 8, 2024." - "Version 2.1.4 was deployed to production." However, Facts in an institutional memory system must not be treated as context-free truths. A Fact may be true only within a specific time period, project, department, system configuration, or operational context. For example, the Fact that Server X was the production server in 2019 may remain historically true, but it may no longer be operationally valid in 2026. Therefore, Facts must retain temporal scope, provenance, verification status, confidence, and precision (Kulkarni & Michels, 2012; Moreau & Missier, 2013). Newly derived Memory Objects may also force the system to reevaluate earlier Facts. For example, a Fact such as "On March 25, 2023, there were three A100 GPUs in the server room" may later be challenged by a newly derived Memory Object stating that all A100 GPUs were removed from the server room on March 24, 2023. In that case, the system must not silently overwrite the old Fact. It must recognize a contradiction, inspect the source evidence and timeline, and determine whether the earlier Fact was wrong, whether the newer Memory Object was wrong, or whether the validity window of one or both objects must be narrowed. In other cases, a later Memory Object may not contradict the earlier Fact but may instead supersede it by showing that a once-true Fact later became invalid for current use. A Fact in the Memory DBMS answers several questions: - What is being asserted? - When was the assertion true? - How confident is the system that it is true? - Was it verified, and if so when? - What evidence supports the assertion? - Has it been contradicted, superseded, or made stale? This allows the system to distinguish between a Fact that is historically accurate and a Fact that is currently actionable. ## 3.4 Memory Object A Memory Object is broader than a Fact. It captures an assertion and its institutional meaning. Memory Objects are contextual, temporal, relational, and often narrative. They represent categories of institutional knowledge that matter over time, including (Walsh & Ungson, 1991; Stein & Zwass, 1995; Hogan et al., 2021): - Events and incidents; - Decisions and discoveries; - Assumptions, preferences, and warnings; - Lessons learned and procedural knowledge; - Dependencies and changes that affect future work. For example, the Fact: > "Server X was installed on March 12, 2019." may contribute to a Memory Object such as: > "Server X was installed in March 2019 as part of the organization's migration from shared hosting to a dedicated application environment. The installation was performed to support Project Y, and later became the basis for the production deployment architecture used by the team." The Fact identifies what happened. The Memory Object explains why it mattered, how it related to other activities, and how future users or AI agents may need to interpret it (Walsh & Ungson, 1991; Stein & Zwass, 1995). Memory Objects often combine multiple Facts and Claims. A memory may be derived from emails, chat conversations, tickets, meeting notes, source code commits, database records, and operational logs. It may also include Relationship Edges to people, teams, projects, systems, decisions, documents, and later outcomes. For this reason, the proposed architecture treats Memory Objects as first-class database objects rather than text summaries or vector embeddings (Walsh & Ungson, 1991; Stein & Zwass, 1995; Hogan et al., 2021). The paper maps common memory-theory terms to DBMS terms in Appendix A. That mapping preserves compatibility with AI-memory and cognitive-science terminology while keeping the database object model concrete and operational (Baddeley, 1992; Cohen & Squire, 1980; Tulving, 2002; Squire, 2004; Park et al., 2023; Packer et al., 2023). A Memory Object may describe a specific Episode Object or episodic memory, such as a server installation, outage, deployment, meeting, migration, or customer interaction. It may also preserve the context around a decision, including why a technology, vendor, design, or policy was selected. It may record a discovery such as a defect, risk, performance issue, or business insight. Some Memory Objects capture how a task is performed, adapted, validated, or repaired. Others preserve lessons learned, assumptions that guided prior work, and Relationship Edges among systems or organizational participants. Memories act on a timeline. They may describe what happened in the past, what was believed at a particular time, what changed later, and what remains valid now. This makes the temporal model of a Memory DBMS central to its design (Kulkarni & Michels, 2012). ## 3.5 Episode Object An **Episode Object** is the concrete DBMS representation of a specific remembered episode. It is a governed Memory Object, not a text summary, log entry, or embedding. It binds source evidence, extracted structure, temporal scope, Relationship Edges, security labels, and lifecycle state into an auditable unit. At minimum, an Episode Object requires a stable identity, a version history, and enough typed structure to explain what kind of episode it represents. Its primary fields identify the episode type, the subject anchors, and the normalized action class. Episode types may include an installation, outage, decision meeting, migration, approval, incident, or customer interaction. Subject anchors identify the people, systems, assets, projects, teams, customers, or organizations involved. The object also contains a structured representation of a situation, event, object, or concept, including the participants and Relationship Edges needed to understand it. Using the Semantic Frame terminology in Appendix A, this structure holds fields for purpose, rationale, outcome, constraints, environment, and other frame details. The Episode Object also requires a target or payload that identifies the affected systems, documents, services, artifacts, or remembered objects. Participants and agents are represented explicitly so the system can distinguish humans, AI agents, services, vendors, approvers, verifiers, tools, and organizational teams. The same object binds the episode to evidence, time, governance, and lifecycle state. Evidence links point to verbatim Source Packages, documents, logs, tickets, transcripts, records, or API payloads. Construction links point to the Claims and accepted Facts used to create or revise the episode. Relationship Edges connect the episode to supporting, contradicting, superseding, causal, dependency, containment, and general related objects. When procedural information is available, the Episode Object links to Workflow Traces containing observed steps, commands, approvals, checks, exceptions, and outcomes. Temporal fields must distinguish event time, source time, valid-time windows, transaction-time windows, verification time, and stale-after rules. Governance fields must include confidence, precision, salience, lifecycle state, security labels, partition membership, and subject or topic access constraints. A Derivation Ledger records how the episode was produced, revised, replayed, promoted, superseded, archived, or retired. ![Figure 3: Episode Object Schema](Figure-3.pdf) *Figure 3: Episode Object Schema.* Replay semantics define how the DBMS reconstructs an episode for inspection, audit, retrieval, or reprocessing. A replay does not mean reproducing the original world event. It means reconstructing a time-aware view of the episode from the evidence and derivation records available to the DBMS. An episode replay can answer at least four questions: - What did the DBMS believe at a prior transaction time? - What happened according to the current accepted view? - What later sources or memories changed the interpretation? - What evidence supports that view? To do this, the replay operation loads the Episode Object data under the requesting account's privileges. The result identifies which Source Packages were inspected and whether the replay is historical, current-valid, transaction-time, or full bitemporal. The replay model preserves future options. If better extraction, summarization, causal analysis, or embedding models become available, the DBMS can replay selected episodes from their original evidence and Derivation Ledger without losing the historical record of how earlier interpretations were produced. ## 3.6 Memory Detail Object Not every useful memory exists at the same level of granularity. A memory such as "installed an Ubuntu 24.04 server on Proxmox" may be useful as a concise historical statement. It may also contain specific operational details that may provide instructions for performing a task. Each operational detail may contain URLs, commands, configuration choices, tool versions, screenshots, log excerpts, approvals, validation checks, and exceptions. The DBMS must therefore support **Memory Detail Objects** as addressable child or linked objects beneath a memory, Episode Object, Workflow Trace, Procedural Memory Object, or Skill Package. A Memory Detail Object may represent a step, substep, parameter, command, or configuration value. It may also represent decision points, validation checks, and potential exceptions or warnings. It must not be stored only as paragraph text inside the parent memory, because humans and AI agents may need to retrieve, inspect, cite, reorder, reuse, or validate the detail independently. This leads to the concept of **recursive detail**. A Memory Detail Object can contain or link to additional Memory Detail Objects, allowing the DBMS to expand a memory only to the level required by the task. A broad historical question may need only the parent memory. A troubleshooting question may need the relevant step and its exception history. Skill Package execution may need the complete ordered procedure, including commands, parameters, validation checks, fallback paths, and source evidence. For example: ```text Episode Object: installed Ubuntu 24.04 server on Proxmox Detail: downloaded Ubuntu Server ISO Detail: source URL Detail: checksum or signature verification Detail: selected release and architecture Detail: uploaded ISO to Proxmox Detail: target storage location Detail: upload method Detail: created new virtual machine Detail: CPU, memory, disk, and firmware settings Detail: network bridge and VLAN settings Detail: boot order and installation media ``` This structure uses document-database ideas because each memory may contain nested, richly described detail. It also requires graph-database behavior because a detail can be reusable across memories, workflows, Skill Packages, subjects, and projects. The detail "uploaded ISO to Proxmox" might appear in Ubuntu installations, Debian installations, disaster-recovery drills, VM migration workflows, and troubleshooting memories. It is represented as an addressable object with Relationship Edges rather than only as a nested string. ## 3.7 Workflow Trace A **Workflow Trace** records the observed sequence of actions in one Episode Object or case. It preserves the steps, actors, tools, inputs, outputs, evidence, confidence, and exceptions that produced a specific outcome (Cohen & Squire, 1980; Squire, 2004; van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). Many institutional memories describe completed events that resulted from a sequence of actions. If the memory is sufficiently detailed, the system can link the event to the step-by-step Workflow Trace that produced it (van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). Workflow Traces are built from addressable Memory Detail Objects rather than only from narrative text. A top-level Episode Object may say that an Ubuntu 24.04 server was installed on Proxmox. Its recursive details can record how the ISO was obtained, where it was uploaded, how the virtual machine was configured, which commands were run, which validation checks passed, and which exceptions occurred. This allows the same memory to support multiple uses: concise historical recall, detailed troubleshooting, Generalized Workflow extraction, and Skill Package execution. The DBMS can expand the trace only as far as the task requires, rather than forcing every user or agent to retrieve the entire procedural tree every time. ## 3.8 Generalized Workflow A **Generalized Workflow** is a repeatable process pattern derived from multiple Workflow Traces or validated examples. A Memory DBMS therefore derives candidate Workflow Traces from individual memories. Across many similar memories, it consolidates Generalized Workflows and forms Procedural Memory Objects that preserve reusable know-how without discarding context (Cohen & Squire, 1980; van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). The resulting workflow must not replace the original Memory Objects. Instead, it is stored as a derived knowledge object linked back to the source Memory Objects, Facts, Claims, and evidence from which it was constructed. This preserves provenance and allows future humans or AI agents to inspect why the workflow exists, which cases support it, which cases contradict it, and under what conditions it applies (Buneman et al., 2001; Moreau & Missier, 2013). ## 3.9 Procedural Memory Object A **Procedural Memory Object** is capability-oriented how-to knowledge for performing, adapting, validating, and repairing work. It is not itself a workflow: a workflow can support a Procedural Memory Object, but it does not exhaust the prerequisites, judgment points, exceptions, validation checks, tool choices, safety constraints, and recovery tactics needed for reuse. When a Generalized Workflow has sufficient evidence, successful outcomes, and current operational validity, it may contribute to a Procedural Memory Object. A Procedural Memory Object describes what the capability is intended to accomplish, when it applies, what must be true before execution begins, and which inputs, credentials, tools, or resources are required. It connects to related standard, variant, and fallback workflows. It also preserves ordered steps, recursive detail objects, decision points, validation checks, expected outputs, known exceptions, recovery tactics, supporting memories, and staleness indicators. AI agents need these distinctions. An agent retrieves a memory to answer a historical question, a workflow to understand a process pattern, and a Procedural Memory Object or Skill Package to perform a current task. A high-confidence, high-precision Procedural Memory Object reduces extra calls to the Memory DBMS or external sources because the Skill Package already packages purpose, preconditions, steps, validation checks, exception guidance, supporting memories, and current-applicability constraints. Lower-confidence or lower-precision Procedural Memory Objects trigger more retrieval, recursive-detail expansion, edge-case review, authorized external lookup, or human review before action. For example, an AI infrastructure agent asked to install a new server may use the server installation Procedural Memory Object or Skill Package as its primary guide. If it encounters an unusual network configuration, it may retrieve prior memories involving similar network exceptions. In this way, memories support both routine execution and edge-case reasoning. ## 3.10 Skill Package A **Skill Package** is a governed package of Procedural Memory Objects, workflows, evidence, and execution policy that can guide humans or AI agents through a repeatable task while preserving the provenance of the events, traces, and workflows from which it was learned. A **competency** is a broader organizational capability composed of related Skill Packages, Procedural Memory Objects, validation records, and supporting evidence. Skill Packages and competencies have concrete schema and runtime behavior. They are usable by humans and AI agents, and their creation must remain traceable to the memories, Workflow Traces, Generalized Workflows, and Procedural Memory Objects from which they were derived. The next section explains how these objects preserve lineage, uncertainty, validity, and change over time. # 4. Provenance, Confidence, Precision, and Temporal Validity The object model only becomes useful if the DBMS can explain where each object came from, how reliable it is, when it applies, and how it changes. This section moves from object definitions to the controls that make those objects trustworthy over time. **Memory DBMS Derivation Concepts and Provenance Concepts** This mapping connects the paper's memory-specific objects to familiar provenance concepts. It helps clarify that the Memory DBMS is not only storing objects; it is also storing the activities, actors, revisions, and supersession relationships that make those objects auditable. | Memory DBMS concept | Provenance-style concept | Example in this paper | Why it matters | |---|---|---|---| | Source Package | Entity | Email, ticket closure, log entry, meeting note, or migration document | Preserves the evidence from which later objects are derived. | | Extraction Run | Activity | Claim extraction from a server-installation email | Makes the derivation step inspectable and repeatable. | | Parser / Model / Human Reviewer | Agent | Parser, approved model, or reviewer that created or accepted a Claim | Records attribution and accountability for derived objects. | | Claim | Entity produced by an activity | "The sender stated an intention or expectation to install the server." | Separates source assertions from accepted institutional Facts. | | Fact | Entity derived from Claims and evidence | "Server X was installed on March 12, 2019." | Records accepted assertions with evidence, scope, and temporal validity. | | Memory Object | Entity derived from Facts, Claims, and sources | Memory explaining the Project Y production migration context | Preserves institutional meaning without severing source links. | | Episode Object | Entity derived from memory and event evidence | The specific Server X installation episode | Gives the DBMS a governed unit for replay, retrieval, and workflow extraction. | | Workflow Trace | Entity derived from an Episode Object and details | Observed production-server installation steps | Links reusable process knowledge back to a specific execution instance. | | Generalized Workflow | Entity derived from multiple traces | Candidate production-server installation workflow | Shows which cases support, contradict, or constrain a reusable pattern. | | Skill Package | Entity derived from validated procedural objects and workflows | Governed production-server installation guidance | Keeps executable or guided task knowledge tied to evidence and approval. | | Revision / Supersession | Revision, invalidation, or derivation relationship | Later migration document narrowing the valid window of an older memory | Preserves history while making current-valid knowledge explicit. | This framing treats provenance as part of the database model rather than as documentation outside the system. Each later section builds on this requirement: confidence, precision, temporal validity, and retrieval all depend on being able to inspect the chain from source evidence to derived use. ## 4.1 Derivation Ledger Using Source Packages, Claims, Facts, and Memory Objects as defined in Section 3, the DBMS must support memory construction from historical artifacts. Those artifacts may include documents, conversations, tickets, logs, databases, and other sources, but the DBMS must preserve evidence and provenance throughout the process (Stein & Zwass, 1995; Buneman et al., 2001; Moreau & Missier, 2013; Consultative Committee for Space Data Systems, 2024). The Derivation Ledger defined in Appendix A records this chain by linking Source Packages to extracted Claims, accepted Facts, Episode Objects, Generalized Workflows, and Skill Packages. The derivation of Procedural Memory Objects, embeddings, summaries, and model-generated artifacts may also be contained in Derivation Ledger entries. It must record which parser, model, prompt template, or human action created or revised each derived object. This prevents derivation from becoming invisible application logic and gives the DBMS a durable way to replay, audit, or regenerate Memory Objects as models and schemas change. In practice, derivation does not need to rely on one model type or one extraction strategy. During different stages of the derivation process, deterministic parsers, extractors, embedding models, LLMs, and custom domain models may all participate. Stable fields such as dates, identifiers, work-order numbers, and inventory counts may be extracted or validated deterministically. Other documentation such as free-text descriptions may benefit from model-assisted extraction, classification, or summarization. All such model-generated outputs must remain provisional until they are linked to source evidence and, where necessary, verified by policy or human review. Implementation may use ingestion pipelines, document parsers, and structured data formats to load source material before memory derivation begins. These tools are implementation aids rather than substitutes for the DBMS Derivation Ledger, provenance model, and review workflow (Apache NiFi, n.d.; Apache Avro, n.d.; Unstructured, n.d.). The running example in Section 3.0 shows how an email, ticket closure, log entry, meeting note, and later migration document can produce Claims, Facts, a Memory Object, an Episode Object, a Workflow Trace, a Generalized Workflow, and a Skill Package. The important derivation rule is that each generated object must retain links to the Claims, Facts, Source Packages, and review or model activity that produced it. Directly supported details, such as a timestamp from a log entry, must remain distinguishable from inferred context, such as a project purpose drawn from meeting notes and a later migration document. A second example is a work order or installation report confirming that a server installation was completed. The source document may contain several distinct assertions that can be separated and preserved individually. From one verbatim work order, the system might derive Facts or strongly supported Claims such as: - "The server was installed on March 24, 2014." - "The server was installed by ACME Installations." - "The server was installed by John Smith." - "Mary Jones verified and approved the installation." Those same Facts may later contribute to one or more Memory Objects, such as: - "The organization used ACME Installations to complete the March 24, 2014 server deployment." - "The installation required formal verification and approval before the server was accepted into service." Not all Claims, Facts, or Memory Objects need to be derived at the moment the source first enters the system. An organization may initially extract only the date and completion status, then return later to the same verbatim work order to derive contractor involvement, individual responsibility, approval history, workflow steps, or compliance-relevant context when those details become operationally important. This deferred derivation model is one reason raw source preservation matters: it allows the system to deepen its understanding of past evidence without losing traceability to the original document (Consultative Committee for Space Data Systems, 2024; Sculley et al., 2015). This same deferred model also allows the DBMS to reopen earlier conclusions. A newly derived Memory Object may reveal that an earlier Fact must be contradicted, superseded, or given a narrower validity window. If later interpretation shows that hardware was taken out of service, the system must reevaluate the affected Facts rather than leave them marked as current. This derivation path is critical. Without it, a memory becomes an unsupported summary. With it, the memory becomes inspectable, verifiable, correctable, expandable, and reusable by both humans and AI agents (Buneman et al., 2001; Cheney et al., 2009; Moreau & Missier, 2013). ## 4.2 Confidence and Precision ### Confidence as Policy-Governed Metadata Confidence scores are treated as policy-governed metadata, not as universal truth probabilities. A score may be meaningful only when the DBMS records the conditions that give it context: - Object type. - Source class. - Policy version. - Evaluator. - Model version. - Calibration dataset. - Verification process. Unless those conditions are recorded and calibrated, the score is best interpreted as an operational signal for review, ranking, filtering, or promotion rather than as mathematically objective truth. These metadata fields identify what must travel with a confidence score for that score to remain interpretable. They answer a practical governance question: what does the DBMS need to preserve so that a future user can inspect, calibrate, or challenge the score? | Metadata item | Purpose | |---|---| | Raw component scores | Preserves extraction, source, evidence, truth, verification, and other component values before aggregation. | | Aggregate score | Stores the policy-computed score used for ranking, filtering, or promotion. | | Weights | Shows how component scores contributed to the aggregate score. | | Policy version | Identifies the governance policy under which the score was computed. | | Evaluator | Records whether the score came from a parser, model, rule, human reviewer, or mixed process. | | Model version | Links model-derived scores to the exact model or configuration used. | | Calibration dataset version | Identifies the reviewed dataset used to align scores with observed reliability. | | Last calibration date | Shows when score behavior was last checked. | | Source class | Distinguishes email, ticket, log, signed document, system-of-record data, and other evidence classes. | | Object type | Indicates whether the score applies to a Claim, Fact, Memory Object, Workflow Trace, Skill Package, or other object. | These fields make confidence auditable rather than decorative. A score without policy version, evaluator, source class, calibration context, and object type cannot reliably support ranking, automation, or promotion. ### Why Confidence and Precision Are Separate Both Facts and Memory Objects must include measures of **confidence** and **precision**, but these measures are modeled separately. A statement may be highly precise but poorly supported, or well supported but imprecise. Precision must not be confused with accuracy. Accuracy concerns whether a statement is correct. Precision concerns how specific the statement is. Confidence concerns how strongly the system believes the statement is reliable based on available evidence. Confidence and precision are also internal data items that can participate directly in queries, ranking, filtering, and context assembly. A human or AI agent can ask not only for relevant Memory Objects, but for Memory Objects that meet a required confidence level, precision level, verification state, or evidence threshold. For example, an agent might ask: "Give me instructions for installing the server power supply, starting with instructions with the highest confidence." In that case, the DBMS can rank Procedural Memory Objects, Workflow Traces, source-backed instructions, and related Facts by confidence while still preserving links to the evidence that supports them. For example: > "The server was installed in 2019." This statement may have high confidence but low temporal precision. > "The server was installed on March 12, 2019 at 12:30 PM." This statement has higher temporal precision, but it is not necessarily more accurate. If the only source is an email saying "I am installing the server today," then the exact time of 12:30 PM may have low confidence. Stronger evidence, such as a log entry or ticket timestamp, would be needed to support that level of precision. Therefore, a Memory DBMS must model at least two separate dimensions: 1. **Confidence** --- how reliable the system believes the Fact or Memory Object is. 2. **Precision** --- how specific the Fact or Memory Object is. A useful principle is: > A Fact or Memory Object may be precise without being reliable, reliable without being precise, historically true without being currently valid, and confidently extracted without being fully verified. ### Fact Confidence The confidence of a Fact represents the degree to which the system accepts the assertion as true. Fact confidence may depend on several factors: - The number of supporting sources. - The reliability of those sources. - The consistency of the evidence. - The presence or absence of contradictory evidence. - The verification rules of the system. For example, a Fact derived from a single informal chat message may have lower confidence than a Fact supported by a ticket closure, a server log, a signed document, and a follow-up confirmation. Likewise, a Fact extracted from a clear source statement may have higher extraction confidence than one inferred from vague or ambiguous language. The proposed confidence methodology uses a weighted scoring model based on **Multi-Attribute Utility Theory (MAUT)**, which allows several independently evaluated attributes to contribute to a single normalized utility score (Keeney & Raiffa, 1976). In this model, Fact confidence is represented as a score between 0 and 1. Each contributing category is also scored between 0 and 1 and assigned a policy-controlled weight. The five core categories are extraction, source, evidence, truth, and verification. The total Fact-confidence score can be expressed as: ```text C_fact = (w_extraction * C_extraction) + (w_source * C_source) + (w_evidence * C_evidence) + (w_truth * C_truth) + (w_verification * C_verification) ``` where each category score is normalized between 0 and 1, each weight is greater than or equal to zero, and all weights sum to 1. Extraction confidence measures how reliably the system extracted the assertion from the source. Source confidence measures the reliability, authority, and governance status of the source. Evidence confidence measures the strength, quantity, independence, and consistency of supporting evidence. Truth confidence measures the likelihood that the assertion is actually true after considering contradictions, temporal context, known facts, and domain rules. Verification confidence measures whether the assertion has been confirmed by authoritative systems, independent sources, policy rules, or human review. Weights are configurable by schema, partition, source class, Fact type, and organizational policy. A security event, financial approval, production incident, or informal project note may require different weighting. For example, regulated workflows may place greater weight on verification confidence. Operational troubleshooting may place greater weight on evidence confidence. Records from an authoritative system may place greater weight on source confidence. The DBMS must store both the final score and the materials behind it. Those materials include category scores, weights, evaluators, model versions, policy versions, and supporting evidence. This makes confidence auditable rather than opaque. This separation matters because a Fact may be clearly extracted from a source while still being uncertain as a statement about reality. The system may be highly confident that an email says "I installed the server today," but less confident that the server was actually installed unless corroborating evidence exists. A MAUT-style scoring model makes that distinction explicit: high extraction confidence does not automatically imply high truth confidence or high verification confidence. ### Fact Precision The precision of a Fact represents the specificity of the assertion. Precision may apply to time, entity identity, location, measurement, Relationship Edge, and semantic meaning. Fact precision can also be scored using a MAUT-style weighted model. In this context, the score does not measure whether the assertion is true; it measures how specific the assertion is across the dimensions that matter for retrieval, reasoning, and operational reuse. A Fact such as "the server was installed in 2019" has low temporal precision, while "the installation completed on March 12, 2019 at 12:34:17 PM CST" has high temporal precision. Similarly, "a server" has lower entity precision than "Server X with hostname app-prod-01," and "related to Project Y" has lower Relationship Edge precision than "installed specifically to host Project Y's production application." The total Fact-precision score can be expressed as: ```text P_fact = (w_temporal * P_temporal) + (w_entity * P_entity) + (w_relationship * P_relationship) + (w_location * P_location) + (w_semantic * P_semantic) + (w_scope * P_scope) ``` where each precision score is normalized between 0 and 1, each weight is greater than or equal to zero, and all weights sum to 1. Temporal precision measures how exact the time reference is. Entity precision measures how specifically the subject or object is identified. Relationship Edge precision measures how clearly the Fact defines the connection between entities. Location precision measures the specificity of physical, logical, or organizational location. Semantic precision measures how clearly the action or state is described. Scope precision measures how narrowly the Fact identifies the affected system, team, project, customer, environment, or use case. Weights are configurable by Fact type, schema, partition, and query context. A compliance Fact may require high temporal and scope precision, while an architectural lesson may rely more heavily on semantic and Relationship Edge precision. The DBMS must store the aggregate precision score, the category-level precision scores, and categorical labels. Those labels may include: - Year-level precision. - Date-level precision. - Hostname-level precision. - Rack-level precision. - Project-level precision. - Environment-level precision. A Fact can therefore carry both confidence and precision as separate MAUT-derived values. For example, the system may store a confidence score of 0.82 while also recording a Fact-precision score of 0.74, with temporal precision at date-level and entity precision at hostname-level. ### Memory Object Confidence The confidence of a Memory Object represents its reliability as a contextual object. This is more complex than Fact confidence because Memory Objects are often derived from multiple Claims, Facts, sources, and interpretations. A Memory Object may have high confidence if it is supported by several verified Facts and consistent source materials. It may have lower confidence if it is based on incomplete evidence, inferred Relationship Edges, uncertain timelines, or ambiguous source language. For example: > "The team installed Server X in March 2019 to support Project Y's production migration." This memory contains several components: Server X was installed. The installation occurred in March 2019. It was related to Project Y, and its purpose was to support a production migration. The work was performed by or for a particular team. Each component may have its own confidence level. The server installation date may be strongly supported by logs, while the purpose of the installation may be inferred from meeting notes and emails. The memory as a whole therefore has an aggregate confidence score, but it also preserves confidence at the component level. Memory confidence uses a MAUT-style aggregate score that combines supporting-Fact confidence with contextual coherence. The score accounts for several factors: - Fact reliability. - Claim consistency. - Source diversity. - Inference confidence. - Timeline coherence. - Contradiction status. - Whether the Memory Object remains current or stale. The total memory-confidence score can be expressed as: ```text C_memory = (w_facts * C_supporting_facts) + (w_consistency * C_claim_consistency) + (w_diversity * C_source_diversity) + (w_inference * C_inference) + (w_temporal * C_temporal_coherence) + (w_contradiction * C_contradiction_status) + (w_staleness * C_staleness_status) ``` where each category score is normalized between 0 and 1, each weight is greater than or equal to zero, and all weights sum to 1. Supporting Fact confidence represents the weighted reliability of the Facts used to construct the Memory Object. Claim consistency measures whether the underlying Claims agree or conflict. Source diversity measures whether the Memory Object is supported by independent source classes rather than repeated copies of the same assertion. Inference confidence measures how reliable the derived connection is when the Memory Object includes meaning that was not directly stated. Temporal coherence measures whether the timeline of events is internally consistent. Contradiction status measures whether later evidence challenges the Memory Object. Staleness status measures whether the Memory Object remains operationally useful for current tasks. The weights vary by Memory Object type and use case. A safety-critical procedure may place high weight on contradiction and staleness status, while historical recall may place greater weight on supporting Fact confidence, temporal coherence, and source diversity. As with Fact confidence, the DBMS must preserve the category scores, weights, policy versions, source evidence, and model or human evaluators used to compute the aggregate value. This allows the Memory DBMS to distinguish between a strongly verified memory, a plausible but uncertain memory, a disputed memory, and a memory that was once useful but is now stale. ### Memory Object Precision The precision of a memory represents how specifically the memory describes the event, decision, discovery, or institutional context. A memory may be precise in some dimensions and imprecise in others. For example: "The infrastructure team installed a dedicated production server sometime in early 2019 because the shared hosting environment was no longer sufficient." This memory may have moderate confidence and low-to-moderate precision. It identifies the general event, actor, period, and reason, but lacks an exact date, server identifier, and supporting details. A more precise memory would be: "On March 12, 2019, the infrastructure team installed Server X as the dedicated production host for Project Y after deciding that the shared hosting environment could not support expected application load." This Memory Object is more precise because it identifies the date, actor, server, project, purpose, and decision context. Greater precision still does not automatically imply greater accuracy or confidence. The precision must be supported by evidence. Memory precision is therefore evaluated across several dimensions rather than treated as a single descriptive label: - Temporal precision describes how specifically the memory places events on a timeline. - Actor precision identifies how clearly the memory names the people, teams, systems, services, or AI agents involved. - Entity precision captures whether the remembered objects, systems, documents, or resources are identified generically or specifically. - Causal precision describes how clearly the memory explains why something happened. - Decision precision captures what was decided, by whom, and under what conditions. - Procedural precision describes how specifically the memory explains how work was performed. - Contextual precision describes how clearly the memory connects the event to projects, goals, constraints, risks, dependencies, or outcomes. AI agents need this distinction. An agent may not need a perfect historical narrative to complete a task, but it may need highly precise operational guidance. Conversely, a human reviewing an old project may need broader contextual recall even when some operational details are no longer valid. ## 4.3 Confidence Calibration and Auditing Confidence scores must be calibrated before they are used for ranking, automation, or high-risk decision support. A calibrated score of 0.80 means that comparable Facts or Memory Objects are reliable about 80 percent of the time under the relevant policy, source class, and object type. Without calibration, confidence values may look precise while still being poorly aligned with observed reliability. The DBMS must maintain calibration datasets made from human-reviewed Facts, authoritative-system confirmations, contradicted Claims, stale Memory Objects, and known historical outcomes. It reports calibration quality by source type, model version, Fact type, Memory Object type, partition, and workflow family. For model-derived confidence scores, temperature scaling can be used as a post-processing method when there is enough held-out verification data. Reliability diagrams and expected calibration error are reported so administrators can see whether confidence buckets are overconfident, underconfident, or well aligned with observed outcomes (Guo et al., 2017). Calibration must not erase the underlying MAUT component scores. Instead, the system must store the raw category scores, the aggregate score, the calibration model or policy used, the calibration-data version, and the date of last calibration. If later evidence shows that a source class, extraction model, or workflow family was systematically overconfident, the DBMS can flag affected Facts, Memory Objects, workflows, Skill Packages, and Active Memory Pools for review. ## 4.4 Bitemporal Validity, Staleness, and Supersession Unlike static records, Memory Objects may have a lifespan. Some Memory Objects remain useful indefinitely as historical knowledge. Others become stale when systems change, people leave, policies evolve, projects end, or newer Facts supersede older ones (Kulkarni & Michels, 2012). The lifecycle state of a Memory Object must therefore be explicit. A Memory Object may be **current** when it remains valid for present use, or **historical** when it is true as a record of the past but no longer safe to treat as current guidance. It may become **stale** when it is potentially outdated, **superseded** when a newer Memory Object, Fact, policy, or decision replaces it, or **contradicted** when later evidence challenges it. Some Memory Objects may be **consolidated** into a higher-level summary, workflow, Procedural Memory Object, or Skill Package. Others may become **decayed** when they are retained but assigned lower retrieval priority because they have not been reinforced. Older or lower-priority Memory Objects may follow one of several lifecycle paths: - **Archived** into lower-cost or lower-priority storage. - **Retired** from operational use while preserved for historical recall. - **Pruned** only when policy, legal holds, provenance requirements, and audit rules permit deletion. For example: "Server X is the production server." This memory may have been current in 2019. If production later moved to Server Z in 2022, the original memory remains historically meaningful but becomes stale or superseded as operational guidance. A Memory DBMS must therefore distinguish between: "What was true then?" and: "What is valid now?" This is one of the central requirements for human-AI knowledge sharing. AI agents must not simply retrieve the most semantically similar memory. They must retrieve memories with awareness of time, validity, confidence, precision, salience, and current applicability (Lewis et al., 2020; Liu et al., 2024; Packer et al., 2023). Long-lived memory systems also need lifecycle management that goes beyond staleness. A Memory Object may remain historically true while becoming less useful for routine recall. Other Memory Objects may be consolidated into a higher-level semantic summary, workflow, Procedural Memory Object, or Skill Package. The DBMS must therefore support salience decay, reinforcement, consolidation, archival movement, and policy-governed pruning as explicit lifecycle operations rather than allowing the corpus to accumulate forever with equal retrieval weight. Implementation packages can help prototype decay behavior, but production decay policy must remain governed by the DBMS (Park et al., 2023; Alqithami, 2025; GustyCube, n.d.). The temporal model must be formalized as a **bitemporal** model. That model separates when a Fact or Memory Object was valid in the real world from when the DBMS recorded, accepted, corrected, or retired that knowledge. This distinction matters because institutional memory is often discovered late, corrected after the fact, or reinterpreted when additional source evidence becomes available (Kulkarni & Michels, 2012). At minimum, governed Facts, Memory Objects, workflows, Procedural Memory Objects, and derived Claims must carry temporal fields with distinct meanings. The `event_time` records when the remembered event or source event occurred, if known. The valid-time fields, `valid_time_start` and `valid_time_end`, define the period during which the assertion, Memory Object, workflow, or Procedural Memory Object applies to the represented world. The transaction-time fields, `transaction_time_start` and `transaction_time_end`, define when the DBMS recorded, accepted, revised, or retired a specific version. The `source_time` preserves the timestamp supplied by the original source, such as an email, ticket, log, document, or API payload. The `verification_time` records when the system, policy, or human verifier accepted, rejected, or revised the object. Finally, `stale_after` identifies the time or condition after which the object requires review before operational use. This model allows the DBMS to answer different timing-related questions without confusing them. A valid-time query asks what was true or applicable for the represented world at a given time, such as "Which server was production on March 24, 2023?" A transaction-time query asks what the DBMS believed or had recorded at a given time, such as "What did the system know on April 1, 2023?" A bitemporal query combines both, such as "As recorded on April 1, 2023, what did the organization believe was true on March 24, 2023?" Corrections must not overwrite history. If a source later shows the GPUs were removed from the server room on March 24, 2023, the DBMS must close the valid-time window for the affected Fact. Any earlier Fact claiming that the A100 GPUs were present after that removal is no longer current-valid knowledge for dates after the removal event. The prior Fact remains transactionally visible as something the DBMS once recorded. This lets humans and AI agents distinguish "what happened," "what we believed at the time," and "what we now know was valid." Operationally, bitemporal retrieval exposes explicit query modes rather than relying on implicit interpretation. A query may request current valid knowledge, historical valid knowledge, knowledge as recorded at a transaction time, or a full bitemporal audit trail. These modes must apply consistently across exact lookup, semantic search, workflow retrieval, Active Memory Pool loading, and API access. Current-valid retrieval asks for objects that are valid now and safe for current use: ```pseudocode retrieve memories where subject = "Server X" and time_mode = current_valid and lifecycle_state not in ["stale", "superseded", "retired"] require evidence_links ``` Historical valid-time retrieval asks what was valid in the represented world at a specific time: ```pseudocode retrieve facts where subject = "Server X" and valid_time contains "2023-03-24" and include historical_versions = true ``` Transaction-time retrieval asks what the DBMS had recorded at a specific database time: ```pseudocode retrieve memories where subject = "Server X" as_recorded_at transaction_time "2023-04-01T09:00:00Z" include derivation_ledger_links ``` Full bitemporal audit retrieval combines both views: ```pseudocode retrieve audit_trail where subject = "Server X" and valid_time contains "2023-03-24" as_recorded_at transaction_time "2023-04-01T09:00:00Z" include source_packages, claims, facts, revisions, supersession_edges ``` The Temporal Supersession Engine, defined in Appendix A, is responsible for this behavior. It must apply valid-time and transaction-time rules whenever a Claim becomes a Fact, a Fact changes, a Memory Object is corrected, a workflow is replaced, or a Procedural Memory Object becomes unsafe to use. The engine must close validity windows, create Relationship Edges for supersession, preserve the prior transaction-time record, and update staleness status. It must also notify derived artifacts such as embeddings, workflow summaries, Active Memory Pools, and Skill Packages that they may need review or rebuild. The engine must never erase the prior state merely because a newer state is now preferred; it must make the supersession explicit and queryable. With provenance and temporal validity in place, the next section turns to organization and retrieval. # 5. Organization and Retrieval Retrieval planning appears before the detailed Semantic Frame discussion because organization matters only if it changes how recall happens. The DBMS must choose a governed path through subjects, time, evidence, workflows, and Relationship Edges before it expands into broader semantic search. **Security-Aware Retrieval Planning** ```pseudocode plan_retrieval(query, actor, optional_active_memory_pool): authenticate actor construct authorization_envelope from roles, grants, partitions, delegation_chain, and task context identify Active Memory Pool context if present classify query intent extract retrieval cues: subject action_class object time Relationship Edge evidence requirement confidence threshold precision threshold detail-depth requirement select initial retrieval path based on intent and cues apply partition and policy filters before candidate expansion retrieve candidates as needed using: structured indexes temporal indexes Relationship Edge traversal full-text search workflow and Skill Package lookup recursive detail expansion semantic search validate confidence, precision, freshness, lifecycle state, and permissions assemble retrieval package with source and evidence links audit query, selected path, returned objects, filtered objects, and model/tool calls used ``` This pseudocode is implementation-neutral. It shows the order of governance decisions rather than a required query language. The key point is that authorization, policy filtering, temporal validity, confidence, precision, and audit happen during retrieval planning, not only after final ranking. **Representative Retrieval Paths** The routing matrix turns the retrieval planner into concrete choices. It answers which path to attempt first for different query types, and what governance checks must stay attached as the search expands. | Query type | Primary route | Expansion route | Governance and result package | |---|---|---|---| | Specific historical recall | Subject, action class, and valid-time filters | Relationship Edges, source inspection, semantic recall | Actor authorization, temporal mode, evidence visibility, and lifecycle state; returns Episode Objects, Facts, Memory Objects, source links, and Derivation Ledger entries. | | Current-valid Fact lookup | Fact index and current-valid temporal filters | Supporting Claims, contradiction checks, source links | Valid-time window, transaction-time state, confidence threshold, and source permissions; returns a current Fact with confidence and precision metadata and evidence links. | | Evidence-backed explanation | Derivation Ledger and source links | Supporting and contradicting Relationship Edges, Source Package replay | Source authorization, provenance completeness, and redaction policy; returns an explanation package with Claims, Facts, source spans, and derivation path. | | Temporal/bitemporal query | Valid-time and transaction-time indexes | Supersession edges, archived versions, audit records | Historical access rights, archive policy, and audit scope; returns versioned Facts or Memory Objects with temporal windows and revision history. | | Workflow or Skill Package retrieval | Workflow Trace, Generalized Workflow, Procedural Memory Object, and Skill Package indexes | Recursive detail, validation records, similar episodes | Execution permission, review status, stale-after policy, and tool privileges; returns a workflow or Skill Package package with steps, preconditions, exceptions, and evidence. | | Causal or dependency query | Relationship Edge traversal | Claims, Facts, evidence, temporal ordering, counterevidence | Edge authorization, causal assertion review state, and source access; returns a Relationship Edge path with confidence, mechanism, and supporting evidence. | | Recursive detail expansion | Parent memory, Workflow Trace, or Skill Package detail links | Depth-limited child details, source spans, exception paths | Detail-depth policy, object permissions, and source visibility; returns a detail package with ordered steps, parameters, checks, and evidence. | | Broad exploratory search | Scoped semantic search after policy filters | Graph expansion, reranking, temporal filtering, source inspection | Partition filters, summary policy, and confidence/freshness thresholds; returns a ranked memory package with explicit uncertainty and filtered-result audit. | This view keeps semantic search in perspective. Vector retrieval is one expansion path among several, and every path remains bounded by authorization, validity, evidence, and lifecycle checks. The enterprise Memory DBMS must include native support for semantic search and vector embedding. Embedding and search components must remain interchangeable so the system can evolve as AI technologies improve. Structure-aware memory organization improves retrieval reliability regardless of which vector engine or embedding model is used. When practical, the system incorporates the subject, action class, Semantic Frame, target or memory payload, Relationship Edges, topic, temporal scope, and recursive detail path into both embedded chunks and query-time retrieval packages. This prompt-plus approach allows the DBMS to avoid treating natural-language prompts as opaque strings and reduces the need for low-precision global search (Lewis et al., 2020; Thakur et al., 2021; Khattab & Zaharia, 2020). The retrieval engine supports hybrid recall. It combines structured filters, full-text search, graph traversal, temporal constraints, workflow lookup, source inspection, recursive detail expansion, and vector search. A query such as "What should I know before installing this server?" may need current environment Facts, prior server installation Episode Objects, known edge cases, Generalized Workflows, Procedural Memory Objects, relevant Skill Packages, source evidence, and Active Memory Pool state. A Memory DBMS must return retrieval packages rather than only ranked text chunks. Those packages may include Memory Objects, Facts, source references, workflow steps, recursive detail depth, confidence scores, validity status, permissions, and evidence links. ## 5.1 Semantic Frames The Semantic Frame is a routing and indexing abstraction. It helps the DBMS organize memories by subject, action class, structured meaning, target, and Relationship Edges before selecting a retrieval path. It does not replace relational tables, graph structures, document storage, vector indexes, temporal records, or provenance ledgers. Instead, it provides a shared vocabulary that allows those representations to cooperate under one retrieval plan. The database must organize Memory Objects in a way that supports efficient retrieval, long-term maintenance, scalability, and parallelism across hardware resources. Institutional memory may contain millions or billions of Memory Objects, Facts, Claims, Relationship Edges, events, and other data points. If every query requires a global semantic search across all stored Memory Objects, the system becomes expensive, slow, and difficult to govern. A scalable Memory DBMS therefore requires an internal organizational structure that can compartmentalize resource-intensive operations and distribute work across resources (Walsh & Ungson, 1991; Argote & Ingram, 2000; Ko et al., 2007; Galan, 2023). Using the Semantic Frame terminology in Appendix A, the proposed DBMS uses a hybrid organizational model inspired by English grammar and extended with database-native Relationship Edge structures: ```text Subject └── Verb / action class └── Semantic Frame └── Object / target / payload ↔ Relationship Edge ``` This structure provides a Semantic Frame for organizing memories. It does not replace relational indexes, vector indexes, document storage, time-series structures, or graph traversal. Instead, it acts as an organizing layer that helps the DBMS route queries into smaller, meaningful compartments before applying more expensive retrieval operations such as vector similarity search, Relationship Edge traversal, temporal analysis, or document reconstruction. The same grammar-inspired structure also participates directly in vector embedding and semantic search. When a document, memory chunk, or other textual data is embedded, the DBMS must include the relevant subject, action class, Semantic Frame, and target or memory payload in the embedded text. Query-time retrieval uses the same structure and includes subject, action class, Semantic Frame, target or memory payload, and other key values when they can be derived from the user prompt. These fields are included in the search vector or coordinated retrieval package to compartmentalize the vector search to a reasonable size. Aligning the embedded memory chunks and the query vectors around the same Semantic Frame improves retrieval precision. It also reduces ambiguous matches, helping to ensure the most relevant returned vectors are ranked ahead of contextually unrelated memories. The **Subject** represents the primary entity around which a memory is organized. A subject may be a person, company, project, organization, customer, department, system, server, location, document, product, AI agent, or other identifiable thing. Examples of subjects include: | Subject Type | Example | | --- | --- | | Person | Alice Johnson | | Project | Project Y | | System | Server X | | Organization | Kinetic Seas Incorporated | | Customer | Customer A | | Place | Chicago data center | | AI agent | Infrastructure support agent | | Document | Migration plan v2 | | Application | Billing platform | The subject provides the first level of compartmentalization. A query about Server X must not initially require searching all memories in the enterprise. The DBMS can first restrict the search to memories where Server X is the primary subject, a related subject, or an object connected to another subject. For example: "What do we know about Server X?" can be routed first to the Server X subject compartment, where the system can then search Facts, Claims, events, decisions, workflows, documents, and Relationship Edges connected to that subject. The **Verb** represents the type of action, state, or activity associated with the subject. It describes what happened, what was done, what was discussed, what changed, or what was learned. Examples of memory verbs include actions and states such as `discussed`, `decided`, `discovered`, `planned`, `installed`, `configured`, `purchased`, `reviewed`, `changed`, `failed`, `approved`, `rejected`, `migrated`, `learned`, and `verified`. These verbs let the DBMS classify memories by the type of activity or assertion they represent: a decision, a discovery, a system change, a failure, an approval, a migration, a lesson, or a verification event. The verb level allows the system to narrow the search by action class. For example: "What decisions were made about Project Y?" can be routed to: | Field | Value | | --- | --- | | Subject | Project Y | | Verb | decided | This is more efficient than searching every memory related to Project Y. It also improves retrieval quality because the search is scoped to decision memories rather than all documents, messages, and events. A search that contains both a subject and a verb will usually be more efficient than a search by verb alone because the subject further narrows the candidate set to fewer vectors. A verb-only search such as "show all failed deployments" is still important, but it can be much broader and more expensive in a large enterprise knowledge base. The architecture can therefore use additional strategies for efficient verb-oriented retrieval. This may include verb-level indexes, subject-type partitions, and other methods to identify the most relevant action-class memories without requiring a global search. In the grammar-inspired analogy, the **Predicate** represents the structured meaning around the verb. The formal DBMS term for this structure is **Semantic Frame**. The Semantic Frame describes the assertion, event, decision, discovery, or Relationship Edge being remembered. For the server-installation memory used earlier, the subject may be: Subject: Server X The verb may be: Verb: installed The Semantic Frame may capture structured meaning such as: | Field | Value | | --- | --- | | installed\_as | dedicated production host | | installed\_for | Project Y | | installed\_by | infrastructure team | | reason | shared hosting environment could not support expected load | | event\_date | March 12, 2019 | | outcome | successful | The Semantic Frame makes Memory Objects more than text. It provides a structured representation that can be queried, indexed, validated, and connected to Facts, Claims, evidence, workflows, and timelines. The Semantic Frame may include the role a system or person played, the purpose of an action, the actor responsible for it, the reason it occurred, and the outcome it produced. It may also include time, supporting evidence, confidence, precision, and validity status. In the server-installation example, the Semantic Frame may say that Server X was installed as a dedicated production host for Project Y. It may also record that the infrastructure team performed the work on March 12, 2019, because shared hosting could not support expected load. The successful outcome would remain linked to tickets, email, logs, and meeting notes. Search by Semantic Frame without a subject and action class will usually be very inefficient. Semantic Frame elements such as purpose, reason, outcome, actor, role, and validity occur across many unrelated memories, projects, systems, and workflows. A query that asks only for these frame fields may require broad scans, large vector searches, or heavy reranking unless it is constrained by subject and/or action class. The Semantic Frame is therefore most powerful when used as part of a structured retrieval path, such as subject plus action class plus frame, rather than as an isolated global search field. In this sense, the Semantic Frame is the bridge between natural-language memory and structured database representation. The **Object** represents the thing being acted on, remembered, described, or affected. The object may be another entity, a document, a system, a decision, a configuration, a workflow, a Claim, a Fact, or the memory payload itself. In some cases, the subject and object are both entities: | Field | Value | | --- | --- | | Subject | Infrastructure Team | | Verb | installed | | Object | Server X | In other cases, the subject is the main entity being remembered: | Field | Value | | --- | --- | | Subject | Server X | | Verb | installed | | Object | Dedicated production host role | The object level may also contain or link to the memory payload. However, the payload must not be treated as an unstructured blob only. A memory payload may combine a natural-language summary with structured fields such as extracted entities, dates, actors, outcomes, and other potentially searchable keys. In this sense, objects can behave like documents in a document database because they may carry rich payloads, metadata, and source references. They can also behave like nodes in a graph database because they can participate in typed Relationship Edges across the larger memory structure. Those object Relationship Edges do not need to remain inside a single subject or verb path. An object may connect Memory Objects across subjects, verbs, projects, time periods, workflows, Skill Packages, and security partitions when the Relationship Edge is meaningful and authorized. The object layer may also include durable pointers back to raw source documents, tickets, transcripts, logs, database records, or archive files, allowing derived memories to remain traceable to the evidence from which they were created. The object layer is where the DBMS can attach the actual memory content, but the system also preserves structured fields and Relationship Edges so that the memory can be maintained and retrieved efficiently. ## 5.2 Relationship Edges Relationship Edges, as named in Appendix A, connect Memory Objects, Memory Detail Objects, Facts, Claims, subjects, objects, workflows, documents, and time periods. This is where the grammar metaphor is extended into a database-native graph model. The formal term is **Relationship Edge**. Enterprise memory requires Relationship Edges such as **supports**, **contradicts**, **supersedes**, **derived\_from**, **verified\_by**, **caused\_by**, **depends\_on**, and **part\_of**. The Relationship Edge model must distinguish explicitly between broad association and causality. A `related_to` edge means two objects are connected or worth retrieving together. A `caused_by` edge means that the system, a policy, or a human reviewer has accepted a stronger causal assertion with evidence, mechanism, confidence, and scope. This distinction prevents the graph from implying that events caused one another merely because they appeared in the same project, time window, incident, or Workflow Trace. Relationship Edge types cover the major ways institutional knowledge connects across the system. Basic memory Relationship Edges describe association and sequence. A Memory Object may be `about` a subject, object, or topic. It may occur `before` or `after` another Memory Object or event. It may arise `because_of` another Fact, decision, or condition. It may also be generally `related_to` another object when the system only needs a broad semantic association. Other Relationship Edges describe structure. Containment Relationship Edges place a memory `inside` a project, department, system, or place. Origin Relationship Edges connect a memory `from` a source artifact. Participation Relationship Edges connect a memory `with` a person, team, system, or organization. Detail Relationship Edges such as `has_detail` and `contains` connect parent memories to recursive detail objects. Governance Relationship Edges must also be available. Examples include `supports`, `contradicts`, `supersedes`, `derived_from`, and `verified_by`. These Relationship Edges let Claims, Facts, Memory Objects, workflows, and Skill Packages be traced, challenged, promoted, or replaced over time. Operational Relationship Edges such as `depends_on`, `caused_by`, and `part_of` allow the system to represent process structure, causal assertions, and membership in a larger project, workflow, incident, or timeline. Causal Relationship Edges must carry supporting metadata. That metadata may include the causal mechanism, evidence links, confidence, temporal ordering, candidate counterfactual, reviewer or model source, and whether the causal edge is asserted, inferred, disputed, or verified. The initial DBMS may store and query these causal edges without claiming to solve full causal inference. Later versions may add a causal reasoning subsystem that derives candidate causal chains, evaluates interventions, or answers counterfactual questions using the stored evidence and typed graph (Jaimini & Sheth, 2022; Zellinger et al., 2024). Relationship Edges allow the Memory DBMS to move beyond hierarchical storage. A memory may be stored primarily under one grammar-inspired subject, action class, Semantic Frame, and target path, but it may also be connected to many other memories through Relationship Edges. This prevents the system from becoming trapped in a rigid folder structure. This makes the memory useful for building agentic workflows and maintaining institutional knowledge. ## 5.3 Compartmentalized Retrieval A major purpose of the organizational model is to reduce the cost and ambiguity of search. In a large enterprise database containing memories, search occurs in stages. A query such as "Why was Server X installed?" is routed as a scoped recall path rather than as an undifferentiated semantic search. The retrieval process identifies the subject, expands the likely action-class space, selects Semantic Frame targets, searches relevant memory compartments, traverses Relationship Edges, retrieves supporting evidence, and returns an answer with confidence, precision, and provenance. ![Figure 4a: Installation-Reason Retrieval Plan](Figure-4a.pdf) A query such as "What is our process for installing a production server?" follows a different path because the user is asking for reusable operational knowledge rather than a reason for a specific past event. The DBMS identifies the object type and action class, retrieves similar Episode Objects, extracts Workflow Traces, compares common and exceptional paths, and returns a Generalized Workflow with supporting memories and confidence. ![Figure 4b: Production-Server Workflow Retrieval Plan](Figure-4b.pdf) *Figure 4: Compartmentalized Retrieval Plan.* This routing model allows the DBMS to select the appropriate retrieval strategy rather than treating every query as a generic semantic search (Barnett et al., 2024; Khattab & Zaharia, 2020; Thakur et al., 2021). ## 5.4 Search Path Selection and Query Hints A generic user query must not force the DBMS to begin with a single default retrieval method. The same natural-language request may require different search paths for different goals. Some requests ask for a historical Memory Object, a current-valid Fact, or a supporting source. Others ask for a workflow, Skill Package, causal explanation, recursive detail expansion, or exploratory semantic search. The DBMS therefore treats the initial query as a request to build a retrieval plan rather than as text to send directly to a vector index. The search path selection process begins by creating a retrieval envelope. The envelope identifies who is asking and under what context. That includes the authenticated account, roles, Active Memory Pool, application context, agent delegation chain, allowed partitions, current task, query text, and any structured fields supplied by the caller. The DBMS then extracts candidate retrieval cues from the query. Those cues may include subject, verb or action class, object type, topic, time range, Relationship Edge hints, desired answer shape, evidence requirement, confidence threshold, precision requirement, and recursive detail depth. These cues are treated as candidates rather than as final truth, because generic language may be incomplete or ambiguous. After cue extraction, the DBMS classifies the likely intent of the query and chooses an initial path. A specific recall question usually begins with subject, verb, temporal, and catalog filters before graph or vector expansion. A "why" or "how do we know" question begins with the Derivation Ledger, evidence links, source references, and supporting or contradicting Relationship Edges. Task-oriented questions follow a different path. A "how do we perform this task" question begins with Workflow Traces, Generalized Workflows, Procedural Memory Objects, Skill Packages, and recursive detail objects. A date-sensitive question begins with temporal indexes and bitemporal validity. A dependency, cause, or Relationship Edge question begins with graph traversal. A broad exploratory question may begin with a scoped semantic search, but even then the DBMS must apply authorization, partition, subject, topic, and time filters before expanding into larger vector search. The selected path is a plan, not a rigid single step. The retrieval coordinator may start with the cheapest or most precise indexes and gather candidate Memory Objects and Facts. It may then expand into graph traversal, recursive detail, vector similarity, source inspection, or workflow lookup when the first path is insufficient. The final result must be assembled only after access control, confidence, precision, validity, provenance, and evidence requirements have been checked. This makes generic search more reliable because the system can adaptively choose the right search structure while still preserving deterministic governance boundaries. The DBMS also supports an optional **query hint** structure. Hints allow a user, application, AI agent, or MCP server to suggest the initial search path, expected result shape, or depth of detail when the use case is known. For example, a caller may know that the query is asking for a workflow, a source-backed answer, a current-valid Fact, or a detailed procedural expansion even when the natural-language prompt is short. A hint guides planning, but it must not override security, access control, validity rules, provenance requirements, or DBMS safeguards. The system can ignore or downgrade a hint when it conflicts with policy, missing evidence, or the query's inferred intent. For example, a procedural query may include a hint package like this: ```json { "query": "What should I know before installing this server?", "hints": { "intent": "procedural_guidance", "preferred_paths": ["workflow", "skill_package", "recursive_detail"], "subject": "Server X", "object_type": "production server", "time_mode": "current_valid", "detail_depth": 2, "evidence": "summaries_with_source_links", "minimum_confidence": 0.75, "partitions": ["Project Y", "Infrastructure"] } } ``` In this example, the hint tells the DBMS to begin with workflow and Skill Package retrieval rather than open-ended semantic recall. The `detail_depth` value asks the DBMS to expand the procedure to major steps and substeps, but not necessarily to every command, log excerpt, and source artifact unless the agent later asks for deeper evidence. This pattern supports both human usability and machine precision: casual users can ask ordinary questions, while applications and AI agents can provide structured hints when they know the operational context. This is consistent with retrieval systems that interleave search with reasoning or use retrieval self-critique to improve grounded answers (Trivedi et al., 2023; Asai et al., 2024). The security and governance controls for retrieval planning, graph expansion, summary generation, and context-package assembly are centralized in Section 8. ## 5.5 Recursive Detail Expansion Recursive detail uses the Memory Detail Object defined in Section 3.6 to expand a memory only to the level required by the task. Retrieval supports progressive expansion. A query or API call may ask for the parent memory only, for the first level of details, for all details to a specified depth, for only details related to a subject or exception, or for the evidence behind a particular step. This allows the DBMS to keep ordinary recall concise while still supporting the deep operational detail needed to build and execute Procedural Memory Objects, Skill Packages, and competencies. As described in Section 5.4, those retrieval packages become the working context used by Active Memory Pools. # 6. Active Memory Pools for Human-AI Collaboration Active Memory Pools describe how durable memory becomes governed working context. The lifecycle matters because agents and humans need a shared task surface without letting temporary observations, stale context, or unauthorized material become durable institutional memory by accident. ## Active Memory Pool Lifecycle The lifecycle tables answer two questions: how a pool is safely opened and loaded, and how work inside the pool becomes reviewed knowledge or preserved history. Separating those phases keeps setup controls distinct from promotion and closure controls. **Pool Setup and Loading** | State or operation | Purpose | DBMS-managed objects involved | Governance and resulting state | |---|---|---|---| | Create pool | Establish a governed working-memory space for a task, project, incident, or agent group. | Active Memory Pool, audit record, membership record | Creator authorization, partition scope, retention policy, and audit logging create an empty governed pool. | | Define task scope | Bind the pool to a purpose, subject, workflow, time window, and allowed partitions. | Pool scope, policy record, Semantic Frame cues | Scope approval, partition policy, and stale-after defaults give the pool an enforceable retrieval boundary. | | Attach humans, agents, tools, and service accounts | Identify who and what may read, write, retrieve, or promote from the pool. | Member links, agent accounts, tool definitions, service accounts | Least privilege, delegation-chain recording, and tool registry validation make membership and execution rights explicit. | | Load governed context | Assemble authorized Memory Objects, Facts, workflows, Skill Packages, and source references. | Context Package, Memory Objects, Facts, Workflow Traces, Skill Packages | Security-aware retrieval, redaction, evidence policy, and temporal validity make initial context available for work. | The setup phase turns an ordinary task boundary into a governed database object. Before any collaboration begins, the pool has scope, membership, retrieval limits, loaded context, and auditability. **Observation, Promotion, and Closure** | State or operation | Purpose | DBMS-managed objects involved | Governance and resulting state | |---|---|---|---| | Publish observations | Let humans, agents, or tools record task-local observations. | Pool observations, tool-call records, source snippets | Actor attribution, input validation, and source trust labels make observations visible within the pool. | | Mark pending Claims | Convert useful observations into Claims awaiting review. | Claims, source links, Derivation Ledger entries | Promotion permission, evidence requirement, and confidence policy separate candidate knowledge from durable truth. | | Refresh context | Recheck loaded context against updated Memory Objects, policies, Facts, and stale-after rules. | Context Package, retrieval package, supersession edges | Freshness policy, authorization recheck, and audit logging update pool context or mark it stale. | | Validate or reject observations | Review pending observations and Claims. | Claims, Facts, review records, Derivation Ledger entries | Human or policy approval, verification process, and contradiction checks accept, reject, or retain Claims for later review. | | Promote durable knowledge | Convert validated Claims into Facts, Episode Objects, Workflow Traces, or Memory Object updates. | Facts, Episode Objects, Memory Objects, Workflow Traces | Provenance, temporal validity, confidence threshold, and audit record create or update durable memory. | | Update workflows or Skill Packages | Apply validated lessons to reusable procedures. | Generalized Workflows, Procedural Memory Objects, Skill Packages | Review status, security policy, rollback path, and stale-after review revise reusable knowledge or queue it for review. | | Archive or close pool | End active work while preserving required records. | Active Memory Pool, Context Packages, audit log, retained observations | Retention policy, legal hold, export controls, and final audit close, archive, or retain the pool for historical replay. | The second phase is deliberately conservative. It allows active work to create useful memory, but only through review, provenance, temporal validity, and lifecycle controls that keep temporary collaboration from becoming unexamined institutional truth. ## Context Packages A Context Package is the compact, policy-aware projection of durable memory, current Facts, workflows, Skill Packages, evidence links, and pool observations into an AI-usable context window. It is assembled for a specific actor, task, Active Memory Pool, time mode, and authorization envelope. Context Packages are not substitutes for durable Memory Objects. They must preserve references back to Source Packages, Claims, Facts, Memory Objects, Episode Objects, Workflow Traces, Skill Packages, and Derivation Ledger entries. They must be permission-filtered before assembly, refreshable as underlying objects or policies change, and auditable as part of the retrieval and model-use record. Because a Context Package is a projection, it may become stale or invalidated. If an underlying Memory Object is superseded, a Fact loses current validity, a workflow is retired, a Skill Package is suspended, or an access policy changes, the DBMS must mark affected packages for refresh or prevent their continued use. An Episode Object becomes useful AI context when the DBMS assembles it into a policy-governed, time-aware working set for a specific task. The Episode Object preserves what happened, when it happened, who or what participated, what evidence supports it, and how later interpretation changed. The Context Package is the operational projection of that memory into the current task. AI agents operate through bounded context windows containing selected instructions, retrieved data, tool outputs, conversation history, task state, and intermediate reasoning artifacts. Usable AI context must therefore be relevant to the task, permitted by the user's authority, current, compact, and specific enough to support reliable action. It also preserves links back to evidence, Claims, Facts, Episode Objects, Workflow Traces, and Relationship Edges so humans or AI agents can inspect why a piece of context was provided. The Memory DBMS treats context assembly as a governed database function rather than as ad hoc prompt construction. A context-building operation can select Memory Objects by subject, task, project, system, time period, Relationship Edge path, confidence state, and access policy. It then packages the result into concise summaries, structured Facts, Workflow Traces, and source links when the agent or human reviewer needs verification. Compartmentalized search also supports **pre-loaded search contexts** for high-speed work. Before a human or AI-agent task begins, the DBMS can build a subject-scoped memory buffer pool containing relevant Memory Objects, Facts, workflows, Procedural Memory Objects, Skill Packages, source references, and recent Active Memory Pool context. This can be initiated by a user prompt, application request, API call, or MCP server command. Example requests include "load authentication memories and Skill Packages for Project Y" or "prepare the production-server installation context for this deployment task." A cache or buffer pool is the performance mechanism used to make selected content faster to retrieve; it is not a substitute for the governed Memory Object. The preload operation uses the same governed retrieval model as ordinary search. It identifies the subject, allowed topics, relevant verbs, workflow families, source classes, confidence thresholds, validity windows, and security boundaries before materializing any shared working set. The resulting cached pool must not be an opaque shortcut around the DBMS. It must preserve provenance, source pointers, confidence, precision, staleness status, and access-control labels so agents can inspect why a memory was loaded and whether it is safe to use. Subject-based loading reduces repeated broad searches during active work. For example, agents collaborating on authentication for a PHP system can use preloaded memories, login workflows, OAuth or OIDC decisions, token-handling edge cases, prior incident records, approved Skill Packages, and raw-source pointers instead of repeatedly searching the full enterprise memory space. Real-time shared observations are a proposed extension of this pattern. Multiple agents and humans may read from and write to the same Active Memory Pool simultaneously while they perform a task, record actions, raise questions, add observations, and propose Claims. The Active Memory Pool is intended to become a shared operational memory surface rather than a static search result. Because these Active Memory Pool observations may later influence decisions or be promoted into durable institutional memory, every write must remain attributable to a user account, AI-agent account, MCP server, tool, or application. The same permissions, retention rules, and promotion policies used elsewhere in the DBMS must govern those writes. ![Figure 5: Active Memory Pool](Figure-5.pdf) *Figure 5: Active Memory Pool.* An Active Memory Pool may be created for a project, incident, deployment, investigation, design session, coding task, support case, or multi-agent collaboration. It can be loaded from a prompt, API command, MCP tool request, SQL function, or structured query that identifies a subject, topic, workflow, time range, or task. The pool contains relevant Memory Objects, Facts, workflows, Skill Packages, source references, pending Claims, task observations, and collaboration state. Agent-to-agent shared memory channels extend Active Memory Pools when multiple AI agents or humans need simultaneous access to the same working context. These channels support scoped membership, publish-and-subscribe updates, pending observations, retrieved memory references, conflict markers, promotion candidates, and audit logs. Access may be implemented through APIs, WebSockets, direct TCP/IP, or other transports, depending on latency, deployment, and governance needs. These are implementation examples rather than architectural requirements. Regardless of transport, the channel must remain governed by the same identity, privilege, partition, provenance, and promotion rules as the rest of the DBMS. Active Memory Pool observations must not automatically become permanent Memory Objects. The system supports a promotion path from active observations to pending Claims, verified Facts, Episode Objects, Workflow Traces, Generalized Workflow updates, Procedural Memory Object updates, and Skill Package refinements. It also supports consolidation and lifecycle management so old episodic traces do not remain equally prominent forever. Salience, reinforcement, decay, archive movement, legal hold, and retention policy determine whether memories remain in active retrieval paths, become consolidated into higher-level procedural knowledge, move to cold storage, or are eventually pruned when policy permits. Pool isolation, transport governance, and promotion controls are treated as security and governance requirements in Section 8. The next section describes how repeated episodes and active work can be generalized into workflows and reusable Skill Packages. # 7. Workflow and Skill Package Derivation A Memory DBMS must preserve what happened. It also derives knowledge about how outcomes were achieved. The object types used in this section are defined in Section 3; this section focuses on how those objects are derived and validated (Cohen & Squire, 1980; Squire, 2004; van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). These promotion gates prevent extracted workflows from being treated as automatically authoritative. They answer when a pattern may be inspected, when it may guide planning, and when it may become executable or reusable procedural knowledge. **Workflow and Skill Promotion Gates** **Workflow Derivation Gates** | Promotion stage | Required evidence | Validation and allowed use | Blockers and audit requirements | |---|---|---|---| | Extracted Workflow Trace | Source-linked steps from one Episode Object or case | Source replay, timestamp review, and actor/tool check permit inspection and retrieval. | Missing evidence, ambiguous order, or unauthorized source blocks promotion; audit requires extraction run, source links, and model or reviewer identity. | | Candidate Generalized Workflow | Multiple Workflow Traces or validated examples | Trace clustering, conformance checks, and exception review permit candidate analysis only. | Too few traces, conflicting variants, or low confidence blocks promotion; audit requires supporting and contradicting trace links. | | Reviewed Generalized Workflow | Evidence review and policy or human approval | Reviewer signoff and process-mining comparison where available permit retrieval and planning guidance. | Unresolved contradiction, stale environment, or missing review blocks promotion; audit requires review record, policy version, and confidence/precision record. | These gates keep process discovery tied to evidence. A recurring pattern can help retrieval and planning before it becomes operational guidance, but it cannot become a Procedural Memory Object or Skill Package without review. **Skill Package Promotion and Lifecycle Gates** | Promotion stage | Required evidence | Validation and allowed use | Blockers and audit requirements | |---|---|---|---| | Procedural Memory Object candidate | Reviewed workflow plus prerequisites, checks, exceptions, and source links | Dry-run review, expert review, and policy check permit non-executable guidance. | Missing preconditions, weak validation, or unsafe exception handling blocks promotion; audit requires candidate version, evidence package, and reviewer identity. | | Validated Procedural Memory Object | Successful validation or approved operational use | Test execution, conformance review, and human or policy approval permit guided human use and controlled agent planning. | Current-valid dependency failure or insufficient security policy blocks promotion; audit requires validation record, valid-time window, and stale-after rule. | | Draft Skill Package | Validated procedural knowledge, input/output contracts, security policy | Schema review, tool permission review, and Context Package test permit sandbox or review use. | Missing rollback path, missing approval, or invalid tool contract blocks enablement; audit requires draft version, execution policy, and source links. | | Enabled Skill Package | Approved draft with current-valid dependencies | Runtime test, policy approval, and audit review permit governed human or AI-agent execution. | Tool, model, source, or workflow dependency not approved blocks enablement; audit requires enablement record, execution policy, and audit requirements. | | Suspended or superseded Skill Package | New evidence, policy change, failed execution, or replacement version | Staleness review, incident review, and supersession analysis permit historical recall only or restricted use. | Unsafe current use, policy violation, or contradicted procedure blocks ordinary use; audit requires suspension reason, supersession edge, and affected pools. | | Retired Skill Package | Retention decision and replacement or end-of-life record | Archive review and dependency cleanup permit historical and audit access. | Legal hold or unresolved incident review blocks final retirement; audit requires retirement record, retained evidence, and archive policy. | The lifecycle view makes reuse conditional. Skill Packages are valuable because they can guide future action, but that same power requires approval, auditability, rollback, suspension, and retirement paths. ## 7.1 Workflow Traces As defined in Section 3.7, a Workflow Trace turns a detailed Episode Object into an ordered, evidence-linked case. This lets process-mining methods work with remembered work as well as conventional event logs, while preserving the source material that supports each step (van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). For the server-installation running example in Section 3.0, the Workflow Trace is the evidence-linked ordered path through the work: selected resources, configuration steps, validation checks, exceptions, and transition into operational use. When those steps are preserved or reconstructed from tickets, commands, logs, documentation, and conversations, the episode becomes one execution instance that can support later workflow analysis. At derivation time, the DBMS forms candidate Workflow Traces from individual Memory Objects and compares them across similar cases. Supported patterns can be consolidated into Generalized Workflows and Procedural Memory Objects without discarding the evidence and context behind the original work (Cohen & Squire, 1980; van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). Many server-installation memories, performed by different people across different projects and environments, may allow the system to identify a candidate Generalized Workflow. The system compares similar traces, extracts common steps, identifies variations, distinguishes required steps from optional steps, and preserves known exceptions without treating any extracted pattern as authoritative before validation. ## 7.2 Generalized Workflows For example, if the system contains many successful installation traces, it may discover that most of them include the following recurring pattern: 1. define the application or business requirement; 2. select the target server, virtual machine, or cloud instance; 3. install or provision the operating system; 4. configure networking, DNS, firewall, and access controls; 5. install required runtime dependencies; 6. configure application services; 7. deploy application code or database components; 8. validate connectivity, security, and performance; 9. document the server and link it to the responsible project; 10. transition the system into operational use. Recurring patterns like this can be converted into Skill Packages or competencies when they are sufficiently supported, validated, and current. These packages make it possible for both humans and AI agents to perform tasks based on validated workflows while still accessing the supporting memories behind the workflow. That access matters because real operational work often depends on exceptions and edge cases. A human or AI agent using the Skill Package can inspect how similar problems were handled before, which variations succeeded or failed, and which evidence supports the recommended path. Recursive detail makes that inspection practical because the agent can begin with a Generalized Workflow. If the agent is uncertain about a step, it can retrieve the substeps and exceptions for that step. After completing the substep, it can return to the higher-level Skill Package without flooding the Active Memory Pool with unrelated detail. Workflow promotion must preserve lineage. A Generalized Workflow is stored as a derived knowledge object linked back to the source Memory Objects, Facts, Claims, and evidence that support or constrain it. That lineage lets later users inspect why the workflow exists, which cases support it, which cases contradict it, and under what conditions it applies (Buneman et al., 2001; Moreau & Missier, 2013). This design allows the Memory DBMS to support both **specific recall** and **generalized operational knowledge**. Specific recall answers questions such as: "When was Server X installed, who installed it, and why?" Generalized workflow knowledge answers questions such as: "What is the organization's proven process for installing a production server?" Procedural Memory Object knowledge answers a different question: "How does the organization know how to install, adapt, validate, and troubleshoot production servers in real environments?" The Semantic Frame and Relationship Edge model also supports workflow formation because it gives the DBMS a consistent way to group similar Episode Objects before attempting process discovery. Repeated Episode Objects can be grouped by subject type, action class, object type, Semantic Frame, outcome, Relationship Edge, and available Workflow Trace. This makes the organization model more than a storage convention: it becomes part of the learning mechanism that helps the DBMS identify reusable operational patterns (van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). From those groups, the system can consolidate a candidate Generalized Workflow or Skill Package while preserving known exceptions such as firewall-rule conflicts, DNS delays, package-version conflicts, or insufficient disk allocation. At minimum, the resulting workflow must carry confidence, precision, validity status, review status, and provenance metadata so humans and AI agents can assess how strongly the workflow is supported and whether it remains safe under current operating standards. This allows the Memory DBMS to help transform repeated institutional events into reusable Procedural Memory Objects, Skill Packages, and competencies. The organizational structure is both a storage model and a learning model. ## 7.3 Procedural Memory Objects Section 3.9 defines the Procedural Memory Object. This section focuses on how Generalized Workflows contribute to Procedural Memory Objects. In runtime use, a validated Procedural Memory Object can guide ordinary execution while still allowing recursive retrieval of source-backed exceptions, variants, and supporting memories. This is where the system connects process derivation to practical human and AI-agent work. ## 7.4 Skill Packages Section 3.10 defines Skill Packages and competencies. This section focuses on their schema and runtime behavior. A Skill Package guides one repeatable task or task family. A competency is broader: it is an organizational capability composed of related Skill Packages, Procedural Memory Objects, validation records, supporting evidence, and operational history. A Skill Package object must have a stable identifier and version, name, purpose, and descriptions. For analysis purposes, the object maintains links to the Procedural Memory Objects and workflows that justify it. Skill Packages are searchable by attributes such as project, subject, environment, technology stack, time window, and governing policy. The Skill Package definition defines preconditions, inputs, and outputs. The Skill Package body defines artifacts to be created, steps, decision points, and validation checks. It also carries a security policy that matches other object types in the database such as table security and stored function execution rights. Other attributes like model policy, Skill Package confidence, precision scores, and model dependencies must also be tracked. At runtime, a Skill Package executes as a governed state machine rather than as a free-form prompt. The concrete runtime format may vary based on the LLM, agent framework, and orchestration harness used to manage Skill Package utilization. Some Skill Packages may be materialized as system prompts or prompt templates. Others may be Markdown files that describe operational procedures, application plugins, MCP-accessible tools, or workflow definitions invoked by a runtime. Regardless of packaging, the runtime binds the current user or agent account, Active Memory Pool, task objective, authorized partitions, and relevant source context. It then executes the governed procedure in stages: - Check preconditions. - Load only authorized Memory Objects and workflows. - Present or execute steps. - Record observations. - Evaluate validation checks. - Branch on known exceptions. - Emit new Claims, Workflow Traces, or Procedural Memory Object updates when execution produces useful new knowledge. This runtime distinction supports safety. A human may use the Skill Package as guided operational documentation. An AI agent may use it as an executable procedure only if its account, tools, model policies, and target partitions permit that use. In either case, every Skill Package execution must produce an auditable execution record that can later support workflow conformance, Procedural Memory Object refinement, staleness review, or incident investigation. Promotion into an enabled Skill Package requires concise acceptance criteria: - Source-backed steps with links to the supporting Episode Objects, Workflow Traces, Facts, and Source Packages. - Current-valid preconditions, dependencies, and applicability scope. - Validation checks that define expected outputs and failure conditions. - Known exception handling and escalation paths. - Security policy for actors, tools, partitions, source access, and model calls. - Confidence threshold, review status, or human approval appropriate to the risk class. - Human or policy approval where the Skill Package can affect production, regulated, or safety-critical systems. - Rollback, suspension, supersession, and retirement procedures. ## 7.5 Workflow Extraction Engine Workflow extraction must be implemented as a required governed engine rather than as an informal summarization step or optional future benefit. The engine's purpose is to transform Episode Objects and source evidence into inspectable Workflow Traces, candidate Generalized Workflows, and supporting material for Procedural Memory Object formation. This is an architectural proposal informed by process-mining methods. It must remain evidence-linked and reviewable rather than presented as automatic truth (van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012). A practical workflow extraction engine begins by selecting the scope of analysis. The scope must include the project, subject, action class, time window, source types, and security domain. The engine then groups events into candidate cases, such as one server installation, incident response, deployment, or approval workflow. Within each case, it extracts relevant steps from tickets, logs, transcripts, commands, documents, and Episode Objects while preserving source links. The supporting processing steps normalize different wording into common action classes, objects, actors, tools, and outcomes. The engine orders steps using event time, source time, and transaction time while preserving uncertainty. It then constructs per-case Workflow Traces with actors, steps, inputs, outputs, evidence, confidence, and exceptions. Similar traces can be clustered by subject type, action class, outcome, environment, tool stack, and exception pattern. Those clusters allow recurring sequences and branches to be proposed as candidate Generalized Workflows. Before promotion, the engine performs causal analysis, conformance review against existing workflows, and human, policy, or model-assisted validation. Candidate workflows must not influence Procedural Memory Objects or Skill Packages until they have appropriate provenance and review status. ![Figure 6a: Workflow Formation from the Organizational Model](Figure-6a.pdf) Figure 6a shows the formation stage that precedes engine execution. Episode Objects and Memory Detail Objects are grouped through the organizational model so repeated work can become evidence-linked Workflow Traces and candidate Generalized Workflows. This keeps workflow discovery anchored in governed memory structure before the extraction engine validates, promotes, or rejects candidate procedures. ![Figure 6b: Workflow Extraction Engine Process](Figure-6b.pdf) *Figure 6: Workflow Extraction Engine.* The engine must preserve both positive and negative evidence. Successful traces may support a Generalized Workflow, while failed or partial traces may identify missing prerequisites, unsafe assumptions, or known exception paths. The output must include a proposed step sequence, supporting traces, contradictory traces, confidence and precision scores, applicability conditions, known variants, and links back to the source Claims, Facts, and Episode Objects. The workflow extraction engine also separates temporal sequence from causality. A trace may show that a configuration change happened before an outage, but a causal finding requires additional support. That support may include a mechanistic explanation, repeated pattern, diagnostic evidence, human verification, or counterfactual analysis. For example, "the server failed after the network change" is a sequential or correlational Relationship Edge. By contrast, "the network change caused the server failure because it removed the failover route" is a causal Claim that is represented, reviewed, and queried differently. Causal knowledge graph research shows that causal edges and counterfactual reasoning require richer structure than ordinary graph adjacency. This paper therefore treats causal reasoning as an architectural hook and future capability rather than as an automatic inference guarantee (Heindorf et al., 2020; Jaimini & Sheth, 2022; Zellinger et al., 2024). The workflow extraction engine must not directly overwrite an existing workflow or Procedural Memory Object. Instead, it creates candidate workflow versions with provenance and review status. A candidate may be accepted, rejected, merged, retained as a variant, marked environment-specific, or used only as an exception record. This keeps process mining aligned with the DBMS governance model. ## 7.6 Workflow and Skill Package Validation Process-mining literature primarily validates methods against event logs. Applying those methods to narrated memories, extracted Episode Objects, emails, tickets, commands, and documentation is a proposed extension of the approach. The DBMS therefore treats memory-derived Workflow Traces as candidates until they are validated against source evidence, event logs, human review, or later successful execution. Validation compares memory-derived traces with known process records when they exist. A server-installation workflow, for example, may be checked against ticket histories, deployment logs, command logs, monitoring events, and change-management approvals. Process-mining tools and event-log datasets can provide a practical validation path. They can support: - Conformance checking. - Process discovery. - Replay fitness. - Precision. - Generalization. - Exception analysis. These validation methods are useful reference points for memory-derived workflows (van der Aalst et al., 2004; IEEE Task Force on Process Mining, 2012; Berti et al., 2023; van Dongen, 2019). The DBMS requires validation status before a Generalized Workflow influences a Skill Package or runtime agent behavior. A candidate workflow may be marked as: - Extracted. - Partially validated. - Validated. - Contradicted. - Superseded. - Environment-specific. - Unsafe for execution. These states prevent the system from treating a plausible narrative pattern as a proven operational procedure. Because derived workflows and Skill Packages can influence future action, the next section centralizes the security and governance controls around them. # 8. Security and Governance This section separates "what can go wrong" from "what the DBMS must enforce." The threat-model tables identify failure modes, while the control mapping turns those risks into database responsibilities that must apply during retrieval, model execution, tool use, synchronization, and promotion. **Memory DBMS Threat Model** The threat model is organized by where leakage or unsafe action can enter the system. The first group focuses on retrieval and context assembly; the second group covers tools, agents, promotion, model calls, rebuilds, and synchronization. **Retrieval and Context Leakage Risks** | Risk | Attack or failure mode | Affected objects and impact | Required DBMS controls | |---|---|---|---| | Semantic retrieval leakage | Unauthorized objects influence vector candidates, reranking, snippets, or summaries before policy filtering. | Memory Objects, Facts, Source Packages, summaries, and Context Packages may reveal restricted information even when final object IDs are hidden. | Authorization-aware candidate generation, partition-aware index selection, redaction, audit logging | | Unauthorized graph traversal | A user follows Relationship Edges from an allowed object into restricted subjects, projects, or evidence. | Relationship Edges, Episode Objects, Facts, and workflows may expose sensitive adjacency, dependency, or causal information. | Relationship Edge authorization, traversal-depth policy, edge redaction | | Summary or Context Package leakage | Summaries combine authorized and unauthorized source material. | Context Packages, summaries, and retrieval packages may disclose restricted Facts through compact generated text. | Policy-aware summarization, source filtering before generation, citation-level permission checks | | Stale Active Memory Pool use | Agents continue using cached context after Facts, policies, or workflows change. | Active Memory Pools, Context Packages, and Skill Packages may cause agents to act on superseded or unsafe guidance. | Stale-after review, refresh requirements, invalidation notifications | These risks all arise before the final answer or package is assembled. The DBMS therefore has to enforce policy during candidate generation, traversal, summarization, and context refresh rather than waiting until the end of the retrieval pipeline. **Tooling, Agent, Synchronization, and Operational Risks** | Risk | Attack or failure mode | Affected objects and impact | Required DBMS controls | |---|---|---|---| | Source-package prompt injection | Source material contains instructions that attempt to override system or policy behavior. | Source Packages, extraction runs, and model calls may let malicious source text influence extraction, summarization, or tool use. | Source trust labels, source quarantine, prompt-injection treatment for source material | | Unsafe MCP/tool call | Agent attempts a tool call outside its authorized partition or with malformed input. | MCP Tool Definitions, tool registry, audit records, and source systems may enable unauthorized data access, unsafe mutation, or external system misuse. | Tool registry validation, schema validation, least-privilege accounts, audit logging | | Cross-agent memory contamination | One agent's task-local observations leak into another agent's task context. | Active Memory Pools, observations, and Context Packages may propagate incorrect or unauthorized assumptions across workstreams. | Active Memory Pool isolation, membership checks, promotion workflow | | Agent delegation or impersonation | Delegated agent acts beyond the authority of the user or parent agent. | Agent accounts, delegation records, and tool calls may create privilege escalation or untraceable action. | Delegation-chain recording, scoped agent credentials, least privilege | | Unauthorized promotion from observation to durable memory | Pool observations become Claims, Facts, or workflow updates without review. | Claims, Facts, Episode Objects, workflows, and Skill Packages may turn unsupported or malicious content into institutional knowledge. | Promotion workflow, evidence requirements, reviewer or policy approval | | Model-call misuse | Model invocation uses unapproved model, prompt, source scope, or output destination. | Model-Call Functions, derived artifacts, and summaries may let sensitive data leave the policy boundary or unsupported outputs become durable. | Model registry validation, prompt policy, output schema validation, audit logging | | Embedding/index rebuild policy regression | Rebuilt indexes omit policy filters or use stale labels. | Semantic indexes, routing indexes, and summaries may make old permissions or restricted content searchable. | Rebuild policy tests, red-team regression testing, index-version audit | | Archive restore or local-node synchronization leakage | Restored or synchronized objects bypass current partitions, grants, or redactions. | Archives, Local Memory Nodes, Source Packages, and derived objects may cause historical restricted data to reappear in active retrieval. | Restore validation, synchronization policy, access-policy reapplication, audit logging | The second group shows why governance cannot be limited to retrieval. Tools, models, agents, rebuild jobs, and local synchronization all need the same catalog, permission, validation, and audit discipline as ordinary memory access. **Risk-to-Control Mapping** The control mapping translates the threat model into enforceable DBMS behavior. Grouping the controls by category makes clear that some controls belong inside retrieval planning, some inside source and model governance, some inside agent and tool access, and some inside operations. **Retrieval Controls** | Control | Risks addressed | Required DBMS behavior | |---|---|---| | Authorization-aware candidate generation | Semantic retrieval leakage, summary leakage | Filter partitions, subjects, sources, and object classes before retrieval expansion. | | Partition-aware index selection | Semantic retrieval leakage, rebuild regression | Select indexes that match the actor's authorization envelope and policy version. | | Relationship Edge authorization | Unauthorized graph traversal, causal leakage | Check edge-level permissions before traversal or path summarization. | | Policy-aware summarization | Summary or Context Package leakage | Generate summaries only from objects the actor may inspect. | | Redaction | Source and summary leakage | Remove or mask restricted fields before packaging, summarization, or model calls. | **Source and Model Controls** | Control | Risks addressed | Required DBMS behavior | |---|---|---| | Source trust labels | Prompt injection, weak evidence | Classify sources by trust, quarantine status, and use limitations. | | Source quarantine | Prompt injection, unsafe extraction | Prevent untrusted source content from influencing Claims, summaries, embeddings, or prompts until reviewed. | | Prompt-injection treatment for source material | Source-package prompt injection | Treat source instructions as data unless policy explicitly promotes them. | **Agent and Tool Controls** | Control | Risks addressed | Required DBMS behavior | |---|---|---| | Tool registry validation | Unsafe tool call, model-call misuse | Confirm tool identity, enabled state, implementation type, routing, and allowed partitions. | | Input and output schema validation | Unsafe tool call, model-call misuse | Validate request and response shapes before execution and persistence. | | Least-privilege agent accounts | Delegation, impersonation, unsafe tool call | Bind each agent and service account to scoped privileges. | | Delegation-chain recording | Agent delegation or impersonation | Record who delegated which task, to which agent, under what authority. | | Active Memory Pool isolation | Cross-agent contamination, stale pool use | Enforce pool membership, scope, partitions, and cache boundaries. | | Promotion workflow | Unauthorized durable memory promotion | Require evidence, confidence or review status, temporal scope, and approval where policy requires it. | **Operations Controls** | Control | Risks addressed | Required DBMS behavior | |---|---|---| | Stale-after review | Stale Active Memory Pool use, unsafe Skill Package use | Mark or block context that has passed review windows or has superseded dependencies. | | Audit logging | All risks | Record retrieval, filtering, model calls, tool calls, promotions, rebuilds, restores, and synchronization. | | Red-team regression testing | Leakage and policy regression | Re-run adversarial tests after model, index, connector, restore, or policy changes. | The control groups reinforce the same design boundary from different angles. Security is not a final filter around search results; it is a DBMS behavior that must apply to index selection, Relationship Edges, summaries, tools, model calls, lifecycle state, and operational recovery. **Semantic retrieval leakage example.** Suppose an infrastructure agent is authorized to inspect Project Y but not a restricted acquisition project. If the retrieval system first performs vector search across both partitions, expands graph neighbors, and asks a model to summarize the top candidates before filtering final object IDs, the summary may reveal that Server X was connected to the restricted acquisition project. The final response may hide restricted object IDs, but the unauthorized association has already leaked through ranking, graph expansion, or generated text. A Memory DBMS must therefore apply authorization before candidate generation, during Relationship Edge expansion, before summarization, and again during result packaging. **MCP/tool-call abuse scenario.** An agent in an Active Memory Pool requests a tool exposed through the first supported MCP Tool-Calling Protocol Adapter, or a later tool-calling protocol, to read deployment secrets from a partition outside the agent's grant. A second attempt uses malformed input to bypass a required `project_id` field. The DBMS rejects or downgrades the call because the tool registry confirms the tool's enabled state and allowed partitions, the input schema rejects malformed parameters, and the agent account lacks the required privilege. The audit log records the denied call, delegation chain, request payload classification, and policy decision. **Active Memory Pool isolation scenario.** Two pools may both concern "production server migration," but one may be for Project Y infrastructure and another for a confidential customer migration. Even if they share similar subjects, workflows, or Skill Packages, their memberships and partitions differ. Cached context, pending observations, unresolved Claims, and generated summaries must not move between the pools unless policy permits a deliberate transfer. Otherwise, an agent in one task could inherit stale or unauthorized assumptions from another task. ![Figure 7: Security-Aware Retrieval Coordinator](Figure-7.pdf) *Figure 7: Security-Aware Retrieval Coordinator.* Security and governance requirements apply across retrieval, Active Memory Pools, model execution, tool calls, source ingestion, and promotion of durable memory. Section 8 centralizes those controls so later implementation mechanisms do not bypass the DBMS governance model. Semantic retrieval must be security-aware. Authorization is evaluated before candidate expansion, during index selection, and again when results are assembled. The system must avoid exposing unauthorized information through vector similarity, graph traversal, summaries, Relationship Edge expansion, or Active Memory Pool loading. This means access policy cannot be bolted onto the final answer only after retrieval. It must be part of retrieval planning, candidate filtering, reranking, evidence expansion, and result packaging. Graph traversal must be authorization-aware for both nodes and Relationship Edges. A user or agent must not infer restricted subjects, projects, sources, or workflows merely because an authorized object is adjacent to an unauthorized one. Summary generation and Context Package assembly must apply the same policy checks as direct retrieval. A compact answer, generated summary, or Active Memory Pool load can still leak unauthorized Facts if it is assembled from material the caller was not allowed to inspect. Model execution, prompt policy, tool registries, protocol adapters, transport choices, dispatch behavior, and result persistence are implementation requirements described in Section 9. The security requirement in this section is that those mechanisms remain subject to the same identity, partition, provenance, validation, promotion, and audit controls as retrieval and durable Memory Objects. Source Packages need trust and quarantine controls before their contents influence Claims, summaries, embeddings, workflows, or prompts. Instructions found inside a Source Package are treated as source content rather than trusted system instructions until source trust, policy, and review state allow use. Every actor that connects to the DBMS must have an account. This includes human users, applications, service accounts, AI agents, MCP servers, local memory nodes, and administrative processes. The system supports direct user privileges, role-based privileges, API keys linked to individual accounts, service-account controls, and administrative role creation. Built-in role patterns such as CONNECT, RESOURCE, and DBA may provide a familiar baseline. The system also supports custom roles aligned to projects, subjects, topics, workflows, source domains, and governance responsibilities. Privileges must apply to memory-specific objects and semantic slices rather than only to tables or collections. A user may be allowed to read a topic such as authentication in PHP systems without receiving full access to every project where authentication work occurred. The authorization model supports grants on subjects, verbs, topics, projects, partitions, source types, workflow objects, Active Memory Pools, and Relationship Edges among those objects. Grammar-based organization expresses access control over institutional knowledge at a level more meaningful than a table, file, or vector namespace. Active Memory Pools must remain isolated by membership, task scope, allowed partitions, validity windows, and promotion policy. A pool created for one incident, project, agent group, or delegated task must not expose its cached context, pending observations, or summaries to a different pool unless policy permits that transfer. Active observations must not become durable memory automatically. Promotion from Active Memory Pools into pending Claims, verified Facts, Episode Objects, Workflow Traces, Procedural Memory Objects, or Skill Package refinements uses the same attribution, provenance, verification, temporal validity, permission, and audit controls used elsewhere in the DBMS. Logging, auditing, and observability are required enterprise features. The DBMS must record who accessed, changed, verified, promoted, synchronized, exported, deleted, or derived governed objects. It also records ingestion jobs, model execution, prompt or template policy, model version, index rebuilds, archive recalls, synchronization events, recovery operations, quality signals, performance metrics, and traces. These records support security review, operational monitoring, regulatory obligations, model lifecycle governance, AI risk management, and debugging when retrieved memories or derived Skill Packages are questioned (Kent & Souppaya, 2006; Joint Task Force, 2020; NIST, 2023). The next section narrows these governance principles into implementation requirements. # 9. Implementation Requirements The implementation requirements distinguish logical DBMS responsibilities from replaceable implementation mechanisms. The tables in this section identify what the Memory DBMS must own, while leaving storage engines, indexes, protocols, and model-serving choices open. This section intentionally limits the implementation discussion to requirements the proposed DBMS must satisfy. The purpose is not to prescribe a complete storage-engine design or product implementation. Instead, it defines the architectural commitments needed for the system to operate as a database of memories rather than as an application assembled from unrelated search, graph, document, vector, and time-series tools. The detailed engineering choices, benchmark targets, and internal algorithms belong in a separate implementation specification. **Required Capabilities and Example Mechanisms** The mechanism matrix separates each required capability from examples of how it might be implemented. A "No" in the mechanism column means that the specific mechanism is optional, not that the capability is optional. | Required DBMS capability | Examples of possible mechanisms | Mechanism is mandatory? yes/no | Notes | |---|---|---|---| | Governed model invocation | Registered Model-Call Functions, service APIs, scheduled jobs, workflow steps, stored procedures, SQL-callable functions | No | The requirement is governed invocation with policy, validation, storage, and audit controls. | | Semantic indexing | Vector indexes, multi-vector retrieval, hybrid sparse/dense search, routing vectors | No | Semantic search is a capability; a specific vector database or index is not prescribed. | | Graph traversal | Native graph store, relational edge tables, document-linked edge indexes, graph engine integration | No | Relationship Edge semantics and authorization are required regardless of storage representation. | | Temporal validity | Bitemporal tables, temporal document versions, event-sourced records, versioned object history | No | The DBMS must distinguish valid time and transaction time. | | Provenance ledger | Append-only ledger, versioned derivation records, event log, provenance graph | No | Derivation must be replayable, inspectable, and auditable. | | Tool-calling access | First supported MCP adapter, future protocol adapters, service proxy, API gateway, local tool runner | No | MCP is the initial interoperability target, not the permanent protocol boundary. | | Context Package assembly | Retrieval coordinator, summarization job, template renderer, model-assisted context builder | No | Assembly must be permission-filtered and evidence-linked. | | Active Memory Pool synchronization | Publish/subscribe channel, API polling, message bus, WebSocket, direct TCP/IP transport | No | Transport choice is an implementation mechanism; pool isolation and audit are required. | | Backup and restore | Snapshot backup, logical export, archive tiers, restore jobs, integrity checks | No | Durable objects, catalog state, provenance, and policies are priority recovery assets. | | Derived-artifact rebuild | Re-embedding jobs, summary regeneration, index rebuild queues, workflow regeneration | No | Rebuilds must use preserved sources, model records, policy versions, and audit trails. | | Local-node synchronization | Sync protocol, queue-based exchange, conflict records, tombstone handling | No | Local nodes must not bypass enterprise policy. | | Security-aware retrieval | Authorization-aware candidate generation, partition-aware indexes, redaction, policy-aware summarization | No | Retrieval governance must occur before and during expansion, not only after final ranking. | The architectural commitment is to preserve governance at the DBMS boundary while allowing mechanisms to evolve. This keeps the proposal from depending on any single storage engine, vector index, model provider, protocol, or synchronization design. Figure 2 provides the reference architecture view for the core domains and connected systems. It includes the Enterprise Memory Core, Local Memory Nodes, Active Memory Pools, model execution, tool-calling adapters, source systems, model providers, agent frameworks, and collaboration tools. A Memory DBMS must meet five requirements. It must preserve evidence and provenance behind memories. It must support retrieval across structured and semantic representations. It must govern native model execution and LLM tool-calling access inside the database boundary. It must enforce security and temporal validity during recall. It must also allow derived artifacts to be rebuilt or improved as models and indexes evolve. These requirements distinguish the proposed system from a conventional vector store, document database, knowledge graph, workflow tool, or application-side LLM orchestration layer (Moreau & Missier, 2013; Kulkarni & Michels, 2012; Hogan et al., 2021). Two DBMS-native surfaces span these domains. A **Native Model Execution Engine** invokes approved model services through DBMS-managed controls: - Catalog entries. - Permissions. - Policies. - Validation. - Routing. - Audit records. SQL-callable functions are one possible implementation interface, but not the required abstraction (PostgreSQL Global Development Group, n.d.). An **LLM Tool-Calling Access Surface** lets AI agents query and use governed memory tools through database-managed protocol adapters, a registry, a dispatcher, and an audit layer. Section 8 addresses security, access control, authorization, audit, model-call controls, and tool-call permissions. ## 9.1 DBMS Boundary and Responsibilities **DBMS Boundary and Responsibilities** This boundary view answers a practical design question: which responsibilities belong inside the Memory DBMS, and which external systems may remain connected but governed. The split keeps the logical ownership model readable while preserving the external integration points. **Core Memory and Provenance Responsibilities** | Inside the Memory DBMS | Outside but connected through governed connectors | Notes | |---|---|---| | Source Package Registry | Source systems of record | The DBMS tracks source identity, trust, retention, and derivation links; the source system remains authoritative for its operational domain. | | Claims | Source documents, messages, tickets, logs | Claims are DBMS objects even when extracted from external material. | | Facts | Authoritative systems and human review processes | Facts carry accepted scope, evidence, confidence, precision, and temporal validity. | | Memory Objects | Knowledge bases and document repositories | External repositories may supply sources; governed Memory Objects live inside the DBMS. | | Episode Objects | Event streams and collaboration tools | Episodes bind evidence, Semantic Frames, time, Relationship Edges, and lifecycle state. | | Memory Detail Objects | Command histories, runbooks, transcripts | Details are addressable DBMS objects when used for recall, workflow derivation, or Skill Package execution. | | Derivation Ledger | External processing services | External parsers or models may participate, but the DBMS records derivation. | | Temporal Supersession Engine | Source-system change logs | The DBMS manages current validity, historical validity, stale state, and supersession. | | Relationship Edges | External graph or index implementations | Edge semantics, permissions, and audit remain DBMS responsibilities. | **Retrieval, Access, and Agent-Integration Responsibilities** | Inside the Memory DBMS | Outside but connected through governed connectors | Notes | |---|---|---| | Retrieval planning | Search engines, vector indexes, full-text indexes | External or internal indexes can be mechanisms; retrieval policy is DBMS-owned. | | Authorization and audit | Identity providers and SIEM tools | External systems may integrate, but object-level memory authorization and audit are enforced by the DBMS. | | Active Memory Pools | Collaboration tools and agent workspaces | Pools are governed DBMS working-memory spaces even when surfaced in external tools. | | Context Packages | Agent frameworks and application prompts | Packages are DBMS-assembled projections with source links and permissions. | | Model registry | Model providers | The DBMS tracks approved models, versions, policies, and outputs. | | Tool registry | External APIs and tool servers | The DBMS validates tool identity, schema, privileges, routing, and audit. | **Connected External Systems and Replaceable Mechanisms** | Connected system or mechanism | Examples | Boundary note | |---|---|---| | Source systems of record | Email, ticketing, code, observability, ERP, CRM | These remain authoritative for their native records and feed Source Packages. | | Model providers | Cloud model APIs, local model servers | Providers execute models; DBMS policy controls invocation and persistence. | | Agent frameworks | Agent runtimes and orchestration systems | Frameworks may call DBMS tools but do not own memory governance. | | Collaboration tools | Chat, documents, project workspaces | Collaboration systems can contribute observations and display context. | | External APIs | Business applications and services | Calls enter as governed connector or tool-call records. | | Storage engines or index implementations | Relational stores, object stores, vector indexes, graph engines | Physical mechanisms are replaceable below the logical Memory DBMS boundary. | The boundary matters because the DBMS can integrate external systems without surrendering memory governance to them. Source systems, tools, models, and indexes may remain outside the core. Object identity, provenance, validity, permissions, and audit stay inside the Memory DBMS. The enterprise Memory DBMS must define native support for memory-related and AI-related database objects. These objects are usable by humans, applications, AI agents, Tool-Calling Protocol Adapters such as the initial MCP adapter, and traditional API clients. They are also extensible by developers building applications on top of the Memory DBMS. The purpose of these objects is to make agent support a database capability rather than an application-only integration problem. AI engineers can create, load, inspect, execute, and extend governed Memory Objects without understanding the internal storage details of the DBMS. The DBMS exposes stable object types and DBMS-managed operations. Those operations manage identity, permissions, validation, provenance, audit records, and lifecycle state. This object-and-operation layer is the extension boundary for the DBMS. Developers may add several kinds of extension objects: - New Skill Packages. - Connectors. - Protocol-specific tools such as MCP Tool Definitions for the initial adapter. - Model-Call Functions. - Context-loading strategies. - Application-specific Memory Objects. Those extensions use the same catalog, permission, provenance, validation, and audit framework as the built-in objects. This allows the system to support new agent workflows without turning memory management back into scattered application code. ## 9.2 Enterprise Memory Core The logical architecture must include three architectural domains. The **Enterprise Memory Core** is the durable system of record for institutional memory. It owns the primary Memory Objects and the governance records around them. Those owned records include: - Source archives, Claims, Facts, Episode Objects, and Memory Objects. - Workflows, Procedural Memory Objects, Skill Packages, and Relationship Edges. - Partitions, indexes, catalog metadata, and audit records. - Users, roles, privileges, and model lifecycle metadata. The Enterprise Memory Core must provide a governed object model for the main Memory Objects. That includes Source Packages, Claims, Facts, Episode Objects, Memory Objects, and Memory Detail Objects. It also includes workflows, Procedural Memory Objects, Skill Packages, Relationship Edges, and derived artifacts. These objects must not be treated as loose application records. They are first-class database objects with identifiers, provenance, temporal fields, confidence and precision metadata, lifecycle status, access controls, and links back to supporting evidence. The core also supports recursive detail. Memories, Workflow Traces, Procedural Memory Objects, and Skill Packages can expand from concise summaries into source-linked operational detail when the task requires it. That detail may include steps, substeps, parameters, commands, validations, exceptions, and evidence. When legal and retention policies permit, the core must preserve a **Verbatim Source Archive** of timestamped raw inputs. Future extraction models, embedding models, summarizers, and workflow-mining methods may need the original material rather than only derived records. The system catalog must serve as the central metadata repository for the DBMS. It describes metadata for identity, structure, policy, models, indexes, archives, rebuilds, and operations. Core catalog metadata includes: - Users. - Roles. - Privileges. - Schemas. - Partitions. - Object types. - Relationship Edge types. - Retention policies. - Verification policies. - Source types. Operational catalog metadata includes: - Model versions. - Index definitions. - Active Memory Pools. - Local nodes. - Archive tiers. - Rebuild state. - Operational statistics. The catalog also describes model and tool metadata: - Model-Call Functions. - Prompt templates. - Call instructions. - Tool definitions. - Protocol adapter definitions. - Input and output contracts. - Dispatcher routes. Catalog information is readable through governed query surfaces. Administrators, applications, authorized users, and agents can then inspect the structure, health, usage, and performance of the system. A SQL-compatible interface is one possible access mechanism. At the system level, the catalog exposes statistics for: - Subjects. - Verbs. - Topics. - Projects. - Security domains. - Active Memory Pools. - Model executions. - Tool calls. - Time partitions. The core must provide bitemporal behavior. Every governed Memory Object must distinguish when an event happened or was valid from when the database learned, recorded, modified, or superseded it. New Memory Objects may invalidate or supersede prior Facts without erasing the older historical record. This matters for institutional memory because a statement may be true for a past period, false for the present, and still useful for understanding how a decision or workflow evolved. The core must implement the Derivation Ledger described in Section 4.1. This ledger is the basis for auditability, review, model reprocessing, evidence inspection, and downstream invalidation. Those invalidations may occur when a source, model, Fact, or workflow changes. The core depends on the partitioning, transaction, backup, recovery, and operations requirements described in Section 9.6. Those requirements protect multi-representation memory operations from partial commits without requiring a particular storage engine or index implementation. Core object types must include the objects defined in Section 3 and Appendix A: - **Memory Objects**. - **Episode Objects**. - **Memory Detail Objects**. - **Workflow Traces** and **Generalized Workflows**. - **Procedural Memory Objects**. - **Skill Package Objects**. - **Tool-Calling Protocol Adapter Objects**, including MCP Server Objects and MCP Tool Definitions for the initial adapter. - **Context Package Objects**. - **Connector Objects**. Not every Skill Package or tool needs to be derived automatically from existing memories. The DBMS must support manual creation and loading of Skill Packages, MCP tools for the initial adapter, connector definitions, Context Packages, and curated memory data. A human engineer may author a Skill Package directly. An organization may import a Skill Package from a repository. An application developer may register a connector to an existing API. The DBMS allows these objects to be loaded first, then linked to memories, evidence, Workflow Traces, or validation records as those Relationship Edges become available. DBMS-managed operations provide a consistent way to manage these objects. At minimum, the DBMS supports operations for the core Memory Object lifecycle: - Create. - Register. - Import. - Validate. - Version. - Enable or disable. - Execute. - Audit. - Retire. The same operation layer also supports Active Memory Pool work. It can load context into an Active Memory Pool, retrieve context from an Active Memory Pool, and refresh context during a workflow. It can also promote useful observations into pending Claims, Facts, Memory Objects, workflow updates, or Skill Package refinements. For Skill Packages, the DBMS supports both derived and manually loaded objects. A derived Skill Package may be created from repeated Workflow Traces. A manually loaded Skill Package may be written by a human expert before enough memory exists to derive it. In both cases, the Skill Package must remain a governed database object. It must carry versioning, permissions, input and output contracts, execution policy, confidence, review status, and audit records. Tool-Calling Protocol Adapters and controlled data-gathering calls are described in Section 9.5. At the Enterprise Memory Core boundary, tools, connector calls, and imported results must enter the same governance framework as Memory Objects. That framework includes catalog, permission, provenance, validation, and audit controls. Context loading is a first-class DBMS operation. An agent or application can request a Context Package for a task, project, subject, workflow, or Active Memory Pool. The DBMS assembles the package from authorized: - Memory Objects. - Facts. - Source links. - Skill Packages. - Workflow Traces. - Current observations. The package is compact enough for use in an AI context window while retaining links back to the governed Memory Objects that produced it. ## 9.3 Local Memory Nodes **Local Memory Nodes** allow humans, applications, and AI agents to stage or operate with local subsets of memory near the point of work. They can then synchronize selected Claims, Memory Objects, or Source Packages back to the enterprise system. Local Memory Nodes support offline, private, edge, or personal work without becoming independent ungoverned databases. A local node may hold: - Selected Memory Objects. - Pending Claims. - Source snippets. - Task context. - Local observations. - Synchronization metadata. Bitemporal database designs such as XTDB illustrate one implementation pattern for retaining valid-time and transaction-time history across changing Facts, although the proposed Memory DBMS does not require a specific product design (XTDB, n.d.). When reconnected, the node submits local changes to the Enterprise Memory Core. Those changes may include: - New Claims. - Episode Objects. - Source Packages. - Conflict records. - Deletions or tombstones. - Workflow updates. - Promotion candidates. The enterprise system remains authoritative, but local nodes make memory capture possible closer to where work occurs. ## 9.4 Native Model Execution Engine Model services are treated as replaceable and governed components. The governed model layer may include: - Embedding models. - Rerankers. - Extraction models. - Summarizers. - Workflow-mining models. - Validation models. - Small maintenance language models. Those services may run locally on CPU, locally with GPU acceleration, through approved cloud services, or through another approved model-serving arrangement. GPU-accelerated similarity search and efficient LLM-serving systems show why hardware placement and model-serving design affect retrieval and model-execution performance (Johnson et al., 2021; Kwon et al., 2023). Local execution may improve data locality, latency, and governance control. Cloud execution may offer elasticity, managed operations, and stronger models. The architecture supports both. Model choice is controlled by these factors (Shi et al., 2016; Satyanarayanan, 2017): - Policy. - Workload. - Data sensitivity. - Cost. - Compliance. - Infrastructure availability. The DBMS exposes model execution through DBMS-managed catalog objects and governed operations. SQL-callable functions, stored procedures, jobs, service calls, or workflow steps are possible implementation mechanisms. Within the DBMS framework, administrators can: - Register approved model calls with typed input parameters; - Define prompt templates or embedding configurations; - Specify call instructions and model-routing policies; - Set output contracts, execution privileges, storage targets, and audit requirements. A DBMS-managed operation can invoke an approved model service from within the database boundary. Depending on the implementation, that operation may be exposed through several mechanisms: - SQL function. - Stored procedure. - Trigger. - Scheduled job. - Workflow extraction step. - Skill Package execution. - Active Memory Pool operation. - Service API. Prompts, embedding configurations, and call instructions are governed memory infrastructure. A prompt or configuration is versioned, permissioned, tested, and linked to the outputs it creates. This applies when the system performs model-assisted work such as: - Summarizing an Episode Object. - Extracting a Workflow Trace. - Creating an embedding. - Validating a candidate Procedural Memory Object. - Classifying a Source Package. - Answering a governed recall request. When a model call completes, the result is written directly into the appropriate DBMS-managed destination. That destination may be: - A database object. - A ledger entry. - An Active Memory Pool. - A pending Claim. - An index structure. - A derived artifact. It must not pass through a loose chain of application services. This reduces cross-program orchestration and improves provenance. It also gives the DBMS one place to enforce model policy, transactional integrity, retention, and auditability. The model registry must track: - Model identity. - Version. - Dimensions. - Embedding space. - Prompt or template policy. - Evaluation status. - Rollout state. - Derived artifacts. When embedding models change, the system must support migration strategies that avoid forcing long downtime. Acceptable strategies include blue-green indexes, dual-space query routing during transition, adapter-based alignment between embedding spaces, and staged background re-embedding. Existing research and implementation examples show several paths for embedding migration. These include adapter-based alignment, dimensional adaptation, and alias-based cutovers (Vejendla, 2025; Maystre et al., 2025; Yoon et al., 2024; Adwant, 2026; Qdrant, n.d.; Weaviate, n.d.). The registry must record which Memory Objects, indexes, summaries, workflows, and Skill Packages were produced by which models. That record allows upgrades to be audited, rolled back, compared, or used to trigger targeted reprocessing (Sculley et al., 2015; Mitchell et al., 2019; Gebru et al., 2021; TensorFlow, n.d.). The system also manages embedding write amplification. Multi-view embedding can improve precision, but embedding every memory through every possible scope at ingestion time may create unnecessary storage, cost, and rebuild burden. The DBMS supports embedding budget policies, lazy or deferred embedding, compact routing vectors, partition-specific embedding scopes, and rebuild prioritization. High-value active partitions may receive richer embeddings, while cold historical partitions may rely on fewer embeddings until queried, restored, or selected for reprocessing. The native model execution surface allows approved model services to be invoked through registered DBMS-managed calls. This may include running approved local LLMs, embedding models, rerankers, classifiers, and validation models on internal equipment. It may also include calling approved cloud models through their provider APIs. In a SQL-oriented implementation, these calls may be exposed through registered SQL functions, but the DBMS requirement is governed invocation, not a specific calling syntax. Model-Call Functions may perform several kinds of work. A function might summarize a Source Package, extract candidate Claims, derive workflow steps from Episode Objects, or create embeddings. Other functions might rerank candidate Memory Objects, validate a Procedural Memory Object, classify a Memory Object by subject and action class, generate a retrieval package, or compare conflicting evidence. Each callable operation also binds the controls required for safe execution. Execution controls include: - Executing account. - Model policy. - Prompt template or embedding configuration. - Allowed partitions. - Input schema. - Output contract. - Timeout. - Cost policy. Interface controls include the API endpoint, runtime target, request format, response parser, and persistence target. When cloud model APIs are used, provider-specific authentication, request shape, response mapping, retry policy, and error handling are configurable in the DBMS rather than hard-coded into application services. The output is stored directly in the DBMS with: - Model identity. - Prompt or configuration version. - Source links. - Confidence. - Precision. - Transaction time. - Audit metadata. ## 9.5 LLM Tool-Calling Access Surface The LLM Tool-Calling Access Surface provides a DBMS-managed registry, dispatcher, and audit layer for AI-agent tool use. MCP is the first supported Tool-Calling Protocol Adapter for practical interoperability with current tool-using models. The protocol adapter layer must remain replaceable. In this model, tools may be implemented as database routines, external executables, service calls, proxied MCP tools, or other adapter-specific mechanisms while preserving a single database-managed schema, permission, routing, and logging model. The access surface receives agent requests through a listener, sidecar, embedded service, or equivalent adapter and asks the DBMS for the tool definition. The DBMS verifies that the tool exists and is enabled. It then checks permissions and validates input against the registered schema. After validation, the system dispatches the call according to implementation type and captures the result. It then validates output against the registered contract, writes the audit log, and returns a normalized response through the active protocol adapter. Moving the tool-calling registry and dispatcher into the DBMS creates an enterprise security advantage. Agents do not receive a separate ungoverned tool universe with its own permissions and logs. Tool access can use the same DBMS controls used for SQL, retrieval, workflow execution, and Active Memory Pools: - Accounts. - Roles. - Grants. - Partition rules. - Derivation Ledger. - Model registry. - Audit controls. Natural-language agent access then remains compatible with database governance. An agent can ask for memories, workflows, Skill Packages, or Active Memory Pool context through MCP or a future tool-calling protocol. The DBMS still decides which tool exists, which data may be touched, how inputs and outputs are validated, and how the call is recorded. The protocol layer remains replaceable. If tool-calling conventions move from MCP to another protocol or interaction model, the DBMS must preserve the same catalog, permission, validation, routing, and audit abstractions. Only the listener and protocol adapter layer may need replacement or extension. For MCP servers and tools, and for later protocol adapters, the DBMS maintains a governed registry. The registry identifies each protocol endpoint, the tools it exposes, the schemas those tools accept, the privileges required to call them, and the data partitions they may access. A tool may call a database operation, invoke an external process, call another protocol server, or proxy a governed API. The DBMS must still validate inputs, enforce permissions, record the call, and store the result in the appropriate memory or workflow context. Agent workflows also require controlled data gathering. During a workflow, an AI agent may need current operational state from several places: - An API. - An application query. - A file inspection. - A source record. - A protocol server such as an MCP server. These calls are represented as governed connector or tool calls rather than untracked external activity. Results enter the DBMS as Source Packages, observations, pending Claims, Active Memory Pool updates, or workflow execution records. This preserves provenance and allows later review of what the agent saw and why it acted. ## 9.6 Partitioning, Backup, Recovery, and Operations Partitioning is required for performance, governance, lifecycle management, and future distribution. The system supports partitions by: - Subject. - Project. - Security domain. - Time range. - Workflow. - Source domain. - Retention policy. - Active Memory Pool. Cross-partition queries must be explicit about authorization and result assembly. Memory Objects often reference Facts, sources, or workflows outside their primary project. As the system grows, partitioning also becomes the first step toward a distributed memory database that can operate across equipment in a network. High availability and active-active replication remain outside the initial scope. The DBMS must define transaction semantics for multi-representation writes. A single operation may update several representations (Gray & Reuter, 1992): - Object metadata. - Source links. - Graph Relationship Edges. - Temporal windows. - Full-text indexes. - Semantic indexes such as vector indexes when used. - Workflow records. - Audit logs. The proposed architecture does not require a particular storage engine, but the DBMS must provide an internal transaction boundary that prevents partially committed memory operations. Existing storage engines and database APIs illustrate possible implementation substrates, but they do not define the memory architecture itself (LMDB Project, n.d.; TidesDB, n.d.). A unified logical write-ahead log, global commit sequence, MVCC strategy, or equivalent mechanism makes crash recovery able to restore all internal stores to a consistent state. Critical promotion and supersession operations require stronger isolation guarantees than low-risk maintenance tasks. Backup and recovery prioritize durable assets that cannot be cheaply regenerated. Core recovery assets include: - All metadata. - System catalogs. - Memory Objects. - Facts. - Claims. - Derived workflows. - Skill Packages. Embeddings, semantic indexes including vector indexes when used, summaries, routing structures, and other derived artifacts are recoverable through rebuild procedures when source data and metadata remain intact. For large deployments, this strategy can reduce total cost of ownership by avoiding full backup of every rebuildable semantic artifact. It still requires tested rebuild ordering, restore validation, and audit records showing which models, source snapshots, templates, and index definitions were used during recovery. The DBMS must expose stable client access surfaces. At minimum, it supports common enterprise programming environments such as Python, Node.js, PHP, and other languages through drivers, APIs, or protocol bindings. It also supports a query surface that combines structured requests, SQL-like inspection where appropriate, and prompt-plus retrieval commands for memory-oriented recall. Applications can retrieve memories, sources, workflows, Skill Packages, and Active Memory Pool context without depending on a single proprietary client workflow. Once those implementation responsibilities are defined, the architecture needs empirical validation. # 10. Empirical Evaluation Plan The evaluation plan turns the architecture into testable prototype questions. It treats retrieval quality as only one part of the proof; grounding, temporal reasoning, workflow derivation, calibration, security, and recovery also have to be measured. The architecture is evaluated as a Memory DBMS, not only as a retrieval application. Evaluation measures whether the system retrieves the right memories, preserves evidence, supports long-term context, derives workflows safely, calibrates confidence, avoids leaking unauthorized information, and can recover derived artifacts when models or indexes change. The evaluation matrix names each phase, the question it answers, and the prototype definition work required before measurement can begin. It is a test plan for the category boundary, not a generic retrieval benchmark checklist. | Phase | Evaluation Question | Example Metrics | Prototype Definition Needed | |---|---|---|---| | Retrieval quality | Does the DBMS retrieve the right Memory Objects, Facts, workflows, and Source Packages for heterogeneous queries? | Recall@k, nDCG@10, MRR, answer latency, evidence-retrieval coverage | Define query sets, corpus slices, and baseline retrieval systems. | | Grounding and evidence support | Are answers and retrieved packages backed by specific, authorized, current evidence? | Citation coverage, citation precision, source-link usability, grounding error rate | Define annotation policy for source support and citation quality. | | Temporal reasoning and staleness | Does the DBMS distinguish current-valid, historical, stale, superseded, and contradicted knowledge? | Stale-memory rejection rate, temporal accuracy, supersession detection, abstention quality | Define temporal test cases and accepted staleness behavior. | | Workflow and Skill Package derivation | Do candidate workflows and Skill Packages match evidence and validated process records? | Conformance fitness, replay fitness, precision, generalization, exception detection | Define promotion criteria and review gates. | | Confidence and precision calibration | Do confidence and precision scores reflect observed reliability for each object type and source class? | Expected calibration error, reliability diagrams, overconfidence rate, confidence drift | Define calibration datasets and recalibration triggers. | | Security and governance | Do retrieval, summaries, Active Memory Pools, model calls, and tools avoid exposing unauthorized information? | Leakage red-team pass rate, authorization failure rate, audit completeness, policy regression count | Define negative-test suite and red-team scenarios. | | Operational recovery and rebuilds | Can durable memory state and rebuildable artifacts be restored consistently? | Restore time, rebuild correctness, rebuild completeness, audit replay coverage | Define backup, restore, and rebuild validation procedures. | The evaluation phases mirror the architecture's claims. A prototype that retrieves relevant text but cannot preserve evidence, respect time, govern access, validate workflows, or rebuild derived artifacts would not satisfy the Memory DBMS boundary proposed here. ## 10.0 Open Prototype Evaluation Tasks The first prototype requires a concrete evaluation package. That work includes defining baseline systems for comparison, including a vector-store/RAG baseline, a knowledge-graph baseline, and a manually curated workflow baseline. It also requires test corpora and Source Packages that represent realistic enterprise documents, tickets, logs, meeting notes, Workflow Traces, and source-system records. The retrieval track requires query sets for exact lookup, semantic recall, Relationship Edge traversal, workflow lookup, and recursive detail expansion. The grounding track requires a source-support annotation protocol for memories, generated answers, Context Packages, and Skill Package guidance. The temporal track requires test cases for valid time, transaction time, supersession, staleness, and historical recall. The workflow track requires promotion criteria for moving candidate workflows into Procedural Memory Objects or Skill Packages, along with validation fixtures using event logs, tickets, command histories, Episode Objects, and Source Packages. The confidence track requires calibration datasets, policy versions, and recalibration triggers for Claims, Facts, memories, workflows, and Skill Packages. The security track requires regression tests for retrieval leakage, summary leakage, unauthorized graph traversal, stale pool access, source-package prompt injection, and unsafe MCP/tool calls. The recovery track requires backup, restore, archive recall, and derived-artifact rebuild procedures for prototype evaluation. ![Figure 8: Evaluation Pipeline](Figure-8.pdf) *Figure 8: Evaluation Pipeline.* ## 10.1 Retrieval Quality Retrieval quality is tested with heterogeneous benchmark collections and enterprise-like corpora. BEIR can provide a broad zero-shot retrieval baseline, while LoCo can test whether the architecture handles long-context retrieval cases where relevant evidence may be distributed across long documents or many chunks (Thakur et al., 2021; Saad-Falcon et al., 2024). Target metrics must include Recall@k, nDCG@10, MRR, answer latency, evidence-retrieval coverage, and the percentage of returned memories with usable provenance links. Evaluation question: does the DBMS retrieve the right Memory Objects, Facts, workflows, and Source Packages without relying only on generic semantic similarity? Example metrics: Recall@k, nDCG@10, MRR, answer latency, evidence-retrieval coverage, and the percentage of returned memories with usable provenance links. ## 10.2 Grounding and Evidence Support Citation faithfulness and answer grounding are tested before answers are trusted in production. RAG-QA Arena-style evaluation can help measure whether generated answers remain grounded in retrieved sources across domains (Han et al., 2024). For this DBMS, the evaluation also checks whether source links are specific, authorized, current, and sufficient for human review. Evaluation question: are answers and retrieval packages grounded in specific Source Packages, Claims, Facts, and evidence links that the caller is authorized to inspect? Example metrics: citation coverage, citation precision, source-link usability, grounding error rate, unsupported-answer rate, and authorization-correct citation rate. ## 10.3 Temporal Reasoning and Staleness Long-term memory quality is evaluated separately from ordinary search. LongMemEval-style tasks can test multi-session memory, memory updates, temporal reasoning, and abstention when the system does not have enough evidence (Wu et al., 2024). The DBMS reports whether it retrieves the correct prior Memory Object, recognizes superseded Memory Objects, avoids stale operational guidance, and preserves links to the Claims and sources that support the answer. Evaluation question: does the DBMS distinguish current-valid knowledge from historical, stale, superseded, contradicted, or insufficiently supported knowledge? Example metrics: stale-memory rejection rate, temporal accuracy, supersession detection, contradiction handling, and abstention quality. ## 10.4 Workflow and Skill Derivation Workflow and Skill Package derivation require their own validation track. Candidate workflows are compared against event logs and process-mining baselines before they are promoted into Procedural Memory Objects or executable Skill Packages. PM4Py and public event-log datasets such as BPI Challenge 2019 can support tests of process discovery, conformance checking, replay fitness, precision, generalization, and exception detection (Berti et al., 2023; van Dongen, 2019). Evaluation question: do candidate Workflow Traces, Generalized Workflows, Procedural Memory Objects, and Skill Packages match evidence and validated process records? Example metrics: conformance fitness, replay fitness, precision, generalization, exception detection, review acceptance rate, and unsafe-promotion rejection rate. ## 10.5 Confidence and Precision Calibration Confidence and precision are evaluated as operational data, not just metadata. Calibration tests report expected calibration error, reliability diagrams, overconfidence by source type, and confidence drift after model or source changes (Guo et al., 2017). A Memory DBMS can show that high-confidence memories are actually more reliable than low-confidence memories in the reviewed evaluation set. Evaluation question: do confidence and precision fields accurately guide retrieval, review, promotion, and safe action for the relevant object type and source class? Example metrics: expected calibration error, reliability diagrams, overconfidence rate by source type, confidence drift, and precision-at-threshold for promoted objects. ## 10.6 Security and Governance Security and governance evaluation must include negative tests. The system verifies that unauthorized memories are not exposed through semantic similarity, Active Memory Pools, graph expansion, summaries, model calls, MCP tools, or citation links. These tests are repeated after index rebuilds, embedding-model migrations, archive restores, connector changes, and policy updates. Evaluation question: do retrieval, summaries, Active Memory Pools, model calls, tool calls, and citations enforce authorization and audit requirements across ordinary and adversarial cases? Example metrics: leakage red-team pass rate, authorization failure rate, graph-traversal leakage rate, summary leakage rate, tool-call policy violation rate, and audit completeness. ## 10.7 Operational Recovery and Rebuilds Operational recovery tests whether durable Memory Objects, provenance, temporal records, policies, and audit logs survive failure and restore. Rebuild tests verify that embeddings, semantic indexes, summaries, routing structures, and other derived artifacts can be regenerated from preserved source data, metadata, model records, and policy records. Evaluation question: can the DBMS restore durable memory state and rebuild derived artifacts without losing provenance, policy state, or temporal correctness? Example metrics: restore time, rebuild correctness, rebuild completeness, consistency checks passed, audit replay coverage, and post-restore retrieval parity. The conclusion will tie the proposed objects, governance model, implementation boundary, and evaluation plan back to the core architecture. # 11. Conclusion Organizations do not merely need more storage, larger context windows, or another retrieval application. They need a durable way to preserve what was known, how it became known, when it was valid, who may use it, and how it informs later work. The problem is not a shortage of records. It is that records, source evidence, interpretations, decisions, procedures, and AI-ready context are usually spread across separate systems and application logic. Institutional knowledge is reconstructed again and again, and agents that act on reconstructed context can inherit stale instructions, unsupported summaries, or information they were never authorized to use. The core of the proposed architecture is a memory-native DBMS model. Source Packages preserve original evidence. Claims preserve what a source asserted before the system accepts it as truth. Facts represent assertions accepted within a defined scope. Memory Objects and Episode Objects preserve institutional meaning around those assertions. Memory Detail Objects allow memories and procedures to expand only to the depth required by a task. The Derivation Ledger records how objects were produced, revised, validated, superseded, or retired. That object model gains its force from temporal and evidentiary controls. A Memory DBMS must distinguish what was true in the represented world from what the database knew at a given transaction time. It must also distinguish confidence from precision, and both from current validity. These distinctions matter because a statement can be historically accurate yet unsafe for current operational use, highly precise yet weakly supported, or strongly supported yet no longer current. Retrieval in this architecture is not generic semantic search. Vector search, graph traversal, temporal filtering, full-text retrieval, source inspection, workflow lookup, and recursive detail expansion are all useful, but the contribution is their organization around Memory Objects, Relationship Edges, policy-aware retrieval packages, and auditable evidence paths. Search results are not just ranked text. They are structured packages that expose why a memory was returned, what supports it, what contradicts it, whether it remains valid, and whether the requesting actor may use it. Active Memory Pools extend durable memory into shared working context. They allow people, agents, tools, and service accounts to collaborate inside a task-scoped memory space with permissions, provenance, retention, and promotion rules attached. Context Packages then project durable memories, current Facts, workflow guidance, Skill Packages, and pool observations into compact AI-usable form without replacing the underlying database objects. This is especially important for multi-agent work, where private or stale context can lead to inconsistent assumptions and unsafe action. The same structure supports workflow and Skill Package derivation. Repeated Episode Objects and Memory Detail Objects can produce Workflow Traces. Similar traces can be generalized, validated, and promoted into Procedural Memory Objects. With sufficient evidence, review, current-valid preconditions, exception handling, security policy, and audit controls, those objects can become Skill Packages that guide repeatable work. A Skill Package is therefore not simply a prompt or script; it is procedural knowledge tied to source evidence and lifecycle state. The proposal deliberately uses existing and familiar components where they fit. Vector search, graph databases, temporal modeling, provenance standards, model execution, tool-calling protocols, workflow mining, and backup/recovery mechanisms all inform the design. The paper does not claim that these components are individually new or that the architecture is already proven. Its contribution is the organization of these capabilities around memory-native DBMS objects, controlled derivation, and shared use by people and AI systems. Preserving source evidence keeps the system upgradeable. As models, indexes, tool protocols, workflow extractors, and policies change, the DBMS can rebuild derived artifacts without losing provenance or erasing earlier interpretations. The next step is empirical validation: prototype implementation, retrieval and grounding tests, temporal and confidence calibration, workflow-validation experiments, security regression testing, and recovery/rebuild evaluation. Those tests will determine where the architecture succeeds, where it needs constraint, and what is required before a Memory DBMS can become a practical foundation for long-term institutional memory. # Appendix A. Proposed Terminology This appendix provides a consistent vocabulary for the paper. The first table maps the grammar-inspired analogy used for explanation to the formal DBMS terminology used in the architecture. | Grammar-Inspired Term | Formal DBMS Term | Recommended Use | |---|---|---| | Subject | Entity Anchor | Primary organizing entity | | Verb | Action Class | What happened or what is being remembered | | Predicate | Semantic Frame | Structured meaning of the memory | | Object | Target / Memory Payload | Thing acted on or remembered | | Preposition | Relationship Edge | Connection between Memory Objects, Facts, Claims, sources, workflows, and entities | The model may still be described as grammar-inspired, but the formal architecture uses **Relationship Edge** rather than **Preposition**. Prepositions provide useful human-readable labels for many relationships, but institutional memory requires a broader graph structure that can represent temporal, causal, evidentiary, procedural, hierarchical, and semantic connections. Therefore, the paper uses the term Relationship Edge to describe typed edges between Memory Objects, Facts, Claims, sources, workflows, entities, and timelines. The proposed memory organization model is: Subject → Verb → Predicate → Object ↔ Relationship Edge The next table separates conceptual memory-theory terms from the formal object names used by the proposed DBMS. | Conceptual Memory Term | DBMS Representation | Recommended Use | |---|---|---| | Episodic Memory | Episode Object | Use the Section 3.5 definition; "event memory" may be used only as an informal synonym. | | Semantic Memory | Facts, Relationship Edges, and semantic indexes | Stable knowledge about entities, concepts, meanings, and relationships. | | Procedural Memory | Procedural Memory Object | Use the Section 3.9 definition. | | Working Memory | Active Memory Pool | Temporary shared task context for humans and AI agents. | In this terminology, **episodic memory** and **procedural memory** remain conceptual memory-theory terms, while **Episode Object** and **Procedural Memory Object** are the formal DBMS object names defined in Section 3. The final tables are the terminology reference for the rest of the paper. They keep formal names stable and use cross-references where the full definition appears earlier. | Canonical Object Term | Meaning | |---|---| | **Episode Object** | See Section 3.5. | | **Memory Detail Object** | See Section 3.6. | | **Recursive Detail** | Expansion of Memory Detail Objects only to the depth required by a task, query, review, or Skill Package execution. | | **Workflow Trace** | See Section 3.7. | | **Generalized Workflow** | See Section 3.8. | | **Procedural Memory Object** | See Section 3.9. | | **Skill Package** | See Section 3.10. | | **Competency** | See Section 3.10. | | **Active Memory Pool** | Scoped working-memory space for a task, project, incident, agent group, or collaboration session. | | **Derivation Ledger** | Auditable lineage from Source Packages through derived memory, workflow, Skill Package, and artifact records. | The remaining canonical terms name subsystems, operations, and access surfaces that enforce or expose the object model. | Canonical Subsystem or Access Term | Meaning | |---|---| | **Temporal Supersession Engine** | DBMS subsystem for valid-time windows, transaction-time history, corrections, supersession, staleness, and current validity. | | **Security-Aware Retrieval Coordinator** | Subsystem that builds authorization context, prefilters retrieval, post-validates candidates, and assembles policy-aware result packages. | | **Native Model Execution Engine** | DBMS subsystem that invokes approved model services through governed DBMS-managed calls and stores outputs directly in database objects. | | **Model-Call Operation** | Governed DBMS operation binding model configuration, policy, input schema, output contract, storage target, and audit requirement. | | **LLM Tool-Calling Access Surface** | Database-managed listener, registry, dispatcher, validation, permission, protocol adapter, and audit surface for governed memory tools. | | **Tool-Calling Protocol Adapter** | Protocol-specific adapter, initially MCP, that translates agent tool calls into the DBMS-managed tool model. | | **MCP Tool Definition** | Catalog object describing an MCP-accessible tool, including implementation type, state, schema, privileges, routing, and audit policy. | | **Transaction and Recovery Manager** | Subsystem for isolation, crash recovery, and internal multi-representation atomicity through WAL, MVCC, global commit sequence, or equivalent mechanism. | # Appendix B. Canonical Object Field Sets The field groups below are conceptual. They identify minimum metadata that each object must carry without prescribing physical schema design. A final implementation may normalize, partition, index, or materialize these fields differently. ## Source Package ```text Identity and versioning: source_package_id, version, created_at, updated_at, content_hash Classification: source_type, source_class, source_system, trust_label, retention_class Source and evidence: source_uri, source_time, verbatim_archive_uri, extracted_text_link, evidence_scope Provenance and derivation: ingestion_run_id, parser_or_connector_id, derivation_ledger_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: source_reliability_score, extraction_quality_score, precision_notes Relationship Edges: relationship_edge_links, derived_object_links Security and access control: access_policy_id, security_labels, partition_ids, quarantine_state Lifecycle state: lifecycle_state, retention_state, legal_hold_state Audit metadata: audit_event_links, policy_version ``` ## Claim ```text Identity and versioning: claim_id, version, created_at, updated_at Classification: claim_type, subject_anchor, action_class, object_anchor Source and evidence: claim_text, source_package_links, source_span_links, evidence_links Provenance and derivation: extraction_run_id, evaluator_id, derivation_ledger_links Temporal fields: source_time, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: raw_component_scores, aggregate_confidence, aggregate_precision, weights, calibration_dataset_version, last_calibration_date Relationship Edges: supporting_claim_links, contradicting_claim_links, relationship_edge_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, review_status Audit metadata: audit_event_links, policy_version ``` ## Fact ```text Identity and versioning: fact_id, version, created_at, updated_at Classification: fact_type, subject_anchor, action_class, object_anchor, scope Source and evidence: accepted_claim_links, supporting_evidence_links, contradicting_evidence_links Provenance and derivation: verification_run_id, verifier_id, derivation_ledger_links Temporal fields: event_time, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, verification_time, stale_after Confidence and precision: raw_component_scores, aggregate_confidence, aggregate_precision, weights, calibration_dataset_version, last_calibration_date Relationship Edges: relationship_edge_links, supersedes_links, superseded_by_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, contradiction_status, verification_status Audit metadata: audit_event_links, policy_version ``` ## Memory Object ```text Identity and versioning: memory_id, version, created_at, updated_at Classification: memory_type, subject_anchor, action_class, Semantic Frame, salience Source and evidence: summary, fact_links, claim_links, source_package_links, evidence_links Provenance and derivation: derivation_ledger_links, evaluator_id, model_version Temporal fields: event_time, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: component_confidence_links, aggregate_confidence, aggregate_precision, calibration_dataset_version Relationship Edges: relationship_edge_links, episode_links, detail_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, staleness_status, supersession_status Audit metadata: audit_event_links, policy_version ``` ## Episode Object ```text Identity and versioning: episode_id, version, created_at, updated_at Classification: episode_type, subject_anchors, action_class, Semantic Frame, outcome Source and evidence: memory_links, source_package_links, evidence_links, participant_links Provenance and derivation: claim_links, fact_links, derivation_ledger_links Temporal fields: event_time, source_time, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, verification_time, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, component_scores Relationship Edges: relationship_edge_links, workflow_trace_links, detail_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, replay_status Audit metadata: audit_event_links, policy_version ``` ## Memory Detail Object ```text Identity and versioning: memory_detail_id, version, created_at, updated_at Classification: detail_type, detail_order, detail_depth, action_class Source and evidence: detail_text, command_or_parameter_value, source_package_links, evidence_links Provenance and derivation: parent_object_id, parent_object_type, derivation_ledger_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, component_scores Relationship Edges: child_detail_links, relationship_edge_links, workflow_step_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, reuse_status Audit metadata: audit_event_links, policy_version ``` ## Derivation Ledger Entry ```text Identity and versioning: ledger_entry_id, version, created_at, updated_at Classification: activity_type, derivation_stage, object_type Source and evidence: input_object_links, output_object_links, source_package_links, evidence_links Provenance and derivation: actor_id, evaluator_id, parser_id, model_version, prompt_template_id, tool_call_links Temporal fields: activity_time, transaction_time_start, transaction_time_end Confidence and precision: confidence_delta, precision_delta, scoring_policy_version Relationship Edges: relationship_edge_links, prior_revision_links, supersession_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, replay_status Audit metadata: audit_event_links, policy_version ``` ## Workflow Trace ```text Identity and versioning: workflow_trace_id, version, created_at, updated_at Classification: case_id, workflow_family, subject_anchor, action_class, outcome Source and evidence: episode_links, step_links, actor_links, input_links, output_links, source_package_links, evidence_links Provenance and derivation: extraction_run_id, derivation_ledger_links, reviewer_id Temporal fields: event_time_start, event_time_end, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, step_confidence_links Relationship Edges: relationship_edge_links, generalized_workflow_links, exception_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, validation_status Audit metadata: audit_event_links, policy_version ``` ## Generalized Workflow ```text Identity and versioning: generalized_workflow_id, version, created_at, updated_at Classification: workflow_family, scope, applicability_conditions, outcome_class Source and evidence: workflow_trace_links, supporting_episode_links, contradicting_trace_links, evidence_links Provenance and derivation: derivation_ledger_links, clustering_run_id, reviewer_id Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, validation_score, calibration_dataset_version Relationship Edges: step_pattern_links, variant_links, exception_links, relationship_edge_links Security and access control: access_policy_id, security_labels, partition_ids Lifecycle state: lifecycle_state, validation_status, supersession_status Audit metadata: audit_event_links, policy_version ``` ## Procedural Memory Object ```text Identity and versioning: procedural_memory_id, version, created_at, updated_at Classification: capability_name, task_family, applicability_conditions, risk_class Source and evidence: generalized_workflow_links, step_links, validation_links, evidence_links Provenance and derivation: derivation_ledger_links, reviewer_id, approval_record_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, validation_confidence, calibration_dataset_version Relationship Edges: relationship_edge_links, Skill Package links, exception_links, rollback_links Security and access control: access_policy_id, security_labels, partition_ids, required_privileges Lifecycle state: lifecycle_state, validation_status, retirement_status Audit metadata: audit_event_links, policy_version ``` ## Skill Package ```text Identity and versioning: skill_package_id, version, created_at, updated_at Classification: skill_package_name, task_family, competency_links, risk_class Source and evidence: procedural_memory_links, workflow_links, validation_links, evidence_links Provenance and derivation: derivation_ledger_links, author_or_importer_id, approval_record_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: aggregate_confidence, aggregate_precision, review_status, calibration_dataset_version Relationship Edges: relationship_edge_links, tool_links, model_call_links, rollback_links, supersession_links Security and access control: access_policy_id, security_labels, partition_ids, execution_policy, required_privileges Lifecycle state: lifecycle_state, enabled_state, suspension_reason, retirement_status Model/tool metadata: input_contract, output_contract, tool_requirements, model_policy_id Audit metadata: audit_event_links, policy_version ``` ## Active Memory Pool ```text Identity and versioning: active_memory_pool_id, version, created_at, updated_at Classification: pool_scope, task_type, subject_anchor, time_mode Source and evidence: loaded_context_links, source_package_links, evidence_links Provenance and derivation: context_package_links, promotion_candidate_links, derivation_ledger_links Temporal fields: opened_at, closed_at, valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: context_confidence_summary, context_precision_summary Relationship Edges: member_links, agent_links, tool_links, relationship_edge_links Security and access control: access_policy_id, security_labels, partition_ids, membership_policy, delegation_chain_links Lifecycle state: lifecycle_state, refresh_state, archive_state Audit metadata: audit_event_links, policy_version ``` ## Context Package ```text Identity and versioning: context_package_id, version, created_at, updated_at Classification: request_id, request_intent, time_mode, detail_depth Source and evidence: memory_links, fact_links, workflow_links, skill_package_links, source_package_links, evidence_links Provenance and derivation: retrieval_plan_id, active_memory_pool_id, derivation_ledger_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after, refresh_time Confidence and precision: package_confidence_summary, package_precision_summary, filtered_object_summary Relationship Edges: relationship_edge_links, returned_object_links, redacted_object_links Security and access control: requesting_actor_id, access_policy_id, security_labels, partition_ids, authorization_envelope_id Lifecycle state: lifecycle_state, refresh_state, invalidation_reason Audit metadata: audit_event_links, policy_version ``` ## MCP Tool Definition ```text Identity and versioning: mcp_tool_definition_id, version, created_at, updated_at Classification: tool_name, protocol_adapter_id, implementation_type, enabled_state Source and evidence: registration_source, documentation_links, evidence_links Provenance and derivation: registrar_id, approval_record_links, derivation_ledger_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Relationship Edges: tool_links, model_call_links, source_system_links, relationship_edge_links Security and access control: access_policy_id, security_labels, partition_ids, required_privileges, allowed_partitions Lifecycle state: lifecycle_state, suspension_reason, retirement_status Model/tool metadata: input_schema, output_schema, execution_policy, routing_policy, timeout_policy, cost_policy Audit metadata: audit_event_links, audit_policy, policy_version ``` ## Model-Call Function ```text Identity and versioning: model_call_function_id, version, created_at, updated_at Classification: function_name, model_task_type, execution_mode, risk_class Source and evidence: prompt_template_links, source_package_links, evidence_links Provenance and derivation: model_id, model_version, evaluator_id, derivation_ledger_links Temporal fields: valid_time_start, valid_time_end, transaction_time_start, transaction_time_end, stale_after Confidence and precision: calibration_dataset_version, last_calibration_date, expected_confidence_behavior Relationship Edges: output_object_links, tool_links, context_package_links, relationship_edge_links Security and access control: access_policy_id, security_labels, partition_ids, required_privileges, allowed_partitions Lifecycle state: lifecycle_state, rollout_state, suspension_reason, retirement_status Model/tool metadata: input_schema, output_contract, execution_policy, storage_target, prompt_policy_id, cost_policy Audit metadata: audit_event_links, policy_version ``` # Appendix C. Research and Standards References Alqithami, S. (2025). "Forgetful but Faithful: A Cognitive Memory Architecture and Benchmark for Privacy-Aware Generative Agents." arXiv:2512.12856. [Link](https://arxiv.org/abs/2512.12856) Argote, L., & Ingram, P. (2000). "Knowledge Transfer: A Basis for Competitive Advantage in Firms." *Organizational Behavior and Human Decision Processes*, 82(1), 150-169. [Link](https://www.sciencedirect.com/science/article/pii/S0749597800928930) Asai, A., Wu, Z., Wang, Y., Sil, A., & Hajishirzi, H. (2024). "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." *ICLR 2024*. arXiv:2310.11511. [Link](https://arxiv.org/abs/2310.11511) Baddeley, A. (1992). "Working Memory: The Interface between Memory and Cognition." *Journal of Cognitive Neuroscience*, 4(3), 281-288. [Link](https://pubmed.ncbi.nlm.nih.gov/23964884/) Barnett, S., Kurniawan, S., Thudumu, S., Brannelly, Z., & Abdelrazek, M. (2024). "Seven Failure Points When Engineering a Retrieval Augmented Generation System." *CAIN 2024*. arXiv:2401.05856. [Link](https://arxiv.org/abs/2401.05856) Berti, A., van Zelst, S., & Schuster, D. (2023). "PM4Py: A process mining library for Python." *Software Impacts*, 17, 100556. [Link](https://doi.org/10.1016/j.simpa.2023.100556) Buneman, P., Khanna, S., & Tan, W.-C. (2001). "Why and Where: A Characterization of Data Provenance." *ICDT 2001*. [Link](https://homepages.inf.ed.ac.uk/opb/papers/ICDT2001.pdf) Cheney, J., Chiticariu, L., & Tan, W.-C. (2009). "Provenance in Databases: Why, How, and Where." *Foundations and Trends in Databases*, 1(4), 379-474. [Link](https://research.ibm.com/publications/provenance-in-databases-why-how-and-where) Cohen, N. J., & Squire, L. R. (1980). "Preserved learning and retention of pattern-analyzing skill in amnesia: Dissociation of knowing how and knowing that." *Science*, 210(4466), 207-210. [Link](https://pubmed.ncbi.nlm.nih.gov/7414331/) Consultative Committee for Space Data Systems. (2024). *Reference Model for an Open Archival Information System (OAIS).* CCSDS 650.0-M-3; ISO 14721:2025. [Link](https://ccsds.org/searchpubs/entry/3054/) Galan, N. (2023). "Knowledge loss induced by organizational member turnover: a review of empirical literature, synthesis and future research directions (Part I)." *The Learning Organization*, 30(2), 117-136. [Link](https://doi.org/10.1108/TLO-09-2022-0107) Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daume III, H., & Crawford, K. (2021). "Datasheets for Datasets." *Communications of the ACM*, 64(12), 86-92. [Link](https://dl.acm.org/doi/10.1145/3458723) Gray, J., & Reuter, A. (1992). *Transaction Processing: Concepts and Techniques.* Morgan Kaufmann. [Link](https://dl.acm.org/doi/10.5555/573304) Guo, C., Pleiss, G., Sun, Y., & Weinberger, K. Q. (2017). "On Calibration of Modern Neural Networks." *ICML 2017*, 1321-1330. arXiv:1706.04599. [Link](https://arxiv.org/abs/1706.04599) Han, R., Zhang, Y., Qi, P., Xu, Y., Wang, J., Liu, L., Wang, W. Y., Min, B., & Castelli, V. (2024). "RAG-QA Arena: Evaluating Domain Robustness for Long-form Retrieval Augmented Question Answering." *EMNLP 2024*, 4354-4374. [Link](https://aclanthology.org/2024.emnlp-main.249/) Heindorf, S., Scholten, Y., Wachsmuth, H., Ngonga Ngomo, A.-C., & Potthast, M. (2020). "CauseNet: Towards a Causality Graph Extracted from the Web." *CIKM 2020*, 3023-3030. [Link](https://doi.org/10.1145/3340531.3412763) Hogan, A., Blomqvist, E., Cochez, M., D'Amato, C., de Melo, G., Gutierrez, C., et al. (2021). "Knowledge Graphs." *ACM Computing Surveys*, 54(4), Article 71. [Link](https://dl.acm.org/doi/10.1145/3447772) IEEE Task Force on Process Mining. (2012). "Process Mining Manifesto." *Business Process Management Workshops*, LNBIP 99, 169-194. [Link](https://www.tf-pm.org/upload/1580737614108.pdf) Jaimini, U., & Sheth, A. (2022). "CausalKG: Causal Knowledge Graph Explainability Using Interventional and Counterfactual Reasoning." *IEEE Internet Computing*, 26(1), 43-50. [Link](https://doi.org/10.1109/MIC.2021.3133551) Johnson, J., Douze, M., & Jegou, H. (2021). "Billion-scale similarity search with GPUs." *IEEE Transactions on Big Data*, 7(3), 535-547. [Link](https://doi.org/10.1109/TBDATA.2019.2921572) Joint Task Force. (2020). *Security and Privacy Controls for Information Systems and Organizations* (NIST SP 800-53 Rev. 5). National Institute of Standards and Technology. [Link](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) Kent, K., & Souppaya, M. (2006). *Guide to Computer Security Log Management.* NIST SP 800-92. [Link](https://csrc.nist.gov/pubs/sp/800/92/final) Keeney, R. L., & Raiffa, H. (1976). *Decisions with Multiple Objectives: Preferences and Value Tradeoffs.* Wiley. Khattab, O., & Zaharia, M. (2020). "ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT." *SIGIR 2020*, 39-48. [Link](https://arxiv.org/abs/2004.12832) Ko, A. J., DeLine, R., & Venolia, G. (2007). "Information Needs in Collocated Software Development Teams." *ICSE 2007*, 344-353. [Link](https://doi.org/10.1109/ICSE.2007.45) Kulkarni, K., & Michels, J.-E. (2012). "Temporal Features in SQL:2011." *SIGMOD Record*. [Link](https://dl.acm.org/doi/10.1145/2380776.2380786) Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H., & Stoica, I. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." *SOSP 2023*. arXiv:2309.06180. [Link](https://arxiv.org/abs/2309.06180) Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." *NeurIPS 2020*. [Link](https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html) Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). "Lost in the Middle: How Language Models Use Long Contexts." *Transactions of the Association for Computational Linguistics*, 12, 157-173. [Link](https://aclanthology.org/2024.tacl-1.9/) Maystre, L., Ortega Gonzalez, A., Park, C., Dolga, R., Berariu, T., Zhao, Y., & Ciosek, K. (2025). "When Embedding Models Meet: Procrustes Bounds and Applications." arXiv:2510.13406. [Link](https://arxiv.org/abs/2510.13406) Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., et al. (2019). "Model Cards for Model Reporting." *FAT 2019*. [Link](https://arxiv.org/abs/1810.03993) Model Context Protocol. (2025). *Specification* (Protocol revision 2025-11-25). [Link](https://modelcontextprotocol.io/specification/2025-11-25) Moreau, L., & Missier, P. (eds.). (2013). "PROV-DM: The PROV Data Model." W3C Recommendation. [Link](https://www.w3.org/TR/prov-dm/) NIST. (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0).* [Link](https://www.nist.gov/itl/ai-risk-management-framework) Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., & Gonzalez, J. E. (2023). "MemGPT: Towards LLMs as Operating Systems." arXiv:2310.08560. [Link](https://arxiv.org/abs/2310.08560) Park, J. S., O'Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. (2023). "Generative Agents: Interactive Simulacra of Human Behavior." *UIST 2023*. arXiv:2304.03442. [Link](https://arxiv.org/abs/2304.03442) Saad-Falcon, J., Fu, D. Y., Arora, S., Guha, N., & Re, C. (2024). "Benchmarking and Building Long-Context Retrieval Models with LoCo and M2-BERT." arXiv:2402.07440. [Link](https://arxiv.org/abs/2402.07440) Satyanarayanan, M. (2017). "The Emergence of Edge Computing." *Computer*, 50(1), 30-39. [Link](https://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf) Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., et al. (2015). "Hidden Technical Debt in Machine Learning Systems." *NeurIPS 2015*. [Link](https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems) Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). "Edge Computing: Vision and Challenges." *IEEE Internet of Things Journal*, 3(5), 637-646. [Link](https://doi.org/10.1109/JIOT.2016.2579198) Squire, L. R. (2004). "Memory Systems of the Brain: A Brief History and Current Perspective." *Neurobiology of Learning and Memory*, 82(3), 171-177. [Link](https://pubmed.ncbi.nlm.nih.gov/15464402/) Stein, E. W., & Zwass, V. (1995). "Actualizing Organizational Memory with Information Systems." *Information Systems Research*, 6(2), 85-117. [Link](https://pubsonline.informs.org/doi/10.1287/isre.6.2.85) Thakur, N., Reimers, N., Ruckle, A., Srivastava, A., & Gurevych, I. (2021). "BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models." *NeurIPS Datasets and Benchmarks*. arXiv:2104.08663. [Link](https://arxiv.org/abs/2104.08663) Trivedi, H., Balasubramanian, N., Khot, T., & Sabharwal, A. (2023). "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions." *ACL 2023*. arXiv:2212.10509. [Link](https://arxiv.org/abs/2212.10509) Tulving, E. (2002). "Episodic Memory: From Mind to Brain." *Annual Review of Psychology*, 53, 1-25. [Link](https://www.annualreviews.org/doi/10.1146/annurev.psych.53.100901.135114) van Dongen, B. F. (2019). *BPI Challenge 2019* (Version 1). 4TU.ResearchData. [Link](https://doi.org/10.4121/uuid:d06aff4b-79f0-45e6-8ec8-e19730c248f1) van der Aalst, W. M. P., Weijters, A. J. M. M., & Maruster, L. (2004). "Workflow Mining: Discovering Process Models from Event Logs." *IEEE Transactions on Knowledge and Data Engineering*, 16(9), 1128-1142. [Link](https://www.vdaalst.com/publications/p245.pdf) Vejendla, H. (2025). "Drift-Adapter: A Practical Approach to Near Zero-Downtime Embedding Model Upgrades in Vector Databases." *Proceedings of EMNLP 2025*, 15938-15949. [Link](https://aclanthology.org/2025.emnlp-main.805/) Walsh, J. P., & Ungson, G. R. (1991). "Organizational Memory." *Academy of Management Review*, 16(1), 57-91. [Link](https://www.jstor.org/stable/258607) Wu, D., Wang, H., Yu, W., Zhang, Y., Chang, K.-W., & Yu, D. (2024). "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory." arXiv:2410.10813. [Link](https://arxiv.org/abs/2410.10813) Yoon, J., Sinha, R., Arik, S. O., & Pfister, T. (2024). "Matryoshka-Adaptor: Unsupervised and Supervised Tuning for Smaller Embedding Dimensions." *EMNLP 2024*, 10318-10336. [Link](https://aclanthology.org/2024.emnlp-main.576/) Zellinger, L., Stephan, A., & Roth, B. (2024). "Counterfactual Reasoning with Knowledge Graph Embeddings." *EACL 2024*, 2753-2772. [Link](https://aclanthology.org/2024.eacl-long.168/) # Appendix D. Implementation References and Product Documentation Adwant, G. (2026). *vectormigrate: Python-first tooling for safe embedding-model migration across vector retrieval systems.* PyPI. [Link](https://pypi.org/project/vectormigrate/) Apache Avro. (n.d.). *Apache Avro Documentation.* [Link](https://avro.apache.org/docs/) Apache NiFi. (n.d.). *Apache NiFi User Guide.* [Link](https://nifi.apache.org/docs/nifi-docs/html/user-guide.html) GustyCube. (n.d.). *membrane/pkg/decay package documentation.* Go Packages. [Link](https://pkg.go.dev/github.com/GustyCube/membrane/pkg/decay) LMDB Project. (n.d.). *LMDB documentation.* [Link](https://lmdb.readthedocs.io/en/latest/) PostgreSQL Global Development Group. (n.d.). *PostgreSQL Documentation.* [Link](https://www.postgresql.org/docs/current/) Qdrant. (n.d.). "Migrate to a New Embedding Model with Zero Downtime in Qdrant." [Link](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) TensorFlow. (n.d.). *ML Metadata.* [Link](https://www.tensorflow.org/tfx/guide/mlmd) TidesDB. (n.d.). *TidesDB C API Reference.* [Link](https://tidesdb.com/reference/c/) Unstructured. (n.d.). *Unstructured open source overview.* [Link](https://docs.unstructured.io/open-source/introduction/overview) Weaviate. (n.d.). "Collection aliases." [Link](https://docs.weaviate.io/weaviate/manage-collections/collection-aliases) XTDB. (n.d.). "What is XTDB?" [Link](https://docs.xtdb.com/intro/what-is-xtdb.html) # Appendix E. Figure Production Brief This appendix is an internal production brief for the paper's figures. It preserves figure requirements for visual design work and is omitted when the white paper is circulated as an external publication body. | Figure | Linked file | Production brief | |---|---|---| | Figure 1: Memory Object Lifecycle | Malu-Figure-1.pdf | Show the lifecycle from preserved evidence to operational procedural knowledge. Include Source Package, Claim, Fact, Memory Object, Episode Object, Workflow Trace, Generalized Workflow, Procedural Memory Object, Skill Package, and Derivation Ledger links. Emphasize that each derived object remains traceable to source evidence. | | Figure 2: Memory DBMS Reference Architecture | Malu-Figure-8.pdf | Show the reference architecture for the proposed Memory DBMS. Include Enterprise Memory Core, Local Memory Nodes, Active Memory Pools, source systems, model providers, agent frameworks, Tool-Calling Protocol Adapter, Native Model Execution Engine, and security/governance layer. Emphasize that catalog, permissions, validation, provenance, routing, policy, and audit remain owned by the DBMS even when storage engines, tools, models, and applications are external. | | Figure 3: Episode Object Schema | Malu-Figure-4.pdf | Show the conceptual structure of an Episode Object. Include identity/versioning, evidence links, temporal fields, Semantic Frame, Relationship Edges, confidence/precision, lifecycle state, security labels, and Derivation Ledger. Emphasize that an episode is a governed replayable object, not a loose narrative summary. | | Figure 4a: Installation-Reason Retrieval Plan | Malu-Figure-5.pdf | Show a scoped historical retrieval path for an installation-reason query. Include authentication, authorization envelope, query classification, structured filters, temporal filters, graph traversal, semantic search, recursive detail expansion, evidence packaging, and audit. Emphasize policy filtering before candidate expansion. | | Figure 4b: Production-Server Workflow Retrieval Plan | Malu-Figure-6.pdf | Show workflow-oriented retrieval for a production-server process query. Include authentication, authorization envelope, query classification, workflow lookup, structured filters, temporal filters, graph traversal, semantic search, recursive detail expansion, evidence packaging, and audit. Emphasize that workflow retrieval follows a different path from historical recall while using the same governance controls. | | Figure 5: Active Memory Pool | Malu-Figure-7.pdf | Show an Active Memory Pool as a governed task-scoped working-memory space. Include pool scope, humans, AI agents, loaded context, pending observations, Context Packages, promotion path, and audit log. Emphasize isolation, refresh, and promotion controls. | | Figure 6a: Workflow Formation from the Organizational Model | Malu-Figure-2.pdf | Show how organized Episode Objects and Memory Detail Objects become workflow candidates. Include Episode Objects, source evidence, Memory Detail Objects, Workflow Traces, clustering, and Generalized Workflows. Emphasize that grouping is evidence-linked and reviewable. | | Figure 6b: Workflow Extraction Engine Process | Malu-Figure-3.pdf | Show the workflow extraction engine process. Include Episode Objects, source evidence, Memory Detail Objects, Workflow Traces, clustering, Generalized Workflows, validation, Procedural Memory Objects, and Skill Packages. Emphasize promotion gates before runtime use. | | Figure 7: Security-Aware Retrieval Coordinator | To be finalized before publication | Show actor identity, authorization envelope, partition filtering, index/path selection, graph authorization, semantic retrieval filtering, summarization policy, tool-call controls, and audit logging. Emphasize that authorization is applied before and during retrieval expansion, not only after results are assembled. | | Figure 8: Evaluation Pipeline | To be finalized before publication | Show the empirical evaluation pipeline for the proposed Memory DBMS. Include retrieval tests, grounding tests, temporal tests, workflow tests, calibration tests, security tests, and recovery/rebuild tests. Emphasize that evaluation covers governance and recoverability as well as retrieval quality. |