How the Engine Thinks About Data
How the engine forms memory and assembles context, and how it weighs each piece of information based on scope and attribution.
The Clinia Context Engine does two jobs for agents working in healthcare: it forms memory from the data it receives, and it assembles context from that memory when agents need it. The engine also tags every piece of information with a scope, meaning who the information is about, and an attribution, meaning who wrote or said it. From these two tags, the engine works out the information's authority, meaning how much it should count for a given task.
Not yet exposed in the API
The engine already takes scope, attribution, and authority into account internally, in different ways across Recorded Memory and Learned Memory, but exposing these concepts through the API clearly and explicitly is something our team is still working on.
Memory formation and context assembly
Memory formation is the write side. It is extracting, persisting, updating, invalidating, and forgetting information as new data arrives into the engine. The job is to decide what survives between calls, and the hard problems are consolidation (is this something the engine already knows?) and staleness (is what it knows still true?).
Context assembly is the read side. It is exposing, addressing, navigating, resolving, and listing information for agents at query time. The job is to decide what lands in the agent's context window on a given call, and the hard problems are relevance (is this information relevant to the current task?) and token economics.
The two motions serve the same goal, since context assembly is how agents effectively reach the memory the engine has formed.
Scope
Scope says who a piece of information is about, such as a patient or an organization. The engine uses scope to decide who can read the information, who can change it, and how long it is kept. The model has four scopes:
- Patient: the person receiving care, and everything about their health and administrative record.
- Organization: reference and institutional knowledge that belongs to no single patient or operator, whether clinical, financial, or administrative, such as clinical guidelines and care pathways, formularies, payer policies and fee schedules, and the organization's own operating procedures.
- Operator: whoever is driving the interaction, such as a clinician, a care coordinator, a claims adjudicator, or the patient acting on their own behalf.
- Agent: the agent itself, including its role, its responsibilities, and its guardrails.
A session, for example, always belongs to exactly one patient, so its messages and the memories learned from it fall under the patient scope.
Attribution
Attribution says who wrote or said a piece of information. It is about the author, not about the system that stored or sent the information. The model has three attributions:
- System-reported: authored by an institution or instrument acting in an official capacity, such as clinical notes, lab results, device readings, and insurance claims.
- User-reported: authored by the subject or someone speaking for them, such as symptom accounts, histories, preferences, and caregiver observations.
- Agent-reported: authored by an agent, typically derived from context it already holds, such as summaries, inferences, and resolved entities.
Knowing who said something does not tell you whether it is true. A clinical note carries institutional weight, which is usually earned, but that weight does not make it accurate. In pediatrics, for example, a parent's report can count for more than a system's record.
Provenance and attribution
Provenance answers where a piece of information came from, such as a system of record, a connector, or an interaction, and attribution answers who authored it. The two are easy to conflate, because a system of record can carry user-reported content. For example, an EHR can send a FHIR QuestionnaireResponse with answers the patient filled in, or a MedicationStatement that lists the medications the patient says they take. In both cases the patient is the author, even though the information came from the EHR. This is why the model attributes each piece of information to its author, and not to the system it came through.
Authority
Authority is how much a piece of information should count. A patient, a caregiver, a nurse, a doctor, and a lab can all say different things about the same patient, and an agent needs to know which one to rely on.
The answer depends on the task, so the engine does not set authority directly at ingestion time. It works it out later from the information's scope and attribution, and from checks such as how recent the information is and whether other sources agree with it. Because authority is kept separate from attribution, the engine can keep information that conflicts, remember who said what, and decide how much each piece counts for the task at hand.
Where each piece of information lives
Scope and attribution together place every piece of information in one cell of the model. Each scope can be thought of as having its own section of memory, such as the patient graph, and the cells describe what lives inside it.
| Scope | System-reported | User-reported | Agent-reported |
|---|---|---|---|
| Patient | Health data documented by systems of record | What the patient, or a proxy, said about themselves | Summaries and inferences drawn from patient context |
| Organization | Guidelines, care pathways, payer policies, and procedures | Staff notes on how a site actually runs things | Patterns agents observe across many interactions |
| Operator | The operator's profile, such as their role and credentials | The operator's stated preferences and corrections | Working habits an agent inferred from interactions |
| Agent | The agent's purpose, configuration, and guardrails | - | Cues on how to navigate context, learned from agents |
Additional data dimensions outside of scope and attribution exist without affecting where data lives. Form (structured or unstructured) is an input concern that describes how information arrives. Domain (clinical, financial, or administrative) is metadata on a piece of information, with no storage or governance rules of its own.
Patient graph
The Patient Graph holds everything the engine knows about a patient. Two mechanisms write to it, and they differ by how the information is collected.
Recorded Memory is formed by reading data in systems of record, such as EHRs, labs, and payers. It covers what those systems have already documented, whether as structured data, documents, or images, and the engine collects it through integrations with those systems. Recorded Memory reconciles that data across sources, resolves duplicates into facts, and infers the relationships between them.
Learned Memory is memory formed by analyzing agent interactions. It covers what is learned about the patient during a session, such as symptoms, preferences, concerns, and treatment adherence, whether the patient, a caregiver, or a clinician is the one speaking. Learned memories are append-only today, so each one is kept as it was said and is never merged or updated.
Facts formed as Recorded Memory and memories from Learned Memory stay distinct in the patient graph, but are linked, so an agent sees what the record documents alongside what was learned in interactions. A learned memory that contradicts a fact is linked to it as a conflict, and the fact is left untouched.
The two features do not map one-to-one onto the attribution columns. Recorded Memory mostly carries system-reported information and Learned Memory carries user-reported information, but a FHIR bundle can carry what a patient reported, as described in Provenance and attribution.
The API exposes this model through its own objects. From Theory to Practice is the reference page to get more practical.