Article

AI Memory Needs Data Contracts, Not Just Vector Search

By Gavin Somers · 7 min read · Published 1 July 2026 · Updated 15 July 2026

• AI Readiness
• Reporting Trust
• Semantic Layer
• Data Value Chain

AI memory usually starts with a simple promise: connect the model to your documents and let it retrieve the right context.

That can work for many useful questions. Vector search is good at finding semantically similar text. It helps when the user needs a passage, a note, a document, or a rough cluster of related material.

But business memory has a harder job.

If an agent is helping with project status, risks, decisions, commitments, owners, open loops, or customer context, similar text is not enough. The agent needs to know what kind of thing it has found, where it came from, whether it is current, how it relates to other things, and which source should be trusted.

That is a data contract problem, not only a retrieval problem.

The weak version of memory

The weak version of AI memory treats notes as a pile of text.

The workflow often looks like this:

documents -> chunks -> embeddings -> vector search -> model answer

That architecture can be useful. It can make a large note base searchable. It can give a model relevant passages. It can reduce the need to remember exact filenames or keywords.

The problem is that the model is still being asked to rediscover structure at query time.

When the user asks “what decisions affect Project Atlas?”, the model should not have to infer from raw prose which notes are decisions, which project they apply to, whether a decision has been superseded, and which source created the evidence. Those are not just semantic similarities. They are business relationships.

Business memory needs modeled objects

Useful business memory contains objects, not just passages.

For example:

• A decision has a title, date, owner, status, source, and affected entity.
• A risk has severity, owner, current state, source evidence, and related project.
• An open loop has task text, status, source note, linked entity, and age.
• A project has relationships, events, states, decisions, risks, and unresolved actions.

Those objects can still originate in ordinary notes. They do not require people to abandon Markdown, Obsidian, meeting notes, or daily logs.

But somewhere between capture and AI consumption, the system needs to turn text into governed context.

That is the same logic behind Reporting Trust: a number is not safe just because it exists in a dashboard. It becomes safer when it is defined, sourced, owned, explained, and safe to use.

AI memory needs the same discipline for text.

A proof path from notes to MCP

I have been building a small public proof of this idea in the obsidian-mcp-context repo.

The project deliberately uses generated and synthetic Obsidian-style vaults, not my personal vault. That matters because the proof should be inspectable without exposing private notes.

The supported workflow is:

generated Obsidian vault
  -> container-mounted vault at /vault
  -> Postgres raw landing tables
  -> dbt Postgres marts
  -> MCP consumers

The notes remain the source input. The warehouse becomes the contract layer.

The parser extracts headings, blocks, tasks, wikilinks, tags, semantic lines, frontmatter, and provenance. Postgres stores the raw parsed rows. dbt then builds marts for entities, relationships, states, events, timelines, decisions, risks, and open loops. MCP tools expose the modeled context to agent clients.

That gives an agent more than “here are some similar chunks”.

It can ask for a project brief, a decision log, a risk register, entity context, open loops, relationships, or timeline evidence from known marts with source-linked rows.

The contract matters more than the demo

The important part is not Obsidian itself.

Obsidian is just a useful scale model: Markdown notes, links, daily logs, project pages, meeting notes, decisions, risks, and tasks are easy to inspect.

The more important contract is:

• What counts as an entity?
• How is identity made stable?
• Which folders or note types imply business meaning?
• Which relationships are deterministic?
• Which rows preserve source provenance?
• Which marts are generic enough for other vaults?
• Which tests prove expected context exists?

In the demo, entities have stable IDs such as project:project-atlas. Built-in folders such as People/, Companies/, Projects/, Decisions/, Risks/, Daily/, Meetings/, and Research/ map to known types. Custom folders can become custom entity types. Generic marts expose entities, relationships, states, events, context, and open loops.

That is a data contract. It tells the agent what shape of context it can expect.

Tests are part of memory

Business memory should be testable.

The demo stack does not only ingest notes and hope the answers look plausible. It runs dbt tests and reconciliation checks.

Some tests check that required marts are populated. Others check that expected decisions and risks are connected to the right project. The point is not that every future business memory system will use the same test cases. The point is that memory quality should be observable.

If the context layer says a project has decisions, risks, open loops, and events, tests should be able to prove that the expected relationships survive parsing, ingestion, transformation, and retrieval.

That is very different from asking a model to search a pile of documents and trusting the answer because it sounds fluent.

Where vector search still fits

This is not an argument against vector search.

Vector search is useful when the user needs fuzzy discovery, related passages, broad recall, or search across language that does not share exact terms.

But it should not be the only memory layer for questions that depend on state, type, ownership, chronology, or source authority.

A stronger architecture can use both:

structured marts for known business objects
vector search for supporting passages and fuzzy discovery

The structured layer answers questions like:

• Which decisions apply to this project?
• What risks are still open?
• Which people are linked to this account?
• What changed since the last review?
• Which open loops are stale?

The retrieval layer can then help find supporting passages, similar cases, or wider context.

The model should not have to choose between structure and language. It should get both.

The Reporting Trust connection

This is the text version of the same problem that appears in reporting.

In reporting, weak foundations show up as dashboards that disagree with spreadsheets, finance packs, and source systems.

In AI memory, weak foundations show up as agents that retrieve plausible passages but cannot reliably distinguish a decision from a risk, a current commitment from an old discussion, or a source fact from a generated interpretation.

The Semantic Layer Gate says transformed data should not leave Transform until business meaning, ownership, caveats, and safe-use context are clear.

AI memory needs an equivalent gate for text:

raw notes -> parsed evidence -> modeled objects -> tested context -> agent answer

That is how unstructured notes become safer business context.

What to build before smarter prompts

Before asking for a smarter AI memory prompt, ask whether the context layer has a contract.

Useful questions:

• Which business objects should memory expose?
• Which source formats create those objects?
• How are object IDs made stable?
• Which relationships are deterministic?
• Which fields are interpreted and need review?
• Which tests prove the expected context is present?
• Which tools expose structured context to agents?
• Which private sources must stay out of the workflow?

The answer does not have to be heavy. The public demo starts with generated Markdown, Postgres, dbt, tests, and MCP. The same principle can apply to other systems.

Do not make the model rediscover business structure from raw text every time someone asks a question.

Compile the structure. Test it. Expose it through tools. Then let the model reason with context that has a contract.

For the broader AI reporting side of this argument, read AI needs a semantic layer and AI across the Data Value Chain. For a practical, human-reviewed implementation workflow, use the AI Analytics Engineering Workflow Kit. For the underlying business trust frame, start with Reporting Trust or get the free opening chapter.