413
products in the shared catalog, each tied to what it does
66
functions (MFA, SIEM, firewall...) that link products to requirements
11
fields in one interview view: the inventory and its scoping answers together
7 of 12
assets in a realistic machine shop found a catalog match
The data model
One inventory row per system, a link into the catalog, and five later steps reading it.
Blue fields are computed and overwritten on every scoping run. The catalog is reference data, identical in every client base; the inventory starts empty in each one.
1
Record: one row per system
Typed during the interview, with the scoping answers in the same pass.
- Name the instance only when it needs one. One firewall is just its product name. Two of the same product get names that tell them apart ("CUI-enclave FortiGate", "guest Wi-Fi FortiGate"). Every reader falls back to the product name when Instance Name is blank.
- Link the product in the catalog, and record what the client actually uses it for in their words.
- Record how this client runs it. Deployment Model (self-hosted, IaaS, PaaS, SaaS, hybrid) is this client's choice for this instance. The catalog separately lists every model the product offers.
- Ask the scoping questions now, per system, while the client is in the room. Coming back for them means a second meeting.
All eleven fields sit in one view, "Inventory: scoping inputs (interview)". The order across the interview is 2a people, 2b inventory, 2c flows, then the 2d computation: "one long conversation recorded in several places". Flows come after the inventory because a hop can only point at a system that exists.
The scoping answers, and what each informs
| Field | Answers | Informs |
|---|
CUI Handling Intent | Intended / Capable but not intended / Not capable | CUI Asset, Contractor Risk Managed, Out-of-Scope |
Specialized Asset Type | The device types (IoT, OT, test equipment and so on), or an explicit "Not Specialized" | Specialized Asset |
Separation Claim and Separation Enforced By | Is it separated from CUI systems, and which control proves it | Out-of-Scope |
Restricting Policy | The policy statement that keeps CUI off it | Contractor Risk Managed |
SSP-Named For Requirements | The security requirements the SSP relies on it for | Security Protection Asset and Security Role |
Blank is safe: an unanswered row computes to Needs Review, never to Out-of-Scope. How the engine weighs these is on the data flow page.
2
Match: the catalog link
The link is what lets later steps reason about a product they've never seen before.
- Products link to functions, functions link to requirements. A requirement doesn't name vendors; it needs functions such as multi-factor authentication or log collection. So one catalog of 413 products, each tagged with the functions it provides, serves every client.
- One row per vendor product. A product that spans several functions is one row with several function links, not one row per function.
- FedRAMP status is checked, not assumed. A daily job re-checks every tracked FedRAMP claim against the FedRAMP Marketplace data published by GSA, then reports any product flagged FedRAMP Authorized that no confirmed claim backs, and any confirmed authorization left unflagged. It never changes the flag; a person does.
- New catalog rows are verified one at a time against the vendor's own page, with the date checked recorded on the row.
When the client's system isn't in the catalog
The link isn't required, and the steps that reason by function simply skip an unlinked row. That is safe for scoping, which falls to Needs Review, but it means the claim pre-fill and the evidence-request wording can't see that system.
What a realistic shop showed. Of 12 systems in a synthetic 42-person machine shop, 7 found a match. Two only matched a near miss (a Windows Server 2019 box linked to a 2012 row; a Veeam backup server linked to Veeam's Office 365 product). Five had nothing: the CNC controller, the CAM workstation, guest Wi-Fi, the multifunction printer, and QuickBooks. The catalog was built as a catalog of security tools, and an inventory is a catalog of assets.
The rules for the inventory import, when it's built
- Never silently drop a row. An unmatched system goes to a review queue, not a filter.
- Never silently guess a match. Record the match confidence; a low one goes to the same queue.
- Import the inventory fields only. The scoping answers stay blank, so every imported row computes to Needs Review until someone asks.
- Keep provenance visible. A client's list is what the client told us, on that date. Shadow IT, shop-floor equipment and MSP-managed systems are usually missing from it.
3
Feed: what reads each row
Five later steps, each reading a different part of the row.
| Step | Reads | What it does with it |
|---|
| Data flows (2c) | The row itself | Each hop's source and destination point at inventory rows |
| Scoping engine (2d) | The scoping answers, the product's functions, the flows | Writes Scoping Category, Security Role and a Rationale sentence |
| Claim pre-fill (2e) | Product → functions, compared with the functions each requirement's evidence needs | Proposes "Implemented", "Partial" or "Not Implemented" as the weakest kind of claim, for the client to confirm |
| Evidence requests (4) | Product → functions | Replaces {{technology}} with the client's own tool names. If no tool provides the function, the placeholder stays and the request is flagged "No inventoried tool provides..." |
| SSP (7) | Every row, its category, rationale and deployment model | The system environment table, grouped by category; cloud services drawn inside the boundary |
The pre-fill is a starting point, not a finding: in the synthetic run the client corrected 24 of 44 inferred claims. That is why it is ranked below anything the client says.
Decision log
The calls that shaped the inventory, and when they were made.
| Decision | Why | When |
|---|
| Inventory rows link to a shared catalog; client data stays in the client base | The same reference-versus-client split used everywhere else | 2026-07-19 |
| One catalog row per vendor product, many functions each | A product spanning functions was duplicated once per function | 2026-07-19 |
| Deployment options on the product, deployment model on the instance | What a product offers and what this client runs are different questions | 2026-07-19 |
| Scoping answers live on the inventory row | Flows settle only two of the five categories; the rest need type, intent and SSP answers | 2026-07-20 |
| Import rules: never drop, never guess | Structured input looks authoritative even when it's a guess | 2026-07-20 |
| Separation claim plus the control that proves it | Out-of-Scope needs separation, and separation needs proof | 2026-07-22 |
| Client edits arrive as proposals, never direct writes | A status flag on the live row can't cover an edit or a delete | 2026-09-04 |
| FedRAMP flags checked daily against Marketplace-confirmed claims | A vendor's claim is not an authorization | 2026-09-28 |
Known gaps
- Hand entry only. There is no import from a client's inventory spreadsheet yet, and typing the inventory is the largest manual step in an engagement.
- The catalog is thin on ordinary assets. Whether a client system may stand unlinked with an explicit type, instead of being forced onto a near miss, is still open.
- No client upkeep yet. A worksheet or portal editor for the client to keep the inventory current is logged, not built, and nothing notices when an inventory stops matching reality.
- No FIPS certificate link per system. The certificate records live in a separate reference base, and cross-base links aren't supported, so linking a system to its validated module is still undecided.
- The FedRAMP flag isn't used for scoping yet. Cloud endpoints are recognized by name pattern and flagged for review; the flag itself is only checked, not read, by the scoping step.
- The Separation Claim wording misleads. On a segmented machine that still receives CUI, "logically separated" reads as true; it means separated from CUI systems. A careful operator got it wrong twice.