Most AI portfolios are a list of links. Each goes to a repository with a README, a screenshot and a line such as "built with" followed by five product names. A reviewer opens one, sees the familiar shape of a tutorial and moves on.
Over the previous seven parts, Umgeni Fibre's support desk grew from a ticket classifier into an assistant that remembers, answers from current knowledge, checks lines, books technicians and hands billing disputes to finance. The code is the least interesting thing about it. What makes it valuable as a portfolio piece is everything around the code: why each stage was added, what it made worse, how it was tested, what it costs and how it is run.
This final part shows how to present that, to two very different audiences, from one body of evidence.
Two audiences, one project
Umgeni Fibre is fictional, and its systems and figures are illustrative. Imagine presenting the project twice in one week: to a solution architect who might hire you or approve the design, and to the operations director who would pay for it.
The architect wants to see boundaries, failure handling and traceability. The business leader wants outcomes, what changed and what scaling would cost. Both care about the middle column: what one case costs, what happens when the system is wrong, and who looks after it. That middle column is where most portfolios are silent, and where a learner who followed this series has the most to show.
What goes in the portfolio
Umgeni's portfolio is one repository and one short document. The document has seven sections, each backed by something in the repository.
1. The problem, in numbers. About 9,000 tickets a month, hand-routed; outage spikes burying billing and business tickets; customers repeating themselves. One paragraph and a baseline.
2. The stages and the decision log. For each of the five stages: the failure that justified it, the change made, the evidence it worked and what it made worse. This is the "note of what the stage made worse" from Part 1, collected into one table. It is the page reviewers read most closely, because it shows judgement.
3. The contracts. The triage output schema from Part 3, the state and preference records from Part 4, the tool definitions from Part 6 and the dispute hand-off from Part 7. Each versioned, each with its validator.
4. The evaluations. The 600-ticket labelled set and its accuracy by band; the multi-turn memory tests; the 80-question retrieval set measured before answers; the tool and hand-off tests. Results with dates, not adjectives.
5. The economics. Cost and latency per case at each stage, with the provider prices used and the date they were checked. In the illustrative figures, a fully handled line-down conversation costs well under a rand, so the business case rests on staff time and customer experience rather than on model cost. Saying that plainly is more credible than inflating either.
6. The known failure modes. Mixed-problem tickets, isiZulu retrieval quality, booking duplicates, loop limits, a stale index. What each looks like, how it is detected and what the system does.
7. The runbook. What the person on duty does when something goes wrong.
The runbook is the strongest evidence
A runbook proves that you thought about the system after the demo. Umgeni's is short and specific:
| Situation | How it shows up | What to do |
|---|---|---|
| Model provider down or slow | Latency alert; triage fallback rate jumps | Nothing urgent: everything falls back to human queues. Post a desk notice. |
| Cost per conversation spikes | Daily cost-per-case alert | Check traces for loops hitting the step limit; check for a prompt or index change. |
| Booking tool misbehaving | Booking rate alert, duplicate check firing | Switch off book_technician with its flag. Read tools keep working. |
| Index stale | Freshness check on notices fails | Re-run the notice refresh; until fixed, the assistant says it cannot confirm maintenance. |
| Customer disputes a stored preference | Desk ticket | Show the record and its source; correct or delete it, logged. |
Notice that the first row is almost boring. That is the result of decisions made in Part 2: if the model disappears, the business continues as it did before AI. Being able to say "the worst case is the old process" is one of the most persuasive sentences you can put in front of an operations director.
From trace to evidence
The last practical habit is turning traces into something a reviewer can read. A trace is a stream of timed events: model calls, tool calls, tokens, durations. An evidence record arranges one run so that someone who was not there can answer a fixed set of questions in order.
Umgeni generates an evidence record for every conversation that took an action and for a random sample of the rest. Here is a trimmed, illustrative example for one booking:
{
"case_id": "C-20519",
"input_masked": "Line down since last night, [PHONE] is my number",
"context_used": ["state:verified otp_sms", "notice:none for Umbilo", "line_status:no_signal"],
"tool": { "name": "book_technician", "params": { "slot_id": "S-1015-0800" } },
"policy": { "rule": "booking.residential.single_fault", "decision": "auto_approved" },
"result": { "booking": "B-77120", "at": "2026-10-14T11:02:41+02:00" },
"validation": { "schema": "pass", "slot_offered": true, "customer_confirmed": true },
"cost": { "model_calls": 5, "estimated_zar": 0.42, "seconds": 9.8 },
"final_response": "Booked: technician Thursday 08:00 to 12:00. Reference B-77120."
}
The policy field is the one most demo traces leave out, and the one an auditor will ask for first: not just what happened, but which rule allowed it. A trace is not an evaluation explains why the two must be kept apart, and evals that gate real work shows how evaluation results can decide what ships.
The developer is moving from typist to conductor
Look back at what the work in this series consisted of. Very little of it was writing model-calling code. Most of it was deciding what each model call should see, defining contracts, designing tests, setting limits, reading traces and writing down trade-offs. Much of the code itself could be drafted by a coding agent under that direction.
That is the shift in the developer's role that AI is producing: less time typing, more time specifying, directing and verifying. It is the same shift the coding agent harness describes for software delivery generally.
A related idea is worth naming in a portfolio. Context engineering is now part of software design. What goes into each model call (the state record, the retrieved passages, the tool descriptions, the business rules the model is told about) determines behaviour as much as any code does. In Umgeni's repository, those context assemblies are files, versioned and reviewed like code, with tests that fail when they change unexpectedly. Showing that you treat context as a designed artefact, not a string you edit until the demo works, tells a reviewer a great deal.
Who owns it on Monday
The last section of any credible portfolio names owners. Umgeni's support lead owns the labelled set and adds 50 newly labelled tickets a month, closing the ownership gap noticed in Part 3. Network operations owns the notices and their expiry dates. Field services owns the booking tool and its flag. Finance owns the dispute workflow. The engineering team owns the contracts, evaluations and runbook.
A learner presenting a personal project will not have a finance team. They can still show that they know these roles exist, and say who would own each piece in a real organisation. That is the difference between a demo and a system.
Key points
Evidence beats links. One evolving system with a decision log, contracts, evaluations and economics outweighs many repositories.
Speak to the middle column. Cost per case, behaviour when wrong and ownership matter to both architects and business leaders.
Lead with the runbook. "The worst case is the old process" is a sentence that wins trust.
Turn traces into evidence records. Include the policy decision, not just the events.
Show the conductor's work. Contracts, context, tests and limits are the engineering; the typing is the easy part.
This is the final part. Start again from Part 1, Stop collecting AI tutorials, or take each capability further in Memory Is an Architecture Decision and RAG That Survives Production. All parts are on the series page.
How CloudNala can help
We help teams and individuals turn a working AI build into evidence a decision-maker can trust: decision logs, versioned contracts, evaluation results, cost per case, known failure modes and a runbook with named owners. For organisations, that is the material a go-live decision should rest on. For engineers, it is the portfolio that shows judgement rather than tutorial completion.
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.
Plan an AI MVP Build Sprint or write to us at consult@cloudnala.co.za