This map is part of the network change acceptance guide, which covers what to inventory before a refresh. The worked exception follows one missed dependency hour by hour. This page answers a different question for network automation integrators: which tool holds which piece, and which identifiers hold the pieces together.
Five systems behind one accepted change
A typical regional operator spreads one change across five tools, often administered by different teams. One row per system:
| System | Record it holds | Linking key it shares | Usual owner |
|---|---|---|---|
| Change management (ITSM) | Request, risk and impact assessment, approvals, emergency-change justification, review | Change number; device names typed into the request | Change manager |
| Network inventory or source of truth | Devices, interfaces, circuits and services mapped to ports; history of edits if kept | Asset ID, hostname, circuit and service IDs | Network planning or engineering |
| Test automation system | Test plans, scripts, run results with pass or fail and timestamps | Target hostname or address; change number if the run is tagged | Network test lead |
| Configuration backup store | Pre- and post-change configs per device, by date | Hostname, backup timestamp | Network operations |
| Service desk | Customer incidents, linked to a change where the agent recorded it | Change number in a related-record field; customer and circuit ID | Customer care lead |
The change system is the spine because every approval hangs off the change number. NIST SP 800-128 describes change control as changes being formally identified, proposed, reviewed, analyzed for security impact, tested and approved before implementation, and in operators that work that way, each of those steps leaves a dated entry under one number. The other four tools only join the spine if they carried that number, or something that maps to it, at the time.
Linking keys, and where each one slips
| Key | Should appear in | Where it fails | What to ask |
|---|---|---|---|
| Change number | Change system, test runs, maintenance notes, related incidents | Test runs saved by device name only; incidents never linked | Are test runs tagged with the change number? |
| Asset ID | Inventory, change request | Change requests list hostnames, not asset IDs | Does the change form pull devices from the inventory? |
| Hostname | Inventory, test system, backups | Old and new hardware sharing one hostname during a swap | How are old and new devices named during a cutover? |
| Circuit and service IDs | Inventory port map, impact analysis, incidents | Dependencies held only in device config, never in the inventory | Is the impact list generated from the inventory, and how complete is it? |
| Time | Every system | Tools logging local time without an offset, or clocks out of sync | Do all tools record UTC or an offset? |
| Approver | Change system | Acceptance given in chat or by phone | Is acceptance always recorded against the change? |
Time deserves more attention than it gets. NIST SP 800-53 control AU-8 asks that audit time stamps come from system clocks and be recorded in UTC, with a fixed offset from it, or with the local offset included. A test tool that logged local time with no offset, in a different zone from the change system, makes a 02:20 result look like it happened after a 07:15 incident. Ask once, early, whether every tool records the zone.
One change joined across systems (Illustrative)
A fictional 330-person managed WAN provider upgrades the operating system on a pair of core switches. Every identifier is invented.
| Step | System | Record | Key carried forward |
|---|---|---|---|
| 1 | Change system | Change 58840 approved: OS upgrade on core-sw-01 and core-sw-02, impact list of 22 services | Change 58840, two hostnames |
| 2 | Inventory | core-sw-01 is asset A-1193; ports map to 22 service IDs | Asset A-1193, service IDs |
| 3 | Backup store | Pre-change configs saved 23:40 UTC for both switches | Hostnames, UTC time |
| 4 | Test system | Run tagged 58840: 22 of 22 service checks pass at 01:55 UTC | Change 58840, hostnames |
| 5 | Change system | Acceptance recorded by the shift lead at 02:05 UTC against run 58840 | Change 58840, approver |
| 6 | Backup store | Post-change configs saved 02:10 UTC; diff shows only the expected version lines | Hostnames, UTC time |
| 7 | Service desk | No incident linked to 58840 within the review period | Change 58840 |
This one joins cleanly because the test run carries the change number, the inventory supplies the asset and service IDs the impact list was built from, and every tool writes UTC. Step 6 is the quiet hero: a config diff that shows nothing unexpected is positive evidence the change did only what it claimed. In the worked exception on the related page, the same diff is where the missing customer route surfaced.
The third source: configuration backups
A test system can only prove what it was asked to check, and if the checks were generated from the inventory, its coverage equals the inventory's coverage. That is why a reconstruction needs the backups as an independent third source. They record what the device actually did, including static routes, filters and policies that nobody entered into the inventory, so the gap between documented and actual dependencies becomes visible.
Two practical questions follow. First, how long are backups kept: a rolling window per device, or every version since the device was installed? Second, does the inventory keep its own history? If the inventory keeps only its current state, what the inventory believed on the night of a change is lost unless snapshots were taken. During a refresh, either store can be retired along with the old hardware, which is the timing the main guide discusses.
Clock and identity checks for the network operations head
These are answerable from memory or a screen, without exporting anything:
- Which tools hold change requests, test runs, maintenance notes, configs and incidents, and since which year each?
- Are test runs and incidents tagged with the change number?
- Do change requests reference inventory asset IDs, or free-text hostnames?
- Do all five tools record UTC or an explicit offset?
- How long are config backups retained, and does the inventory keep history?
- Roughly how many changes a year, and roughly how many have a linked incident?
- Did a contractor or MSP author test plans or notes? The MSP ticket data page explains why that matters for ownership.
The answers feed the network change referral brief template. What makes a history like this licensable, beyond joins, is covered in what makes a dataset licensable, and integrators who also advise IT services firms may find IT consulting firm data licensing useful.
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting introductions. Customer service IDs and topology are sensitive; what can be licensed after de-identification, and whether any buyer wants it, stays unknown until SourceX reviews it with the operator's authorized contact.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the network operations head confirms that test runs carry the change number and config backups go back years, register as a partner, check the operator on who qualifies and read the program terms before making the introduction.