🚧 Early alpha — building the foundation. See the roadmap →
Challenge 40: Control, risk, or obligation as the backbone entity?
Why this exists
Section titled “Why this exists”“Assess once, comply many” implies one canonical thing you assess once. The KB implies that thing is the control. But three candidate backbones exist, and they correspond to the three teams:
- Control-centric (security/control ops) — atomic unit = control; requirements and risks attach to it.
- Risk-centric (risk management / ISRM) — atomic unit = risk; controls are mitigations, requirements are drivers.
- Obligation-centric (regulatory/compliance) — atomic unit = obligation/requirement; controls are evidence of satisfaction.
Picking one as the backbone privileges one team’s worldview. Picking wrong forces the other two to bend their mental model to yours.
What we already have
Section titled “What we already have”| Asset | What it gives us |
|---|---|
| Control-centric vs obligation-centric compliance | The two lenses already named; this adds the risk lens and forces a choice |
| Unified risk model | The current shared-entity set (control, requirement, risk, asset, vendor, process, finding, evidence, incident) |
| Hierarchy primitives · Terminology | The vault primitives + vocabulary any backbone must express |
| SSSOM · STRM | The edge metadata + set-theoretic relation vocabularies the backbone’s edges rely on |
| ETL & import (schema-as-primitive) · System architecture | Where the backbone lands in the engine; what “backbone-agnostic schema” would mean |
| v0.1 schema spec | The Tier 1 contract a backbone choice must fit |
What to investigate
Section titled “What to investigate”- Single backbone vs typed-node graph. Is there one privileged entity, or a small fixed set (control, requirement/obligation, risk) joined by typed edges where no node is privileged? What does each cost in query complexity and in onboarding each team?
- Model each candidate end-to-end. For control-, risk-, and obligation-centric: show how the same real question (“does our incident-response control satisfy DORA Art. 17, NIST CSF RS, and CRI’s incident diagnostics, and what risk does it reduce?”) is expressed and answered. Which model answers all three lenses cleanly?
- Edge semantics. Whatever the backbone, the edges carry the meaning (satisfies / mitigates / requires / evidences / equivalent / subset). Confirm the STRM set-theoretic + SSSOM edge vocabularies cover the needed relations across all three lenses.
- Asymmetry of “assess once.” Does “assess once” actually mean assess the control once? Or assess the risk once and inherit? Or evidence the obligation once? The phrase may quietly assume the answer.
- Schema implication. State what the chosen backbone means for the Tier 1 schema — node types, required edges, and whether the schema should be backbone-agnostic (express all three, privilege none).
Deliverable shape
Section titled “Deliverable shape”- A recommendation: single backbone entity or a typed-node set with no privileged node — with the reasoning.
- A worked example answering one cross-lens question under each model.
- The concrete Tier 1 schema implication (node/edge types).
Anti-patterns
Section titled “Anti-patterns”- Defaulting to control-centric because the KB leans that way.
- Forcing risk and compliance teams into a security-team mental model.
- Treating “assess once, comply many” as self-evidently control-shaped.
- Ignoring that the edge vocabulary may matter more than the node choice.
Success criteria
Section titled “Success criteria”- A clear, defended backbone decision (or a defended “no privileged node”).
- Cross-lens worked example that a fresh reader finds convincing.
- An explicit Tier 1 schema consequence.