What To Demand From An AI System Design

Everything a buyer can purchase before a build falls into one of two categories, and the line between them is not price, page count, or the credentials of whoever signs it. It is whether the thing handed back has a failure condition. A document does not have one. Whatever it concludes about feasibility, architecture, or risk, it arrives complete, it reads as authoritative, and nothing that happens next can grade it before the build money has already moved. That is not a complaint about the people who write documents — it is a property of the artifact. A system design engagement belongs to the other category: it ends in a spike that either runs against your data, in your stack, or does not.

That distinction is the whole purchase, because the distance a pre-build engagement is supposed to measure is exactly the distance a document cannot reach. Research on AI project failures (RAND, 2024), requirements engineering research (Ahmad et al., 2022), and a case study of ML engineering practice (ICSE, 2019) converge on the same location for the damage: not the model, but the gap between the business outcome someone approved and the technical system that was actually reachable in the buyer's environment. Enterprise survey data (BCG, 2024) puts a number on the population — across roughly 1,000 executives, only about a quarter of companies had moved past proof of concept into tangible value. An artifact that never touches the environment cannot close a gap that only exists inside it.

Here is what that looks like in a real system. ML LABS built the cloud backend for HeartSciences' AI-ECG platform, which had to integrate bidirectionally with a major EHR vendor. Two hospitals on the same vendor sent the patient identifier in the same HL7 field — one zero-padded the medical record number to a fixed width, the other left it variable, and a parser that worked end to end at the first site mismatched results to the wrong patient at the second. One site populated the ordering provider field with an internal directory ID, another with a national provider identifier, a third with a free-text initial-and-surname string. Another site expected results only in answer to an explicit order; the next expected them to arrive unsolicited. None of that was in any specification, and none of it would have appeared in any architecture document, however good. It appeared because code ran — against a full EHR integration simulator ML LABS built precisely so the team could keep shipping instead of queuing for vendor sandbox windows.

graph TD
    A["Named Workflow<br/>+ Named Dataset"] --> B["Architecture<br/>+ Build Plan"]
    B --> C["Working Spike<br/>In Your Stack"]
    C --> D{"Does it run<br/>end to end?"}
    D -->|"Yes"| E["Fixed-Price Quote<br/>+ Go / No-Go"]
    D -->|"No"| F["Full Refund"]

    style A fill:#1a1a2e,stroke:#0f3460,color:#fff
    style B fill:#1a1a2e,stroke:#0f3460,color:#fff
    style C fill:#1a1a2e,stroke:#ffd700,color:#fff
    style D fill:#1a1a2e,stroke:#ffd700,color:#fff
    style E fill:#1a1a2e,stroke:#16c79a,color:#fff
    style F fill:#1a1a2e,stroke:#e94560,color:#fff

The Deliverable That Cannot Fail

The reason a document is such a comfortable purchase is that it is unfalsifiable by construction. It can be excellent — legible current state, ranked risks, a named recommendation — and still leave the buyer holding the identical uncertainty they started with, dressed better. Nothing in it was tested against the one environment that decides the outcome. Research on hidden technical debt in ML systems (NeurIPS, 2015) is the canonical statement of why: the model is a small fraction of a production ML system, and the rest is machinery — data plumbing, serving, configuration, glue — that a document can describe accurately and never once exercise. ML engineering guidance (Google, 2024) treats the hidden assumptions inside that machinery as a primary source of downstream failure, and hidden assumptions are, definitionally, the ones a written review does not know to interrogate.

There are three ways a pre-build deliverable stays unfalsifiable, and each one is visible in the finished artifact before the buyer relies on it. It stays descriptive instead of decisional: the summary lists observations and names no path. It stays technical without translating the commercial consequence: risks are graded by likelihood and severity, but never tied to a specific spend or schedule outcome. Or it stays cautious past the point of usefulness: every risk ends with "should be evaluated further", and the buyer is handed back the original decision in a heavier envelope.

Fixing those three is necessary and it is not sufficient, which is the part that matters. An opinionated document with a recommendation on the first page, risks ranked by their effect on that recommendation, and explicit conditions under which it would flip is a genuinely better document — and it still has no failure condition. The only artifact that has one is a system that runs.

What Design Hands Back

A system design engagement produces five things, and only one of them can fail:

1. The system architecture for the named workflow.
2. A written build plan an engineer can execute.
3. A fixed-price Build quote — the number, in writing.
4. A working spike, running end to end against the named dataset.
5. A go / no-go recommendation with the reasoning documented.

The spike is the load-bearing item, and its scope is fixed in writing at kickoff: the workflow it must demonstrate, the dataset it must run against, and the path it must traverse in your stack. Where the law will not let data leave your network, it runs inside your VPC against a de-identified or synthetic extract — the location moves, the pass condition does not. Because that target is written before the work starts, "done" is never a matter of opinion, and ML LABS puts money behind it: if the spike does not run as scoped, for reasons within our control, the fee comes back in full.

Notice what the guarantee deliberately excludes. The content of the recommendation is not a target and is not a refund trigger — the spike is protected, the answer is not. That exclusion exists so the answer can be no. A major US TV network had already been quoted a full software build for a workflow that did not require one, and their AI Program Manager put the outcome of the session that stopped it on the record:

Omar delivered in two weeks what our team estimated would take six months. The scoping session alone saved us from a $200K mistake. He operates at a level you rarely see in this industry.

— AI Program Manager, a major US TV network

The other four outputs are what the running spike converts into money. A fixed-price quote is only defensible because the risky path has already been executed once, so the number is priced against a known system rather than an imagined one. The $20,000 is credited toward the Build, within the window the service page states — which means that on a build you proceed with, the proof cost nothing, and on a build you kill, it cost you a fraction of the budget you did not commit. Interim results early instead of a finished document late is the shape the Quantitative Researcher at the World Gold Council named in his published reference to ML LABS: "Came back fast with interim results and nailed the delivery."

Grade It Before You Buy It

The four questions below apply to any pre-build engagement, from any vendor, including this one. They are ordered by how much discomfort they cause the party answering.

• What runs at the end, and against which dataset? If the answer names an artifact rather than an execution, you are buying a document.
• What is the pass condition, and who wrote it down? A target written after the work is a grade the vendor gave itself.
• Is the build number fixed, or is it a range that will be revisited? A range that survives the engagement means the engagement did not reduce the risk it was hired to reduce.
• Can the recommendation be "don't build" — and do you still get paid? If the answer is no, the recommendation is not independent of the incentive.

The last one is the one that separates a design engagement from a sales motion, and it is structural rather than a matter of character. A party paid only when the build proceeds is facing a gradient on the recommendation whether or not anybody involved wants to be. The way to neutralize a gradient is not to promise integrity; it is to make the honest answer as valuable to the vendor as the profitable one, which is what a credited fee and a spike-anchored refund do at the same time.

When Design Is The Wrong Step

A design engagement will faithfully design whichever workflow it is pointed at, which makes the pointing the actual decision — and if several candidate workflows are still on the table with no owner and no written success condition, that decision has not been made yet. Buying design at that moment purchases an expensive, rigorous answer to a question nobody has finished asking. The work of choosing the first use case comes first, and it is a much cheaper step.

The second disqualifier is the dataset. A spike is only as real as the data it runs against, and if nobody can produce that data — not the production copy, not a de-identified extract, not a synthetic one with the same shape — then the blocker is the data path, not the architecture. That is a finding rather than a failure, and it is the one the data foundation an AI build actually needs exists to address; whether your data is build-ready is the diagnostic that decides which of the two you are looking at.

First Steps

1. Write the failure condition before you commission anything. One sentence, gradeable by a stranger who did not help write it. If you cannot produce that sentence, whatever you buy next will be a document.
2. Choose the single path the spike must demonstrate. Not the system — the one end-to-end path whose success would change the budget conversation. Name where it starts, where it ends, and every system it crosses on the way.
3. Price the "no". Decide what it is worth to you to learn that this should not be built. If that outcome has no value, you are not shopping for a design engagement.

Demand A Spike, Not A Deck

Make the running system the deliverable and let every other artifact hang off it. Name the workflow, name the dataset, write the path the spike has to demonstrate in your own stack, and fix that target before anyone starts. The architecture, the build plan, and the fixed price all become defensible in the same moment for the same reason: the risky path has been executed once already, in your environment, against your data, and everything downstream is priced against a system that exists rather than one that has been imagined convincingly.

That is the whole content of an AI system design engagement — architecture, a written build plan, a fixed-price Build quote, a go / no-go, and a spike that runs the named workflow end to end or the fee comes back — and what makes the targets inside it hold is that they were written to be checkable before work started. A document that cannot fail also cannot protect you. A spike that runs is a claim about your environment that has already survived contact with it, and the budget conversation on the far side of it is a different conversation: not whether this will work, but what the number is.

References

1. Ahmad, K., Abdelrazek, M., Arora, C., Bano, M., & Grundy, J. A Systematic Mapping Study on Requirements Engineering for AI-Intensive Systems. arXiv, 2022.
2. RAND Corporation. Analysis of AI Project Failures. RAND Corporation, 2024.
3. 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.
4. Google. Rules of Machine Learning: Best Practices for ML Engineering. Google Developers, 2024.
5. 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.
6. Boston Consulting Group. AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value. BCG, 2024.