Greenbox has 2,500 subscribers across Perth and is opening in Melbourne. The team has grown to twelve people, and the codebase has been restructured around bounded contexts. But the substitution logic that matches produce to boxes still lives in the founder’s head, and that’s about to become a problem.
Every Tuesday at 5am, Maya’s alarm goes off. She makes a coffee, opens the farm availability spreadsheet, and starts matching supply to demand. Which farms have what. Which subscribers get which box. What to do when Dave’s zucchini crop falls short and she needs a substitute that works for customers who are vegan, or allergic to nightshades, or just really hate beetroot.
This has worked fine for a year. Maya’s brain is the substitution engine. She knows that when zucchini is short, you swap in green beans unless it’s winter, in which case you swap in broccoli unless the customer has flagged a preference against brassicas, in which case you swap in sweet potato unless the box is a small box and sweet potato would push the weight over the limit.
She does this for two thousand five hundred subscribers. Every Tuesday. In her head.
Now Greenbox is opening Melbourne. Anika has joined to handle Melbourne operations. She’s sharp, organised, and excited. She also has zero farming experience. She doesn’t know which farms are reliable, which produce substitutes well for what, or which customers will email Sam in a fury if they get kale instead of spinach.
Maya can’t be the substitution engine for two cities. Perth takes three hours. Melbourne will take another two. Five hours before sunrise every Tuesday. And if Maya’s sick? On a plane? On holiday?
The business depends on the contents of one person’s head. The Event Storming session flagged substitution policy as a hotspot months ago, “who decides, and how?” was the pink note Maya reached for first. That’s not a staffing problem. That’s a survival risk.
The Example Map that broke
Anika’s first instinct is good. She suggests they Example Map the substitution rules.
Yellow card: “Substitute produce when a farm can’t supply.” They start writing rules and examples.
The first rule is simple: “When a produce item is short, substitute a similar item from the same category.” Zucchini short, substitute green beans. Apples short, substitute pears. Easy.
Then the conditions start multiplying. Season (green beans aren’t available in winter). Allergens (nightshade allergy means no capsicum for tomatoes). Customer preferences (“no beetroot”). Price band (can’t put $8 of cherries where $3 of carrots was). Box size (pumpkin fits in a large box, not a small one). Farm reliability (Maya orders 20% less than Dave offers because he overpromises every spring).
Twenty minutes in, Anika has six rules and five conditions per rule. The green cards pile up. Thirty examples and they haven’t covered tomatoes, apples, or leafy greens.
“This isn’t working,” Anika says. “We’re going to need hundreds of cards.”
She’s right. When conditions multiply, Example Mapping produces a card explosion. The tool isn’t wrong, it’s the wrong tool for this problem shape.
Decision tables
Charlotte has been watching. “You need a decision table.”
A decision table is a structured way to express every combination of conditions and actions. Columns are conditions and actions. Each row is a complete rule.
Charlotte draws the structure for zucchini substitutions:
| Season | Allergens | Preferences | Box Size | Price Band | Substitute |
|---|---|---|---|---|---|
| Summer | None | None | Small | Standard | Green beans |
| Summer | None | None | Large | Standard | Green beans |
| Summer | None | No legumes | Small | Standard | Yellow squash |
| Summer | None | No legumes | Large | Standard | Yellow squash |
| Summer | Nightshade | None | Small | Standard | Green beans |
| Winter | None | None | Small | Standard | Broccoli |
| Winter | None | None | Large | Standard | Broccoli |
| Winter | None | No brassicas | Small | Standard | Sweet potato |
| Winter | None | No brassicas | Large | Standard | Pumpkin |
| Winter | Nightshade | None | Small | Standard | Broccoli |
| Winter | Nightshade | No brassicas | Small | Standard | Sweet potato |
| Any | Any | Any | Any | Premium | Asparagus (seasonal) |
Every combination has a row. Every row has an unambiguous action. No gaps.
Maya looks at the table. “This is what I do in my head every Tuesday.”
Building the tables together
Maya and Anika spend two days building decision tables for the twelve most commonly substituted produce items. Each table has between twenty and forty rows.
Halfway through the first day, they hit Mrs Patterson.
Tom has built the initial table with five columns. Maya shakes her head. “Where’s the customer preference column?”
“That’s ‘Preferences.’ No legumes, no brassicas, no nightshades.”
“Those are category preferences. I mean specific customer preferences. Mrs Patterson hates beetroot. She’s never flagged it as an allergy. She just hates it. I’ve kept it in my head since she emailed Sam eight months ago. If the system substitutes beetroot into her box, she’ll be upset. And she’s been subscribed since week three.”
They add a “Customer Flag” column, a boolean marking whether the customer has any individually recorded preference. It adds rows to every table, but it captures something that lived only in Maya’s memory.
“Mrs Patterson’s beetroot just added a dimension to twelve decision tables,” Tom says.
“Mrs Patterson’s beetroot just made the system honest about what it doesn’t know,” Charlotte replies.
Anika challenges with edge cases. “What if the customer is vegan AND allergic to nuts AND in the small box AND it’s winter? What do we substitute for the capsicum?”
Maya pauses. “I… honestly don’t know. I’ve never had that combination.”
That’s the point. The table forces them to confront every combination, including ones Maya has never encountered. They decide: sweet potato. Row 34 of the capsicum table.
“How often does this come up?” Anika asks.
“Maybe once a quarter. But when it does, I spend ten minutes agonising. Now it’s a lookup.”
Dave visits the office on Thursday with a sample crate of a new cherry variety. Maya shows him the decision tables. Row 7: “Adjust Dave’s supply estimates by -20% based on historical over-promising.”
Dave stares at the screen for a long time.
“You’ve put my forty years of farming into a spreadsheet. I don’t know whether to be flattered or offended.”
“Both is fine,” Maya says.
Dave leans closer. He reads more rows. “This one’s wrong. Butternut pumpkin as a summer substitute for zucchini, but I don’t grow butternut in summer. Too hot. You want Kent pumpkin.”
Maya corrects the row. Dave watches her type.
“Huh. Quicker than calling you at five in the morning, I suppose.”
Feeding it to the LLM
Priya takes the zucchini table and prompts the LLMA neural network trained to predict the next token in a sequence, large enough that it generalises to tasks it wasn’t explicitly trained for. :
Here is a decision table for zucchini substitutions. Each row specifies conditions and the correct substitute. Generate a Go function that takes these conditions as inputs and returns the correct substitute. Include unit tests covering every row.
The LLM generates a function and a table-driven test suite. Every row becomes a test case. All pass. The code is a straightforward series of conditionals mirroring the table.
They repeat for all twelve produce items. Total: about a thousand lines of Go with four hundred test cases.
Anika runs Melbourne
The following Tuesday, Anika runs Melbourne matching for the first time. She enters farm availability. The engine handles matching. Where manual review is needed, a new farm, a produce item not in the tables, the system flags it.
She finishes in forty minutes.
Maya reviews the output. Two minor adjustments, an unusual beetroot variety classified as “root vegetable” that Maya thinks belongs in “salad greens.” They update the table. Regenerate the code. The test suite catches the change.
On Wednesday morning, Maya sends a message to Slack: “For the first time in a year, I woke up at 7am on a Tuesday. Not 5am. Anika handled Melbourne. The engine handled the matching. I reviewed the output over breakfast instead of building it from scratch in the dark.”
That evening, she texts her mum.
“Is this how you felt when you sold the farm?”
Her mum responds twenty minutes later. “No. This is how I felt when you left.”
Maya reads it three times, standing in the bathroom with toothpaste on her lips. Her mum doesn’t mean it as a wound. She means: the hardest letting go isn’t giving up the thing. It’s watching someone else carry it forward and knowing they’ll carry it differently than you would.
When to use decision tables vs Example Mapping
Example Mapping is right when a story has a few rules with a few conditions each. If your map fits on a table with room to spare, you don’t need a decision table.
Decision tables are right when conditions multiply, four, five, six independent variables and the combinations explode. When every example card looks like the one before with one condition changed. When completeness matters.
The team often starts with Example Mapping and switches mid-session when the cards pile up. Anika’s zucchini session is the textbook case.
Sam’s shared inbox now has eighty-plus emails per week. Jas looks at Sam’s spreadsheet of common questions and designs a FAQ page based on the top ten. Support volume drops thirty percent. Sam: “The best support is the support you don’t need.”
Maintaining the tables
Decision tables are living documents. When Greenbox onboards a new farm growing something they’ve never substituted, dragon fruit. Maya and Anika write a new table in an afternoon. The LLM generates code and tests.
When a customer complains about getting kale instead of silverbeet, Anika checks the table. Row 17 says kale is valid. They add a condition: if the customer has previously complained, flag for manual review. New row. New code. New test.
The tables are the single source of truth. Not the code, the tables. The code is generated from them. Charlotte insists on this discipline: “The moment you start editing code instead of updating the table first, you’ve lost the connection between business logic and implementation.”
What comes next
The tables are done. The LLM generated code and tests from them. But what does that code actually look like? Next: the substitution engine in Go.
The next chapter, Decision Tables: The Substitution Engine in Go, publishes around 24 June.