At the end of the day, if your model predicts a profit loss that never shows up on the P&L, your events were wrong, and the odds of consistently getting them right are thin.
That’s actually the point. The value isn’t in betting on one forecast, it’s in being able to spin up hundreds of simulations quickly and look for trends. Instead of endless debate over Option A vs. B vs. C, you run them all.
If 80% of scenarios show the Vancouver office underwater in Q1, that’s a signal worth digging into. If it only shows up in 20%, you know not to over-index on it. It’s less about false precision and more about identifying patterns of risk and opportunity across a range of possibilities.
It did feel like the article compressed that nuance (maybe due to AI-assisted phrasing?), but if not, fair enough! sorry for suggesting it.
A lot of it is turning all that information back into something that people can use. PNL is so standard that it's a good format for most executives.
And yes, spent a lot of time bouncing back-and-forth between ChatGPT and custom editing the article.
The big goal is taking all of this one step further and using generative AI to actually build the financial models and interact with them. Large language models have a good understanding of core business concepts, and being able to "train" a model to understand, our events means we can map common business concepts to our nodes and build the models for people conversationally. We've got this working under the hood but still have a lot of refining to do before it can be user facing.
jonnylegs•5mo ago
It struck me that most financial and business models don’t work this way. In spreadsheets, time is something you simulate with formulas, but the system doesn’t understand that a hire in April triggers payroll in May and revenue in June. The “why” and “when” behind the numbers are missing.
This piece is about applying an event-based approach - treating business actions (hiring, contracts, re-orders, product launches) as logic blocks that sit on a timeline. The idea is that this structure makes models more resilient, makes scenario planning easier, and gives AI something useful to work with.
Curious if others here have run into the same spreadsheet limitations - and whether anyone has tried event-driven or simulation-style approaches outside of finance (e.g. supply chain, operations, project planning).
dragonwriter•5mo ago
It does if the person designing the spreadsheet knew that and it was part of what the sheet was designed to model; there’s nothing about spreadsheets in that, just about the underlying assumptions the particular spreadsheet is built around.
I’ve certainly built and used spreadsheets where this kind of thing was part of the model, and also those where it wasn’t.
jonnylegs•5mo ago
But time is not the fundamental axis in a spreadsheet. Sure there are tons of date formulas - but the calculations don't step through time, day by day (or weekly/monthly/hourly) like they do in other simulation systems.
And the dependencies between cells are pretty hard-coded.
again. -almost anything is possible in a spreadsheet but you're cutting corners to make it happen.
dragonwriter•5mo ago
I’ve worked with lots of financial projection and reportinf spreadsheet, and time has usually been the, or at least a, fundamental axis.
> but the calculations don't step through time, day by day (or weekly/monthly/hourly) like they do in other simulation systems.
They... absolutely do, if the underlying view that the sheet is built around is a sequence of time steps. A workbook with a control plane sheet or sheets with starting values and a grid of input variables in rows and timesteps in columns with an output sheet with output variables in rows and timesteps in columns, where each output row has a formula taking into account outputs in earlier timesteps and inputs in the same or earlier timesteps is, IME, a fairly common way to construct a modeling tool using spreadsheet software.
jonnylegs•5mo ago
In contrast, (and the whole thesis of the software we've built) simulation and event-based approaches treat time as a first-class citizen. The engine itself steps through each day, week, or month, checking which events are active and applying their effects. Instead of hand-building those mechanics each time, you snap together reusable logic blocks. For the modeler, it’s less about “can we do this?” (because spreadsheets can do almost anything) and more about “should we keep reinventing the wheel, or use a framework that makes time and dependencies explicit by design?”