Executive summary
This article argues that AI production failures stem from specifications that capture processes without encoding organizational judgment. The author introduces the Specification Architect role and a five-layer framework (Intent, Semantics, Realization, Determinism, Execution) illustrated through a hospital AI system that ranked patients correctly by its own logic but identified the wrong ones for intervention.
Consider a scenario common in healthcare AI. A hospital wanted to keep its sickest patients out of the emergency room. The objective was straightforward. Some patients return to the ER again and again, and a timely nurse intervention (a phone call, a medication review, a follow-up booked) often prevents the next visit. The constraint was scale, with thousands of patients treated by only a handful of nurses. Someone had to decide which patients to reach first.
So the team built an AI prioritization system. Product defined the objective, nursing explained what good intervention looked like, the architects designed it, the engineers built it. The architecture was elegant: every patient became a set of structured attributes (diagnoses, medications, admissions, outcomes) and an agent scored each one and produced a ranked list.
Reviews passed, tests passed, and the system did exactly what it was designed to do. The list was wrong.
A veteran nurse looked at the recommendations and frowned. “These aren’t the patients who need us.” She pointed halfway down the page, at people the system had ranked low. “Those are the ones who’ll be back next week.”
There was no bug. The model behaved correctly, the architecture worked, the specification was complete. And the system would still have sent scarce nursing capacity to the wrong doors.
This is the failure mode of AI-native systems. As more companies move from AI pilots to AI software development, specification quality becomes a production concern The next production incident will come from correct code, faithfully executing intent that never captured the organization’s judgment.
In this scenario, someone needed to be accountable for translating organizational intent, domain judgment, and evaluation criteria into specifications the AI system could execute safely. That role, what I call the Specification Architect, is what this article is about.
When Ranking Replaces Reasoning
The architecture did exactly what the specification asked. The specification carried the hidden assumption that prioritizing patients was a scoring problem. Convert patients to attributes, compute risk, rank, done.
The agent turned each patient into a list of numbers and ranked by closeness to an “ideal” profile. That works when your data is rich, but this data wasn’t. When a record is thin, most of what distinguishes one patient from another never reaches the numbers, so the system was comparing the few fields that happened to be filled in. Someone stable at home and someone barely hanging on came out nearly identical. The math was confident. Confidently wrong.
The nurse was running an inquiry. She formed a hypothesis, chased the uncertain cases, pulled the missing evidence, applied what she knew about this neighborhood and this population, and escalated the ones she couldn’t call from a chart. This shows that the system executed a procedure and how the nurse operated from a purpose.
The specification was thorough on process and silent on judgment. A longer ladder pointed at the wrong wall. The question is who was responsible for where it pointed.
Who Owns the Specification in an AI System?
For decades you could separate the work cleanly. Product managers defined requirements, architects designed systems, and engineers built them. Human review sat between every layer, slow but forgiving, because people quietly filled the gaps no one had written down.
AI removes that buffer. Specifications become systems in minutes, not months. There is no slow middle left to catch the unspoken assumption. Everything that used to live in people’s heads, like the meaning, the trade-offs, and the judgment, now has to become an explicit production artifact, up front.Someone has to own that translation.
I call that role the Specification Architect. This is not a replacement for the product manager or the architect; this is the person accountable for making sure that organizational intent survives the trip into production. The primary artifact is the specification itself, a machine-consumable expression of purpose, meaning, constraints, evaluation criteria, and the boundaries of judgment.
That artifact governs five layers that make up what I call Feature Production Architecture. Most organizations invest heavily in two of them, Realization and Execution, associated with the models, agents, and infrastructure. The failures keep coming from the two they underfund, which are Intent and Semantics.
Intent: What Are We Actually Trying to Achieve?
A requirement names the goal, but intent goes further. It names the way of thinking that gets you there.
The original spec in the hospital scenario described a process for computing risk and ranking patients. The rewrite described a different outcome. The system would find the patients most likely to benefit, gather more evidence when confidence is low, surface uncertainty instead of hiding it, and escalate when the evidence runs out. Architecturally, that changes everything. The system stops optimizing to produce a score and starts optimizing to support a decision.
This is the layer organizations underinvest in the most. Not because they ignore it, but because they’re sure they’ve handled it. They wrote a clear requirement, held a planning meeting, and logged it in the backlog. A requirement tells the machine what you want, whereas intent tells it how to think about getting there. AI turns that gap into a production failure at full speed.
Semantics: What Does the Organization Mean?
When the hospital spec was written, the guiding principle was “think like a nurse.” Which nurse? A new graduate? A fifteen-year veteran? An oncology nurse, an ER nurse? The phrase means something different in every context.
Traditional systems treat meaning as metadata. AI systems expose it as production-critical architecture. “High risk” is not a textbook code. It’s what high risk means according to this hospital, or this population. It could be which clinic never answers, which neighborhood loses people when the bus route changes, what “lives alone” actually signals here. That meaning doesn’t live in the model. It lives in your organization. Turning it into executable semantics is the job. Intent without semantics produces confident mistakes faster.
Realization: How Does the AI System Reason?
With intent and semantics set, this becomes an architecture problem. The old design was a single scoring agent. The new one is a reasoning system with a goal, a set of tools, and the freedom to decide what to look at next (pull the readmission history, check adherence, flag the social factors) inside deliberate boundaries. The aim is a system that can investigate. An unfenced agent optimizes for finishing, not for being right. The Specification Architect draws the boundaries; the technical architect builds within them.
Determinism: How Do We Know It’s Correct?
Traditional systems validate implementation. AI systems have to validate decisions. That means defining, up front, what a good recommendation looks like, measured against cases the experts already judged, so correctness has teeth before the agent ever runs. The model underneath will change with a new version, and a different provider. The guarantee can’t. The generator changes; the guarantee doesn’t.
Execution: Where Does Human Judgment Belong?
Most teams put the human at the end to review and approve everything. That doesn’t scale, and it insults the expert. The better design treats human judgment as part of the spec. The human sits in two deliberate places. First, upstream, as the source the intent was written from. Then at the stakes, where the harness routes irreversible, care-affecting calls to a person and lets the agent run the reversible ones alone.
The goal is specifying exactly where the loop needs a human, and why. Too many checkpoints, and you’ve rebuilt the slow middle. Too few, and you’ve automated away accountability in a field that can’t afford it.
Where Learning Actually Lives
What changed wasn’t the model or the agent. What changed was the harness around it.
The agent reasons; the harness governs what it reasons with and what happens to the decision. The veteran nurse’s value was never a set of facts to be retrained into a model. It was a judgment formed of patterns, exceptions, trade-offs, and context. That belongs in the specification, not buried in model weights. The best AI systems won’t improve mainly through retraining. They’ll improve through the specification getting sharper every cycle. Agents execute; specifications learn.
Improvement Lives in the Specification
If you’re coming from traditional architecture, here’s the transition that stings, and it took me a while to accept it. You were trained to own structure: boxes, arrows, clean interfaces, a design you could point at and call correct. The new job asks you to give that up. You no longer hand the machine a path. You hand it a purpose and a set of limits, and you let it find the path itself. That feels like losing control. You’re trading control over the steps for control over the outcome, which is the only control that ever mattered.
Whether this becomes a dedicated title, an evolution of the architect, or a merger of product and engineering is an organizational choice. But the accountability already exists. Someone is already responsible for whether your organization’s judgment survives contact with production, whether you’ve named them or not.
Key Takeaways
- The most dangerous AI failures come from correct code executing specifications that missed the organization’s actual judgment.
- A requirement tells the machine what you want; intent tells it how to think about getting there.
- Organizational meaning, such as what “high risk” or “think like a nurse” actually signals in context, is production-critical architecture.
- AI systems improve through sharper specifications each cycle, not through model retraining.
- Human judgment belongs at two deliberate points: upstream as the source of intent, and at the stakes where decisions are irreversible.
