Context is not hiding in your database

Context is not hiding in your database.

The database may hold the file, the email, the note, the spreadsheet, the contract, the invoice, the drawing, or the decision log. It may even hold all of them.

That does not mean it holds the context.

A record tells you what was written down. It often does not tell you why it mattered, who softened the advice, which exception everyone understood, what the client really meant, which assumption was political, or why the team decided not to use the obvious precedent.

That is the problem with treating AI context as a storage problem.

Search is useful. Retrieval is useful. Better indexing is useful. But professional context is not a substance waiting to be extracted from a folder. It is the meaning around the record.

The Perfect Archive Can Still Be Wrong

Imagine a firm with a perfect archive.

Every document is searchable. Every matter file is indexed. Every email is available. Every note has been transcribed. Every client call has a summary. Every drawing, invoice, brief, agreement, policy, and spreadsheet can be retrieved.

That sounds powerful.

It can still give the wrong answer.

Not because the archive is empty. Because it is too confident about what a record means.

The old clause may exist, but the partner may know it should not be used with this client. The spreadsheet may show the number, but the finance lead may know the assumption was only accepted for last year's budget. The design brief may say "bold", but the studio may know this client uses that word to mean "less generic", not "louder".

These are not edge cases. They are the work.

Tacit Knowledge Is Not A Defect

Michael Polanyi's famous idea was that "we know more than we can tell" ^{1Michael Polanyi, The Tacit Dimension}. That is often treated as a knowledge-management problem, as if the organisation simply failed to document enough.

Sometimes that is true. Some things should have been written down.

But tacit knowledge is not just laziness or missing paperwork. It is part of skilled work. People learn patterns, histories, client preferences, professional standards, and local meanings that are hard to reduce to a tidy field in a system.

Nonaka's work on organisational knowledge makes a similar point: organisations create knowledge through movement between tacit and explicit forms, not by pretending everything important is already explicit ^{2Ikujiro Nonaka, "The Knowledge-Creating Company"}. Later work on "ba" describes shared context as a condition for knowledge creation, not merely a container for documents ^{3Nonaka, Toyama, and Konno, "SECI, Ba and Leadership"}.

That matters for AI because a retrieved document is explicit. The judgment around it may not be.

Records Are Traces Of Work

A document is not the work. It is a trace of the work.

An email may record the decision, but not the pressure around the decision. A contract may record the final position, but not the internal debate. A project note may capture the action, but not the reason it mattered. A drawing may show the current design, but not the rejected paths that shaped it.

Brown and Duguid's work on communities of practice is helpful here. They argued that learning and knowledge live in practice, not only in formal descriptions of work ^{4Brown and Duguid, "Organizational Learning and Communities-of-Practice"}. People understand work by participating in its routines, language, shortcuts, exceptions, and standards.

That is why a new person can read the file and still not understand the matter.

It is also why an AI system can retrieve the right document and still miss the point.

What Retrieval Can Do

Retrieval-augmented generation is still important.

The basic idea is sensible: instead of asking a model to answer from its general training, retrieve relevant sources and use them to produce an answer. The original RAG work by Lewis and colleagues helped make this pattern central to knowledge-intensive AI systems ^{5Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"}.

For professional work, source grounding is not optional. A person needs to know where an answer came from. They need to inspect the evidence, challenge it, update it, and decide whether it is good enough.

Retrieval can help with:

• finding relevant records;
• reducing reliance on memory;
• exposing sources behind a claim;
• comparing versions;
• surfacing missing material;
• preparing a first pass for review.

That is a real gain.

But retrieval does not automatically solve context.

What Retrieval Misses

Retrieval can miss context in at least five ways.

First, it may retrieve the wrong source because the language overlaps but the situation differs.

Second, it may retrieve an old source without knowing that practice has changed.

Third, it may retrieve the official record but miss the informal exception.

Fourth, it may find several conflicting records and smooth over the conflict.

Fifth, it may treat absence as evidence. If the archive does not contain the reason, the system may act as if no reason exists.

Recent work on enterprise RAG benchmarks points in this direction. Internal company knowledge often requires cross-document reasoning, conflict handling, and recognising when information is missing rather than simply retrieving a relevant paragraph ^{6EnterpriseRAG-Bench}.

That is the harder problem: not "can we find a document?" but "can we tell what kind of confidence this document deserves?"

A Better Question

Instead of asking, "Do we have the data?", ask:

• Is this source current?
• Is it authoritative?
• Is it complete?
• Is there a known exception?
• Who understands the history?
• What changed since this was written?
• What would make this misleading?
• What should the reviewer check?

These questions are less exciting than "connect all the data." They are also closer to how professional judgment works.

The goal is not to make AI omniscient. The goal is to make the state of knowledge inspectable.

Context Has A Social Shape

Professional context often lives between people.

The partner knows why the client is sensitive about timing. The manager knows which number everyone distrusts. The architect knows which design move was rejected for reasons that never made it into the brief. The senior associate knows which clause looks standard but changes the commercial position.

That does not mean context should remain trapped in private memory. Private memory is fragile. People leave, forget, get busy, or assume others know what they know.

But the answer is not to pretend that context is already in the database.

The answer is to build systems that let people attach meaning to records:

• this source is old;
• this is the current precedent;
• this client prefers this route;
• this assumption needs checking;
• this note explains why we rejected the obvious option;
• this answer is incomplete without speaking to this person.

That is how the database becomes more useful. Not by claiming to contain all context, but by making the gaps visible.

The Plain Test

There is a simple test for an AI system using internal knowledge:

Can it say what it does not know?

Can it show which sources support the answer?

Can it separate the record from the interpretation?

Can it warn that a source may be stale?

Can it show conflicting evidence rather than hiding it?

Can it point to the person or review step needed before action?

If not, the system may still be useful for search and drafting. But it should not be mistaken for context.

The file may tell you what happened.

It often takes a firm to know why it mattered.

Sources

1. Michael Polanyi, The Tacit Dimension
2. Ikujiro Nonaka, "The Knowledge-Creating Company"
3. Nonaka, Toyama, and Konno, "SECI, Ba and Leadership"
4. Brown and Duguid, "Organizational Learning and Communities-of-Practice"
5. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"
6. EnterpriseRAG-Bench