Ask a financial model a question and it gives you a number. Numbers feel like answers. They look precise, they fit in a sentence, and they end meetings. But a number on its own is the least durable form of knowledge a business can produce — because the moment someone asks "where did that come from?", it has nothing to say for itself.
The Problem With Naked Numbers
Here is a real output from a financial model we built for a controlled environment agriculture business: a retail mix of 10% or above is sufficient to exceed an $80M valuation at Year 6.
Stated that way, it sounds like a fact. It is not. It is a conclusion that holds only under specific assumptions: a yield of 80 kg per square meter, a 12x EBITDA multiple, retail pricing at $0.515 per ounce against $0.297 for food service, and a particular deployment schedule. Change any of those and the number moves. The naked version of the claim cannot be defended in diligence, cannot be compared against a later run of the model, and cannot be safely reused by anyone who wasn't in the room when it was produced.
Most analysis dies this way. Not because it was wrong, but because it was unaccompanied.
The Discipline: "According To"
The fix is a small habit with large consequences. Every published finding from the model carries the same attribution: "According to GreenOS-Fin, ..." — naming the system, its revision, and the date of the run.
That phrase looks like branding. It is actually an engineering constraint, because attribution forces three things to exist. First, a named source: if the finding is "according to" something, that something must be inspectable. Second, stated assumptions: an answer is not just a number; it is a number under stated assumptions. Third, reproducibility: every report is dated and never overwritten, so a reader can see exactly what changed between runs and why.
There is one more rule, and it is the one that builds trust: every answer states what the model does not account for. A threshold result is not a forecast. Saying so out loud is what keeps the attribution honest — and what lets a skeptical reader extend trust to the next answer.
The Test
The difference between storing analysis and engineering knowledge comes down to the unit of work. A spreadsheet in a shared drive is storage. The engineered unit is the complete package: the question, the method, the assumptions, the answer, the citation, and the boundary conditions.
Next time a number lands in front of you — in a board deck, a diligence packet, a forecast — ask the only question that matters: according to what?
If there is no answer, you don't have knowledge. You have a number.
