The Tool Is Not the Answer. The Tool Is the Problem.

For two decades, enterprise software has positioned itself as the cure for organizational forgetting. The problem has a name. It is not a knowledge problem.

---

What follows is a practitioner hypothesis drawn from direct observation, not empirical research: stated with enough precision to be falsified, and intended to be.

WHAT WE CALLED A KNOWLEDGE PROBLEM

For two decades, enterprise software has positioned itself as the cure for organizational forgetting. You cannot find the reasoning behind a vendor decision. You buy a sourcing platform. Each purchase deepens, in aggregate, the condition it was meant to fix.

This is not a knowledge problem. It is decision record fragmentation: the loss of reasoning, authority, and evidence as decisions pass through systems designed to process them, not preserve them.

I work inside one of the largest supply chain software companies in the world. What I am watching is an organization that has instrumented every data flow and holds no record of why its decisions were made.

WHAT PROVENANCE ACTUALLY MEANS

The W3C PROV standard¹², formalized in 2013, defines provenance as the record of an entity's origin: who produced it, what it was derived from, and under what process. OpenLineage³ and Apache Atlas⁴ apply provenance to data pipelines, tracking dataset origin, transformation history, and downstream dependencies. Git applies provenance to code: every change is attributed, timestamped, and causally linked to its predecessor.

The problem is not that provenance infrastructure does not exist. The problem is where organizations deploy it and where they stop.

We have applied provenance to code. We have applied it to data pipelines. We have applied it to ML models, where lineage tracking is now a compliance requirement in regulated industries. We have not applied it to decisions.

Figure 1. Processing architectures preserve the transaction but dissolve the reasoning. Preserving architectures capture the decision event as a structured, bi-temporal record alongside the transaction.

WHAT A DECISION RECORD REQUIRES

A decision is not a transaction. A decision record must capture what was chosen, by whom, under what authority, on what evidence, against what alternatives, with what expected outcome, and critically: what the system knew at the time the decision was made.

That last element is the hardest to preserve. It requires what database researchers call bi-temporality: the ability to query not just current state but the state of knowledge at a specific point in the past. Jensen and Snodgrass's foundational work on temporal data models⁵⁶, now codified in the ANSI SQL:2011 standard⁷, established the formal basis for this: distinguishing valid time (when something was true in the world) from transaction time (when the system recorded it).

Standard bi-temporal systems, as defined by ANSI SQL:2011, maintain two axes: valid time and transaction time. Decision provenance requires a third. Decision time is the moment the judgment was made: distinct from when the underlying facts became valid, and distinct from when the system recorded the change. Without that third axis, the corpus cannot be queried as it was reasoned at the point of choice.

Figure 2. Standard bi-temporal systems cover valid time and transaction time. Decision provenance requires a third axis: decision time, the moment the judgment was made.

In distributed systems, where most enterprise decisions are made across services, teams, and regions simultaneously, decision time is not a simple timestamp. It is a causally ordered event. Hybrid logical clocks⁸, as implemented in systems like CockroachDB, provide a practical mechanism for causal ordering without requiring global synchronization: a solved problem in distributed systems research⁹ that has not yet reached standard enterprise SOR platforms.

No current enterprise system of record holds this structure natively at the decision layer. Decision provenance is not proposed for automated or micro-decisions (routing optimizations, pricing adjustments, inventory replenishment triggers) but for the class of consequential decisions where the reasoning has organizational learning value and the outcome is measurable against a defined expectation.

This is not a vendor failure. Nobody has named the decision as the unit worth preserving, and that absence is structural, not accidental.

The hardest implementation problem is not the schema. It is capture. A decision record only exists if something writes to it: a human, a workflow hook, or an inference layer (each requiring different instrumentation and adoption strategies). Structural capture via workflow hooks and API instrumentation, rather than manual entry, reduces but does not eliminate the political fiction problem inherent in any self-reported decision record. Capture must be deliberate and domain-specific. It does not happen by instrumenting existing systems more deeply.

The capture cost calculus changes when the corpus has a training destination: structured decision records become worth capturing not just for retrieval but because they are the labeled data that unstructured institutional memory can never produce.

THE INFRASTRUCTURE GAP IS NOT TECHNICAL

Event sourcing¹⁰, formalized by Martin Fowler, proposes capturing every state change as an immutable event. Pat Helland's "Immutability Changes Everything"¹¹ (ACM Queue, 2015) argues that immutable, append-only logs are the only reliable foundation for systems that must reconstruct their own past. Martin Kleppmann's treatment of event logs¹²¹³ demonstrates that the event log, not the current state, is the ground truth.

The answer to whether this is event sourcing with better marketing is: partially, and that is the point. Event sourcing solves the state provenance problem. It does not solve the decision provenance problem, because decisions are not state changes. A decision is a moment of judgment: an actor, with a specific authority level, choosing between alternatives, on available evidence, with an expected outcome. That judgment does not appear in an event log. It appears, if at all, in a Slack thread, a meeting note, or the memory of the person who made it.

A competing hypothesis worth naming: as language models improve at unstructured text understanding, the absence of structured decision provenance matters less. If a future model can reconstruct decision reasoning from Slack threads, email chains, and meeting transcripts with sufficient fidelity, the architectural commitment this paper proposes becomes unnecessary. The rebuttal is semantic, not technical: unstructured text captures what was said. A decision record captures what was decided: the final actor, the final authority, the chosen alternative, the expected outcome. The thread does not contain the judgment. It contains the discussion that preceded it.

THE FRACTURE LINE: WE STOPPED ONE LAYER SHORT

The enterprise has invested heavily in systems that remember what happened. It has not invested in systems that remember why.

Consider a supply chain decision. A procurement team switches a primary supplier during a disruption event. The decision is logged in the sourcing platform as a supplier change, timestamped, attributed to a user account. What is not recorded: the three alternatives that were evaluated, the risk scores available at the time, the executive who approved the deviation from preferred-vendor policy, the expected impact on unit cost and lead time, and the reasoning that weighted speed of supply restoration over cost efficiency. Six months later, when the audit comes or the next disruption hits, none of that reasoning is recoverable. The outcome existed: restored supply within five days. The decision record did not.

This is provenance decay: the progressive loss of causal context as decisions pass through systems not designed to hold it. The rate accelerates with every migration, reorg, and renewal cycle that fails to carry the decision record forward, because decision records tied to a specific system's schema do not survive migration to a new schema without a mapping layer that almost never exists in practice. This acceleration is an observed pattern, not yet empirically validated at scale.

The closest existing approximations clarify where the gap actually lives. Document-based decision records (Amazon's six-pager, military after-action reviews, McKinsey decision frameworks) capture reasoning in prose. They are not queryable across time, do not survive system migration as structured data, and cannot be used as training material without significant transformation. Microsoft 365 Copilot retrieves context from documents and threads: the strongest current approximation of organizational memory retrieval. It cannot tell you what the expected outcome of a decision was, whether the decision was correct, or who held authority at the moment of choice. SAP Signavio mines process patterns from event logs: retrospective pattern detection, not prospective structured capture¹⁴. Palantir Foundry tracks actions taken through Foundry workflows, closer to decision provenance than any other commercial platform currently available, but it captures actions taken within Foundry, not decisions made outside it, does not record alternatives considered or authority level as structured fields, and the corpus lives in Palantir's infrastructure, not the organization's. The proprietary training asset argument fails under that licensing model.

These characterizations reflect capabilities as of mid-2026. The underlying principle, that retrieval systems and decision record systems are architecturally distinct, does not depend on any specific vendor's current feature set.

First: this is a process improvement problem, solvable with better meeting hygiene and structured postmortems in existing tools. It is not. Postmortems capture reflections after the fact, not the evidence state at the moment of choice. Second: this is a data governance problem addressed by existing MDM and data catalog vendors like Collibra and Alation. It is not. Those tools govern data assets, not the decisions made using them. Databricks Unity Catalog tracks data lineage (how data moved and transformed), not the decisions that directed those movements¹⁵. Third: compliance frameworks like SOX¹⁶, GDPR Article 22¹⁷, and ISO 31000:2018¹⁸ already mandate decision audit trails. They do, for regulatory purposes, recording what was decided. They do not record why, with what alternatives, on what evidence, for organizational learning. Compliance audit and learning provenance are architecturally distinct requirements.

This is also what separates decision provenance from knowledge management. Tools like Confluence, Notion, and SharePoint capture documents about decisions. A decision record is not a document. It is a structured schema: actor, authority, alternatives, evidence state, expected outcome, outcome link. A document can be searched. A schema can be measured, queried across time, and trained on.

The organizations that have felt this most acutely are not the ones with the least data. They are the ones with the most: enterprises that have instrumented every transaction and aggregated every metric but cannot answer a simple question. Why did we decide what we decided, and were we right?

WHAT THE INFLECTION POINT ACTUALLY LOOKS LIKE

There is a pattern, observed, not universal, in enterprises at sufficient SaaS portfolio maturity. At some point, the cost of maintaining the ecosystem (licensing, integration, migration, retraining, data reconciliation) exceeds the intelligence value any new tool adds. The tools are no longer generating organizational learning. They are generating the fragmentation that requires the next tool.

The response most organizations reach for is consolidation: fewer tools, better integrations, a data platform that unifies the outputs. This is the right answer to the wrong question. Unifying the outputs of systems that never held decision provenance does not recover the reasoning. It aggregates the residue.

WHAT "BUILT TO REMEMBER" REQUIRES

At minimum, a system designed to hold decision provenance requires four things that current enterprise systems of record do not natively provide at the decision layer.

A decision schema: a structured record of actor, authority, alternatives, evidence inputs, expected outcome, and timestamp of decision, distinct from the transaction record it produced.

Bi-temporal storage: the ability to query what the system knew at the time of the decision, using valid-time and transaction-time axes as defined in ANSI SQL:2011, plus a third decision-time axis for causal ordering.

Immutability: the decision record, once written, is append-only. Corrections are new records with provenance chains to the records they supersede. This is the pattern Helland describes and that Git implements for code.

Outcome linkage: a mechanism connecting the decision record to the measured outcome it produced, on whatever timeline the feedback requires. For the supplier switch example above, the outcome record holds delivery time against the five-day expectation, unit cost variance, and the date that ground truth became available. The technical link, a foreign key from decision record to outcome record, is straightforward. The measurement process is domain-specific and must be defined per decision type before deployment.

None of these primitives are novel. What does not exist is their application, as a coherent pattern, to the decision layer.

THE SPECTRUM, NOT THE BINARY

The choice is not between feeding the SaaS ecosystem and abandoning it. Most organizations will continue operating the tools they have. The question is whether they build alongside those tools a layer that holds what the tools were never designed to hold.

What follows is forward-looking hypothesis: the primitives above are implementable today; what they compound into over time is speculative but directionally credible.

The organizations that build that layer will accumulate a corpus of structured, provenance-tagged, outcome-linked decisions. That corpus becomes suitable for fine-tuning (or equivalent training methodology) as volume and schema consistency increase, with thresholds that are task and model dependent¹⁹. It is building the asset that makes training possible in years two and three.

That corpus is also, by definition, proprietary, because it encodes not just what an organization did but how it reasoned, which no external vendor can replicate or sell back. Proprietary corpus ownership requires explicit contractual data residency controls with infrastructure vendors. It does not follow automatically from building internal rather than licensed infrastructure.

The longer an organization delays structured decision capture, the larger the provenance debt becomes, because every year without it is another year of causal context that cannot be recovered.

WHAT WOULD INVALIDATE THIS

A paper that cannot be falsified is not making claims.

[F1] Show one enterprise system of record that natively maintains actor, authority, alternatives, evidence state, and outcome linkage at the decision layer in production at scale, and the claim that current tools do not hold decision provenance fails.

[F2] Show that decision reasoning is systematically preserved across tool migrations in organizations that have undergone three or more SOR replacements, and the provenance decay acceleration claim fails.

[F3] Show that a corpus without decision provenance produces equivalent fine-tuning results to a provenance-tagged corpus at equivalent volume, and the proprietary training asset claim fails.

[F4] Show that SaaS portfolio spend increases produce increasing intelligence value rather than decreasing marginal returns past a threshold, and the inflection point pattern fails.

If any of these can be demonstrated, this paper requires revision. That is not a hedge. It is the standard.

THE QUESTION WORTH SITTING WITH

If your organization faced its next disruption tomorrow: could you reconstruct the reasoning behind the last decision you made in that domain? Not the outcome. The reasoning. The alternatives. The evidence. The authority. The expected outcome, and whether it materialized.

If the answer is no, you do not have a knowledge problem. You have a provenance problem. And no tool on your approved vendor list was designed to fix it.

The primary barrier to decision provenance is not technical. It is that the people positioned to fund it are also the people whose reasoning it would make auditable.

REFERENCES

1. [1]Moreau, L. and Missier, P. (eds.), PROV-DM: The PROV Data Model, W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-dm/↩
2. [2]Missier, P., Belhajjame, K., and Cheney, J., "The W3C PROV family of specifications for modelling provenance metadata," EDBT, 2013. https://dl.acm.org/doi/10.1145/2452376.2452478↩
3. [3]OpenLineage Specification, Linux Foundation, 2021. https://openlineage.io/spec↩
4. [4]Apache Atlas, Apache Software Foundation. https://atlas.apache.org↩
5. [5]Snodgrass, R.T. (ed.), The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995. ISBN 0-7923-9614-6.↩
6. [6]Jensen, C.S. and Snodgrass, R.T., "Temporal Data Management," IEEE Transactions on Knowledge and Data Engineering, Vol. 11, No. 1, 1999. https://ieeexplore.ieee.org/document/755613↩
7. [7]ISO/IEC 9075-2:2011, SQL Part 2: Foundation (SQL/Foundation). https://www.iso.org/standard/53682.html↩
8. [8]Kulkarni, S., Demirbas, M., Madappa, D., Avva, B., and Leone, M., "Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases," SSS, 2014. https://link.springer.com/chapter/10.1007/978-3-319-03089-0_2↩
9. [9]Lamport, L., "Time, Clocks, and the Ordering of Events in a Distributed System," Communications of the ACM, Vol. 21, No. 7, 1978. https://dl.acm.org/doi/10.1145/359545.359563↩
10. [10]Fowler, M., "Event Sourcing," martinfowler.com, 2005. https://martinfowler.com/eaaDev/EventSourcing.html↩
11. [11]Helland, P., "Immutability Changes Everything," ACM Queue, Vol. 13, No. 9, 2015. https://dl.acm.org/doi/10.1145/2857274.2884038↩
12. [12]Kleppmann, M., Designing Data-Intensive Applications, O'Reilly Media, 2017. ISBN 978-1491903124.↩
13. [13]Kleppmann, M. and Beresford, A.R., "A Conflict-Free Replicated JSON Datatype," IEEE Transactions on Parallel and Distributed Systems, Vol. 28, No. 10, 2017. https://ieeexplore.ieee.org/document/7821746↩
14. [14]van der Aalst, W.M.P., "Process Mining," Communications of the ACM, Vol. 55, No. 8, 2012. https://dl.acm.org/doi/10.1145/2240236.2240257↩
15. [15]Abraham, R., Schneider, J., and vom Brocke, J., "Data Governance: A Conceptual Framework," European Journal of Information Systems, Vol. 28, No. 4, 2019. https://www.tandfonline.com/doi/full/10.1080/0960085X.2019.1572483↩
16. [16]Sarbanes-Oxley Act of 2002, Public Law 107-204, 116 Stat. 745. https://www.congress.gov/107/plaws/publ204/PLAW-107publ204.pdf↩
17. [17]Regulation (EU) 2016/679 (GDPR), Article 22: Automated individual decision-making, including profiling. https://gdpr-info.eu/art-22-gdpr/↩
18. [18]ISO 31000:2018, Risk Management: Guidelines. https://www.iso.org/standard/65694.html↩
19. [19]Zhao, W.X. et al., "A Survey of Large Language Models," arXiv:2303.18223, 2023. https://arxiv.org/abs/2303.18223↩

This is the first essay in a three-part series. Essay II examines what the absence of decision provenance costs organizations at the point of AI training. Essay III examines what it costs at the point of accountability.

Jack Roche writes Roche on Strategy, on enterprise AI governance, partnerships, and judgment under pressure. Twenty years in enterprise software, operating and advising across strategy, partnerships, and governance. More at rocheonstrategy.com. This essay is published under CC BY 4.0.