Context is not hiding in your database
Why professional context is not just stored data, and why AI needs more than searchable records to support serious work.
TLDR
- A database can store records, but it does not automatically store why those records mattered.
- Professional context lives in timing, relationships, assumptions, exceptions, authority, and history as much as in documents.
- AI systems need searchable sources, but they also need ways to expose gaps, conflicts, freshness, and human judgment.
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" 1. 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 2. Later work on "ba" describes shared context as a condition for knowledge creation, not merely a container for documents 3.
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 4. 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 5.
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 6.
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.
Four Things A Record Does Not Automatically Provide
It helps to separate four layers that are often collapsed into the word “data.”
A record is an inscription: an email, field, document, note, or transaction. It tells us something was captured.
Current state is an account of what is true now. It may require reconciling several records, checking freshness, and identifying which event superseded another.
Context explains why the current state matters here: the relationship, intent, obligations, timing, priorities, and dependencies around it.
Judgement is the decision about what should happen next. It uses records and context but also accepts responsibility for consequence.
A database can contribute to all four. It does not turn the first into the other three automatically.
Freshness Is A Relationship, Not A Timestamp
The newest record is not always the most authoritative. A recent informal message may not override a signed instruction. A database field may have been updated after a decision but by someone without authority to make it. A policy may be current in publication date yet inapplicable to a grandfathered case.
Freshness therefore needs a relationship between time, source, authority, and purpose. The system must know not only when something changed, but what that change is allowed to mean.
Intent And Absent Rationale
Records are often biased toward what happened, not why another path was rejected. A team may decide not to pursue the obvious option because of a conversation, a sensitivity, or an anticipated dependency. If the rationale was never captured, retrieval can repeatedly rediscover the rejected option and present it as new insight.
This is not solved by recording every conversation. It is solved by identifying decisions whose rationale will matter later, then retaining a concise account: what was considered, what was chosen, what assumption governed the choice, and when it should be revisited.
Retrieval Has To Admit Conflict And Absence
Enterprise retrieval is difficult precisely because sources conflict, information is missing, and answers depend on cross-document coherence. EnterpriseRAG-Bench evaluates systems against these conditions rather than assuming a clean collection 6.
A useful system should therefore be able to say:
- these sources disagree;
- this record is older but more authoritative;
- the decision rationale is absent;
- this person or role must be consulted;
- no action is justified from the available evidence.
That is not a failure of intelligence. It is a sign that the system understands the boundary between retrieval and organisational judgement.
From Storage To Operating Intelligence
The goal is not a perfect archive. It is an operating arrangement in which the right evidence, relationships, authority, and uncertainty become visible at the point of work. This is what connects context to operating intelligence.
It also connects context to memory. When an organisation records the rationale behind a consequential choice or keeps a promise attached to its owner and conditions, it makes future work start from a better state. That is different from accumulating more documents. It is the deliberate construction of a system that can remember its own promises.
Sources
- Michael Polanyi, The Tacit Dimension
- Ikujiro Nonaka, "The Knowledge-Creating Company"
- Nonaka, Toyama, and Konno, "SECI, Ba and Leadership"
- Brown and Duguid, "Organizational Learning and Communities-of-Practice"
- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"
- EnterpriseRAG-Bench
/ Start
Start with one business outcome. Expand from there.
Begin with a focused review rhythm, workflow, or team where better operating context would immediately change the quality of preparation and judgment.