The most thorough review most systems ever receive is the post-incident review. After an outage, a data complaint or an unexpected invoice, a team finally looks at ownership, access, recovery, cost and dependencies with real attention. The findings are usually familiar: nobody owned it, the restore had never been tested, a dependency was out of support, the costs sat in someone else's budget.
Almost every one of those findings could have been discovered before the system was trusted with real work. Due diligence belongs before promotion. It costs far less there, the team still has time to fix what it finds, and the organisation makes its decision knowing what it is accepting.
This part describes how to run that review in a way that is rigorous without becoming a bureaucracy. It builds on the evidence areas in Part 3 and the adopter interviews in Part 4.
Waterberg Mining Services is fictional, and its systems and figures are illustrative.
The shape of a review
Promotion request. The sponsor asks for a gate, naming the stage they want to move to and the date. The request is short: one page, linking to the evidence.
Reviewer assigned. Someone outside the delivery team takes responsibility for the review. At Waterberg this is a rotating role among senior staff in operations, finance, information security and IT, so no single function becomes the gatekeeper for everything. The CNCF follows a similar idea in its own lifecycle, where a member of its Technical Oversight Committee sponsors and leads due diligence for each project rather than the project's own maintainers.
Evidence pack. The team assembles the evidence for each area required at the target stage. The pack arrives before the interviews, so interviews can test it rather than replace it.
Adopter interviews. The reviewer talks to users, the workflow owner, support, security and operations, as described in Part 4.
Findings and blockers. The reviewer writes up what was found and classifies each gap as a blocker or a follow-up.
Decision. The lifecycle review makes one of three decisions: promote, hold for remediation, or return or stop. The decision is recorded with the evidence it relied on.
At Waterberg the whole sequence takes three to six weeks for an Incubating-to-Trusted-production gate, most of which is waiting for interviews to fit around shift schedules. An Experiment-to-Incubating gate usually takes a week or two.
Blockers and follow-ups
The most important judgement in the review is the line between a blocker and a follow-up. Get it wrong one way and promotions stall on cosmetic gaps. Get it wrong the other way and known risks are promoted with a promise to fix them later.
The test Waterberg uses is a single question: would this gap matter in the first incident, audit or invoice after promotion? If yes, it is a blocker. If not, it is a follow-up with a named owner and a date.
Typical blockers:
- No named service owner.
- An open high-severity security finding with no formal risk acceptance.
- No cost owner or ceiling.
- Recovery never rehearsed.
- A dependency without vendor support, such as a model version with a published retirement date before the next review.
- Personal information flowing to a provider without approval.
Typical follow-ups:
- Dashboard and reporting improvements.
- Additional languages or formats.
- Integrations users have asked for but do not need.
- Documentation tidying.
The discipline is to refuse to downgrade a blocker because the promotion date matters to someone. Promoting with a known blocker converts a risk the organisation could have avoided into operating debt it now has to carry.
What makes a review independent enough
Independence is a spectrum, and a mid-sized organisation does not need an internal audit function for every gate. A review is independent enough when:
- the reviewer did not build the system and does not report to the person who did;
- the reviewer chooses which adopters to interview, not the team;
- the reviewer can see the raw evidence, not only a summary;
- the decision is made by a group that includes someone accountable for risk and someone accountable for cost.
Waterberg's monthly lifecycle review is chaired by the head of digital, with a delegate from the CFO's office, the information security officer and a rotating representative from site operations. Four people, one hour a month.
A worked review
The haul truck maintenance model's promotion to Trusted production, introduced in Part 3, went through this process.
The reviewer, a senior planner from a different region, read the evidence pack and found seven of nine evidence areas complete. Interviews with two maintenance planners, a fleet supervisor, the service desk lead and the information security officer added detail the pack lacked. Planners trusted the model for the large haul trucks but had learned to ignore it for the smaller support vehicles, where the training data was thin. The fleet supervisor wanted the model's reasons shown alongside each prediction.
The findings classified two blockers (recovery never rehearsed, no cost owner) and three follow-ups (support vehicle accuracy, showing reasons, a monthly accuracy report). The lifecycle review held the promotion for three weeks. Both blockers were closed, the restore rehearsal found and fixed a missing backup table, and the model was promoted at the next meeting. The support vehicle limitation was documented in the system's published limits, so new planners would not discover it the hard way.
That review cost perhaps twenty hours of effort across all participants. The alternative was discovering the missing backup table during a real outage.
What the reviewer writes
The review record should fit on two pages and follow the same shape every time, so the lifecycle review can read it quickly and an auditor can follow it later:
- the initiative, the current label and the label requested;
- the evidence areas checked, with a link to each piece of evidence and a one-word result: present, partial or missing;
- who was interviewed, by role rather than name, and the main points each raised;
- blockers, each with an owner and a target date;
- follow-ups, each with an owner;
- the reviewer's recommendation and the decision the lifecycle review actually made.
Recording the decision separately from the recommendation matters. When the two differ, the record shows who accepted which risk.
Keeping it light
Due diligence becomes a bureaucracy when it repeats work, demands evidence that does not affect the decision, or becomes a queue. Three habits keep it light:
- Reuse evidence. The security review, cost report and restore rehearsal should be produced as part of normal work, not created for the gate.
- Scale with risk. Use the tiers from Part 3. A low-tier internal tool needs a lighter pack than a payroll integration.
- Fix the date, not the outcome. Gates run on a regular schedule. Teams know when the next opportunity is, and a hold costs weeks, not months.
For how this connects to the agent-specific evidence a reviewer should expect, From agent dashboard to operating model describes the operational evidence an AI agent should produce once it is running.
Next: Part 6, How to graduate an internal developer platform. All parts are on the series page.
How CloudNala can help
We act as independent reviewers for promotion decisions on AI systems and internal platforms, and we help organisations design a review process proportionate to their size: evidence lists, reviewer rotation, interview guides and decision records that leadership can audit.
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