Systems of Record Were Never Designed to Certify Truth

We Ask Enterprise Software to Do Something It Was Never Built to Do

Every enterprise depends on Systems of Record. Enterprise Resource Planning. Point of Sale. Customer Relationship Management. Payroll. Inventory. Manufacturing. Accounting. Supply Chain, etc.

Collectively, they form the operational memory of an organization, recording millions of transactions every day: sales, purchases, invoices, payroll, inventory movements, customer interactions. Without them, modern business simply would not function. They are, in a very real sense, the reason a company can look back at any given Tuesday and know what happened.

Yet somewhere over the past twenty years, something unexpected happened. Quietly, almost without anyone deciding it on purpose, we began asking these systems to answer a question they were never designed to answer.

"Can we trust the numbers?"

That is a very different question — and it's the one AI is now asking, at scale, on every query, whether anyone intended it to or not.

Recording Is Not Certifying

Imagine visiting a courthouse. The clerk faithfully records testimony. Every word spoken becomes part of the official record. But the court reporter is not responsible for determining whether every witness told the truth. Recording testimony is not the same as verifying testimony, those are two different jobs, held by two different people, governed by two different standards.

Enterprise software operates much the same way. A System of Record records what happened or more precisely, what it was told happened. It records transactions. It stores information. It preserves history.

What it does not do — what it was never built to do — is independently determine whether the information entering the system is complete, consistent, governed, or comparable across the enterprise. Those responsibilities belong elsewhere.

The problem is that, in many organizations, "elsewhere" doesn't exist.

The Restaurant That Wasn't Wrong

Consider a multi-unit restaurant company. Every location submits daily sales, payroll, inventory, and purchasing information. The System of Record faithfully collects every transaction. The monthly financial reports are produced on time. The dashboards look polished. Everything appears normal.

Then someone asks a seemingly simple question: which restaurant has the highest food cost?

The answer depends on dozens of assumptions that never made it into the report. When was inventory counted? Were transfers recorded consistently? Did invoices arrive before month-end? Were promotional items classified the same way at every location? Was waste recorded, or estimated, or skipped entirely? Did every store follow identical business rules, what about KPI's? Are they uniform or its own local version of them?

The System of Record cannot answer those questions. Not because it malfunctioned because it was never designed to.

Retail Faces the Same Challenge

A national retailer acquires another chain. Both organizations operate successfully. Both use respected enterprise software. Both maintain accurate transaction histories.

Yet one company defines "same-store sales" differently than the other. Inventory shrink is calculated using different business rules. Returns are recognized differently. Markdowns follow different accounting practices, legacy decisions made years apart, by different finance teams, for reasons that made sense at the time.

The ERP faithfully records both sets of transactions. But it cannot independently reconcile conflicting business definitions — that was never its job. The software did exactly what it was designed to do. The organization simply expected something more of it.

Manufacturing Tells the Same Story

A manufacturer operates six production facilities. Every plant report throughput, downtime, scrap, labor efficiency, and production yield. Executive dashboards compare facilities every morning, ranked side by side as if the comparison were self-evidently fair.

One plant consistently appears to underperform. Capital investment is redirected. Management changes are considered. Months later, engineers discover each facility measured downtime differently. One included scheduled maintenance. Another excluded it. A third reset the downtime clock after every shift change.

The dashboards were accurate. The comparisons were not — and no one caught the difference until real capital had already moved.

The Architecture Gap

This is not a software failure. It is an architectural assumption one baked so deeply into how enterprise systems evolved that almost no one thinks to question it.

For decades, enterprise architecture looked something like this:

Notice what is missing. Nowhere does the architecture ask an obvious question.

"Has operational truth been independently verified before intelligence is applied?"

That omission is becoming increasingly important, because AI does not distinguish between trustworthy information and merely available information. It processes both with remarkable efficiency and remarkable confidence regardless of which one it was actually given.

The Difference Between Data and Evidence

Evidence has characteristics that ordinary information does not. Evidence can be traced. Evidence can be reproduced. Evidence has provenance and lineage. Evidence survives independent scrutiny.

Most operational data is never asked to meet those standards, and until AI arrived, that rarely mattered. Humans naturally questioned unusual reports. Managers recognized inconsistencies because they lived inside the business. Controllers investigated anomalies as a matter of professional instinct.

AI changes that dynamic. Its confidence often causes us to question less — not more — which makes trustworthy evidence more important than ever, precisely at the moment organizations are least inclined to demand it.

A New Architectural Responsibility

Perhaps the next evolution of enterprise software isn't another dashboard. Or another AI assistant. Perhaps it is something more fundamental: a layer responsible for asking questions before intelligence is ever applied.

Are these metrics complete? Are they governed? Are they consistent? Can they be reproduced? Can they be independently verified? And if not, should AI be relying on them at all?

That question may become one of the defining architectural decisions of the next decade not which model an organization chooses, but whether anything stands between its operational data and that model's confident, fluent output.

The Executive Test

This week, ask your technology leaders five questions.

1. Which of our Systems of Record certify operational truth rather than simply recording transactions?
2. Can two independent teams reproduce our most important KPIs from the original source data?
3. Where are business definitions formally governed?
4. How do we know identical metrics mean the same thing across every business unit?
5. What evidence supports the information our AI consumes every day?

The answers will tell you far more about your AI readiness than any software demonstration ever could.

The Certified Intelligence Principle

"No AI system should be trusted more than the evidence on which it depends."

---

First published on Substack on July 28, 2026. Read the original ↗ · Subscribe ↗