For Compliance · the method
How we solve it.Piece by piece, with provenance.
How one control spine answers many regimes — the crosswalk method, and where the genuine deltas come from.
The exhibits
The working surfaces behind the answer.
Living maps live on the Controls reference — one instrument home for spine and crosswalk. Open the block you need; come back here for the method story.
Assess-once standards mapAICM · CCM · AISMM → regimesFoundation and AI deltaAISMM roll-up · CCM inheritanceSkill-mediated regimesPrivacy and payments leverageAICM domain mapThe control spine itselfPiece 1
One spine
Inputs
- The CSA AICM: 18 domains, 247 control objectives, reconciled verbatim against the CSA source at every build
Mechanism
- Every control question lives in exactly one domain (a MECE partition, machine-enforced); every regime is a lens onto that partition, never a second catalog
Outputs
- One implementation surface — controls get built once, evidenced once
Provenance: lib/aicm-taxonomy.ts + the validate-mece build gate; CSA attribution preserved verbatim.
The deeper layer — named here, shown in a walkthrough
- The partition rules and the rationale for the intentionally empty domains
Piece 2
The crosswalk & the real deltas
Inputs
- 3 regimes mapped authoritatively (AI-native) and 5 inherited through the CCM bridge
Mechanism
- Each regime maps to the spine with a gap profile: fully covered, partially covered, genuinely uncovered
- Inherited (pre-AI) frameworks additionally carry an AI-delta: the AI-only controls they never reach — that delta is your genuinely new work
Outputs
- Per-regime coverage plus a named delta list — what you already satisfy, what needs a mapping argument, what is new
Provenance: lib/standards-crosswalk.ts, generated from the CSA source files and guard-checked.
The deeper layer — named here, shown in a walkthrough
- The control-level mapping table itself — which objective satisfies which clause of which regime
- The delta lists per inherited framework, control by control
Piece 3
Who owns each control
Inputs
- The SSRM (Shared Security Responsibility Model) read of every objective
Mechanism
- Each control resolves to provider-owned, shared, or deployer-owned — so audit effort lands only on what is actually yours to evidence
Outputs
- An ownership split you can hand to an auditor next to the coverage read
Provenance: The SSRM ownership map, rendered at /library/ownership.
The deeper layer — named here, shown in a walkthrough
- The per-control ownership assignments and the contested-boundary notes
Piece 4
The reskilling list
Inputs
- The Track 2 reskilling master list: 247 AICM controls, each attributed to one persona owner with a skill verb and a capability prompt
- Your saved diagnostic answers, where a run exists: the same answers Track 1 scored
Mechanism
- Controls that run the AI audit, honor the privacy obligations, assure the supply chain, map the regulations once, and keep the people side compliant resolve to compliance as primary
- Track 2 is the diagnostic inverted: a control absent or breached in a function’s answers is re-read as the named skill this role acquires. No second scorer, no second instrument
Outputs
- 45 controls resolving to this role across 5 skill groups — a named skill list: direction and next rung, never a complete how-to
Provenance: tools/reskill-persona-map.json → lib/reskill-master.ts (owner sample-review approved 2026-07-17); gaps join in lib/reskill-deltas.ts.
The deeper layer — named here, shown in a walkthrough
- The per-control attribution table for this role and the judgment notes on boundary controls
Piece 5
The stack & instruments
Inputs
- 16 published instruments in three lanes — 14 testers, 3 corpora, 5 controls — validated at every build
- Python 3 stdlib-only tooling — nothing to install to reproduce a claim
Mechanism
- Control-lane instruments evidence objectives directly — the artifact an auditor sees names the instrument that produced it, so evidence reuse across regimes is mechanical, not argumentative
- Lane integrity is machine-enforced: an instrument never grades its own lane, and nothing on this site says "tested" without a named instrument behind it
Outputs
- A named, reproducible instrument behind every tested claim you read here
Provenance: lib/tools-registry.ts, guarded by validate-tools in the prebuild chain; instrument detail renders in the /controls drill.
The deeper layer — named here, shown in a walkthrough
- The per-instrument wiring: which tool validates which skill, and which tool grades which instrument
- Acceptance thresholds per tester lane