Unreliable results
Same input, different answer. Nothing is reproducible, so nothing is testable — and a feature you can’t test is a feature you can’t maintain.
Your engineering team
Fixed by pillar 04 →
Most teams ask “should we add AI?” — the wrong question. The real ones are where it sits, which model does the job, what it’s allowed to touch, and what shape data goes in as and comes out as. Get those right and AI is an enhancement. Get them wrong and you’ve wired a random number generator into your product.
At the edge — classifying, summarising, drafting — or in the middle, deciding, routing, writing to the database, talking to the customer. The deeper into the critical path, the tighter the constraints have to be.
Not everything needs a frontier model. Every job has its own failure cost, latency budget and price. A big model on a trivial classification is waste; a small model on nuanced reasoning is risk.
Read or write. Suggest or execute. Human-in-the-loop or autonomous. This is the blast-radius question: what is the worst thing this AI can do when — not if — it is wrong?
The model never sees raw, unbounded user input; it sees a validated, scoped, typed payload. And it never returns free prose into your system; it returns a schema you check, with a defined path for when that check fails.
Structured inputs and outputs are the difference between an AI feature and an AI liability.
Same input, different answer. Nothing is reproducible, so nothing is testable — and a feature you can’t test is a feature you can’t maintain.
The model writes bad data, triggers the wrong action, or loops on a runaway call. The invoice arrives before anyone notices the bug.
Hallucinated facts, off-brand tone, an invented price, wrong advice — shown to a real customer with your logo above it.
An AI at the edge of a system suggests things to humans. An AI in the middle of a system makes decisions the rest of the system trusts.
Both are legitimate. They are not the same engineering problem. Move the model one step deeper into the critical path and every guarantee downstream of it becomes your responsibility to re-establish.
“Use the best model” is not a strategy. It’s a bill.
Each job in your system has a failure cost, a latency budget and a price ceiling. Picking a frontier model for a trivial classification burns money on every request forever. Picking a small model for nuanced reasoning saves cents and buys risk.
Read or write. Suggest or execute. This is the only pillar your insurer would care about.
Before you grant an AI an action, write down the worst thing that action can do when the model is confidently wrong — then multiply it by the number of times it can happen before a human notices.
This is the one the other three build toward. Constrain what goes in. Validate what comes out. Decide, in advance, what happens when validation fails.
A schema turns a language model from something you hope behaves into something your type system can reason about. It also gives you the thing free prose never can: a failure you can catch, log, retry and alert on.
{
"email_body": string(≤4000),
"customer_id": uuid,
"currency": "AUD" | "USD"
}
// raw user text never
// reaches the model alone
{
"price": number,
"lead_time_days": int(1..90),
"confidence": 0..1
}
// fails validation →
// retry, then human
This is a real quote card — the kind of component sitting at the end of a hundred AI features shipped last quarter. With both guards on it renders the same way every time. Switch one off and the model’s off-day becomes the customer’s problem.
Press “Run the same request 5×”.
Watch what comes back.
Same prompt. Same model.
One difference: a contract.
0 / 8 answered
If you’re about to add AI to something people pay for, an hour on placement, permissions and schema now is cheaper than the incident later. Bring your feature — we’ll walk the eight questions with you.