Decision Memory: The layer that generally gets skipped

I have now raised this twice and developed it neither time. In the piece on the five layers it was memory engineering, and I admitted I had underrated it. In the piece on context layers it was the third question, the one about what was already decided, and I gave it four lines.

It keeps coming back because it is the part of the stack with no natural owner.So, properly this time.

What decision memory is, and what it is not

Decision memory is the record of the assumptions and choices your organisation has already made, with the reasoning attached, available to whoever picks the question up next.

It is not any of the following, though it gets confused with all of them.

It is not your data.Your data says what happened. Decision memory says what you concluded and why you concluded it.

It is not conversation history. Session memory is a chat that remembers the last twenty turns. Useful, and it evaporates.

It is not retrieval over your documents. A vector index will find you the report. It will not tell you that the assumption underpinning that report was overridden in March by someone who had a reason.

It is not an audit log either, though it is closest to that.An audit log records that a value changed and who changed it. Decision memory records why, and what else the decision was supposed to hold true for.

Why it gets skipped

Three reasons, and none of them are technical.

Nobody asks for it.It appears in no RFP I have seen. Buyers ask about model accuracy, ingestion throughput, and access control. They do not ask whether the system remembers its own reasoning, because that failure has not bitten them yet in a way they could name.

It has no dashboard. Every other layer produces something you can put on a screen. Decision memory produces the absence of a problem, which demos badly.

And the cost is deferred. A system without it works fine for a year. It degrades when the person who made the original call moves teams, and by then the degradation looks like a people problem rather than an architecture one.

What it costs in aviation specifically

Aviation analytics runs on assumptions, and the assumptions are contestable.

A shop visit forecast rests on a derate assumption. Somebody chose it, for a reason, informed by how that operator actually flies the asset rather than how the lease says they might. Six months later a different analyst runs the same forecast, picks a defensible but different derate, and produces a materially different number.Both are defensible. Only one of them reflects what the team actually knows.

A workscope gets costed against a scenario. Which scenario, and why that one rather than the more conservative option, is a decision with money attached. If that reasoning lives in somebody's head or in a thread, the next costing starts from zero.

A records correction is the clearest case. Your team works out that a particular MRO issues under a trade name, or that an operator reports cycles in a column nobody else uses. That is knowledge, expensively acquired, one document at a time. If it does not persist into the extraction layer, the same correction gets made in March, then June, then September.The tool never improves and the people stop trusting it, which is the real cost and it is not recoverable by buying a better model.

And a return conditions clause gets interpreted. Legal and technical sit down, argue about what a phrase means, and settle it. That interpretation should govern every redelivery under that lease form from then on.Usually it governs exactly one, because it was settled in an email.

The re-litigation problem

Here is the shape of it. Same question, asked twice, eighteen months apart. Two answers, both defensible, arrived at by two competent people who could not see each other's reasoning.

That is not an error anyone gets blamed for, which is why it persists.Nothing failed. No alert fired. The organisation simply paid twice for the same thinking and ended up with two versions of the truth, and will discover this in a meeting with a counterparty present.

In a regulated industry it gets sharper.The standard worth designing to is that somebody who was not in the room can reproduce the output months later.Not approximately reproduce it. Reproduce it, including the assumptions, because the assumptions are where the judgement lives and judgement is what gets challenged.

What it looks like when it is built

Assumptions become objects rather than parameters. A derate assumption has an author, a date, a rationale, a scope of what it applies to, and a link to every output it fed. When it changes, you can see what it invalidated.

Corrections persist downward. A records fix does not stay in the corrected document. It updates the extraction layer, so the next document from that source is read correctly without anyone intervening.This is the difference between a tool and a colleague, and it is mostly an architecture decision rather than a model one.

Decisions surface at the point of the next decision.Filing them is not enough.The moment somebody starts a new shop visit forecast on that asset is the moment they need to see what was assumed last time, without going to look for it.

And provenance connects the two directions. From an output back to the assumptions behind it, and from an assumption forward to everything it touched. The second direction is the one people forget to build and the one you need when an assumption turns out to be wrong.

What the research actually supports

I could not find a study that prices decision memory directly, and I am not going to invent one. What exists is adjacent, and the recent work is more useful than the numbers usually quoted.

Deloitte's 2025 survey asked organisations what was obstructing their AI automation strategy. Searchability of data came back at 48 percent.Reusability of data came back at 47 percent, which is close to a direct measurement of the problem this piece is about.Searchability is finding the artefact. Reusability is whether the work behind it can be picked up and built on, and almost half of organisations say theirs cannot.

The same body of research explains what that costs in practice. Deloitte's 2025 Emerging Technology Trends study found 30 percent of organisations exploring agentic options and 38 percent piloting them, butonly 14 percent with something ready to deploy and 11 percent actually running in production.The gap between piloting and production is where these projects go to die, and the reasons are rarely about model quality.

Older work points the same direction. IDC found in 2018 that data professionals lose roughly half of every week, with about 20 percent going on duplicated work.Duplicated work is re-litigation with a stopwatch on it.Somebody redoing an analysis that already exists is not a search problem, because they often do not know there is anything to search for.

One caution on this genre. A lot of what circulates here does not survive inspection. The widely quoted figure that knowledge silos cost enterprises 5 to 15 percent of annual revenue is attributed, in the places I found it, to nothing more specific than industry analysts. Much of the older productivity material traces back to a single estimate from 2001 that drifted upward through repetition. I have left both out. If you have seen this territory quantified properly, particularly in a regulated industry, I would like to read it.

The short version

Your data is stored. Your documents are retrievable. Your reasoning is on somebody's laptop.

If an agent is going to act on your behalf, it needs to know what you already decided, or it will confidently decide it again.

References

1. Deloitte.Agentic AI strategy, Deloitte Insights, 2025. Source of the finding that 48 percent of organisations cite searchability of data and 47 percent cite reusability of data as challenges to AI automation strategy.https://www.deloitte.com/us/en/insights/topics/technology-management/tech-trends/2026/agentic-ai-strategy.html
2. Deloitte.2025 Emerging Technology Trends, reported in the above. Source of the adoption figures: 30 percent exploring agentic options, 38 percent piloting, 14 percent deployment-ready, 11 percent in production.
3. Deloitte.State of AI in the Enterprise, 2026 report.Survey of 3,235 senior leaders across 24 countries, conducted August to September 2025. Referenced for context on enterprise agentic adoption.https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
4. McKinsey & Company.The State of AI in 2025: Agents, innovation, and transformation.Online survey fielded 25 June to 29 July 2025, 1,993 respondents across 105 nations. Notes that agent use is most commonly reported in IT and knowledge management functions.https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
5. Microsoft.2026 Work Trend Index: Agents, human agency, and opportunity.Survey conducted by Edelman Data x Intelligence among 20,000 knowledge workers who use AI at work across 10 markets, 18 February to 7 April 2026. Referenced for context on information load.https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
6. IDC, 2018, as reported inReality Check: Still Spending More Time Gathering Instead Of Analyzing, Forbes Technology Council. Source of the finding that data professionals lose roughly half of each week, including about 20 percent on duplicated work. Cited as secondary; the primary IDC publication is not openly available.https://www.forbes.com/councils/forbestechcouncil/2019/12/17/reality-check-still-spending-more-time-gathering-instead-of-analyzing/
7. White, Martin."Time spent searching" - a chronology of the myth and some recent research, 2020. Traces how a 2001 estimate drifted through repetition. Basis for excluding the commonly quoted "2.5 hours a day searching" figure.https://www.linkedin.com/pulse/time-spent-searching-chronology-myth-some-recent-research-white

KeepFlying® builds the aviation FinTwin on Databricks and Azure. Outputs trace back through transformation and extraction to the source page, and the assumptions behind them are held as first-class objects rather than parameters in a notebook.

#DecisionIntelligence #DataGovernance #AgenticAI #AIGovernance #KnowledgeManagement