Enterprises Remember What Happened and Lose Why

Your company is probably quite good at remembering what happened.

The order was approved. The price changed. The customer received an email. The inventory moved. The contract was signed. The support case closed. Somewhere, in some system, there is a row that proves it.

Now ask why.

Why did the sales team make an exception for this customer? Which evidence mattered? What alternatives did they reject? Who had authority to approve it? Was the exception intended to become a precedent, or was it permitted only because of conditions that no longer exist? Did it work?

The answer is often scattered across a meeting, a private message, an email thread, a spreadsheet, a person’s memory, and perhaps a sentence in a CRM note. The transaction survived. The judgment that produced it did not.

This is the context gap.

For years, organizations could survive that gap because people supplied the missing context. A good employee knew which customer record was misleading, which written rule had an unwritten exception, which metric needed explanation, and who to call before acting. The software stored the state of the business. People reconstructed its meaning.

AI changes the economics of that arrangement. We are asking software to participate in work that depends on the very context our systems routinely fail to preserve.

The missing part of the record

Enterprise systems are optimized for many legitimate purposes. Accounting systems preserve financial events. CRMs preserve customer activity. ERPs coordinate products, orders, inventory, and fulfillment. Ticketing systems track issues through a workflow. Data platforms aggregate information for analysis.

Their failure to preserve every surrounding reason is not evidence that these systems were badly designed. A transaction system should be excellent at transactions. A system of record should be authoritative about the identity and state it governs.

Nor is this an argument that normalization or relational storage inherently destroys context. It does not. Particular schemas and workflows can still omit the relationships a later decision needs.

But a transaction is not a decision.

A completed field generally does not tell us what the person was trying to accomplish, what evidence was available, or what had been excluded. It rarely preserves the alternatives, assumptions, or local conditions that governed the choice. It may tell us who entered a value while saying nothing about who supplied the judgment, who had authority to act, what later correction changed our understanding, or whether the result served its purpose.

Sometimes those things belong in a system already. Often they do not. More often, fragments exist in several legitimate systems and in the work between them.

The context gap is therefore not simply “missing data.” It is a broken relationship between evidence, judgment, authority, action, and outcome.

Why retrieval is not enough

The first response to this problem is usually retrieval: connect the AI to the documents, email, CRM, data warehouse, or knowledge base. This can be useful. An artificial worker should not invent information that an authorized source can provide.

The trouble begins when access is mistaken for understanding.

Which source governs the customer’s identity? Which policy was effective when the decision was made? Is a confident statement in a meeting transcript an approved fact, one person’s assertion, or an abandoned proposal? Does access to a customer record authorize its use for this purpose? Which disagreement must remain visible? What should happen when two sources conflict?

A search result can be relevant without being authoritative. A citation can show where a statement came from without proving that the statement is true. The newest document may be less governing than an older executed agreement.

An AI cannot solve these distinctions merely by reading everything. It cannot receive every potentially relevant condition, and more context does not make contradictions disappear. It may instead increase noise, exposure, latency, anchoring, and false confidence.

The architectural problem is not to give the AI all the context. It is to preserve and assemble fitting context for consequential work.

The big, fat file folder-without the file folder

There was something useful about an old physical account file.

It could hold the contract, correspondence, handwritten notes, approvals, and odd exceptions together. A competent person could spread the contents across a desk and reconstruct the situation. The file was incomplete and imperfect, but its contents retained proximity to the human story.

Digital systems gave us enormous gains in access, integrity, coordination, and scale. They also distributed that account across specialized systems, each with its own schema, purpose, custodian, and view of the world.

Contextual Data Architecture does not propose putting everything back into one giant digital document. It does not require copying every enterprise record into a new context database. And it certainly does not justify recording every conversation forever.

It asks whether we can recover the useful property of that file:

Can an authorized worker assemble the evidence, identity, conditions, rationale, authority, alternatives, and history needed to understand one consequential situation-without erasing where those things came from or what may legitimately be done with them?

That account may reference several systems of record. Some sensitive context may remain with its custodian. Some meaning may be captured as structured events, some as source spans, some as explicit assertions, and some as unresolved disagreement. The assembled account may exist only for the duration of a task.

The goal is not a bigger pile. It is a more faithful and governable account of the situation.

Capture judgment while it still exists

Even this account cannot always be reconstructed after the fact.

People rationalize. Memory compresses. Alternatives disappear once a decision feels inevitable. A correction gets applied, but the triggering case and reason vanish. Six months later, the organization retains a mysterious rule that no one trusts enough to remove.

Important context should therefore be captured in the work, near the moment of judgment. That does not mean asking employees to document every thought or exposing a model’s hidden internal reasoning. It means preserving the parts of a consequential decision that other people and systems are entitled to inspect: the task, the evidence supplied, material alternatives and objections, stated assumptions and rationale, unresolved uncertainty, governing authority, the action ultimately taken, and any later correction or outcome.

The burden should follow consequence. A reversible internal draft needs little ceremony. A pricing exception, public communication, financial commitment, or decision affecting another person’s rights may need substantially more.

Capture should also have a purpose and a lifecycle. Institutional learning does not excuse surveillance. Information that should never have been collected does not become legitimate because it might help a future AI.

When labor becomes capital

This is where the context problem becomes an economic one.

Labor normally disappears into the moment. A person interprets an unusual order, repairs a mapping, finds the governing policy, or identifies a dangerous exception. The immediate problem is solved, but the next person must purchase the same learning again.

Software can convert part of that labor into capital.

A correction can become a regression test. A repeated judgment can become a scoped rule. A safe sequence can become a workflow. A hard-won distinction can become a type or invariant. A decision and its outcome can become evidence for the next similar case.

The value is not that software eliminates people. The value is that work leaves behind a productive capability.

But capitalization is not automatically good. A mistaken judgment can become a scalable mistake. A rule can outlive the conditions that justified it. Human review can be hidden as unpaid maintenance behind an allegedly autonomous system. Workers can supply the knowledge while someone else captures all of the resulting value.

Context determines whether accumulated software is living institutional capability or fossilized error. Reusable rules and models need evidence, scope, authority, correction, evaluation, ownership, and a way to expire.

What Contextual Data Architecture changes

Contextual Data Architecture begins from a simple proposition:

Enterprises should preserve enough of the situated evidence, judgment, authority, and consequences surrounding work that a later human or artificial worker can understand what happened, act within legitimate bounds, and improve the system without inventing the missing story.

That proposition changes what we ask of an architecture.

Where should this record be stored? It is still a useful question, but so is: which context must travel with it?

Is this information relevant? Perhaps, but is it supported, and may it govern this decision?

Did the model return an answer? Then we should still be able to distinguish the context supplied, the proposal made, the evaluation performed, the authority exercised, and the external effect created.

Did someone fix the prompt after a failure? Good. Now ask whether that correction should become a scoped rule, test, workflow change, source correction, or explicit exception-and whether the eventual outcome can be joined back to the context and decision that produced it.

These responsibilities may be implemented in existing applications, a shared service, several federated services, or a small amount of disciplined process. CDA is not a mandatory platform topology. It is an architecture of contextual relationships and obligations.

A diagnostic for Monday morning

Choose one consequential decision your organization made recently. It does not need to involve AI.

Can you answer:

1. What purpose was the decision intended to serve?
2. What evidence and governing records were actually available?
3. What alternatives, exclusions, and uncertainties materially shaped it?
4. Who had authority to approve the resulting action?
5. Can a later outcome be joined back to that decision without reconstructing the story from memory?

If the answers are distributed but recoverable, you have ingredients for contextual capability.

If the answers exist only in one person’s head, you have key-person risk.

If the transaction is perfectly recorded but the decision cannot be reconstructed, you have a context gap.

If you cannot tell who had authority or what information may be used, you have something more serious than a data problem.

A working proposition, not a finished doctrine

I do not yet know whether Contextual Data Architecture deserves to be treated as a distinct architectural discipline. Its value may ultimately lie in joining established practices from data governance, knowledge management, information architecture, software reliability, security, and organizational design.

That distinction matters. A new name is valuable only if it changes a design decision.

This article does not establish that proposition. It grows out of field experience, but I have not yet converted that experience into a client-safe case or asked a qualified architect to try to break the thesis.

The claim I want to test is that consequential AI work fails at the joins: between evidence and interpretation, between interpretation and authority, between decision and action, and between action and institutional learning. Designing those joins explicitly may produce systems that remember more than what happened. They may retain enough of why to remain useful, bounded, and correctable.

I would particularly value disagreement on four questions:

1. Is the loss of decision context a distinct enterprise architecture problem, or is it adequately covered by existing disciplines?
2. Which parts of situated judgment can be captured without producing surveillance or intolerable documentation burden?
3. Where have you seen richer context improve an AI-assisted workflow-and where has it merely added cost or false confidence?
4. What architectural decision changes once evidence, authority, action, and outcome are treated as one connected problem?

The next working note will ask what context actually is-and why relevance, support, authority, time, and disagreement cannot be collapsed into one retrieval score.