The short version
- Acceptance does not mean something functions but that somebody else can keep operating it. Those are two different tests.
- Six artefacts carry operations: inventory diff, HLD/LLD, configuration templates, test report, change log and acceptance record.
- The key criterion is not completeness but reusability: a PDF describes the state, a template recreates it.
- If you cannot find these artefacts in a proposal, ask before awarding the work — they are rarely produced afterwards.
Accepting a network project is, in many cases, a shared look at a working state: the sites are connected, the wireless carries, the application responds. Then it gets signed. What is not tested is the actual question — whether anyone can continue without the builder.
Two tests, not one
The first test is functional: does it do what it should? Necessary, but easy to pass — on handover day everything stands freshly configured and closely watched.
The second test is operational: can somebody else take this over, understand it and change it? It is rarely asked, yet it decides the cost of the next five years. A network only its builder can change is not a finished project but an ongoing contract.
The six artefacts
We run every change through the same six stages, and each leaves exactly one artefact that lasts. That is not a formality: together those six documents are the answer to the second test.
Inventory diff
The actual state, gathered from devices, controllers and APIs and set against the existing documentation. The value is in the difference: it shows where the assumptions were wrong.
HLD and LLD
Target architecture and detailed design — what is built and why this way. The LLD later answers the question operations asks most often: why is this actually solved like this?
Configuration templates
The target configuration as a template from structured data, not as a transcribed device configuration. Only the template can be reused for the next site; the finished text cannot.
Test report
Automated checks of routing, adjacencies, VPN, redundancy and reachability — before and after the change. The report is the basis for approval and later the benchmark when something behaves differently.
Change log
What was changed when and by whom, with approval and fallback path. During an incident this is the very first question — and without a log, the most expensive one.
Acceptance record
What was handed over, what was tested, what explicitly remains open. That last item is the most valuable: a named open point is operational knowledge, a concealed one is a trap.
The criterion is reusable, not complete
A thick documentation package is not yet a good handover. The difference is whether an artefact describes the state or produces it. A PDF with configuration screenshots describes; a versioned template with its data produces. At the next site that is the difference between a day and a week.
Three questions test this quickly and without technical depth:
- Can we build another site from what was delivered without asking you? If not, you have a description, not a template.
- Do the artefacts live in our tools? Repository, wiki, ticket system — not as an email attachment and not on the provider's portal.
- Is the test run repeatable? A test report whose checks cannot be executed again evidences a day, not a state.
Ask before awarding, not at acceptance
Artefacts are produced during the work or not at all. Demand them only at acceptance and they get produced retrospectively — and retrospective documentation describes what somebody remembers, not what was built.
Four points therefore belong in the enquiry: which artefacts are delivered, in what form, in whose tools they live, and who owns them. The answers are short and distinguish providers far more clearly than day rates.
For IT providers buying in capacity this is the single most important point — it decides whether the next change has to be bought in again. More on that in the article on white-label collaboration. How we run the six stages is described on our page for network automation.
Why open points belong in the record
No project ends without remainders: a device to be replaced next quarter, an exception that stays for good reasons, a feature waiting on a software release. The reflex to leave those out of the acceptance record is understandable and wrong.
A named open point with a date and an owner is operational knowledge — it turns up at the next incident as an explanation rather than a surprise. A concealed one gets found eventually, and then it is not the exception that is questioned but the handover as a whole.