IPAM as an operational source of truth

Inventory alone is not enough

A list of subnets is useful, but a source of truth must also explain intent. For every address block, operators should be able to determine its owner, purpose, environment, location, routing context, lifecycle state, and relationship to DNS and DHCP.

The goal is not to record every possible field. The goal is to make the decisions that matter explicit and reliable enough for both people and automation.

Model plan, assignment, and observation

Planned data describes what should exist: a reserved prefix, a DHCP pool, a static allocation, or a naming convention. Assignment data describes who or what owns an address. Observed data describes what the network currently sees. Mixing these without labels creates false confidence.

• Plan: approved networks, pools, reservations, and policy
• Assignment: owner, service, device, ticket, and lifecycle state
• Observation: leases, DNS records, discovery, and last-seen signals

Build a small lifecycle

A practical lifecycle can be simple: requested, approved, allocated, active, deprecated, and reclaimed. Each transition should identify who made the change and why. Reclamation is especially important; stale allocations make capacity planning inaccurate and can leave abandoned DNS records or access rules behind.

Use required metadata sparingly. Owner, purpose, environment, and lifecycle state usually provide more value than dozens of fields that nobody maintains.

Earn trust through reconciliation

IPAM becomes authoritative when teams routinely compare intended state with DHCP leases, DNS data, routing tables, cloud inventories, and discovery results. Differences should produce a reviewable exception, not an automatic overwrite with no context.

A source of truth is a maintained decision system, not a database that happens to contain addresses.