ESSAY · 2026.10.18
Before an AI-generated number becomes a business decision
By Kyunghan Bae, F&B operator
Suppose an AI assistant tells a café owner that a menu item has a 30% margin. Before acting, the owner needs to know what went into that number. Does the price include VAT? Is the delivery fee charged on the full selling price? Does packaging cost apply to one drink or an entire order? A fluent explanation can leave these questions unanswered.
I run UNICUP and build tools for decisions about menus, costs, and purchasing. Alongside that work, I contribute fixes to scientific and data software. These activities share a practical concern: what must be true before we can use a result?
F&B Margin Kit makes its calculation rules explicit. It takes menu prices, quantities, ingredient costs, packaging costs, and platform fees to calculate contribution before fixed costs. All amounts in this example are in KRW. A hypothetical drink priced at 5,500, with 10% VAT, ingredient cost of 1,200, packaging of 150, and a 3% fee on the full selling price, contributes 3,485 per unit. Applying the fee to the price excluding VAT changes the answer. The agreement and input records should settle that choice.
AI can help explain a calculation or organize an input table. To check the result, an operator also needs the original row and the rule applied to it. A price comparison should show whether the selling price, cost, or assumed sales quantity changed. That makes the proposed action easier to assess.
My contribution to USGS's dataretrieval-python, PR #431, addressed missing observation timestamps. Missing inputs could produce invalid time filters. The patch rejected those inputs before a request was made, and the maintainer extended validation for timestamps and search windows. The contribution was merged and credited in the v1.4.0 release notes.
For a business reader, the comparable question is whether a sales row without a date belongs in a period comparison. Filling in today's date, separating the row, and stopping the calculation are different decisions. Recording the missing value preserves the operator's opportunity to choose.
The software checking a result needs scrutiny too. In Rule2DRC, PR #4 fixed a condition where an evaluation could report success despite a failed testcase execution. Failed runs could become zero predictions that matched an all-zero expected result. The change requires every testcase execution to succeed before applying the remaining checks. The PR records include reproduction results using actual KLayout executions.
A similar reporting mistake would treat an unreadable delivery-channel export as zero sales. A finished table does not establish that every source was processed. Operators need to distinguish an empty source, a failed import, and a period with no transactions.
Resource use offers another test of careful implementation. In forest-confidence-interval, PR #134 changed how selected class-probability columns were retained so unused arrays could be released earlier. In the comparison recorded in the PR—50 trees, 20 classes, and 10,000 test rows—Tracemalloc peak usage fell from approximately 84.2 MB to 8.4 MB. All 10,000 variance outputs were byte-identical. The patch is merged; it follows the latest 0.9 release checked on October 18, 2026.
Another merged forestci contribution, PR #128, corrected a bias calculation that used only part of the training data. It restored the use of all training rows and removed a dependence on row order. Reordering a business input table provides a similarly useful check: the totals should retain the same meaning.
Operators do not need to read every implementation. They can ask for three things:
- Input basis. Identify the period, location, currency, tax treatment, and source row. Keep missing values distinct from zero.
- Calculation rules. Show the fee basis, included costs, and assumed quantities. Recalculate one important item independently.
- Completion evidence. Reconcile expected and processed items. Retain failures, omissions, the rules used, and the software version.
These checks become concrete when placing an order. F&B Margin Kit's purchasing command combines planned menu quantities, recipes, preparation yields, and raw stock. It pools shared ingredients, subtracts stock once, and rounds shortages up to complete purchase packs. Planned sales quantities come from the operator.
If AI proposes next week's latte sales, the owner can assess that estimate against trading days, events, and recent sales before using it. The purchasing calculation can then apply the agreed quantity to known recipe and stock records. Keeping those decisions visible makes it easier to explain a later difference between the plan and actual sales.
I want these records to be readable by the person placing the order. A useful result lets that person find its inputs, check its arithmetic, and see what completed. That is the evidence I would want beside an AI-generated number before putting business money behind it.
Sources, code, and execution records · checked October 18, 2026