Home / Vaults / Risk Graph Explorer / The seven views
The seven views, explained
One set of answers, seen from seven altitudes. This page walks each view of the Risk Graph Explorer with a screenshot of the live vault and an explanation grounded in the author’s own walkthroughs — because the reasoning behind a view is rarely visible in a picture of it.
Screenshots are of the live vault under the Exposed preset, captured with the published read key. Open it yourself from the vault page and follow along.
Every answer becomes a fact, and the graph is the evidence
This is where answering happens, and the first thing to notice is that a "no" is still information. From the walkthrough: "if you don't have an agent, then we only have one piece of information here — but this is a fact."
The questions walk a deliberate path: what the agent is, what data is in its reach, whether its output decides about a person, what it can do with that data (cannot see it · reads it · reads and changes it), whether it can change production, how it is stopped, who may stop it, how long stopping takes, whether stopping was ever tested, what it can reach if it misbehaves, whether it has outbound access, whether the damage is reversible, whether there is a written procedure, whether the actions could be reconstructed, and whose account it acts under.
Each answer lands as an F-nn fact chip, and the graph draws the relationships between them — amber for exposure, green for assurance, ghosted for nobody has said either way. That last one matters: an unanswered question is drawn as an absence rather than silently treated as a pass.
The same technical answers, weighed against what is at stake
Context is the view that makes the app's core claim enforceable. The technical answers can be as alarming as you like; if nothing is behind them, little follows. The header carries the verdict in plain language — decides about a person · in production · at stake — and those three phrases are what turn a list of facts into a register worth reading.
This is the difference between a risk tool and a checklist: a checklist scores the agent, this weighs the agent against the estate it runs in.
The org chart, with risks flowing up it
The view the author calls "crazy powerful", and the header states its invariant outright: every risk is assigned to somebody, and every risk reaches the board.
Read the counts under each role and you can see the two modes the walkthrough describes. The CISO shows 14 assigned · 14 through; the CTO 4 assigned · 25 through; the board simply 37 arrive here. Assigned is what you personally hold. Through is what arrives because the risk graph says it must — "he arrives because of the risk graph says so". The SRE holds a set; the platform owner inherits those and adds its own; the CTO inherits everything below and adds its own; the CEO connects the dots.
The consequence is the one worth quoting: "no risk then becomes orphaned, because every risk will flow upwards, and that's super important." An owner cannot be surprised at the top by something nobody carried up.
Risks that cause risks, and the ability to walk it backwards
The second graph, and a different question: not who holds this but what produced it. Columns are levels — inherent at the left, operational rising by causal depth, and the corporate register pinned to the right, because that is where the question stops.
Click any entry and it colours what produced it (upstream) and what it produces (downstream). The walkthrough uses it in both directions: "if you go to 'led by' at the bottom, you arrive at the bottom of the risk; if you go 'leads to', you're navigating upwards." So a corporate-level entry can be interrogated — "why is it? It's because we have that one, and that one, and this one" — until you reach the specific answers that caused it.
One detail that only an honest tool ships: a dashed edge is a cycle, and the cycles are real. Rather than hiding a loop that the model does not like, it draws it.
The familiar artefact — with its provenance attached
This is the output most organisations already recognise: a risk register. What is different is that every row carries where it came from. Per the walkthrough: "for every risk that you have here, you can see who's assigned, who causes it, and who leads to, and how does it connect."
A conventional register is a list of assertions someone typed. This one is a projection of the graph — which means it cannot contain a risk that nothing produced, and it cannot lose a risk that something did.
Nobody can accept on anybody else’s behalf
Acceptance is where the register stops being a document and becomes a decision. Each role holds what it holds and must accept it personally — and the author is explicit that this is where the value shows up: "everybody that is going to accept it is going to push back."
That pushback is the feature. The walkthrough contains a live example of the author disagreeing with his own tool — "I actually don't agree with these risks… I don't buy that" — and the point is what happens next: because every risk is fact-derived, the disagreement resolves into which fact is wrong rather than whose opinion is louder. "The cool thing is that we start to have the evidence to show exactly why we are saying this."
Decisions become incidents and projects
The last view closes the loop. Acceptance is not the end of a risk; it is a commitment that produces consequences — the things that will happen if the exposure materialises, and the work that would change it.
In the parent vault this is where a board refusal funds a project that flips the whole graph to the safer option. Here it is the same mechanism in miniature: the register does not merely describe a position, it names what follows from holding it.
The same estate, at three settings
The presets are the fastest way to feel what the tool actually does. These are the role risk map for the same organisation under three different sets of answers — nothing about the org chart changed, only what is true about the agent.
A typical deployment
An agent is present and the estate is ordinary. Risks exist, they are held, and they reach the board — but the shape is contained.
The same estate, governed
Approvals, a tested stop, a named authority, bounded reach. From the walkthrough: "you have the govern, we can see it's a much cleaner sort of flow of events." The risks do not vanish — they arrive with far less weight, and by shorter paths.
This is the argument the whole tool exists to make. The register is not a verdict on whether you should run an agent; it is a picture of what you are carrying, which changes when the controls change.
Why this workflow is powerful
| What it does | Why it matters |
|---|---|
| Answers are facts, and facts are cited | Every risk traces to the specific answers that produced it. Disagreement becomes "which fact is wrong", not "whose judgement wins" |
| No risk is orphaned | Every risk is assigned and every path terminates at the board. Nothing can sit in a register held by nobody |
| Assigned is distinguished from inherited | A role sees what it personally holds and what merely passes through it — two very different conversations |
| Acceptance is personal and cannot be delegated | The register becomes a set of decisions with names on them, and the pushback that follows is the point rather than a failure |
| Cycles are drawn, not hidden | A model that shows its own loops is one you can argue with |
| Nothing is at stake ⇒ a short register | The output scales with exposure, which is what separates a register from a checklist |
| It runs in a vault, in your browser | No account, no upload, no network call. The answers you give about your estate never leave the page |
The last row is what makes the rest publishable. A tool that asks these questions is asking for an unusually candid description of your weakest controls — and this one can be handed to somebody as a read key that carries the whole application, with nothing to send anywhere.