AO coverage. Addresses all six System Baselining objectives: baseline established [a] and covering hardware, software, firmware, and documentation [b]; baseline maintained across the life cycle [c]; inventory established [d] and covering the same four categories [e]; inventory maintained across the life cycle [f].

Baseline as code [a][b]. Each system role has a baseline expressed as Ansible roles plus a written specification in the same repository. The specification covers the hardware model and configuration the role assumes, the software package set with pinned versions, the minimum firmware level (BIOS/UEFI, switch and array firmware, endpoint TPM), and the documents that belong to the baseline — the role specification itself, its network diagram, and its hardening rationale. Documentation lives beside the code so a baseline version means one identifiable set of settings and papers.

Inventory of record [d][e]. NetBox holds devices, virtual machines, roles, owners, life-cycle state, serials, and firmware level. Software inventory is collected by osquery and joined to the device record; the firmware fields are populated from the same collection rather than typed in by hand, which is why they are now accurate. Every record links to the baseline version it is supposed to match and to its documentation set.

Maintenance across the life cycle [c][f]. Baseline changes go through the change process described in the CM.L2-3.4.3 example and produce a new version tag (vYYYY.MM). Procurement and decommission both write to the inventory: nothing is racked without a record, and retirement flips life-cycle state and links the sanitization ticket. A nightly reconciliation compares observed hosts against the inventory and files a ticket for anything present but unrecorded, or recorded but absent for 14 days.

Maintenance. Nightly reconciliation with ticketed exceptions; quarterly review that each active role still has a current baseline version and that its documents were reviewed within the year; post-upgrade re-diff of the running configuration against the role definition.

Accepted gap. Two shop instruments run vendor-supplied images we may not modify, so their baseline is the vendor's documented configuration plus our isolation and monitoring requirements. They are inventoried with firmware level and vendor documentation reference, and flagged so nobody assumes our roles apply to them.

• Repository showing role definitions, pinned versions, and baseline specification documents
• Inventory export with hardware, software, firmware, and documentation links
• Baseline version tags with the change tickets that produced them
• Nightly reconciliation output and a resulting ticket
• Vendor-image exception records with their isolation requirements