Systems register

A system is what the organization actually owns; the servers are only how it happens to run. The business rating, the suggestions, the collision engine, the update cadence and the connections graph all hang off the system name — which is why it is an asset in its own right and not a string on a server row.

Two views, one table

Under the title is a view switch:

• Register — every system, by owner, criticality, servers and coverage.
• Ownership attestations — the same systems, sorted by who still owes an answer. A red badge on the tab counts the systems nobody has confirmed.

This is a view, not a second page: clicking a row in either opens the same system record. Each view keeps its own saved views, columns and filters — filtering on attestation state and filtering on coverage are not the same question.

The columns

Eight are shown by default; the rest are available behind the columns button.

Column	What it says
System	The name. Additional names captured as aliases are counted beside it
Criticality	The business classification — see below
Owner	Who is responsible. An account that is not active in the directory is marked
Servers	How many servers are assigned
Update coverage	The share of servers whose due date has not passed
Stale servers	How many are past it
Ownership attestation	The state of the periodic attestation
Data completeness	How many of the weighted fields on the record are filled
Open vulnerabilities · Databases · Equipment	What else depends on the system
Lifecycle · Origin · Tags · Environments · Tier · Manual membership	Classification and deployment

Criticality

Value	Meaning
Critical	The most severe business classification the system carries
High
Normal
Unclassified	Nobody has classified it yet

"Unclassified" is not "unimportant." It is its own filter bucket, it is painted in a muted tone rather than red, and the descending sort puts it last rather than first. Otherwise, the moment the business-classification source is unavailable, the whole register would jump to the top of the list — exactly when nobody would think to check.

Update coverage

The share of assigned servers whose next due date has not passed. A server with no last-update date at all is counted separately and not folded into "stale": that is usually a data-collection problem rather than a missing patch, and merging the two produces a number the infrastructure team can fairly dismiss.

Ownership attestation

An attestation is the periodic question "is this system still your responsibility". It is answered on the system record itself, in the Ownership tab.

State	What it says
Approved	The owner confirmed. The counter resets until the next attestation date
Awaiting approval	The date has arrived and has not passed — 30 days ahead of it
Overdue	The date passed and nobody answered. That is an open question, not "no data"
Never done	No attestation has ever been asked for this system

"Never done" is not painted as a fault. It is not the owner's failure, and a list that is entirely red on day one is a list nobody works through.

Three answers are possible: Confirmed ownership, Not my responsibility, and System has been retired. Only the first resets the counter — the other two are recorded in the history while the system keeps appearing as awaiting an owner, because it still lacks one. Each answer can carry a note.

The next attestation date follows the criticality: twice a year for a critical system, annually otherwise. The intervals are configurable, and an interval of zero means "never" — a legitimate answer, not "unset".

Lifecycle, origin and tags

• Lifecycle: planned · build · production · sunset · retired.
• Origin: discovered in a sync (the name appeared in the inventory) or declared manually.
• Regulatory tags: SOX, Directive 364, Amendment 13, PCI DSS, critical infrastructure. They filter and they export.
• Manual membership: whether the system's server list was set by hand or derived from the inventory.

The system record

Tabs: Summary · Ownership · Servers · Databases · Connectivity · Maintenance · System dossier · Documents · Personal · History.

• Editing is per field, under the same contract as the server record: an immediate on-screen update, an explicit message when the save was not written, and a comparison dialog rather than an overwrite when two people edit together.
• Renaming does not orphan the record. The old name is kept as an alias, so values, relations and events recorded under it keep resolving to it.
• Beside the fields the module ships you can add custom fields of your own.

Who may do what

Permission	What it allows
View systems register	The register, owners, coverage and the record
Answer an ownership attestation	Recording an answer
Edit system	Creating and editing a record, aliases, membership and declared dependencies
Merge and split systems	Operations that change the identity every other module joins to
Export systems	Exporting the register and the attestation report