With ordinary software this was simple. You wrote a test. The same input always gave the same output, so the test passed or it failed.
AI does not behave that way. Ask the same question three times and you may get three different answers. Two may be fine. One may be subtly wrong. A single test tells you very little.
Measuring It Differently
So you measure it differently. You collect a set of real examples where you already know what a good answer looks like. You run the system on all of them, and you count how often it gets it right.
Think of a driving test. Nobody can watch a driver on every road for the rest of their life, so we define a set of situations and a passing score. Pass, and you get the licence.
A Worked Example
The video uses round numbers. You gather 200 real cases and set the bar at 95%. Version one scores 90%. It does not ship.
Used this way, the evaluation becomes the acceptance test. It is the definition of good enough, written down in advance.
Version one falls short of the bar and does not ship. Round numbers for illustration.
Why It Matters
This matters more than it seems. Whoever writes the evaluation decides what good means. And every time the model changes, you run it again, so a change that breaks something gets caught before your customers see it.
Benchmarks contrasts with AI Evaluation as Acceptance Test. A benchmark’s public questions are not yours; an acceptance evaluation uses your own real cases and a bar set in advance.
Discardable Software builds on AI Evaluation as Acceptance Test. The checks that tell you the program did the right thing must last even when the code is thrown away.
The Residency Model builds on AI Evaluation as Acceptance Test. The residency’s last step is a test on the work itself, judged on real cases like an acceptance test.
Outcome-Based Pricing builds on AI Evaluation as Acceptance Test. Both sides must agree in advance what counts as solved and who measures it, as in an acceptance test.
AI Evaluation as Acceptance Test builds on Overfitting. An evaluation counts on real cases with known answers, following the overfitting rule to test on what the model has not seen.
Model Deprecation(lesson unlocks soon) builds on AI Evaluation as Acceptance Test. The defense against deprecation is keeping your own test cases and rerunning them before every switch, an acceptance evaluation.
AI Evaluation as Acceptance Test contrasts with Post-Market Surveillance(lesson unlocks soon). An acceptance test decides before shipping; post-market surveillance keeps checking in real use because a test shows one day.
AI Evaluation as Acceptance Test builds on Panel Data(lesson unlocks soon). An evaluation set of real examples stands in for all real use, so who is in that sample shapes the score.
The Business Engineer framework maps where each part of the AI stack sits and who holds the leverage. These pills are short lessons from the same library.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur (for example, How to Digitize a Family Business in Europe) and HackerNoon. Find him on LinkedIn and Substack. See how we source.
