Most traceability programmes die in a spreadsheet. Someone builds a matrix with requirements down one side and tests across the top, fills it in for one release, and abandons it by the third because nobody has time to maintain it by hand. The conclusion drawn is that traceability is too expensive for a fast-moving team.
The conclusion is wrong, but the experience is real. Traceability is cheap when identifiers travel automatically between systems and expensive when people copy them by hand. The goal is not a matrix. It is a small set of fields, carried by each object a team already creates, so that a query can walk from a release decision back to the intent behind it. This part sets out that minimum and how to thread it through a typical toolchain.
Kudu Pharmacies is fictional, and its systems and figures are illustrative. Kudu's Kudu Repeat team uses a backlog tool, a Git host with pull requests, a CI pipeline, a test runner and a release checklist. Nothing exotic. Part 1 introduced the evidence chain; this part is about the plumbing.
Eight objects, a few fields each
Every delivery toolchain creates roughly the same eight kinds of object. Each needs only a few fields to hold the chain together.
Look at the pattern in the right-hand column. Every object carries two kinds of field: a pointer to the object before it and, where judgement is involved, the name of the person accountable. That is the whole design. Pointers let a query walk the chain. Names let an auditor or a post-incident review find the person who can explain a decision.
A few fields deserve comment.
Risk class on the work item. Without it, every change looks the same to the pipeline. With it, the pipeline can demand more evidence for high-risk changes and less for trivial ones. Three classes (high, medium, low) are usually enough. The class is set when the work is planned, by the product owner, and reviewed if scope changes.
Requirement version. Requirements change. A test that proved version 1 of RX-214 may not prove version 2. Recording the version a test was written against lets the pipeline flag tests that are now proving an outdated statement.
Artefact digest on the build. A build ID is a label; a digest is a fingerprint of the actual bytes. The release record should cite the digest, so there is no doubt that the thing tested is the thing deployed. Our AI Software Supply Chain series covers why that distinction matters even more when dependencies can be compromised.
Expiry date on exceptions. An exception without an expiry is a permanent waiver dressed as a temporary one. The field makes old exceptions visible.
Threading the identifiers
The fields only help if they are populated without heroic effort. The trick is to let one identifier carry the next.
At Kudu, the work item KR-1093 (the pharmacist hold change for release 4.12) carries the requirement ID RX-214 and the risk class "high". From there:
- The branch name includes the work item ID. A branch naming rule,
feat/KR-1093-hold, costs nothing and lets every commit be traced to the work. - The pull request template asks for the work item and requirement IDs. A pipeline check fails the pull request if they are missing. Most Git hosts can link the pull request to the backlog automatically once the ID is present.
- The build records the commit SHA and produces a digest. CI systems do this already; the change is to keep it and attach it to the build ID.
- The test runner records the build ID, environment and criterion IDs. Criterion IDs come from test tags or names, enforced by the lint rule from Part 1.
- The release record is generated, not typed. A script queries the runs for the release build, groups results by high-risk criterion and lists open defects and exceptions. The approver reads it and signs it.
None of these steps needs a traceability product. They need naming conventions, two or three pipeline checks and one script. Kudu spent about four days of engineering effort, spread over two sprints, to get there. That is illustrative, but it is the right order of magnitude for a single product team with a modern toolchain.
Where AI helps, and where it must not
AI is useful in this plumbing in two specific places.
Back-filling links for old work. When a team starts, hundreds of existing tests have no criterion IDs. An agent can read each test and suggest the criterion it most likely proves. A person reviews the suggestions in batches. This is exactly the bounded, checkable work Part 2 put in the left-hand column.
Spotting gaps. An agent can read new acceptance criteria and flag those with no tests citing them, or tests whose behaviour no longer matches the current requirement version.
Where AI must not help is in inventing links to satisfy a check. If an agent is told "every test must cite a criterion" and given no further guidance, it will cite something. A false link is worse than a missing one, because it makes a gap look covered. The safeguard is the same as for any agent output: suggestions are reviewed, and the review is sampled for quality.
When the toolchain is fragmented
Many South African organisations run delivery across tools that do not talk to each other: an older on-premises backlog, a cloud Git host, a test management tool from a different vendor, release approvals in email. Integration projects to connect them all are slow and often stall.
A lighter approach works better. Pick the identifier that is easiest to carry everywhere, usually the work item ID, and make it mandatory in text fields every tool already has: branch names, commit messages, test names, release notes. Then let a nightly script assemble the chain from those text fields. It is less elegant than native integration. It is also working within a week.
What the chain enables
Once the metadata exists, questions that used to take a meeting take a query:
- Which high-risk requirements changed in this release, and what evidence covers them?
- Which tests still prove an outdated requirement version?
- Which exceptions expire this month, and who owns them?
- For the incident last Tuesday, which build was running, what did its tests prove and who approved it?
The last question is the one that justifies the effort. When something goes wrong in production, the difference between a two-hour reconstruction and a two-week one is whether these fields existed before the incident.
Next: Part 4, A passed test is not proof of production readiness. All parts are on the series page. For the proposal-side equivalent of this discipline, see Make it easy to award the point.
How CloudNala can help
We help teams design the minimum traceability metadata for their own toolchain, including fragmented ones: naming conventions, pipeline checks, a generated release record and a back-fill plan for existing tests. The aim is a chain that maintains itself as a side effect of normal delivery work.
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 Release Evidence Review or write to us at consult@cloudnala.co.za