Status
Proposed on 2026-03-14 by Lars Solem.
Context
Inventory quality is critical for Dataverket.
Maskin depends on it for hardware identity and placement. Nett depends on it for topology and safe configuration rollout. Sentral depends on it for resource graph correctness and capacity understanding.
The architecture already acknowledges this dependency, but until now it has not defined how inventory is bootstrapped, trusted, and corrected when reality diverges from declared state.
Decision
Dataverket adopts a hybrid inventory bootstrap and drift management model:
- manually curated initial topology and facility data
- automated discovery for safe hardware facts
- explicit drift detection
- operator approval before sensitive topology changes become trusted source of truth
Inventory is therefore neither pure manual documentation nor blind auto-discovery.
Bootstrap model
The initial inventory for a new site or datacenter should be created from curated operator input for:
- sites
- rooms
- racks
- network links
- switch and router management identities
- port topology where known
This is the control-plane seed state that later automation can build on.
Discovery model
Auto-discovery is appropriate for facts that can be learned safely, such as:
- BMC presence and reachability
- server serial numbers
- MAC addresses
- CPU, memory, and disk facts
- currently observed device software versions
Auto-discovery should enrich or validate inventory. It should not silently rewrite high-trust topology data on its own.
Trust model
Inventory fields must have different trust levels.
Examples:
- manually approved rack and port topology is high-trust
- discovered hardware facts are medium-trust until validated
- inferred relationships from partial observation are low-trust until approved
Sensitive automation decisions should rely only on trusted inventory data appropriate to the risk.
Drift model
Drift occurs when declared inventory and observed reality differ.
The platform must detect and surface drift for at least:
- device identity mismatch
- missing or moved hardware
- network topology mismatch
- unexpected interface or link state relevant to managed intent
- capacity mismatch that affects placement decisions
Drift is not always an error, but it is always something the control plane must be aware of.
Approval model
Sensitive inventory changes should require operator approval before they become authoritative.
Examples include:
- changed switch port topology
- changed uplink relationships
- hardware moved between racks
- device role changes with operational impact
This is especially important because wrong topology data can produce wrong network configuration.
Ownership model
Inventory ownership is split as follows:
Sentral Canonical inventory graph and trust state
Maskin Hardware discovery, BMC facts, and server lifecycle linkage
Nett Topology consumption, network-related validation, and drift signals relevant to managed fabric state
No single domain service should be allowed to mutate the whole inventory model casually.
Operational model
Operators must be able to inspect:
- current declared inventory
- recently discovered facts
- current drift signals
- pending approvals
- trust level or source of important inventory fields
Inventory quality cannot depend on tribal knowledge.
Multi-datacenter implications
Because Dataverket is multi-datacenter, inventory must include:
- datacenter identity
- rack and failure-domain metadata
- site-local capacity and placement inputs
- explicit inter-site relationships where they matter
Failover and placement logic depend on this data being trustworthy.
Consequences
- inventory bootstrap becomes an explicit workflow instead of an unspoken prerequisite
- auto-discovery is useful without being allowed to rewrite critical topology silently
- drift becomes something the platform can surface and manage
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- This ADR refines the inventory role described in 009-resource-inventory-and-tenancy-model.md.
- Hardware discovery and provisioning assumptions must align with 006-bare-metal-provisioning-with-ipxe-and-talos.md.
- Network automation safety depends on this model, as described in 005-network-service-and-topology.md.
- Operator visibility and drift surfacing must align with 017-observability-and-operations-baseline.md.
More Information
- inventory trust-state schema
- discovery pipeline design
- approval workflow design
- network topology validation rules
Audit
- 2026-03-14: ADR proposed.