How would you model physical and logical network resources, and what do you do when discovery disagrees with the inventory?

Three layers, not one table

The single most common modelling mistake is one big table of equipment with service details bolted onto it. Inventory needs at least three layers, related but versioned and queried independently.

The physical layer records things you could photograph: sites, racks, chassis, cards, ports, cables, patch panels, fibre strands, and the containment they run through. Its distinguishing feature is that it has a location and a supplier, and that it changes only when someone touches hardware.

The logical layer records resources that exist as configuration rather than as matter: VLANs, IP subnets and addresses, subscriber identities, circuit and channel identifiers, MPLS paths, wavelengths, bearer capacity. Logical resources are hosted by physical ones but do not correspond one-to-one, and they are created and destroyed far more often.

The service layer records what was sold and how it is realised: a broadband service for a given subscriber, realised over a specific port and a specific address allocation. This is the layer that connects the OSS record to the commercial order, and keeping it separate is what lets you re-home a service onto different resources without touching the customer's contract.

The relationships between layers carry the information. A port is contained by a card, which is contained by a chassis. A VLAN is hosted on a port. A service consumes both. Model containment and consumption as first-class relationships and most inventory questions become graph traversals: what services fail if this card is pulled, which is the query the assurance team asks every single day.

A resource lifecycle, not a boolean

in_use = true is not enough, because allocation is a process with a middle. A workable lifecycle for an assignable resource looks like this:

• Planned — modelled but not physically present, so plans can be built ahead of the build.
• Available — present, tested, assignable.
• Reserved — held for a specific order, with an expiry. Reservations without expiry are how inventory silently runs out.
• Assigned — consumed by a live service.
• Quarantined — released but not yet reusable.
• Faulty or retired — present but not assignable, which is different from being in use.

Reservation deserves emphasis because it is where concurrency bites. Two orders decomposing at the same moment will both look for the last available port on a card. The reservation must be an atomic state transition on the resource row, conditional on its current state, so exactly one order wins and the other continues its search — the same conditional-update pattern you would use for any contended resource, applied here to something that costs money to install.

Release is where the record rots

Assignment is easy to get right because someone is waiting for it. Release is not, because nobody is waiting, and that asymmetry is the reason real inventories drift.

Two things go wrong. First, cancellations and cease orders fail halfway and leave resources assigned to services that no longer exist. Over years this manifests as an operator buying equipment it already owns, because the record says the estate is full when it is not. Second, immediate reuse of a just-released logical resource causes live incidents. An IP address handed to a new subscriber the moment the old one disconnects will attract the previous tenant's traffic, cached DNS answers and firewall state; a reused circuit identifier confuses the very correlation logic your assurance platform depends on. Hence the quarantine state, with a cooling period set by how long the surrounding systems remember — lease and session lifetimes, cache expiry, log retention windows — rather than by an arbitrary number.

Reconciling discovery against the record

Discovery, whether by polling the elements, subscribing to their notifications or reading the element managers, gives you what the network is currently configured to do. Comparing it with the inventory produces four categories of difference, and the value of the comparison lies entirely in the classification.

Finding	Likely cause	Correct response
In network, not in record	Manual change, or a fulfilment task whose acknowledgement was lost	Investigate: adopt into the record if legitimate, remove from the network if not
In record, not in network	Failed activation, or a device rebuilt from an older configuration	Re-drive the activation from stored intent
In both, attributes differ	Partial provisioning, or a local edit for a fault that was never rolled back	Decide per attribute which side is authoritative
In both, matching, but no service	Orphaned resource from a failed cease	Verify against the subscription record, then release through quarantine

The response column is doing the real work. A rule that copies discovered state into the inventory would close every one of those rows instantly and destroy the information they contain.

Neither side is the master, and that is the point

The answer that sounds sophisticated and is wrong is "the network is the source of truth, so we auto-correct the inventory from discovery." It fails in three ways at once. It erases intent, so a service that was provisioned and has since silently stopped working now looks correct in the record. It launders unauthorised change, converting a configuration someone made at three in the morning into an approved fact. And it frees resources that are genuinely in use whenever a device is unreachable or a poll times out, which is how a reconciliation job takes out working customers.

Split the authority instead. The inventory is authoritative for intent and for assignment — what was sold, what was allocated to it, what should be configured. The network is authoritative for observed state — what is presently configured and reachable. A difference between them is not a data problem to be silently patched; it is a finding, with a cause, that either re-drives fulfilment from intent or raises a ticket for a human. Auto-remediation is reasonable only for difference types you have measured and understood, and even then it should re-apply intent to the network rather than re-apply the network to the record.