The five infrastructure families

Infrastructure holds five families, one screen each: virtualization, storage systems, cloud accounts, container clusters, and backup & protection.

Family	What a row is	What is not a row
Virtualization	A cluster, and the management plane that runs it	A single host — that is a server
Storage systems	The system	A volume, a LUN or a capacity pool
Cloud accounts	An account, subscription or project, and the link that attaches it	A cloud instance — that is a server
Container clusters	The cluster and its node pools	A pod
Backup & protection	The protection service and the coverage it provides	The backup appliance — that is a storage system whose role is Backup

What belongs here and what stays in the server list

The rule is not "does it have an operating system". An object is a server when the server inventory is already the authority for it: general-purpose compute with a DNS name, patched on the OS vendor's cycle, whose tier produces a meaningful patch cadence and next-due date.

A virtual machine is a server. A container worker node is a server. A cloud instance is a server. A firewall, a switch, a storage controller and a database instance all have an operating system, are all patched, and none of them is a server here.

Where the rows come from

Every row has two halves:

• The discovered half — what an inventory the product already reads knows about the object. Virtualization clusters are derived from the cluster field in the server inventory, and storage systems are detected automatically from the equipment register when the model names a system family the vendor publishes. The other three families are discovered from nowhere.
• The recorded half — what nothing discovers: the support end date, the owning team, the management plane, the HA policy. Those are entered on the record card.

A discovered value is never overwritten by a recorded one. A cluster's platform is read from the hosts actually in it; a typed value beside it would be a second authority for one fact. The card fills in only what no inventory answers.

The Status column — five values, not four

Value	What it means
Fault	The source reports a fault
Warning	The source reports a degraded or partial state
In maintenance	Deliberately out of service — suspended, disabled, in maintenance mode
OK	The source reports everything is well
Unknown	The source said nothing, or said something the product does not recognize

That is also the sort order: worst first, Unknown last. "We cannot say" is not "this is fine", but it is not a finding either, and putting it at the top would bury the real ones.

"In maintenance" and "Unknown" are two different facts. A host deliberately taken out for maintenance has not gone missing, and telling an on-call engineer that its state is unknown wastes the first ten minutes of an incident.

A value the product does not recognize falls to Unknown and the original word stays visible beside it. A source that starts reporting a sixth state must show its own word, not a confident and wrong glyph.

"Support ends" is a date, not a verdict

The column shows the date the source gave and turns red once it has passed. It does not assert that the product is out of support: a red badge on a version still receiving security errata is a false compliance finding the product itself would have produced.

What the five screens share

Full-text search, per-column filters, the quick-filter rail, saved views, column choice and order, and export to CSV and Excel — the same toolkit every table in the product has. The export carries every field the source ships and every custom column that has been added, not only the visible ones.

Next to the refresh button sits a data-freshness chip. The five families are fed by a sync rather than by a live view, so "when was this read" is a question that comes before "refresh it".

Clicking a row opens the record card, and there is no side drawer. A row with no name does not open at all, and the row says why rather than looking inert for no visible reason.

Permissions

Family	View	Edit	Export
Virtualization	virt.view	virt.edit	virt.export
Storage systems	storage.view	storage.edit	storage.export
Cloud accounts	cloud.view	cloud.edit	cloud.export
Container clusters	containers.view	containers.edit	containers.export
Backup & protection	backup.view	backup.edit	backup.export

One key per family rather than one key for all of infrastructure — an organization that bought storage and did not buy containers has to be expressible. The five view keys and the five export keys are an operator's default; no edit key is.

Editing here means editing the inventory inside the product. It changes nothing in the management plane, in the storage system, or at the cloud provider.

On the connection map

Infrastructure records are nodes on the connection map, and the edges are named: Stores on, Replicates to, Member of, Runs on, Backs up, Terminates on.

A storage system that is also in the equipment register carries the same record key in both registers, so the map folds it into one node and the two cards link to each other. Nobody should meet two cards for one machine with nothing saying it is the same machine.

The product reads from inventory sources and never writes back — see Architecture.