Soundtrack for this blog: The Rolling Stones - Gimme Shelter
The room was full of folders. Physical ones. Thick, labeled, neatly arranged. There were process descriptions, policies, diagrams, and procedures for almost everything you could imagine. The organization was proud of its documentation. You could feel it.
When the auditor asked how a particular change had been approved, someone confidently pulled out a process document. It explained the approval flow in detail: who requests, who reviews, who approves. It was well written and clearly thought through. The auditor listened patiently and then asked a simple follow-up question:
“Can you show me where this was actually applied last month?”
That’s when the tone in the room changed. What the team had produced was documentation. What the auditor was asking for was evidence. And the uncomfortable truth was that no one in the room had clearly separated the two in their minds.
Over the years, I’ve seen this same scene play out again and again — sometimes in audits, sometimes in incident reviews, sometimes in internal handovers where no auditor is present at all. The confusion between documentation and evidence is one of the most persistent and quietly dangerous misunderstandings in organizational life.
Documentation tells a story about how things are supposed to work. Evidence tells a story about what actually happened. Both stories matter. They are not the same story.
Early in most projects, this distinction doesn’t feel important. Everyone remembers why decisions were made. If something changes, someone can explain it. If a system behaves a certain way, the people who built it are usually still around. In that phase, logs, tickets, emails, and chat messages feel sufficient. After all, the facts are there.
The problem is that facts without context age badly.
I once worked with a team that prided itself on transparency. Everything was tracked. Every change had a ticket. Every ticket had comments. Every comment had timestamps and names. From a distance, it looked like exemplary governance.
But when a new team took over the system two years later, they struggled to understand why certain design choices had been made. They could see that changes happened, when they happened, and who approved them. What they couldn’t see was why.
The original rationale was never documented. It lived in conversations, assumptions, and shared understanding — all of which had quietly left with the people who moved on. The evidence was intact. The understanding was gone.
That’s when it became clear that evidence alone does not preserve knowledge. It preserves events. Documentation is what preserves meaning.
The reverse problem is just as common, especially in organizations that are highly process-driven. Here, documentation is abundant. Policies explain how access should be granted. Procedures describe how incidents should be handled. Diagrams show how systems are structured. Everything is explained in advance, often in impressive detail.
And yet, when something goes wrong, the documentation turns out to be oddly fragile. I’ve seen organizations point to a beautifully written security policy during an incident review, only to discover that no one could demonstrate whether it had been followed. Access logs were incomplete. Approval records were missing. Changes had been made “urgently” and never reconciled afterward.
The documentation explained intent. It did not demonstrate behavior.
This is where documentation is mistaken for evidence. A policy does not prove enforcement. A process description does not prove execution. A diagram does not prove that a system behaved that way last Tuesday at 3 p.m. Good documentation without evidence creates confidence that may not be deserved. Good evidence without documentation creates confusion that may never fully be resolved.
One of the most subtle traps I’ve seen is when organizations try to force documentation to become evidence. Someone decides that if documentation is updated frequently enough, it can serve both purposes. Procedures start to include operational details. Architecture documents begin to record state rather than structure. Decision documents are rewritten after the fact to align with what already happened.
At that point, documentation stops being an explanation and becomes a narrative defense. You can usually tell when this is happening because the documentation starts to read like an answer to an imagined audit question rather than a tool for understanding. It grows verbose. It becomes careful with language in the wrong way. And ironically, it becomes less useful for the people who actually have to work with the system.
Experienced teams eventually learn to resist this temptation. They accept that documentation and evidence live on different timelines and serve different purposes.
Documentation changes slowly. It captures intent, structure, boundaries, and rationale. Evidence accumulates continuously as work happens. Trying to synchronize them perfectly is neither realistic nor necessary.
A useful way to think about this distinction emerged for me after many years of watching handovers fail. If you remove a piece of information and the system becomes harder to understand, you removed documentation. If you remove a piece of information and the system becomes harder to trust, you removed evidence. Understanding and trust are related, but they are not interchangeable. A system you understand but cannot trust is dangerous. A system you can trust but do not understand is brittle. Mature organizations aim for both, and they do so by being very deliberate about what they document and what they treat as evidence.
This distinction becomes especially important in IT documentation and business analysis work. When a requirement is written down, it explains what is expected. When a test result exists, it demonstrates whether that expectation was met. When a decision is recorded, it preserves why a direction was chosen. When an approval is logged, it shows that responsibility was accepted.
Problems arise when requirements documents are expected to prove compliance, or when approval logs are expected to explain intent. Each artefact starts to carry a burden it was never designed to carry.
Over time, this creates documentation that is heavy, defensive, and still incomplete — and evidence that is abundant but oddly unhelpful. One of the quiet lessons that experience teaches is restraint. Not everything that happens needs to be documented. Not everything that is documented needs to produce evidence. The skill lies in knowing where the boundary is. Early in my career, I believed more documentation meant more control. Today, I believe clearer boundaries mean more control. Documentation should explain the system to someone who was not there. Evidence should allow that same person to verify that the system behaved as claimed.
When those two things work together, audits become conversations rather than interrogations, handovers become transitions rather than excavations, and incidents become learning moments rather than blame exercises.
At GreenMethod, this distinction shapes how we work internally and how we advise clients. We document systems so they can be understood years later, not just during the current project. We rely on evidence to demonstrate execution, not to explain intent. We resist the urge to make one compensate for the absence of the other.
This approach doesn’t eliminate risk. Nothing does. But it makes risk visible, manageable, and explainable which is ultimately what good documentation and good evidence are both meant to support.
Looking back, the organizations that age well are not the ones with the most documentation or the most data. They are the ones that know what each is for.
Documentation explains. Evidence proves.
When you respect that difference, both become far more valuable — and far less painful — over time.