Crosswalk
Every concern in this wiki, the dimension that owns it, the controls that answer it, the recurring process where those controls get checked, and the program-maturity level by which they should exist. This is the traceability table an examiner asks for, and it is generated from the pages rather than maintained by hand.
Regenerate with scripts/gen_crosswalk.py. The concern, dimension, control and gate columns are
derived from front matter and links: a control appears against a concern if either page links to
the other, so a missing row means a missing link, a defect to be fixed in the pages rather than in
the table.
The level column is the exception and it is editorial. It reads the Day 1 / Day 2 / Day 3 ordering in sequencing onto the Crawl / Walk / Run scale the dimension hubs use, and it says by which level a control should exist at all, saying nothing about how good it needs to be. No framework supplies this mapping; it is an editorial judgment made here.
Two things sit outside the table. It says nothing about whether a control is working: that is what “how you’d know it’s working” on each control page is for. And a concern with few rows is not a well-covered concern; it is a concern with few linked controls, which for memory poisoning reflects a genuine shortage of controls in the field rather than an editing miss.