On a commercial project, "it works" is mostly settled by the fact that it is working. On a funded, milestone-based public-sector programme, that is not sufficient. Someone will ask you to demonstrate that milestone three was met, and they will ask in month seven, about an environment that has changed twice since.
If you did not capture the proof at the time, you are reconstructing it. Sometimes you cannot.
Define the evidence point before the work
The discipline is simple and almost never applied: for each milestone, decide in advance what artefact will prove it. Not "we'll screenshot something" — the specific thing.
Access established: the role assignments, and the identity visible in place. Infrastructure deployed: the resource views, plus the infrastructure code that produced them. Pipeline running: the run logs, green, tied to the commit they came from. Service reachable: the deployed URL, and the first telemetry coming off it.
Deciding this up front changes two things. It makes the milestone unambiguous — everyone knows what "done" looks like because it has a named artefact — and it means the capture happens as a step in the work rather than as an archaeology exercise later.
Green and fresh, or reconstructed and weak
The difference between those two rows is entirely timing, and it is larger than it looks.
Evidence captured the same day is authoritative. The pipeline run is there, the resource is in the state the milestone describes, the URL responds. Evidence reconstructed months later is a different artefact: the environment has moved on, the run has aged out of retention, the resource has been reconfigured twice, and what you produce is a description of what happened rather than a record of it.
It is also produced under time pressure, by someone trying to remember, the night before a review. That is the worst possible condition for accuracy, and it is when most proof packs actually get assembled.
The artefacts are evidence too
An underrated consequence of the spec-driven approach: the constitution, specification, technical plan and task list are themselves evidence, and they are versioned in the repository with timestamps and authorship.
That is a considerably stronger record of decision-making than a set of meeting notes. It shows what was decided, when, on what reasoning, and what changed afterwards. For any question about why the system is the way it is — particularly a data-residency question — the git history of the constitution answers it directly.
So the cost of producing that evidence is zero. It is a by-product of working the way you were already working. You just have to not throw it away.
Why the walking skeleton earns its place here
The walking skeleton is the highest-value evidence artefact in the entire delivery, and this is the article where that becomes obvious.
A single thin slice, deployed early, demonstrates in one artefact: that access was established, that the infrastructure code works, that the pipeline reaches the tenant, that the service is reachable, and that evidence capture itself functions. Five milestones' worth of proof from one deployment that does almost nothing useful.
The alternative — three polished features on a laptop — proves none of them.
The audit trail is a design output
There is a governance argument that arrives at the same conclusion from a different direction. Eugene Perumal of Valutivity, writing in ITWeb this month (Deploying AI agents safely), makes the point that a well-governed architecture produces the record as a by-product: what triggered the system, what data it reached, what decisions it made. His formulation is that this is what "differentiates deployable systems from proof-of-concepts."
That is exactly right, and the emphasis belongs on produces. You do not add an audit trail to a system. Either the architecture generates one because access is scoped, defined in code and instrumented — as covered in the least-privilege article — or it does not, and no amount of later effort creates a record of events that were never captured.
For AI features specifically this is becoming the deployment gate rather than a nice-to-have. Perumal reports 75% of enterprise leaders naming security, compliance and auditability as their most critical agent requirements — ahead of capability. An agent that cannot show its working does not get into production in a regulated organisation, regardless of how well it performs.
What we would tell a delivery lead
Write the evidence point into the milestone definition. If a milestone does not name its artefact, it is not defined yet.
Capture on the day, not on request. Put it in the definition of done for the task, not on someone's list for later.
Store it with the code. Same repository, same version control, same review. Evidence in a shared drive gets separated from the thing it evidences.
Treat the skeleton as a deliverable. It looks like nothing and proves almost everything.
The whole thing amounts to one sentence, which is worth being blunt about: if it is not evidenced, it is not done. Not as a philosophical position — as a description of what will happen when someone asks.
How CloudNala can help
Evidence is the thing that gets deferred, because at the moment of doing the work it feels like admin and the deadline is elsewhere. Where we tend to add value is in setting the evidence points up alongside the milestones at the start, so capture is a step in the work rather than a project of its own later — and in making sure the walking skeleton lands early enough to carry as much of that proof as it can.
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 Readiness Workshop or write to us at consult@cloudnala.co.za