Built to Learn: When the Container Needs Rebuilding
So, I said the accounting simulator was ready. Then, I used it.
A few sessions in, something quickly felt off. I realized I wasn't learning - I was guessing. The feedback loop existed on paper, but in practice it wasn't building anything. I'd pick an answer, see whether I was right, and feel nothing accumulate.
That's a specific sort of failure, and I probably should have flagged that in design. Regardless, I went back in and took it apart.
What was actually broken
Three things, once I looked honestly.
The managerial lenses were vague in a way that made guessing the only strategy. The original version offered three options: Cash Flow Timing, Contribution Margin, and Decision Relevance. The problem wasn't the first two — those are concrete enough to reason toward. The problem was the third. Decision Relevance isn't a lens; it's a tautology. Everything is decision-relevant. It became a catch-all that absorbed anything the other two didn't obviously cover, which meant roughly half the scenarios landed there by default.
The financial reasoning question skipped the reasoning. "What is today's net income direction?" is a fine outcome question. But the whole point of learning debits and credits is to develop the mechanical chain that gets you there — what account is touched, what type of account is it, which side is its normal balance, what does this entry do to that balance, and only then: what does that do to net income. Collapsing all of that into a single multiple-choice outcome meant the tool was testing recall of a conclusion rather than building any understanding of the process that produces it.
The scenarios had no context, so you couldn't reason from them. "Today, the company pays $18,000 upfront for a 12-month insurance policy." That's a fact, not a situation. Building like that made it easy to randomize, but that's it. There's no one asking a question, no reason to care about the answer, no angle from which the event means something. Pattern-matching on transaction type is not the same as understanding why the accounting works the way it does, and abstract scenarios invite pattern-matching rather than reasoning.
Three problems, and they compounded each other. Nonspecific lenses plus a collapsed reasoning question plus context-free scenarios meant the tool was technically functional and pedagogically hollow.
How I fixed it, and in what order
The sequencing mattered here, so I want to be explicit about it.
I rebuilt the managerial lens taxonomy first, because everything else depends on what the tool is actually trying to teach. The four lenses I landed on are: Cash vs. Accrual Timing (when does cash move versus when does accounting recognize the event), Cost Behavior (which costs are fixed, which are variable, and what that means for unit economics), Incremental Analysis (which costs and revenues actually change because of a specific decision — sunk costs are irrelevant, only deltas matter), and Working Capital & Liquidity (how does this affect the company's short-term cash position). Each of those is a distinct analytical mode. You can learn to recognize them. You can reason toward them. None of them is a catch-all.
The scenario pool needed rebalancing once the lenses were right. The original ten scenarios clustered heavily around timing — which makes sense, because timing is foundational. But Cost Behavior and Incremental Analysis had almost no representation. So I added four new scenarios purpose-built for those lenses: an automation tradeoff (converting variable labor into fixed depreciation), a production volume increase (fixed cost dilution at higher output), a make-vs-buy decision, and an early payment discount. The last two raised an interesting design constraint: some of the best managerial accounting scenarios are decisions that haven't been executed yet, which means there's no journal entry to show. The tool now asks explicitly whether a journal entry exists today, and getting that wrong is itself an instructive miss.
The financial reasoning restructure came second. The guess is now three linked steps: which account is the focal one for this transaction, is it debited or credited, and does that increase or decrease the account balance. The account is shown because the skill being built is filing, not recall. Where does this get recorded, on which side, and what does that do to the balance? That's the T-account intuition I'm trying to drill.
Scenario context came last, because it only fully pays off once the question structure is right. I gave the simulator a home: Halcyon Woodworks, a mid-size cabinet and furniture manufacturer supplying regional retail chains. The industry is one I know well from prior work, which helped me write scenarios that feel operationally real without being arbitrary. The cast is small — Dana the Controller, Ray the CFO, Priya in Operations, Cal in Sales, Beth in Purchasing — and the scenarios are framed as things happening to them. Ray wants to know why net income didn't move when the cash left. Dana is booking revenue before the check arrives and Cal is confused. Beth flagged an early payment discount and she and Ray are running the numbers. The accounting question is still the accounting question, but now there's a human reason to make it easier to understand.
What the process revealed
I came in thinking I was fixing three discrete problems. What I left with was something more like a principle.
The original tool tested conclusions. The rebuilt tool asks for reasoning. That's the actual difference, and it's the difference between a tool that confirms you already know something and a tool that builds understanding when you don't yet.
The managerial lens problem is the clearest example. "Decision Relevance" as a catch-all didn't just produce bad guessing — it actively prevented learning, because there was nothing to learn toward. A vague category can't teach you to recognize anything. The four replacement lenses work because each one points at a distinct way of thinking about a transaction. You can read a scenario, ask yourself what kind of question it's actually raising, and reason toward an answer. That's a learnable skill. Catching an answer in a net labeled "everything else" is not.
The financial reasoning restructure taught me something similar. The net income direction question felt like accounting. It wasn't. It was arithmetic with accounting vocabulary. The three-step focal account question feels simpler on the surface — it's just three clicks instead of one — but it's doing something fundamentally different. It's asking you to trace a path rather than state a destination. That path is what needs to be learned.
And the scenario context — which felt like the most cosmetic fix of the three — turned out to matter more than I expected. Not because naming a character makes the accounting different, but because a named character with a specific question forces you to read the scenario rather than scan it for keywords. "Ray wants to know why net income didn't move today despite the cash leaving" puts you in the room. You're not pattern-matching on "machine purchase" anymore; you're actually thinking about what Ray is confused about and why Dana would explain it the way she would.
That's the version of the tool I needed. I just didn't know enough about learning design to know I didn't have it yet.
What's still ahead
The rebuild went from ten to fourteen scenarios. Fourteen is still not enough to drill anything into long-term memory — that takes repetition at a volume that requires many more entries across more concept areas. The work ahead is identifying where my understanding actually breaks down under course pressure and building scenarios for those specific gaps.
The other thing I want to revisit is the scenario text itself. The Halcyon cast gives the scenarios a home, but the language is still relatively sparse. There's room to make the situations richer — more operational detail, more of the specific texture of a manufacturing business — without making them harder to read.
But the real question is: do I want or need to revisit all of this, or is it better to move on to something else? Whatever the answer, the simulator is a little better now.
The simulator is built with Python and Streamlit. If you want to talk through the architecture or the learning design decisions, get in touch.