A number is not a fact about the world. It is a fact about the world run through a framework, and your metric's framework is unstated.
On October 5, 1993, Daimler-Benz became the first German company to list on the New York Stock Exchange. To do it, the maker of Mercedes had to translate its books from German accounting rules into US GAAP, and the translation produced one of the strangest sentences in the history of finance. Under German law, Daimler-Benz had earned a profit of 615 million Deutsche Marks that year. Under US GAAP, the very same company, in the very same year, had posted a loss of 1,839 million Deutsche Marks.
Sit with that. Not a rounding difference. Not creative accounting under investigation. Two audited, legal, defensible sets of books describing one factory's one year, and one says "we made about 600 million" while the other says "we lost almost two billion." A swing of roughly two and a half billion marks, and the sign flipped. The company was simultaneously profitable and catastrophically unprofitable, and both numbers were true.
Daimler wasn't lying in either ledger. It was answering a question nobody realized they were asking. The question was never "did the company make money?" The question was "under which framework did the company make money?", and the answer to that depends entirely on which book of rules you opened first.
This is the thing about GAAP and IFRS that matters far beyond accounting, and it's why anyone who ships software, sets metrics, or runs an engineering org should care: a number is not a fact about the world. It's a fact about the world run through a framework, and there is more than one valid framework. The accountants have been living with this truth for a century. The rest of us keep rediscovering it the hard way.
Start with what these two systems even are. US GAAP, Generally Accepted Accounting Principles, is the rulebook the SEC requires for American public companies, maintained by the FASB. IFRS, International Financial Reporting Standards, maintained by the IASB, is what the rest of the world mostly uses: required or permitted in over 140 jurisdictions. Both exist to answer the same question: how is this business actually doing? Both are honest attempts. And they disagree, materially, all the time.
They disagree because a financial statement was never a photograph of a company. It's a model, a compression of millions of messy transactions into a few clean lines, and compression requires choices. When did that sale "happen"? What is that half-finished factory "worth"? Is the money you spent inventing a product an expense (gone, like rent) or an asset (a thing you now own, like a machine)? There is no fact of the matter waiting to be discovered. There is only a rule you adopt and apply consistently. Change the rule and you change the number, not because reality changed, but because the lens did.
Engineers know this shape instinctively, even if they've never read a 10-K. It's the map-versus-territory problem with money on the line. The same production database, queried through two different aggregation pipelines, yields two different dashboards, and both can be correct. The argument is never about the rows. It's about the GROUP BY.
The disagreements aren't random; they cluster around exactly those compression choices. Two examples carry most of the weight.
Inventory: LIFO. Imagine prices are rising and you're selling from a warehouse. Which units did you "sell", the cheap old ones or the expensive new ones? Last-In-First-Out (LIFO) says you sold the newest, most expensive stock first, which makes your cost of goods high and your reported profit low (handy, because in the US it also lowers your taxes). US GAAP permits LIFO. IFRS bans it outright: IAS 2 prohibits LIFO, on the grounds that it rarely matches the real physical flow of goods and lets companies dial their profits up and down by managing inventory timing. So the identical warehouse, the identical sales, produces a different profit in New York than in Frankfurt. Same cans on the same shelves; two different incomes.
Research and development. A company spends a fortune inventing something. Under US GAAP, almost all R&D is an expense: it hits the income statement immediately and is gone, which makes a heavily-inventive company look less profitable than it "really" is. Under IFRS (IAS 38), research is expensed too, but development costs, the later-stage work once the thing is technically and commercially viable, must be capitalized: recorded as an asset and amortized over time. The consequence is stark for exactly the companies a tech audience cares about. A software or pharma firm pouring money into building products can show lower earnings and a thinner balance sheet under US GAAP, and higher earnings and more assets under IFRS, from the same lab and the same spend. Neither is fraud. They are two answers to "is this invention spent or owned?", and that question has no framework-free answer.
Here is where it stops being about accountants. The GAAP-versus-IFRS lesson is the master key to a problem that quietly wrecks technical decisions: almost every number you compare was produced by a framework, and you usually weren't told which one.
"Our model is state of the art." Under which benchmark, which prompts, which scoring rubric? Change the eval framework and the leaderboard reshuffles; the same model is SOTA and also middle-of-the-pack, like Daimler was profitable and bankrupt. "Our database is faster." On which workload, which hardware, which percentile? p50 latency and p99 latency are LIFO and FIFO: two honest lenses on one system that crown different winners. "Engagement is up 12%." Under which definition of an active user, stitched across which sessions, after which bot filter? Two analytics pipelines over the identical event stream will hand you two different growth stories, and a vendor will always quote the framework that flatters the pitch.
None of this is dishonesty, mostly. It's the Daimler situation, repeated a thousand times a day across dashboards: a real number, faithfully produced, under a framework left politely unstated. And the failure mode is always the same: someone compares a number produced under Framework A to a number produced under Framework B and draws a conclusion that exists in neither. That cross-framework comparison is not a smaller mistake than the headline blunders. It is the same mistake the SEC was trying to prevent when it forced Daimler to file a reconciliation: you cannot subtract a German-GAAP profit from a US-GAAP loss and call the difference "performance." You have to translate them into one framework first, or you're comparing nothing.
There's a deeper split underneath the line items, and it's the one engineers will recognize as a fight they're still having. US GAAP is famously rules-based: thousands of pages of specific, bright-line tests. IFRS is principles-based: fewer hard rules, more "exercise professional judgment to faithfully represent the substance." This is not a small stylistic difference. It is two opposite bets about how you make a lot of people behave honestly at scale, and software has made exactly the same two bets.
Bright-line rules are the linter, the CI gate, the hard threshold. Their gift is consistency: everyone gets the same answer, no judgment required, no arguing with the build. Their curse is that a bright line is an invitation to stand exactly one inch on the safe side of it. The classic case is leases. Old US GAAP said a lease was a "capital lease" (on your balance sheet, ugly) if it ran for 75% or more of the asset's life, or if the payments were 90% or more of its value. So companies wrote leases at 74% and 89%, structuring deals to clear the bright line by an inch and keep billions in obligations off the books. Enron turned this art form into a catastrophe. The rule didn't produce honesty; it produced a generation of people optimizing against the rule's letter while gutting its intent. Every engineer who has watched a team game a code-coverage target by writing assertion-free tests that touch every line knows this story in their bones. Goodhart's law has an accounting chapter, and it was written in the 1990s.
Principles-based IFRS makes the opposite bet: state the intent ("substance over form"), trust the judgment, and you can't game a principle by structuring around a number that isn't there. The gift is that it bends toward honesty in the spirit. The curse is that judgment doesn't replicate, two good auditors, same facts, different answers, and "use your judgment" is cold comfort to a regulator who needs to prove something in court. It's the code-review-culture bet: powerful, humane, and maddeningly inconsistent across reviewers.
The mature answer, the one both standards have been limping toward, is the same one the best engineering orgs land on: neither alone works. A bright line with no principle behind it gets gamed; a principle with no teeth drifts. You want a rule that remembers why it exists: a CI check whose failure message explains the value it's protecting, a threshold paired with a "and don't structure around this." GAAP and IFRS spent thirty years and a few financial crises learning that lesson. You can have it for free.
You'd think two honest systems answering one question would eventually converge, and they tried. The 2002 Norwalk Agreement committed the FASB and IASB to harmonize, and on the biggest item they succeeded: revenue recognition genuinely converged into a single standard (ASC 606 / IFRS 15). But the grand merger stalled. The SEC never adopted IFRS for American companies. The US stayed on GAAP; the world stayed on IFRS; the gap that flipped Daimler's sign is, in its essentials, still open today.
It stalled because the frameworks aren't really disagreeing about accounting. They're disagreeing about values. US GAAP's bright lines encode a society that litigates, where "I followed the specific rule" is a legal shield and judgment is a liability. IFRS's principles encode a preference for faithful representation over mechanical comparability. Choosing a framework is choosing what you're willing to trade: consistency for honesty-of-spirit, gameability for litigation-safety, comparability across companies for fidelity to each one. There is no framework-free vantage point from which one is simply correct, which is precisely why two centuries of very smart people haven't picked a winner.
You will never reconcile GAAP and IFRS, and you don't need to. You need to carry the accountants' hard-won humility into every number you touch.
Never compare across frameworks. Before you put two numbers side by side, two benchmark scores, two latency figures, your funnel versus the competitor's, find out if they were produced the same way. If they weren't, you're subtracting a profit from a loss. Normalize the framework first or don't compare at all.
Know which bet your metric is making. Is it a bright-line rule (consistent, and therefore guaranteed to be gamed, so watch the inch on the safe side) or a judgment call (faithful, and therefore drifting, so watch the inter-rater variance)? Each failure mode is predictable once you've named which one you chose. Design for it.
Always ship the framework with the number. The single most honest document in this whole saga is the reconciliation Daimler was forced to file: here's the number, here's the framework, here's exactly how it changes under another. Do that with your metrics. A dashboard that shows "12% growth" without its definitions is the prettier of two equally valid fictions, and someday someone will list it on a different exchange and discover it was a loss all along.
A number is an answer to a question you didn't ask: under which framework? Daimler-Benz was both comfortably profitable and nearly two billion in the red in 1993, and the auditors on both sides were right. Demand the framework. It's the difference between knowing a thing and trusting a translation you never read.
Ship the framework with the number. For an agent, that means shipping the reconciliation.
The essay's one rule, carried into agent work: a result is meaningless without the framework that produced it, so the honest artifact is the reconciliation, the number plus exactly how it was reached. Chain of Consciousness is that reconciliation for an agent: a tamper-evident record of what it actually did and decided to arrive at a result, so a reviewer reads the framework instead of trusting a translation they never saw. The number that ships with its provenance is the one you can compare; the bare number is the prettier fiction.
See Hosted Chain of Consciousness · See a verified action chain
pip install chain-of-consciousness · npm install chain-of-consciousness