Most AI systems are not production ready when they are deployed. They are production-deployed.
The gap between those two things is not a technology gap. It is a practitioner gap — a set of specific decisions made without adequate constraints, specific artefacts never produced, specific translations left incomplete. The failure is predictable before it happens. The incident report describes it after.
The Clarity Point Framework is the structure DataDomine uses to close that gap. Six principles, derived from the map of where practitioners currently operate and what production ready actually requires of them. Applied across every programme, to every decision, in every context where AI systems are built and deployed.
Production ready is not a state a system reaches at deployment. It is a standard defined before the first design decision is made.
The standard has seven dimensions. A system that satisfies six is not almost production ready — it is incomplete, with a failure mode that has a delayed fuse. Each dimension exists because a specific class of production failure is possible without it.
Performs correctly under real production conditions. Handles the failure modes specific to AI — distribution shift, pipeline degradation, silent model drift. Rollback is tested, not documented. The system is reproducible: given the training data, the pipeline, and the configuration, the model in production can be reconstructed and verified.
Observable inward — infrastructure health and model health are separately monitored. Observable outward — explainability is a design property, not documentation. The user can interpret the system's output. The regulator can audit the decision trail. Distribution shift is detectable before it reaches the customer, not after.
Every decision is documented in a form a new person can act on. The data contract is explicit, versioned, and monitored. Human-in-the-loop is real — a person with the right authority and the right information can intervene in time for the intervention to matter. The retraining trigger, the deprecation policy, and the end-of-life procedure are defined before go-live, not discovered under operational pressure.
The cost of operating the system at scale is understood and accepted before deployment. Every major architectural decision has a documented economic argument alongside the technical one. The model card includes a cost profile. The practitioner who can present the economic case for a design decision wins rooms the one who presents only the technical case loses.
Hardened against the attack surfaces specific to AI systems — model inversion, adversarial inputs, data poisoning, prompt injection in agentic pipelines, supply chain provenance. Traditional security frameworks were not designed for these. Security is a separately assessed and continuously maintained property, not a compliance checkbox.
The compliance case is structural, not documentary. Regulatory obligations — EU AI Act Articles 9, 10, 13, 14, 17, 47, and their global equivalents — are satisfied through design decisions made at architecture time, not through documents written after the system is built. The declaration of conformity is a lifecycle obligation, not a deployment event.
The populations most likely to be harmed by model errors have been identified and their outcomes documented. Where the system disadvantages specific groups, that effect is either mitigated or accepted with rationale the organisation can defend publicly. Reputational harm is not quantifiable in advance — which is precisely what makes it the most dangerous risk to carry undocumented.
A system is production ready when seven conditions are simultaneously true — not six, not five. It performs correctly under real conditions and can be reproduced when something goes wrong. It is observable to operators and interpretable to users. The organisation can sustain, override, retrain, and retire it without its original author. The cost of running it at scale was understood before it was deployed at scale. It is hardened against the attack surfaces specific to AI systems. Its compliance obligations are satisfied by design, not by documentation. And the people it could harm have been identified and that risk documented in terms the organisation can defend. A system that satisfies six of these is incomplete — with a failure mode that has a delayed fuse.
Production ready looks different depending on where you are building. The standard does not change. The terrain does.
The framework is applied consistently across all three contexts so that the practitioner can identify which one they are in and what it demands of them — before they commit to an answer.
Maximum design freedom, maximum accountability. Greenfield decisions become the legacy that every subsequent project inherits. The practitioner building from scratch is making choices that will constrain others for years — without the guardrails that existing systems provide. The hardest problem is not what to build. It is committing to design decisions that will still be defensible when someone inherits the system five years from now.
Where most careers actually live. Brownfield means making decisions inside a system that already has opinions — expressed in data models, integration contracts, and the expectations of teams who have built their own work on top of what already exists. The practitioner working in brownfield must distinguish structural constraints from inherited convention. The ones they cannot challenge must be designed around. The ones they can challenge must be challenged with evidence, not preference.
The dominant pattern in enterprise AI. The system of record has its own data contracts, governance obligations, and change control process. The AI layer inherits all of them while delivering a new capability. The hardest design problem is the interface — it must satisfy two governance regimes, two compliance obligations, and two failure mode profiles simultaneously. Every upstream change to the system of record is a potential silent failure in the intelligence layer.
A practitioner trained only in greenfield makes greenfield decisions inside brownfield systems — and cannot understand why they fail. A practitioner trained only in brownfield carries its constraints into greenfield work that did not require them. The practitioner trained in all three understands that the standard is constant and the terrain is not — which is the only understanding that holds across an entire career.
The framework is six principles, not six practices. Each one closes a class of production failure. Together they constitute a discipline.
The principles were derived from a systematic gap analysis — the specific places where current practitioner practice falls short of what production ready requires. They are not independent. The first is the foundation. The other five are its expressions in different domains.
Design for the system's operational lifetime, not the phase you are currently in. The practitioner who thinks lifecycle-first asks, at every decision point: what does this deliverable enable or constrain for every subsequent phase of this system's life — not just the next one? The Principal who defines production ready at project initiation rather than at deployment. The Architect who writes ADRs for the person who inherits the system rather than for the review board that approves it. The MLE who initiates the model card at the first experiment rather than writing it at deployment. Lifecycle thinking is what makes the other five principles coherent rather than additive.
Document the thinking, not just the output. Make assumptions, alternatives, and constraints visible. The practitioner who internalises this principle asks, at every decision point: what am I assuming that I have not documented, and what would happen to this system if the person inheriting it could not see that assumption? The ADR that documents what was decided and why every alternative was rejected. The constraint map that distinguishes structural from inherited. The failure mode registry that names AI-specific failures before they occur.
Complete the translation of your work into every form every downstream audience needs to act on it. The compliance function, the operations team, the Principal, and the regulator all need to act on the same system — but from the same artefact written for only one of them. The FRIA whose findings become design requirements. The data documentation that a compliance auditor and an incident responder can both act on independently. The deployment runbook that includes model-specific validation, not only infrastructure steps.
Every significant decision has an economic argument. Own it alongside the technical one. The Architect who presents the economic case for a design decision gives the Principal what they need to defend it upward — and produces an ADR that survives budget pressure rather than being reversed when the cost becomes visible. The MLE whose model card includes a cost profile answers the economic questions before they are asked. Economic reasoning is not the finance function's responsibility. It is a discipline every practitioner applies to every significant decision.
Satisfy regulatory obligations through design decisions, not documentation exercises. The compliance case is built in, not written on. The risk classification is made before design begins — because it determines what must be designed. Explainability is specified as an architectural constraint — because it cannot be retrofitted after the model is built. The declaration of conformity is a lifecycle obligation maintained throughout the system's operational life, not a deployment artefact signed at go-live.
Close the feedback loop between production behaviour and every upstream decision. Production is not the end of the practitioner's accountability. It is the beginning of the evidence that the decisions they made were the right ones. The Architect who receives the production behaviour report and uses it to test their design's predictions against reality. The MLE whose drift detection log is a compliance artefact, not a monitoring dashboard. The Principal whose lifecycle governance plan routes production intelligence back to the investment decision.
The clarity point — the moment the framework is named for — is the moment when the practitioner understands that production ready is not a destination reached at deployment. It is a discipline applied from the first decision on the first day of the engagement. Their accountability does not end when they hand their work to the next person. It ends when the system has operated correctly, at scale, under real conditions, for the duration the Principal defined — and when the evidence that it did so is available to anyone who asks.
The six principles are developed under conditions that approximate the real ones — not demonstrated in exercises that simulate them.
Every cohort works on a single pre-designed spine project across every session. The project is not an illustration of the framework. It is the vehicle through which the framework is developed in the practitioner — by applying it, under constraint, to a problem with real stakes, in the presence of peers who will challenge the answer.
Each session produces a documented output that contributes to the evolving project artefact. By the capstone, the participant has assembled something complete — a full production-ready architecture document, a model card with compliance evidence, a constraint map, a failure mode registry, a set of ADRs with economic arguments. Not a certificate. A portfolio piece that is evidence of the discipline applied to real work.
The capstone is a defended presentation before a simulated review panel — the Architecture Review Board, the compliance team, or the Principal's direct report. The participant must defend not just what they built but why every decision was the right one. That experience is the Clarity Point made tangible.
Three roles. The same standard. Different gaps. Different clarity points.
The production ready standard applies equally to all three. What differs is the phase of the value stream where each practitioner's decisions determine whether the system reaches it — and the specific gap that prevents them from getting there.
The Principal commissions the system and owns the production ready standard — but most Principals set that standard implicitly, at go-live rather than at initiation, against three dimensions rather than seven, and without the input of the Architect and MLE who know what is achievable. The consequence is a team that optimises for its own interpretation of done. The gap is one of sequence: doing the right things after deployment rather than before design.
"The production ready standard I set before design begins is the brief the Architect designs against and the MLE builds to. If it is vague, the team will define it themselves. If it arrives at go-live, it is no longer a standard. It is a retrospective."
The Architect's gaps are failures of explicitness — the consistent pattern of making decisions that should be documented implicitly. The constraint that is not classified as structural or inherited. The ADR that records the decision without recording why every alternative was rejected. The HITL mechanism specified as a technical component without the organisational authority structure that makes it function. The design that satisfies the review board and does not survive the handoff.
"Production ready is not a higher standard of design. It is the discipline of making explicit what I currently leave implicit — so that the decision I made is the decision the team implements, and the system that reaches production is the system I designed."
The MLE's gaps are failures of translation — producing work that is correct in the experimental context and not transferred into the production context. The model card written at deployment rather than maintained throughout. The evaluation conducted on the test set without testing production conditions. The monitoring designed for infrastructure health without instrumenting model health. The drift event responded to operationally but never recorded as a compliance artefact.
"Production ready is not a higher standard of model performance. It is the discipline of completing the translation — all the way from experiment to evidence, from model to artefact, from alert to compliance record — so that my work survives my departure from the project."
The framework is applied in every programme. Start with the cohort that fits where you are.
Each cohort applies all six principles across a spine project and capstone defence. The artefact you leave with is not a certificate. It is the evidence of the discipline applied to your work — portable, defensible, and production ready.