Count the documents a single business rule passes through on its way to production. It starts in a business case or a policy. An analyst restates it in requirements. An architect restates it again in a design document. It is broken into tickets. A tester rewrites it as test cases. Operations rewrites it once more in a runbook so support staff know what to do when a customer complains.
That is six restatements of one rule by six people, each working from the document before rather than from the source. Each one is a handoff, and every handoff loses something: a condition, an exception, a reason. Nobody does anything wrong. The process is built to lose information.
People partly compensate. The tester asks the analyst what a rule meant. The support lead calls an engineer. Agents do not compensate. An agent reading the runbook acts on the runbook, and an agent reading the tickets builds the tickets. If those have drifted from the rule, the agent faithfully builds the drift.
Seapoint Payments is fictional, and its systems and figures are illustrative. In Part 2, Seapoint's specification ONB-012 changed so that a partial bank-account match holds a merchant's payouts. This part follows that one rule backwards, through every document it had been copied into.
Tracing one rule through six documents
After the stale-rule merge in Part 2, the squad's analyst did something tedious and valuable. The analyst took the partial-match rule as the risk lead had originally written it, with its four conditions, and checked which of those conditions still appeared in each downstream document.
The original rule had four parts: hold payouts on a partial match, create a review task, notify the merchant with a specific reason, and release only after a person confirms the account against a bank letter. By the time the rule reached the support runbook, the review task and the confirmation requirement had disappeared. The runbook told support staff that a merchant whose payouts were held could have them released on request.
Each document had been reasonable when written. The architecture document summarised. The tickets split the work and dropped the reason because no single ticket needed it. The test plan tested what the tickets said. The runbook was written from the test plan because that was the most concrete document available. Every author was conscientious, and the end result contradicted the rule.
Why agents raise the stakes
There are three reasons this pattern costs more when agents are involved.
Agents read whatever document they are pointed at, literally. A person working from the runbook might sense that "release on request" sounds wrong for a fraud control. An agent writing a support tool from the runbook will build a release button.
Agents multiply the number of consumers. One person might read the test plan. Several agents, working different tasks in parallel, each read whichever copy of the truth was put in their context. Divergent copies produce divergent code.
Agents remove the friction that used to force reconciliation. When writing code was slow, an engineer often went back to the source to check, because a mistake cost days. When code arrives in an hour, the incentive to go back to the source weakens, and the drift goes straight into the build.
One specification, owned in sections
The alternative is not a single person who writes everything. It is a single document that everyone writes into, each in their own section, under their own approval.
At Seapoint, ONB-012 became that document. The product owner owns the intent section. The analyst owns business rules and examples, with the risk lead approving any rule that changes a risk control. The architect owns contracts and limits. The tester owns acceptance criteria. The operations lead owns a short operational section, which replaced the separate runbook entry for onboarding: what support staff may and may not do, written directly against the rules they apply to.
Everyone reads the whole document. Agents receive context generated from the current version. Downstream artefacts still exist, because tickets and test cases are useful units of work, but they point at specification sections instead of restating them. A ticket says "implement ONB-012 §4.2" and links to it, rather than paraphrasing §4.2 in its own words.
What changes in practice
| Before | After |
|---|---|
| Each role writes its own document from the previous one | Each role writes its own section of one document |
| Rules are restated at every step | Rules are written once and referenced |
| Drift is found by incidents | Drift is visible because there is only one place to look |
| Runbooks are written from test plans | The operational section sits beside the rule it applies |
| Agents get whatever copy someone pastes | Agents get context generated from the current version |
| A rule change is announced in chat | A rule change is a versioned edit with an approver |
The objections, and fair answers
"One document will become enormous." It can. The answer is structure, not more documents: a specification per capability (onboarding, payouts, disputes), each with stable section identifiers, and short sections. A living specification for one capability is usually tens of pages, not hundreds.
"Not every role is comfortable editing in a repository." True, and this is the most common practical blocker. Some teams keep the specification in a tool business users already use and generate the repository copy automatically. What matters is that there is one source and one version, not which editor people use.
"Our runbooks and test plans serve other purposes too." They do. They can keep those purposes and still point at the specification for the rules themselves. The aim is not to delete documents. It is to stop restating rules.
"This is just spec-driven development." It overlaps heavily, and our Spec-Driven Development series covers the method. The point here is narrower: in an AI-native loop, the cost of keeping several restated copies of the truth rises sharply, so consolidating them stops being good hygiene and becomes a control.
How to start without a big migration
- Pick one rule that has caused a production problem. Trace it through every document it appears in, as Seapoint's analyst did. The result is usually persuasive.
- Create the specification for that one capability, with owned sections and identifiers.
- Change the ticket and test templates so they reference sections rather than restate them.
- Replace the runbook entry for that capability with an operational section in the specification.
- Point agents at the specification only, and remove the habit of pasting older documents into context.
Team structures for SDD covers how responsibilities shift between roles when the team works this way. The short version is that every role still contributes the same expertise. They contribute it to one place.
Next: Part 4, Harness engineering has grown up. All parts are on the series page.
How CloudNala can help
We help teams consolidate restated requirements into a living specification for one capability at a time: tracing a problem rule through its current documents, designing the owned-section structure, changing ticket and test templates to reference it, and setting up how agents receive context from it. The first capability is usually enough for a team to decide whether to extend the approach.
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 Delivery Pilot or write to us at consult@cloudnala.co.za