The first complaint about the new input-finance service at Rooibos Agri Finance, a fictional South African provider of seasonal finance to farmers, did not concern any single AI component. The case is illustrative. A farmer near Clanwilliam received a plain-language explanation that said her application had been referred because "the photographs of the planted area were unclear". The photographs were fine. The image check had passed them. The referral had happened because the repayment-risk estimate fell in the middle band, and the generative assistant, asked to explain the referral, had picked the most plausible-sounding reason from the case notes instead of the actual one.
Each layer had passed its own checks. The failure was in the join between the decision and the explanation. That is the pattern this part is about. Part 1 mapped six capabilities and argued that they overlap rather than replace each other. Here we look at how they combine in one service, and at what has to be designed at each seam.
Why combinations are the normal case
A service that makes a decision about a person usually needs several kinds of answer. Rooibos's input-finance application needs an exact answer (is the applicant eligible?), an estimate (how likely is repayment?), facts read from messy input (what does the title deed say?), new language (how do we explain this?) and some legwork (please send the missing lease agreement). No single capability provides all five well.
The design question is therefore not which layer to use, but which layer does which job, in which order, and what passes between them.
Five patterns that work
These five patterns cover most of the combinations CloudNala sees in decision services. Each has a rule about which layer is allowed to do what.
1. Perception extracts, confirmation follows, rules decide
Image and document analysis turns scans and photographs into structured facts: the title-deed number, the registered owner, the planted area. Until a fact is checked, either against a register or by a person, it reaches the rules as missing, not as a value, for the fields that matter. The model should not be the law sets out this handover in detail for public-sector decisions; the same discipline applies to credit.
2. Rules gate, prediction informs
Explicit rules then apply eligibility to the confirmed facts. Only eligible applications reach the risk model, and the model's estimate informs a decision; it never overrides a rule. A farmer who fails a written eligibility rule is not rescued by a good risk score, and a farmer who passes is not excluded by the model quietly applying a criterion that policy never approved. An ineligible outcome is still an adverse decision, so a credit officer confirms it, checking the facts behind the rule without overriding the policy.
Running rules before the risk model is also cheaper: there is no point estimating risk for an application the policy already excludes.
3. Prediction scores, people decide at the margin
The repayment-risk model produces an estimate, and fixed thresholds divide applications into bands. At Rooibos, the lowest-risk band proceeds to a standard offer that a credit officer signs off in a daily batch; the middle band gets a full review; the highest band gets a review with written reasons. No adverse credit decision is made without a credit officer. The thresholds are policy decisions owned by the credit policy owner, not modelling choices, and changing them is a change to policy.
4. Generation explains, from the decision record only
The generative assistant writes explanations, but only from the case record: the rules that applied, the confirmed facts, the band and the officer's recorded reasons. It may not add reasons, infer reasons or choose between candidate reasons. If the record does not contain a reason, the explanation says the application was referred for review and gives the branch contact. This is exactly the rule Rooibos had failed to enforce in the Clanwilliam case, and it is the second handover in The model should not be the law: the engine's trace becomes the explanation. Every automated recommendation needs a case file describes the record the assistant should draw on.
5. An agent collects, the workflow decides
The bounded agent's job is narrow: find out which documents are missing, ask the applicant for them in the channel they used, read what comes back, and stop when the file is complete, when the applicant stops responding, or after a fixed number of attempts. When it stops, control returns to the workflow. The agent cannot approve, decline or refer, and it cannot change anything in the credit record. This is the middle pattern from Use a workflow until the unknown forces you to use an agent: the uncertainty is in one step (what is missing, and has it arrived?), not in the path.
Patterns that fail
Each of the working patterns has a failing mirror image.
| Failing pattern | What goes wrong | The working alternative |
|---|---|---|
| Generation decides | A language model reads the file and recommends approve or decline; the reasons are fluent and unverifiable | Rules and a validated model inform a credit officer, who decides; generation explains the record |
| Prediction used as a rule | A risk score becomes a hard cut-off without policy approval or validation for that use | Thresholds approved as policy, with people deciding at the margin |
| Perception treated as fact | An extracted field goes straight into a rule with no confidence or confirmation | Unconfirmed facts reach the rules as missing |
| Agent drifts into the decision | The document-chasing agent is given a tool to "close incomplete applications" | The agent stops and hands back; closure is a workflow rule with a person's sign-off |
| Rules rewritten by a model | A model "interprets" policy at run time and the rule changes without anyone approving it | Rules are versioned and owned; models do not change them |
The handover contract at every seam
Most failures in combined services happen at seams, so every seam needs a contract. CloudNala uses six fields.
- Value. The fact, estimate, decision or text being handed over, in a typed form.
- Uncertainty. A confidence, a probability or a band, never silently dropped. A probability of 0.62 should not become "yes" without a recorded threshold.
- Status. Confirmed or unconfirmed, and by whom.
- Source. Which document, register or record the value came from.
- Producer version. Which rule set, model version or prompt version produced it.
- Time. When it was produced, so that stale values can be detected.
The contract is not paperwork. It is what lets the credit officer see why an application is in front of them, lets the explanation draw only on recorded reasons, and lets a reviewer reconstruct a case months later. From prompt to structured contract covers how to enforce typed outputs from a model.
Failure modes in the joins
Beyond the failing patterns, four quieter problems show up in combined services.
- Uncertainty laundering. A probability becomes a yes or no at one seam, and every later layer treats it as certain. Keep the band visible all the way to the officer and the case file.
- Version drift between layers. The risk model is retrained, but the thresholds set for the old model stay unchanged. The bands now mean something different. Treat a model retrain and its thresholds as one change.
- Explanation drift. The decision logic changes and the explanation templates or prompts do not. Explanations go on describing reasons that no longer apply.
- Scope creep in the agent. A useful agent attracts new tasks. Each new tool widens what it can do, and eventually it can affect the decision. Review the agent's tool list at every change, as Agent capability is not agent authority recommends.
Rooibos, after the fix
Rooibos fixed the Clanwilliam failure at the seam, not in the model. The explanation step now receives only the structured case record: rule outcomes, confirmed facts, the risk band and the officer's recorded reason codes. If no reason code is recorded, it cannot produce a specific reason. The team also added a test: for every reason code, the explanation must mention that reason and no other.
Two further changes followed from mapping the seams. The risk model's thresholds were moved into the credit policy owner's change process, so that a retrain could no longer silently shift the bands. And the document-chasing agent's request to add a "close stale application" tool was declined; closure became a workflow rule after thirty days, signed off weekly by a branch manager.
A quick test for any combined service
For each seam in your service, ask:
- Which layer is allowed to decide here, and which only informs?
- Does the handover carry value, uncertainty, status, source, producer version and time?
- If the upstream layer changes version, what downstream threshold, template or rule must be re-checked?
- Can the generative layer say anything that is not in the record?
- Does the agent have any tool that could change the outcome?
Key points
- Most decision services combine capabilities; the design question is which layer does which job and what passes between them.
- Five working patterns: rules gate and prediction informs; perception extracts and confirmation follows; prediction scores and people decide at the margin; generation explains from the record only; an agent collects and the workflow decides.
- Each working pattern has a failing mirror image, such as generation deciding or prediction used as an unapproved rule.
- Put a handover contract on every seam: value, uncertainty, status, source, producer version and time.
- Watch for uncertainty laundering, version drift, explanation drift and agent scope creep.
Next: Part 3, Evaluate each AI layer differently. All parts are on the series page.
How CloudNala can help
CloudNala runs AI decision reviews for services that already combine rules, models and generative or agent components. We map every seam in the service, check each one against the handover contract, identify where a layer is deciding when it should only inform, and give you a prioritised list of fixes, with tests that will catch the same failure next time.
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 an AI Decision Review or write to us at consult@cloudnala.co.za