Evidence Trails for a Service

An evidence trail for a service is the set of records that connects a claim about that service to the facts behind it. It begins with the service and its map, continues through the tolerance set for it, and then gathers the tests that exercised it, the incidents that interrupted it, and the reviews that changed it. Each record in the chain should name the service, carry a date and an owner, and point to the record before and after it, so that a reader can walk the chain in either direction without help from the author.

Building a trail is less about collecting documents and more about keeping the connections between them. A map filed in one place, a tolerance stated in another, and a test result stored somewhere else do not form a trail, even if every item is accurate. The work is to make the links explicit, to use one name for the service throughout, and to file follow-up actions against the service they concern, so that the trail reads as the story of that service over time.

The map and the tolerance give every later record its meaning. The map shows what the service depends on, from customer channels through processing systems to suppliers and data stores, and it lets a reader judge whether a test exercised the dependency that actually matters. Without a map, a test result is just a pass or a fail attached to nothing in particular, and an incident record cannot show which dependency failed or which users were affected.

Tests contribute the evidence that the service can do what its plan says it can do, and they are most valuable when they are specific about what was exercised. A useful test record names the scenario, the dependency it stressed, the people involved, the sequence followed, and the outcome measured against the tolerance, including anything that went wrong or took longer than expected. A record that simply says a test took place, without those details, adds bulk without adding assurance.

Tests also reveal the gap between the plan and the reality of operating it. A recovery sequence that looks tidy on paper may depend on a person who is unavailable, a system that behaves differently under load, or a supplier step that nobody has rehearsed. Recording those discoveries honestly is the point of testing, and the trail should preserve them rather than smoothing them away. A test that finds nothing to improve should prompt a question about whether the scenario was demanding enough, not a celebration.

Incidents contribute a different kind of evidence, because they show what happened when the service was disrupted for real, rather than in rehearsal. A good incident record preserves the timeline, the decisions taken and by whom, the communications sent, the recovery steps followed, and the point at which the service returned to normal, judged against its tolerance. It also records the harm or disruption experienced by users in plain terms, rather than retreating into technical language that hides the effect.

A trail that can only be assembled by its author, over several days, will fail when it is needed most, which is during or just after a disruption, or when an auditor or supervisor asks for it at short notice. Usability comes from consistent naming, from filing records against the service rather than against a project or a team, and from keeping the most recent map, tolerance, test record and incident review easy to find together. If a second person cannot assemble the trail without the author, the trail is not yet in a producible form.

Trails break at handovers. A service changes owner, a supplier changes, a system is replaced, or a team is reorganised, and the records do not follow the change. The old map stays on file while the service it describes no longer exists in that form, and new test records use new names that do not match the old ones. The break is rarely dramatic, which is why it is missed, and it is usually discovered only when someone tries to follow the trail and finds that the names no longer join up.

Trails also break when follow-up is recorded as an intention rather than an action. A review may note that a plan should be updated or a dependency retested, but if no owner and no date are attached, the note fades and the next test rehearses the same weakness. The remedy is unglamorous: every lesson gets an owner, a date, and a place in the trail where its completion will be recorded. A trail that shows completed follow-up is the strongest signal a firm can give that its evidence is used to run the service, not merely to describe it.