What belongs in a machine-readable crosswalk mapping one check to clauses in several frameworks?

## Why the crosswalk is a file and not a spreadsheet The mapping between checks and framework clauses is a claim you will be asked to defend, sometimes a year after you made it. That makes three properties non-negotiable: it must be **diffable** (what changed and when), **attributable** (who decided), and **resolvable** (does the identifier it names still exist). A spreadsheet gives you none of the three. A structured file in the policy repository gives you all three for free, using the review machinery the rules already use. ## The anatomy of one edge Regardless of format, an edge carries: 1. **Subject** — what is being described. A service, a platform component, a control implementation. Not "the company". 2. **Framework and revision** — not "NIST 800-53" but the specific catalog document you mapped against. Revisions move identifiers; an unpinned mapping cannot be checked later. 3. **Clause identifier** — the id as the catalog spells it. 4. **The check** — the identifier of the rule whose results answer the clause. Without it, the edge is an opinion; with it, a failing result can be routed. 5. **Strength** — whether the check fully answers the clause or only part of it, from a closed vocabulary rather than free text. 6. **Owner** — a human who decided, and who is asked when it is disputed. ## How OSCAL expresses it OSCAL, the Open Security Controls Assessment Language, splits the problem into layers. The controls layer holds **catalogs** (a framework's controls as structured data) and **profiles** (a tailored selection of them — a baseline). The implementation layer holds **component definitions** and **system security plans**, which say how something implements controls. The assessment layer holds plans and results. A crosswalk of the kind this question asks about lives most naturally as a **component definition**. Its shape: - A `component` — your service, with a title and type. - One or more `control-implementations`, **one per framework**. Each has a `source`: a URI pointing at the catalog or profile whose identifiers the block uses. This is where the revision is pinned. - Inside each, `implemented-requirements`, one per clause, each with a `control-id` and a description. `props` and `links` let you attach machine-readable extras — the check identifier, a link to the rule, the edge's strength. So the same component appears once, and the framework-specific vocabulary is confined to its own block. Adding a fourth framework adds a fourth `control-implementations` entry; it does not touch the other three, which is exactly the property you want in review. ## The review that actually matters A crosswalk pull request is not a rubber stamp. A reviewer checks: - **Does the clause identifier resolve** in the pinned catalog? An id that no longer exists is the commonest defect after a framework revision. - **Does the named check exist and is it the one that runs?** A mapping to a rule that was renamed or disabled is worse than no mapping, because the report shows a heading with nothing behind it. - **Is the strength honest?** Full versus partial is a claim about what an auditor will find. Silence defaults to full in most renderers, which is how optimistic mappings get made by accident. - **Is a removal deliberate?** Deleting an edge makes a report look better. That should be as hard to land as deleting a test. ## What it is not The crosswalk is not enforcement. No engine reads it to decide whether to admit a resource or fail a build; the check does that, if it does it at all. Mapping a check to three clauses does not make it stricter, and unmapping it does not make a broken listener safe. It is also not the evidence. The edge says a clause is answered by a check; the record that the check ran, what it saw and what happened next lives elsewhere and is the thing an auditor actually samples. Confusing the map with the territory — presenting the crosswalk itself as proof the control operated — is the mistake that turns a good artifact into a liability.