🚧 Early alpha — building the foundation. See the roadmap →

Ontological foundations of the Unified Control Assurance and Risk Model

Created Jun 1, 2026

Why this log

The driving goal is a unified model for the security / GRC / risk / internal-audit problem domains — one shared substrate that Governance, Risk, Compliance, and Internal Audit all operate on. Before building it (ingestion → mapping over the framework corpus), the foundational categories were pressure-tested from first principles. The result is a small, precise ontology that explains why the model has the shape it does — and a guiding constraint: prudence, pragmatism, first principles; no scope creep, no over-engineering.

Three plain-language anchors used throughout (the rest of the doc assumes no philosophy background):

Ontology = what kind of thing something is; what sort of existence it has.
Epistemology = what we know and how sure we can be; the status of claims and beliefs.
Telos = what something is ultimately for — its purpose, as distinct from what it is.

Telos vs ontology — and why this ultimately serves flourishing

The apparatus has a purpose, and at the level of telos it is simple: controls reduce risk, assurance gives justified confidence that they do, and the whole system exists to protect and attain the organization’s objectives — ultimately its flourishing (and, scaled up, the common good). That purpose is real and worth stating plainly. It is not, however, the same axis as ontology — and conflating the two is the error that makes “it’s all just risk reduction” feel true yet useless for building anything.

ONTOLOGY

what it is

The kind of being: a control is a mechanism, a risk a potentiality, an obligation a duty, an assurance a claim. Structures the schema — keeps the kinds distinct so each team’s question stays answerable.

TELOS

what it’s for

The purpose: reduce risk, confirm it’s real, and ultimately protect and attain objectives — the organization’s flourishing. Frames the why — the mission the schema serves.

Structure by ontology; motivate by telos. The schema needs distinct kinds — so a compliance officer’s “is this duty discharged?” and a risk owner’s “is residual within appetite?” stay different, answerable questions. The mission needs the telos — so the distinct kinds add up to something. Two layers, no conflict.

The root is objectives, not risk-reduction

“Everything is risk reduction” captures only the defensive half — avoiding loss. Flourishing also needs the generative half — creating value, which means taking risk, not only reducing it. The mature frameworks bake this in: ISO 31000 and COSO define risk as the effect of uncertainty on objectives, which runs both ways — threat and opportunity. So the true root is objectives / value / flourishing; risk-reduction is its protective service, value-creation its generative one.

OBJECTIVES / FLOURISHING
the root — what the organization is for; what everything is measured against

↓ threatened and enabled by

RISK
threats — reduce

OPPORTUNITY
paths — take

↓ managed by

CONTROL — the mechanism that reduces risk and discharges duty

↓ confirmed by

ASSURANCE — independent confidence that it is real

The chain from the epistemic act (assurance) to the root (flourishing) — this is the sense in which assurance “ultimately accounts for risk”:

assurance→justified confidence→better risk decisions→risk reduced→objectives protected→flourishing

How the field actually structures it

This doesn’t have to be invented from scratch — and notably, the most integrated frameworks already root themselves in objectives, not risk:

Framework	What it puts at the center
COSO ERM (2017)	Value / objectives — risk = the possibility events affect achievement of objectives; explicitly about value creation and preservation
OCEG GRC (Red Book)	Principled performance / objectives — “reliably achieve objectives, address uncertainty, and act with integrity”
ISO 31000	Risk — but defined as “effect of uncertainty on objectives” (bidirectional)
NIST RMF (800-37 / 800-39)	Risk management process; control = the response to risk
Control catalogs (800-53, ISO 27002, CIS)	Controls — the catalog is the structure; risk implicit
Regulatory / compliance	Obligations / requirements
IIA / internal audit	Risk-based assurance — audit where the risk is

The pattern: the mature, integrated frameworks (COSO ERM, OCEG GRC) center on objectives / value / flourishing; the operational ones center on whatever they operate (risk, controls, or obligations). Rooting this model in objectives/flourishing is therefore both the most first-principles direction and the one with the strongest precedent.

Key definitions (ontologically precise, one line each)

Term	Definition
Objective	What the organization is trying to achieve — the value everything else is measured against (the reference point).
Risk	A possible future event, weighted by likelihood and impact, that matters because it affects an objective — part real hazard, part knowledge-estimate.
Obligation	A standing duty that binds you to act — “must, because an authority commands it,” independent of your own risk calculus.
Control	An actual mechanism that operates to manage a risk and/or discharge an obligation.
Audit	The independent, evidence-based act of adjudicating whether a claim matches reality, producing a finding.
Assurance	The genus audit belongs to — the manufacture of warranted confidence in a claim for someone who must rely on it but cannot verify it themselves.
Finding	A persisted assurance assertion — audit’s judgment about a control / risk / obligation (the one thing audit writes).
Governance	The internal authority (board / executives / policy) that sets objectives, risk appetite, and internal obligations.
Compliance	Adherence to external obligations (laws, regulations); one species of obligation, not the genus.

The core ontology — five kinds of being

The categories cannot be collapsed into one node type because they are different kinds of existence:

Category	What kind of thing it is	Mode of being	Verb
Objective	the value everything is measured against	the reference point	”want”
Risk	a possible, graded, goal-relative, half-known event	potentiality (world ∩ mind)	“might”
Obligation	a standing duty that binds	actuality — deontic	”must”
Control	a mechanism that operates	actuality — mechanism	”does”
Audit / Finding	a claim about whether the above is true	knowledge (epistemic)	“is it so?”

This table is the bedrock argument for no privileged backbone node (see Ch 40): forcing a value, a potentiality, a duty, a mechanism, and a claim into one type destroys the distinctions that let the model answer real questions.

Two modes of normativity: risk (prudential) vs obligation (deontic)

“Normativity” = the kind of “ought” / reason-for-action behind something.

Risk is prudential — “you should act, because of consequences to your objectives.” It is discretionary: you can rationally accept a risk. Risk acceptance is a legitimate treatment.
Obligation is deontic (duty-based) — “you must act, because an authority commands it, even if it doesn’t reduce your risk or serve your objectives.” You cannot “accept” an obligation the way you accept a risk; non-compliance is a breach, not a treatment.

The “even if” test is decisive: a true obligation binds even when it raises your risk or costs you objective-attainment (file the 72-hour breach notice; retain the record 7 years). The asymmetry that proves they are distinct sets: you can satisfy every obligation and still be wide open to risk (“compliant but breached”), and you can manage every risk and still be in breach of a formality unrelated to risk. Neither set contains the other → they are not the same thing. They overlap heavily (most obligations exist because someone judged them risk-reducing) — but overlap ≠ identity.

Different satisfaction conditions follow: risk is lowered toward a threshold (a magnitude); obligation is binary discharged (met or breached).

Obligation ≠ compliance (the source dimension)

Obligation is the genus; compliance (regulatory) is one species. Obligations sort by authority-source:

Source	Who imposes it	Sits under	Example
External — regulatory/legal	legislators, regulators	Compliance	DORA 72-hr notice; HIPAA
External — contractual	counterparties	Legal / vendor mgmt	”encrypt customer data per the MSA”
Internal — governance	board / executives / policy	Governance	internal password policy; mandated training; risk-appetite directives

This is why it’s GRC and not just R-C — the G is the internal source of obligations. An executive mandate is a real deontic obligation (“must, because the board said so”), but it is not “compliance” in the regulatory sense — it’s Governance.

The endogenous/exogenous nuance:

External obligations are exogenous — handed to you; you can only comply or breach.
Internal obligations are endogenous — the org imposes them on itself, often as a governance or risk-treatment decision. The org can rewrite its own policy; no one can rewrite a statute. Who holds the pen is the deepest internal/external difference. But once set, an internal mandate is fully deontic for those bound by it.

Schema consequence: obligation stays one node type with an authority_source attribute (internal-governance | external-regulatory | contractual) — so Governance queries its internal mandates and Compliance queries external duties, both distinct from Risk, all discharged by Control.

Risk is the strange one (where ontology meets epistemology)

Risk is the least “thing-like” category. It is uniquely:

Possible, not actual — about an event that hasn’t happened and may never (modal). Everything else is a fact; risk is a potential.
Parasitic / relational — it cannot exist without an objective it bears on. The same event (rain) is a risk to a picnic, an opportunity to a farmer, irrelevant to a submarine. Risk is uncertainty that matters to a goal, not a standalone object.
A magnitude, not a state — likelihood × impact; you have more or less and reduce it toward a threshold.
Future-pointing — obligation binds now, control runs now, a finding judges the past; risk alone aims at what hasn’t occurred.
Bidirectional — modern risk (ISO 31000 / COSO) is the effect of uncertainty on objectives, which can be threat or opportunity. Nothing else has an “upside.”

The deep one: risk is half in the world, half in your head. The hazard is real (ontological); “the risk” — the rating — is your probability estimate, which depends on what you know (epistemological). Knight’s 1921 distinction sharpens it: risk = uncertainty you can put believable odds on; (Knightian) uncertainty = uncertainty you can’t. So risk is a hybrid of a real possible event and your imperfect knowledge of it — the one category that straddles the ontology/epistemology line.

Flag for schema design: because risk is so relation-like (parasitic, graded, half-epistemic), it is the node that is most secretly an edge/overlay. We reify “risk scenarios” as nodes for practicality, but ontologically risk is almost a weighted field over the whole graph. Keep that in mind when modeling it.

Audit & assurance — epistemic in mode, risk-protective in purpose

Audit is second-order: it doesn’t operate controls or reduce hazards — it independently adjudicates whether a first-order claim matches reality, producing justified belief (a finding) for someone who relies on the claim but didn’t do the work.
Assurance is the genus: the manufacture of warranted confidence across a trust gap; it exists only because of information asymmetry — the agent who did the thing and the principal who must rely on it are different people.
Orientation (two axes — see telos vs ontology): in its mode (what it is) assurance is epistemic, not risk reduction — what it directly reduces is information risk, the meta-risk that what you believe about your risk system is false. In its telos (what it’s for) it serves risk reduction and ultimately objectives/flourishing: better-justified beliefs make better risk decisions. Both true; the error is conflating them.

The through-line: risk management changes the world; assurance changes what you are entitled to believe about the world. Audit is the epistemology of the control system, not its physics — it asks “is this true?”, not “is this safe?”.

Precise relation to risk: audit adjudicates claims to assure not against risk but that risk and obligation are under adequate control — so what it assures is the trustworthiness of the control system, the one object that risk, compliance, and audit all orbit.

Internal audit is therefore a hybrid, not a backbone owner (see Ch 41): by professional independence (IIA Standard 1100 / the Three Lines Model) it cannot own the controls/risks/obligations it assesses. It is a lens that reads and tests others’ entities, plus a producer of requirement sets (the IIA Topical Requirements enter the model as just another framework). The only first-class thing audit needs is the finding.

Control earns the center

Two different modes of normativity — prudential (risk, “might/should”) and deontic (obligation, “must”) — converge on one mechanism, the control (“does”), whose reality is then attested by audit (“is it true?”), all in service of objectives (“want”).

              OBJECTIVES                ← teleology: what you're trying to achieve
            /     |      \
   GOVERNANCE    RISK    COMPLIANCE     ← G + C = obligation (deontic, by source)
   (internal    (pru-    (external          R = risk (prudential)
    duty)       dential)  duty)
            \     |      /
               CONTROL                  ← the single act that discharges internal duty,
            (the mechanism)               risk, AND external duty — the convergence point
                  |
                AUDIT                   ← epistemic: independently attests it's real
            (writes Finding)

Control is the center not because it is privileged as a node type, but because it is the one place where governance mandates, risk mitigations, and compliance requirements all land as the same act. That justifies the chosen name “Unified Control Assurance and Risk Model” — its three words name the three useful practitioner lenses (next section): Control (the act), Assurance (the audit stance toward it), Risk (the prudential domain it serves). Governance and Compliance fold into Control (their obligations are satisfied by controls). “Unified Risk and Audit Model” was rejected as a category error — it conjoins a domain of hazards with an epistemic stance toward claims and silently drops the obligation backbone.

The useful perspectives — how audit & GRC actually operate the substrate

The five kinds of being are the foundation (why the categories are distinct). On top of them sit the useful working perspectives practitioners actually use — and they are exactly the three words of the name. Each is a lens over the same shared substrate, with established frames worth modeling explicitly. (Researched 2026-06-01; sources at the end of this section.)

Control — the GRC-operational lens (“implement once, satisfy many”)

The control is the unit of work; the payoff is reuse.

Common-control reuse: one control satisfies many obligations/frameworks — the crosswalk payoff and the whole point of common-control libraries (SCF, OSCAL).
Control function type: preventive / detective / corrective (+ directive), and which one matters — preventive & detective controls reduce likelihood; corrective controls reduce impact. Maps onto NIST CSF functions (Protect / Detect / Respond-Recover).
Control objective → control → control activity hierarchy; controls provide reasonable assurance over the three classic objective categories (operations, reporting, compliance).
Obligation coverage: which duties (internal-governance | external-regulatory | contractual) do we owe, and does a control satisfy each? Governance and Compliance live here — their obligations are discharged by controls.
Substrate: control —satisfies→ obligation, control —mitigates→ risk; control carries a function_type attribute.

Risk — the risk-management lens (“buy risk down to appetite”)

Modeled on the ISO 31000 process (scope → assess → treat → monitor → report).

Inherent → residual: residual = inherent risk reduced by control effectiveness; the movement between the two is the measure of how well controls work.
Risk appetite / tolerance: appetite applies to residual risk — if residual exceeds tolerance, escalate or treat further; residual within appetite must be formally accepted by a risk owner, documented, and monitored. (This is the prudential discretion obligations lack — you can accept a risk; you cannot accept a breach.)
Treatment options: avoid / transfer / mitigate / accept — only mitigate creates controls; the other three are legitimate non-control responses.
Substrate: risk carries inherent + residual grades + a treatment decision; the control —mitigates→ risk edge carries effectiveness.

Assurance — the audit lens (“is it real, and is it covered?”)

Design vs operating effectiveness: design = could the control work, judged at a point in time (SOC 2 Type 1); operating = does it work reliably over a period, tested by sampling (SOC 2 Type 2). Two distinct states on the same control — the single most useful audit distinction.
Assurance coverage (combined assurance / assurance mapping): for each key risk, who provides assurance and when — surfacing coverage gaps (no one looks), duplication (several do the same), and single-point vulnerability (one partial provider). The “are we testing the right things?” lens (IIA Standard 9.5, coordination & reliance).
Findings lifecycle: observation → finding → remediation → follow-up → closure — the audit output that feeds back into the substrate.
Substrate: control carries design_status + operating_status; finding —concerns→ control/risk/obligation; assurance coverage is a query over which findings/tests touch each risk.

Synthesis: one substrate, three useful lenses. Control reuse + obligation coverage (GRC-operational); inherent→residual against appetite (risk management); design/operating effectiveness + coverage + findings (assurance). The name Unified Control Assurance and Risk Model names exactly these three — and they map cleanly onto node attributes (function_type, inherent/residual/treatment, design_status/operating_status) and typed edges (satisfies, mitigates, concerns), so the practitioner perspectives are queries over the schema, not separate models.

Sources: design vs operating effectiveness · inherent/residual + control effectiveness + appetite · combined assurance / assurance mapping · preventive/detective/corrective control types · ISO 31000 risk treatment options

Emerging direction (from Ch 39–41) — not yet locked

Topic	Emerging position	Status
The spine	No engine-level spine. “Spine” is a per-profile view over a peer mesh of typed edges; the Tier-1 schema is the only load-bearing contract → the decision is reversible config, not architecture.	strong
CRI’s role	FI-only profile / authority-of-record, not the universal spine.	strong
Default general hub	NIST CSF 2.0 (outcomes) + 800-53 (controls); SCF/STRM as a local-only mapping accelerator + optional reconciliation hub.	candidate
Backbone	No privileged node; a small typed set (control, risk, obligation, + asset/vendor/process/finding/evidence/incident) joined by typed edges. Control-/risk-/obligation-centric are views.	strong
Audit	Lens + requirement-producer; only new first-class type is Finding (already in the entity list).	strong
Name	Unified Control Assurance and Risk Model — names the three useful practitioner lenses (Control / Assurance / Risk).	chosen

Scope-creep guard (deferred / rejected — keep it pragmatic)

Full OSCAL adoption (Catalog/Profile/SSP/Assessment/POA&M) → defer to v0.1.7 exporter work; keep only the existing junction-note ↔ OSCAL by-component isomorphism.
FAIR / Open FAIR risk-quant subgraph → defer until a user needs quantified risk.
RDF/OWL vs LPG substrate debate → already settled (files-as-graph + SQLite sidecar); do not reopen.
MDM / “golden records” entity-resolution layer → overkill; the practical core (ID normalization, AC-2 vs AC-02) is already a known ETL step.

Open decisions (need user sign-off before the formal write-up)

Default profiles (general hub; FI = CRI profile) and the first crosswalk to build as proving ground.
Whether to graduate this ontology + the useful-perspectives layer into a concepts/ taxonomy page now or after the model is built.
Process the Ch 39–41 deliverables formally (publish to zz-research/, archive briefs, update the unified risk model page) — currently held.

Challenges: 39 — the spine · 40 — backbone entity · 41 — audit role + naming
Unified risk model — the model this reshapes (CRI to be demoted to FI profile)
Control-centric vs obligation-centric compliance — the prior framing this deepens (adds the risk + governance modes)
Security & GRC framework corpus — the data this model will be built over
ETL & import (schema-as-primitive) — why the spine is a profile, not the engine
Terminology · Problem · What makes Crosswalker unique