A structured vocabulary for describing risk, independent of any one
system or domain.
The goal is a shared way to talk about risk that different systems and
people can reason about consistently — the same word meaning the same
thing whether it appears in a design document, a configuration, or a live
observation.
Why a shared vocabulary
Risk is normally described ad hoc: a single point of failure here, a
missed deadline there, a rate limit somewhere else. Each description lives
in its own dialect, in its own document, and can't be compared with the
next one. When two systems or two people describe risk differently, the
disagreement surfaces late — after a decision has already been made.
A risk ontology makes the description explicit so that:
- the same risk appears the same way everywhere it is discussed;
- risks can be aggregated across systems (a component with ten collated risks is different from one with a single risk);
- whoever is reasoning about a system can audit how its risks were stated, not just what they are.
Borrowed discipline
The approach borrows from the same discipline used elsewhere on this site:
make the structure explicit so the reasoning can be audited. A structured
vocabulary is not bureaucracy for its own sake — it is what turns a
collection of individual judgments into something that can be compared,
weighed, and reasoned about as a whole.
Status
Early design work — the vocabulary itself is still being shaped from the
risk patterns that recur across the systems this site describes.
Can we make risk easier to reason about? Help me challenge the model
A risk model is only useful if it holds up against real systems and real decisions.
I'm interested in talking to people who work with enterprise architecture, security, operations or risk management — especially those who have struggled to make risk information consistent across system boundaries.
If you have an example, a counterargument or a problem this might help solve, Contact me on Signal.