Ask five people in the same organisation what "production-ready" means and you will usually get five answers. The developer means the tests pass. The operations lead means it is monitored. The security analyst means the findings are closed. The business sponsor means people are using it. The finance manager has never been asked.
Each of those answers is partly right, which is why the phrase survives. It is also why it causes so much trouble. When "production-ready" is a feeling rather than a list, the decision to promote a system rests on whoever speaks with the most confidence in the meeting.
CloudNala's position is that production-ready should be replaced by a defined set of evidence, every item of which can be checked. In the lifecycle described in Part 1, this is the evidence required to move from Incubating to Trusted production. A system that can show all of it is ready to be trusted. A system that can show most of it has a short, named list of gaps, which is a much better basis for a decision than a yes or a no.
Waterberg Mining Services is fictional, and its systems and figures are illustrative.
Nine areas of evidence
Availability. An agreed service level objective and a measured history against it. Not "it has been fine". A month of measured uptime and latency against a target the business agreed to is enough to start.
Security. A completed review with every high-severity finding closed or formally accepted by a named risk owner, and access scoped to the roles that need it. For AI systems, that includes the model provider's data handling terms and any tool permissions the system holds.
Support. A named team, published support hours and an escalation path. If the system is needed outside office hours, an on-call arrangement that someone has agreed to.
Adoption. Evidence that the intended users use it repeatedly as part of their work. Part 4 goes into why this is different from a user count.
Change. Versioned releases and a rollback that has actually been tested. For AI systems, prompts, model versions and retrieval configuration count as releasable artefacts and need the same versioning as code.
Observability. Logs, metrics and traces that let someone diagnose a problem without the original developer. For AI systems, add quality signals: evaluation scores on a fixed test set, user corrections, escalation rates. Evals that gate real work covers how to turn those into a release control.
Recovery. A restore or failover that has been rehearsed, with the time it took recorded. An untested backup is a hope, not evidence.
Cost. A named cost owner, a monthly ceiling and a cost per useful outcome. For per-use AI services, the cost per outcome matters more than the total, because it tells you what happens when usage doubles.
Ownership. Named owners for the product, the running service, the risk and the realised benefit. These can be the same person in a small organisation. They cannot be nobody.
Claims and evidence
Most promotion meetings run on claims. Claims are not dishonest. They are simply uncheckable.
Converting a claim into evidence is usually a small amount of work. "It has been stable" becomes an uptime chart. "Security had a look" becomes a findings list. "We can restore it" becomes a rehearsal with a stopwatch. The work is small because the system usually is healthy. The conversion simply proves it, and occasionally reveals that it is not.
Proportion matters
Not every system needs the same depth of evidence. A reporting dashboard used by six managers does not need the same recovery rehearsal as a payroll integration. Proportion is applied by setting the bar for each area, not by skipping areas.
Waterberg uses three risk tiers, decided by the data a system touches and what happens when it fails:
| Tier | Example | Availability | Recovery | Support |
|---|---|---|---|---|
| Low | Internal knowledge search on public documents | Best effort, measured | Rebuild from source within a week | Office hours |
| Medium | Haul truck maintenance predictions used by planners | 99% in operating hours | Restore rehearsed, within a day | Office hours, named escalation |
| High | Payroll integration | 99.5%, measured monthly | Restore rehearsed quarterly, within four hours | On-call |
Every tier still answers all nine areas. A low-tier system can answer "recovery" with "we rebuild it from the repository and the source documents, and that takes about two days". That is a real answer, and it is enough.
The AI-specific additions
AI systems need the same nine areas as any other service, plus a few additions that are easy to miss because they do not exist in conventional software.
- A frozen evaluation set that is run before every change to the prompt, model or retrieval configuration, with a pass threshold agreed by the business owner.
- Model and provider dependency records, including the model version, the provider's deprecation notice period and a tested fallback or degradation plan.
- A data boundary record stating which data reaches the model, which is stripped first and where the provider processes it. For South African organisations this connects directly to POPIA conditions on cross-border transfers, which POPIA does not say your data must stay in South Africa explains in plain language.
- Human escalation evidence: how often the system hands a case to a person, and whether those handovers are reviewed.
Using the evidence at Waterberg
Waterberg's haul truck maintenance model was the first initiative to request promotion from Incubating to Trusted production. The team was confident. It had good accuracy on historical data, planners used it daily, and it had not failed in four months.
Against the nine areas, the evidence pack showed seven complete. Two were not: the restore had never been rehearsed, and nobody owned the cost. The model ran on a cloud account shared with the fleet telemetry platform, and its spend was invisible inside that bill.
The review did not reject the promotion. It held it for three weeks with two named blockers. The restore rehearsal took an afternoon and revealed that the feature store backup was missing a table. The cost owner was the fleet maintenance manager, who asked for a monthly report. Both items took little time once they were named. Neither would have been found by asking whether the model was "production-ready".
Part 5 looks at how that review process runs, including who does the reviewing.
Next: Part 4, Your pilot has users. That does not make it mature. All parts are on the series page.
How CloudNala can help
We help teams turn "production-ready" into an evidence checklist proportionate to their risk tiers, and we run independent readiness reviews before a promotion decision. For AI systems we add the evaluation, model dependency and data boundary evidence that conventional checklists miss.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology and AI Maturity Assessment or write to us at consult@cloudnala.co.za