You have a feature, a deadline, and a room that has already decided the work is ready to start. Everybody can describe what it does. Somebody has demoed a version of it in a notebook. The pressure is to begin, and beginning is the one move nobody in the room will be blamed for. So the question worth asking is not whether the team feels ready — it is whether the feature could survive being written into a contract that pays a refund if it misses.
That is not a rhetorical device. ML LABS writes the acceptance targets into the statement of work before a build starts, and a target missed for reasons within our control refunds the fee. A guarantee shaped that way is a filter before it is a promise: a feature that cannot carry a written, gradeable target cannot carry the guarantee either, and the work of discovering that is exactly the work the build was about to skip. Readiness is a property of the artifacts — the target, the access, the owner — and every one of them can be checked in an afternoon, before any budget moves.
The three tests below are the ones a build actually runs on, and they map to what a buyer has to hand over on day one: the workflow and its targets, the repositories and the staging environment and working credentials, and one named engineering point of contact. That list is not administrative. It is the readiness test wearing an intake form.
graph TD
A["Target Test<br/>A stranger can<br/>grade the result"] --> D{"All three?"}
B["Access Test<br/>Repos, staging, keys,<br/>real test data — today"] --> D
C["Owner Test<br/>One named engineer,<br/>one decision-maker"] --> D
D -->|"Yes"| E["Build-Ready"]
D -->|"No"| F["The gap IS<br/>the next engagement"]
style A fill:#1a1a2e,stroke:#ffd700,color:#fff
style B fill:#1a1a2e,stroke:#ffd700,color:#fff
style C fill:#1a1a2e,stroke:#ffd700,color:#fff
style D fill:#1a1a2e,stroke:#0f3460,color:#fff
style E fill:#1a1a2e,stroke:#16c79a,color:#fff
style F fill:#1a1a2e,stroke:#e94560,color:#fffWrite The Target A Stranger Grades
A build-ready feature has an acceptance condition that someone who did not help write it could grade pass or fail. "Add AI to support" cannot be graded. "Generate source-grounded draft replies from the last 90 days of tickets, and hand them to an agent for approval" is closer, and it is still not there — nothing in it says what counts as a good draft.
The shape of a real one is worth studying, because ML LABS has shipped against it. A PropTech platform stated the requirement in its own words — a valuation engine that could "price properties within 10% of closing price in dense markets, in seconds instead of days" — and the engine that came out of it holds within 10% of closing price for 90% of cases. Read the requirement as an engineer and notice what it does. It names the metric (distance from closing price), the tolerance (10%), the regime it applies to (dense markets, which are not the same statistical animal as thin ones), and the latency class. Their Founder/CEO could check every clause of it without trusting anybody, which is what made it worth building against — and, once built, worth something: "That system became the reason investors took us seriously."
Notice also where the difficulty on that build actually sat, because the target as written could easily have missed it. Producing the point estimate was the easy half; calibrating the confidence band — deciding when the system was allowed to be trusted, and routing everything below the bar to a human appraiser — was the harder work. A target that names an accuracy number and says nothing about what happens to the cases underneath it has specified the demo and left the product unwritten. This is the gap requirements research on AI-intensive systems (Ahmad et al., 2022) puts at the center of downstream failure: business intent that is clear in business language and ambiguous in technical language, and research on AI projects going off track (HBR, 2023) describes the result — teams that ship what was asked for and still miss what the business needed. The full discipline of writing targets that survive is the subject of the companion piece on written requirements. For readiness, one test is enough: write the target, hand it to someone who was not in the room, and ask how they would grade it. Their hesitation is your answer.
Hand Over The Keys Today
The access test is brutally concrete, and it is passed or failed today rather than argued about. Can someone produce a working credential and a sample payload for every API in the feature path. Can the team show a recent query result against the production data the feature will actually read, rather than a CSV exported a quarter ago. Is there a repository URL, a staging environment that exists, and a deployment path that does not require a meeting to unblock. When any of those answers is "we will figure that out during the build," the build is being asked to absorb work that belongs upstream of it, and it will absorb it — out of the same budget, at a worse hourly rate.
This is where an AI feature is most exposed, and it is not where the excitement is. Research on hidden technical debt in ML systems (NeurIPS, 2015) found the model to be a small fraction of a production system, with the rest being data plumbing, serving, configuration, and glue; a case study of ML engineering practice (ICSE, 2019) reports the same center of gravity from inside the teams doing it, and ML engineering guidance (Google, 2024) treats the assumptions buried in that plumbing as a primary source of downstream failure. The access test is how those assumptions get flushed out before they are paid for: a credential that does not exist, a dataset nobody has queried this quarter, and a staging environment that is really a slide are all the same finding wearing different clothes.
There is a sharper version of this test hiding inside how ML LABS delivers a contained build: the system is built and run in our environment first, and you test it in your staging environment before you accept it. Every dollar is refundable until you do. That structure quietly asserts something about the feature: it must be demonstrable somewhere other than your production environment. If the only place a feature can be shown to work is production — because the data cannot be extracted, the dependency cannot be stubbed, the behavior cannot be reproduced — then it is not a build, it is an operations change, and it needs a different plan and a different step.
The honest complication is that a hard dependency is not automatically a stop sign. HeartSciences' AI-ECG platform had to integrate with a major EHR vendor whose sandbox access was limited, shared, and externally scheduled — a textbook failure of the access test. The move was not to wait for the calendar to clear. ML LABS built a full EHR integration simulator that replicated the workflows at the protocol level, and development continued against it: per-organization field mappings, bidirectional message handling, authentication binding, all exercised before a sandbox window was ever granted. So the access test has three outcomes, not two — reachable, unreachable, or reachable by building the thing that reaches it. What it never has is a fourth outcome where the dependency is assumed away and discovered mid-build.
One Owner, Not A Committee
A build needs two people and no more: one who can approve a scope tradeoff, and one hands-on engineer who can unblock access, deployment, and review. Research on AI project failures (RAND, 2024) locates the damage in organizational friction more often than in model capability, and the mechanism is unglamorous — a build does not lose its time to hard problems, it loses it to waiting.
The tell is what happens to a mid-build discovery. Suppose the data turns out to contain a category the target never contemplated, and covering it would trade accuracy against coverage in a way that changes the rest of the work. With a real owner, the call is made the same day, the target moves by one clause, and execution continues. Without one, the team picks a default, and the default surfaces at review as a disagreement about scope that nobody can adjudicate. That is not an engineering failure. It is a decision that no one was authorized to make at the speed the work required — and the difference between those two diagnoses is who pays for the rework.
A feature is build-ready when its target can be graded by a stranger, its systems can be reached today, and one person can change the target tomorrow.
When The Answer Is Not Yet
Two kinds of feature fail these tests for reasons no amount of narrowing will fix. The first is the change that spans several teams and rewires a shared platform: it is not a contained build regardless of how the target is written, and treating it as one produces a build that succeeds against its target while the surrounding system refuses it. The second is the feature that is genuinely still a research question — where nobody can yet say what "good" would look like, because the answer depends on what the data turns out to contain.
Both cases have the same resolution, and it is not to build harder. It is to buy the missing artifact first: the decision, if the workflow itself is still contested, or a plan and a working spike, if the workflow is chosen and the uncertainty is technical. Failing a readiness test is not a verdict on the feature. It is a precise description of what the next engagement is for.
First Steps
- Write the acceptance target and hand it to a stranger. Not a teammate — someone who was not in the room. Ask them how they would grade it. Their hesitation is the finding.
- Run the day-one handover, today. Repository URL, staging environment, working credentials, a real query result against real data. Anything you cannot produce this afternoon is a dependency, not a detail.
- Name the two people, in writing. The one who approves a scope tradeoff, and the one who unblocks access. If either slot holds a committee, it holds nobody.
Build What You Can Grade
Match the step to the test you failed. If the target cannot be written because the workflow itself is still contested, the decision comes before the build, and it is the cheapest thing on the ladder to get right. If the target is writable but nobody can prove the path holds in your stack, the missing artifact is a running spike and a fixed price — which is what a good AI system design includes, and the step that produces it sits directly below the build. And the work of carrying a pilot the rest of the way to production begins from exactly the position these three tests describe.
If all three pass — the target is gradeable by a stranger, the keys are on the table, the owner has a name — the feature is ready for a production workflow build, which takes one contained workflow the whole distance and carries its first 30 days of operation with it, because a live system is where a target stops being a document and starts being a fact. The tests are cheap to run and expensive to skip, and the reason they work is that they are not really about the feature. They are about whether the organization around it can say something checkable, hand over something real, and decide something quickly. Features that clear those three bars get built. The rest get discovered eventually, and the only live question is whether you discover them this week, for free, or later, from inside a build you have already paid for.
References
- Ahmad, K., Abdelrazek, M., Arora, C., Bano, M., & Grundy, J. A Systematic Mapping Study on Requirements Engineering for AI-Intensive Systems. arXiv, 2022.
- HBR Editors. Keep Your AI Projects on Track. Harvard Business Review, 2023.
- RAND Corporation. Analysis of AI Project Failures. RAND Corporation, 2024.
- Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. Software Engineering for Machine Learning: A Case Study. ICSE, 2019.
- Google. Rules of Machine Learning: Best Practices for ML Engineering. Google Developers, 2024.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J., & Dennison, D. Hidden Technical Debt in Machine Learning Systems. NeurIPS, 2015.
