The Coffee Board says Coorg grows coffee across 82,000 hectares. ISRO's satellite atlas says 135,796.
They're both the government. They're 65% apart. And my website has to show a number.
My coffee site has region pages — Coorg, Chikmagalur, Wayanad, the usual suspects. Each page is supposed to tell you something about where your coffee grew: area, altitude, rainfall. The kind of facts that make paying ₹1,800 a kilo feel less like a gamble and more like a decision.
So I needed one number: how big is the Coorg coffee belt?
The Coffee Board — the actual government body for Indian coffee — says roughly 82,000 hectares, from 2014 data. Fine. Done. Then, because I'm thorough to a fault, I checked a second source. The National Remote Sensing Centre and ISRO published a 2024 satellite atlas of Indian coffee. Their number for the same region: 135,796.
Let me sit with that. Two arms of the Indian government, both official, both defensible, disagreeing by 65% on the flagship region of Indian coffee.
And the uncomfortable part wasn't the disagreement. It was what happens next.
Whatever number I render, I'm not "reporting the area of Coorg." I'm choosing a side. If I show 82,000, I look wrong to anyone who read the satellite atlas. If I show 135,796, I look wrong to anyone who read the Coffee Board. Either way, the moment a reader checks the other authority, my correct-looking number becomes a trust leak.
The deeper problem is that there often isn't a single right number. "The area of Coorg's coffee belt" depends on who measured, when, and what they counted as the coffee belt. Both agencies measured something real. They just didn't measure the same thing.
So I didn't pick between them.
I made the number carry its own receipts.
Instead of a footnote the frontend has to remember to render — and will forget, on some page, eventually — I pushed provenance into the schema. The canon_regions table got two new columns: area_source and area_as_of. Then came the part I actually like: a check constraint named canon_regions_area_needs_source that rejects any write of area_hectares that doesn't also carry a source and an as-of date.
An unsourced number is now unwritable. The frontend can't forget to attribute the figure, because the database won't let an unattributed figure exist in the first place.
The Coorg page now shows a number with a source and a date. You can see it's ISRO's 2024 figure — or the Coffee Board's 2014 one — and decide for yourself what "the area of Coorg" means. I didn't resolve a 65% government disagreement. I made it impossible to hide.
One wrinkle, and it's the reason I'm writing this down. When you add a hard constraint to a table that already has data, the migration usually dies on the rows that violate it. I had four legacy region rows with area figures and no source. A strict constraint would have aborted the whole migration — and the instinct is to skip the constraint and add a "source" line to the UI instead, leaving every future row unsourced too.
Postgres has an escape hatch for exactly this: NOT VALID. A NOT VALID constraint governs every new write immediately while grandfathering the existing violating rows until you get around to them. So I shipped the constraint, left the four rows flagged, and moved on. The rule is in force today. The legacy cleanup is a chore for some Tuesday, not a reason to leave the door open forever.
This generalizes harder than coffee, and it's why I care about it right now.
I'm a Sr Director of Sales Operations these days, and "revenue" — the number every GTM dashboard is built on — has at least five definitions: won, committed, billed, recognized, MRR. Each with its own as-of date. Each owned by a different team with a different incentive.
When two teams report "the same number" 65% apart, that's not a data bug. That's a missing provenance column. Somebody rendered "revenue" without saying which revenue, from which system, as of when — and picked a side they can't defend the moment the other team opens their own dashboard.
Coffee regions taught me the fix, and it's the same fix in RevOps: don't try to unify the number. Make it carry its receipts — source, definition, as-of — enforced at the schema level, so nobody can write a dashboard figure that doesn't say what it is.
An unattributed number isn't a fact. It's a liability you haven't noticed yet.
Next time you're dead sure of a number, ask which of the two authorities you're silently siding with.