Network Documentation That Writes Itself — And Why Handover Documents Go Stale
Network Documentation That Writes Itself — And Why Handover Documents Go Stale
Open your organisation's most recent network document and ask one question: does it match reality today?
In most organisations the answer is no, and it is nobody's individual fault.
Why documentation always goes stale
Because it is a still photograph of something that moves constantly.
The document is written at handover. Then someone adds a device on a Friday afternoon. Someone edits a firewall rule because the accounting system stopped working. Someone moves a printer to another floor. Each time, the person doing it fully intends to go back and update the document, and nobody does — because updating documentation is never as urgent as the thing that made the system work again.
The result is an organisation holding a document that looks authoritative and that nobody quite trusts. Once it is not trusted it is not used, and once it is not used it is certainly not updated.
The answer is not more discipline
Every organisation has tried to fix this with process: mandate that every change is recorded. It fails repeatedly, because it runs against the reality of work at the coalface.
What works is changing the source of truth — generating documentation from the actual state of the equipment rather than from human memory.
What state-generated documentation looks like
Once equipment is connected to AI through a connector, requesting documentation becomes asking a question.
- Produce a map of what is genuinely connected right now
- List the firewall rules, with an explanation of what each one does
- Summarise what has changed since the previous document
The third one carries the most value, because it turns documentation from a photograph into an auditable record of change.
What still needs a human
Auto-generated documentation tells you what is where. It cannot tell you why.
Why was this segment separated out? Why this structure instead of the simpler one? The reasoning behind a decision is the part an engineer has to write, and it is the part worth the most when the next person inherits the system.
So the approach we use has two layers: state, generated automatically and refreshed on demand; and rationale, written once by a person and revised when the decision changes.
Frequently Asked Questions
Q1: Is this acceptable for an audit?
A1: Yes, and it is often better than hand-written documentation, because each fact is traceable to the device it came from and the time it was read.
Q2: Do we throw away our existing documents?
A2: No. We use the existing material as the basis for the rationale layer, and regenerate the state layer from the live equipment.
Q3: How often does it update?
A3: On request, and on a schedule if you want one. More important than frequency is that every version states its date and its source.
Want to know how far your current documentation has drifted from reality? Consultations are free — LINE @tectony or hello@tectony.co.th