A demo answers a question. A system answers it the same way tomorrow, at a cost somebody predicted, and can show afterward why it answered that way. Nearly all of the engineering is in the second sentence.
An LLM system is not a model with an API key in front of it. It is the routing, retrieval, evaluation, observability and cost discipline that together make a probabilistic component behave like an accountable one.
Most organisations reach a working prototype quickly and then stall for a year. The stall is not a modelling problem. It is that nobody can yet answer the questions production asks: what happens when the vendor changes the model underneath you, which retrieved document produced that sentence, what this will cost at ten times the volume, and what you will hand an examiner who asks why a customer was declined in March.
Those questions are architectural. They are answered by design decisions made before the traffic arrives, and they are very expensive to retrofit afterward.
Which model serves which request, under what policy, and who approved the policy. Routing looks like an efficiency concern and behaves like a governance one, because it silently determines where regulated data goes.
Isolation between workloads, quotas, failure behaviour, and what happens when a provider degrades rather than fails outright, which is the harder case.
Pinning, staged promotion, and the ability to answer which model version served a given decision. Without it, an audit trail records the question and loses the answer.
A gateway that routes on cost alone will, given enough time, route a regulated workload to whichever provider was cheapest that week. Nobody decides this. It is simply what an unconstrained optimizer does, which is the whole argument for making the constraint explicit.
Retrieval is usually treated as a quality mechanism, a way of making answers more accurate. It is also, and more consequentially, an access-control surface. What the index contains is what the model can say. Who may retrieve which partition is an authorisation question that has been quietly relocated into a vector store, often without the access review that any other data store would attract.
The architectural requirements follow from that reading: partitioning that matches the institution's real permission boundaries, provenance carried through to the answer so a citation can be checked rather than trusted, freshness and deletion that actually propagate, and an evaluation set that tests retrieval separately from generation, because a system can retrieve the wrong thing and phrase it beautifully.
Observability for language systems is usually built for debugging, which is a different requirement from being able to reconstruct a decision months afterward for somebody who is not an engineer. The second requirement is the one with a deadline attached.
| The question asked | What has to have been recorded at the time |
|---|---|
| Why this answer? | Prompt, retrieved context with source identifiers, model and version, and the decision path through any tools. |
| Was a human involved? | The trust tier in force, whether review was required, and whether it happened. |
| Has it drifted? | Evaluation results over time against a stable set, not a one-time benchmark at launch. |
| Who changed it? | Change history for prompts, policies and routing rules, held to the same standard as code. |
None of this can be added retrospectively. Evidence is either captured at the moment of the decision or it does not exist, and that asymmetry is why the evidence model belongs in the architecture rather than in the backlog.
Unit economics in language systems are set by decisions that look purely technical: context length, retrieval breadth, how many times a chain re-reads the same material, whether a cheaper model could have served a request that a larger one is handling by default. By the time cost becomes visible on an invoice, it has already been designed in.
The practical consequence is that cost attribution has to exist per use case from the beginning, and the routing policy has to be able to express a cost ceiling as a constraint rather than a hope. This is the operations layer of the series, treated in full in DevOps for AI-Native Platforms and summarised as an operating model at PARA.
The model is one component. The system is the routing and serving gateway in front of it, the retrieval layer that decides what it may know, the evaluation discipline that detects when it changes, the observability that records why it answered as it did, and the cost controls that keep it viable at volume.
Organisations that stall between prototype and production have almost always built the model integration and none of the rest.
Because routing determines which provider processes which data, and that is a residency, contractual and model-risk question before it is a cost question.
A gateway optimising only for cost will eventually route a regulated workload to whichever provider was cheapest that week. No one decides this. It is what an unconstrained optimizer does, which is precisely why the constraint has to be explicit and enforced.
Yes, and treating it as purely a quality mechanism is a common and consequential error. What the index contains is what the model can say, and who may retrieve which partition is an authorisation decision that has been relocated into a vector store.
It should attract the same access review as any other data store holding the same material, and provenance should be carried through to the answer so citations can be checked rather than trusted.
At minimum: the prompt, the retrieved context with source identifiers, the model and its version, the path taken through any tools, the trust tier in force and whether human review was required and occurred, plus change history for prompts, policies and routing rules.
Evidence is captured at the moment of the decision or it does not exist. It cannot be reconstructed afterward, which is why it belongs in the architecture rather than the backlog.
By treating cost as an architectural output rather than an invoice. Context length, retrieval breadth, chain repetition and default model selection set the unit economics before any bill arrives.
Practically that means per-use-case cost attribution from the start, and a routing policy able to express a ceiling as an enforced constraint. Tuning after the fact is possible but far more expensive than designing for it.
The method is published in the Full-Stack AI Engineering Series, whose reference architectures are set in a deliberately fictional institution so the full end-to-end can be shown without exposing a client. Those are reference architectures, not deployed client products.
The production proof is Maxim, the behavioural-intelligence layer for Claude built by iSystematic, which is built on this discipline. Client engagements that apply these patterns are confidential.
The Fit Call is thirty minutes and free. Bring one production use case and the question you would least like a regulator to ask about it.