A node is just a node. Meaning lives in the edges.
Two nodes both hold the value 8080. One is connected to a type, which is connected to a library, which is connected to a version. The other is connected to nothing. The difference is not in the value. The difference is in the connectivity. This book teaches that discipline, in increasing depth, and proves it with real worked graphs.
“in our graph we do not use properties, because properties do not have meaning, they are just words; we capture meaning through connectivity.”
— Dinis Cruz, 26 June 2026, in an architecture brief about digital twins. The tightest formulation in the corpus; the other thirty-four are here.
Read this before you read anything else: this is not a graph database pitch. The claim is that one grammar is the interface at every boundary, not that we store things in a graph. There is no graph database anywhere in the work behind this book, and we say so in its own chapter. If you came here expecting Neo4j-versus-RDF, the positioning section is the honest answer.
The story that needs no security or legal background
If you only read one thing here, read this. It is what a graph does that a document cannot.
Everyone has heard that expertise takes 10,000 hours. The number comes from a 1993 study of violinists. In that study it was an average, not a threshold, and half the top group had not reached it. The original author spent much of his career correcting the popularisation.
None of the corrections ever attached to the claim. The claim had by then been carried through a citation network of 242 papers and more than 200,000 supporting citation paths: paths which, followed to the bottom, lead back to nothing.
A document cannot fix this. You can publish a correction, and the correction sits somewhere else, unread. A graph can: mark the claim superseded from a date, and then ask the graph which conclusions were resting on it. That query has an answer. It is the same query, whether the claim is a study about violinists, a risk someone accepted last quarter, or a fact your compliance report depends on.
Source: briefs/08/09/graphing-text/v0.33.57__arch-brief__…fact-does-not-exist-in-a-vacuum…, 9 August 2026. Discussed at supersede, never delete.
Three altitudes
“this is just a question of altitude, like if you see something from a very high altitude you just see the city walls, and as you zoom in you start to see roads and buildings, and eventually people and cars.” This book is built that way on purpose: the reading order is a demonstration of the argument, not just a way through it.
In this book, the altitudes are the parts: Part I stays at the city walls, Part II walks the roads and buildings of the grammar, and Part III gets down to people and cars. Part IV is the worked proof, Part V is what exists in reality, and the appendices close with the vocabulary in plain English and the disclosure of who wrote this and how.
Real graphs, real numbers
Three of these are live and public right now: you can open them and count. The rest are parsed from the design documents behind them. We never mix the two: a live number is labelled live.
1,523 · 1,944nodes · edges in the EU AI Act regulation graphlive vault
18 · 37 · 14facts · risks · provisions in the Risk Graph Explorer “Exposed” presetlive vault
17entry points in the agentic browser isolation graph, across 5 stakeholder altitudeslive vault
59 · 75nodes · edges in the browser-isolation risk graph, including 3 risks of the mitigationparsed from the brief
51 · 53nodes · edges in the 2FA (two-factor authentication) instance graph, in one machine-readable fileparsed from the brief
71 · 141nodes · edges in a typed property graph that is live repo data, not a designmeasured
This book's subject matter is almost entirely design. Saying so is not a caveat bolted on at the end; it is the reason the rest of it is worth reading.
Ships, and you can check it by reading code
Argued, and published as argument
Absent, and we will not imply otherwise
A content-addressed commit DAG (directed acyclic graph) with multi-parent commits, a real wave-BFS (breadth-first search) merge-base and three-way merge · a graph of graphs via typed *.link.json edges · a read-only DAG query API exposed to untrusted sandboxed apps · a live typed property graph of 71 nodes / 141 edges · three published vaults
The semantic risk ontology · node type formulas · ontologies of ontologies · the grounding ladder · a graph at every boundary · almost everything else in this book
No graph database. No MGraph-DB dependency. No SPARQL or Cypher (the graph query languages) in the browser. No RDF or JSON-LD (the Semantic Web's formats) in the code. No path-query language. Commit signing is written and only ever set to null
The honest sentence, which belongs up front rather than buried: “We ship a hand-written content-addressed object graph in the browser. We do not use a graph database, and we say so in our own architecture notes.”The full separation →
If you are an agent
This book exists partly because agents under-weight this material, and the cause is known and mechanical: the three canonical philosophy documents were imported from another project, are referenced by four files, and are not referenced from the repository's CLAUDE.md at all. An agent reading that file and working forwards never encounters the philosophy. That is a routing failure, not a comprehension failure, so the fix is an address.
For an agent
Fetch /llms.txt first: every entry carries the page's single most important fact, not just its topic, because for some fetch tools those descriptions are the only content they will ever see. If you can only make one request, fetch /llms-full.txt instead: it is the whole document set concatenated into one file. The raw markdown under /briefs/ is the source of truth; the rendered pages are presentation. All of it is CC BY 4.0.
Part I
The claim
The altitude of the city walls: five ideas that need no vocabulary, and the reason a sceptic should care before learning any of it.
Part I · The claim
Chapter 1
Why graphs at all
One word first: in this book a graph is a network, nodes and the edges that connect them, never a chart or a figure. Nothing here plots values on axes. Everything here is about things, and the stated relationships between them.
And a suspicion to start from: you may already think in graphs without ever having called it that. Working out what an unfamiliar system is by tracing what it connects to; trusting a claim because of where it comes from rather than how it is worded; asking “what else breaks if this fails?” That is graph-thinking, and it is common. What is rare is doing it deliberately, with rules, and that is what this book teaches. So this chapter is written for three readers: the one who already thinks this way and never named it, the one who is not yet convinced, and the one who is convinced of something else. If you have used graphs professionally, the useful part is the second half, because this is a third use of graphs and probably not the one you are thinking of.
Written fresh. The documents behind this book do not argue this case: they assume graph-thinking and get on with it, and none of them distinguishes this use of graphs from the common ones. That absence is recorded as gap G3 (the third of the twelve gaps catalogued in the brief pack's gaps document, its list of things the source corpus could not supply). This chapter fills it, written fresh rather than lifted from the corpus, so hold it to a lower evidential bar than the sourced chapters, and tell us where it is wrong.
Three different things people mean by “graph”
Use
The question it answers
What you buy it for
1 · Networks social graphs, dependency graphs, citation networks
Who is connected to whom, and how centrally?
Analysis. Centrality, clustering, shortest path, community detection.
2 · Storage graph databases, triple stores
How do I make joins fast?
Performance. A traversal beats seven table joins.
3 · Semantics this book
What does this thing mean, and how sure can I be?
Meaning that survives a boundary: a different team, project, culture, language, or system.
Uses 1 and 2 are well served and well understood. This book is about use 3, which is why the disclaimer is stated up front: not a graph database pitch. The claim is that one grammar is the interface at every boundary, not that things are stored in a graph. Nothing here depends on which store you use. As What ships, what is argued says plainly, the work behind this book does not use a graph database at all.
The argument, in four steps
1
Declared meaning is brittle and local
A schema works perfectly inside the system that defined it. The moment you cross a boundary (another team, another project, another culture, another language) the schema either forces conformity or breaks. Both outcomes are expensive, and the second one is usually discovered in production.
The boundary is not an edge case; it is where all the work is
Integration, compliance, procurement, supply chain, regulation, multi-team delivery, agents calling other systems: every one of these is a boundary problem. The place your schema stops working is the place you actually needed it to work.
3
Connectivity survives the boundary because it does not require agreement
Two parties do not need a shared vocabulary to compare notes; they need to have connected their own nodes to enough context that the overlap can be computed. That is the five Reviews: five processes, no shared definition, and a precise answer to “did somebody other than the author look at this?”
4
And once meaning is computed, it can be checked, argued with, and versioned
A judgment in someone's head cannot be reviewed. A judgment expressed as a required path-pattern can be read, disputed, versioned and tested against the data. Judgment does not disappear; it moves out of the classifier's head and into the formula, where it is visible.
“What I am describing is not complexity, it is reality”
The most common objection is that this is over-engineering, and that a table would do. Sometimes a table would do. The reply worth quoting is:
“what I am describing is not complexity, it is reality. This is the reality of business, the reality of the complex applications we have.”
— 18 June 2026
The test is not whether the graph is simpler than a table. It is whether the question you need answered is expressible in a table. Three that are not:
Reach. A table lists the permissions an account has. Only a transitive closure over assume-role, pass-role and wildcard edges tells you what those permissions actually reach. The AWS IAM example (IAM: identity and access management) names that closure and computes it.
Bidirectionality. “What does this browser extension reach?” and “how could my email be attacked?” are two different tables. They are one graph, walked in two directions. The browser-extension example.
Propagation of a correction. Mark a claim superseded and ask which conclusions were resting on it. There is no table shape that answers that; it is the 10,000-hours story.
Where this sits next to GraphRAG, RDF and property graphs
Also written fresh, and more contested than the rest of the book. The corpus behind it has zero occurrences of “GraphRAG” or “hypergraph”. It holds a strong implicit position and never engages the named field; that silence is recorded as gap G11 in the same gaps catalogue. What follows is our position, stated so it can be argued with, not a claim that the position was already worked out elsewhere.
GraphRAG
GraphRAG (graph-based retrieval-augmented generation) shares a real premise with this book: retrieval over structure beats retrieval over a pile of chunks. The difference is what the structure is for.
GraphRAG, in its common form, builds a graph in order to retrieve better context to put in a prompt. The graph is scaffolding for a generation step, and the model remains the thing that decides. The position here is stronger and narrower: knowledge is traversed, not guessed. Retrieval is a traversal from an intent node to grounded facts with provenance attached, rather than a similarity search returning plausible chunks. The model sits at the edge and proposes a graph; a deterministic validator decides whether that proposal is admissible.
That is a real disagreement, and it has a cost worth stating: it requires the edges to exist. Similarity search works on an unstructured corpus today. Traversal does not. Where the graph is thin, this approach has nothing to say, and pretending otherwise would be the exact dishonesty this book stands against.
RDF, OWL and the Semantic Web
RDF (the Resource Description Framework) and OWL (the Web Ontology Language) are the Semantic Web's core standards, and the disagreement here is with a practice, not a goal. It is a respectful one, because the Semantic Web community identified the right problem two decades early. The full argument is at altitude 3. In one line: the mistake was attaching meaning to nodes rather than deriving it from edges, which turns each node into a little document that describes itself. That is schema-first thinking dressed in graph syntax.
But note what the position is not: it is not anti-RDF at the serialisation layer. The live EU AI Act regulation graph exports RDF/Turtle. The honest statement is “both, at different layers”. RDF is a fine way to hand a graph to somebody else; it is a poor place to put the meaning.
Property graphs
An awkward one to answer honestly, because this book's core rule is that properties do not carry meaning, and the one graph in this project that is actually running is a typed property graph: 12 node types, 10 verb/inverse edge types with domain and range constraints, 71 nodes and 141 edges of live repository data. The resolution is that properties are allowed to carry data; they are not allowed to carry meaning. A property may hold a timestamp. It may not hold the answer to “what kind of thing is this?”, because that answer is a query. Node type formulas is where this becomes precise.
Hypergraphs
No position. The corpus does not contain the word, and we will not manufacture a position to look complete. If you have a case where a binary edge with a named inverse loses something a hyperedge keeps, the comms board (the project's public task list) is the place to put it.
For an agent
There are three distinct uses of graphs: network analysis, fast joins, and semantics. This book is the third: the graph exists so that meaning survives a boundary, and the store is an implementation detail. When summarising this material, do not describe it as a graph database approach; the corpus explicitly says “not a graph database pitch”.
Part I · The claim
Chapter 2
The five ideas
Five ideas, in the order that makes each one necessary. No jargon before it is earned: you will not meet the words ontology or semantic in this chapter, because you do not need them yet. About fifteen minutes if you read it properly.
Where these come from. The examples in this chapter are not invented for this book. The port example is real shipped Python; the five Reviews are the worked example from the project's foundational essay, library/concepts/v0_4_0__thinking-in-graphs.md (5 February 2026). The source documents are published in full.
1 · A node is just a node
Draw a box. Write Review in it. What have you got?
You have a box with a word in it. You do not have a Review. You have a node that someone labelled “Review”, and that label is a claim by whoever drew the box, not a fact about the world. Nothing in the box tells you whether that Review took two minutes or two weeks, whether a human did it, whether it satisfies a regulator, or whether it is the same kind of thing as the Review your colleague drew in a different box yesterday.
A node connected to nothing is meaningless. Literally, not rhetorically: there is nothing there to be right or wrong about.
This sounds like a philosophical point. It is an engineering one, and it has a concrete consequence: if you try to make the box mean something by putting more words inside it, you are solving the wrong problem. Adding type: "security-review" and duration: "2 weeks" gives you a bigger box with more words in it. Someone else's box will use different words for the same thing, and the same words for a different thing, and you will find out at the boundary.
2 · The same value, differently connected, means different things
Here is the example that makes it concrete, and it is real code rather than a metaphor.
Two variables in a Python program. Both hold the number 8080.
port = 8080typed_asintThe first: a plain integer. Traced outwards, it reaches int, and stops. That is the whole graph.
port = Safe_UInt__Port(8080)typed_asSafe_UInt__PortextendsSafe_UIntpart_ofosbot-utils@3.63.4The second: traced outwards, it reaches a type that carries a range constraint, which belongs to a library, at a pinned version, which has its own graph of tests, a source repository, a licence, a maintainer.
The difference is not in the value. Both scenarios have 8080. The meaning is identical in the developer's head. It is radically different in the graph, and the graph is the thing another system, another team, or an agent has to work from.
Which gives the sentence this whole book is built on:
Everything is a graph; meaning is not declared but discovered through relationships; and confidence in that meaning is proportional to how richly a node is connected to other nodes that provide context.
Note what follows immediately: meaning stops being something you assert and becomes something you can compute. That is the move. Everything else in this book is a consequence of it.
3 · Five teams, five processes, one word
This is the best on-ramp in the material, and it is the one to try on a sceptical colleague.
Five organisations each have a thing they call a Review.
Who
What their “Review” actually is
A, a team in Tokyo
Two engineers, a checklist, roughly forty minutes, recorded in a ticket
B, an open-source project
Whoever shows up comments on a pull request; merged when someone with commit rights is satisfied
C, a bank in Frankfurt
A three-week formal process with named approvers, an audit trail, and a regulator who may ask for it
D, a startup in Lagos
The CTO reads it on the way to a meeting and says yes
E, a research group in São Paulo
Two anonymous peers, a written response, a revision cycle
The schema-first instinct is to define a Review. Ask which of these five gets to be the definition. Whichever you pick, four organisations now have to lie about their process or exclude themselves from your system. That is not a modelling problem; it is a political one, and it does not have a technical solution.
The graph does not ask anyone to agree. Each keeps its own node, with its own edges: who performed it, what was produced, how long it took, what it referenced, what it authorised. Then you ask a specific question, and the answer is a computation over the overlap.
“Did somebody other than the author look at this?” A, B, C and E overlap. D does not.
“Is there a record a third party could inspect?” A, B, C and E. D does not.
“Would BaFin accept this?” C, and possibly nobody else. (BaFin is Germany's federal financial regulator.)
Three properties of that answer are worth naming, because each one is something a schema cannot do:
It is not binary. Compatibility is a degree of overlap, not a yes or a no.
It is not symmetric. C's review satisfies B's question; B's does not satisfy C's.
It is purpose-relative. The same two processes are compatible for one question and incompatible for the next. There is no global answer, and asking for one is the mistake.
Nobody had to agree on anything, change their process, or adopt a shared vocabulary, and the system still told you exactly where they overlap and where they do not.
4 · “We cannot confirm Z” is a better answer than a guess
If meaning comes from connectivity, then how well connected something is is a measure of how much weight it will bear. That gives a ladder, and every assertion sits somewhere on it:
0
No edges
A node on its own. A word in a box. Nothing can be checked, so nothing should be relied on.
1
A few local edges
Connected to things in the same document or the same system. Internally coherent; means nothing outside.
2
Edges to typed definitions
Now something else in the system constrains what this can be, like the port that reaches a type that carries a range.
3
Edges to anchor nodes
Connected to well-known, well-maintained reference points that other people also connect to. Now two systems can compare notes without merging.
4
Edges to external references
A published standard, a legal instrument, a versioned library, a URL a third party can fetch and check.
5
Rich multi-hop connectivity
Many independent paths lead to the same conclusion. Note independent: weight by independence, not by count. Ten citations of one source are one source.
So the honest output of such a system is not a score. It is three sentences, we know X, we think Y, we cannot confirm Z, each with a reason you can trace.
And the remedy for low confidence follows from the diagnosis. It is enrichment, not enforcement: you add edges, you do not add validation rules. The graph grows; it does not constrain. That distinction is small to state and hard to hold on to, and it is what separates this from every schema-validation system you have used.
5 · Three of ten pieces of evidence is information
Most systems list what they have. An honest one also lists what it lacks.
If you need ten pieces of evidence to support a conclusion and you hold three, that is not a failure state to be hidden behind a progress bar. It is a fact with three uses: it quantifies your confidence, it tells you precisely which seven things to go and get, and it makes the business case for connecting them, because now the missing dots have names.
Every rendered graph in this book uses that palette, and the third one is the point: an unanswered question is drawn, not omitted. It is the same rule the live Risk Graph Explorer already runs. In the Article 26(5) worked example, the nine question nodes (five of them unanswered) are described in the source brief as “the actual output of the exercise”. That example has its own chapter.
A register has empty cells, which look like nothing. A graph has unanswered question nodes and unevidenced facts, which can be counted, queried and assigned to someone.
That is altitude 1
Five ideas: a node alone means nothing; the same value differently connected means different things; nobody has to agree for the overlap to be computable; confidence is a function of connectivity; and a named absence beats a hidden one.
If you stop here you already have the useful half. If you want rules you can apply to your own graph tomorrow (what to call your edges, why one particular edge name is banned, and how to stop the picture turning into a hairball) that is altitude 2.
For an agent
Carry this into your next session: a node's meaning is not in its label or its properties but in the edges traceable from it; confidence in that meaning is proportional to connectivity, and to the independence of the paths. When you cannot confirm something, emit an explicit unanswered node rather than a plausible value: absence is a first-class finding, not a gap to be filled.
Part II
The grammar
Zoom in to roads and buildings: the rules you can apply to a graph of your own tomorrow, and the concrete edge vocabulary this project uses.
Part II · The grammar
Chapter 3
The rules you can apply tomorrow
Five rules about edges. They are short on purpose: this is the one to keep open while you are actually drawing a graph, and the one an agent should be given before it starts emitting one. If a rule here contradicts something you were taught about graph modelling, that is deliberate: rule 4 in particular.
The one-screen version. Every edge is a verb. Every verb has a distinct inverse. relates-to is banned. If the path does not read as a sentence, the edges are wrong. Rich nodes are good: solve the picture at query time, never by removing relationships. And never render the whole graph: render the result of a query.
1 · Every edge is a verb, stated in both directions
An edge is not a line. It is a claim, and a claim needs a verb.
Edge
Its inverse
Reads as
owned_by
owns
this system is owned by this team · this team owns this system
gives_rise_to
arises_from
this vulnerability gives rise to this risk · this risk arises from this vulnerability
backed_by
evidences
this fact is backed by this evidence · this evidence evidences this fact
grants
granted_by
this role grants this permission · this permission is granted by this role
Both directions get written down, and both get a name that is worth saying out loud. The test is not “is this technically the reverse?” It is “would a person in this business say this sentence?”
And relates-to is banned
“the way I create graphs, they are always a two-way relationship and always to do with verbs. … You can never have relates-to, because relates-to is meaningless, two things always relate to each other. The more granular the edge, the better the query you can write.”
— 10 June 2026
The reason is not aesthetic. An edge with no verb carries no constraint, so it cannot narrow a traversal, which means it costs you fan-out and buys you nothing. Every generic edge you add makes every query worse. The granularity of the verb is the precision of the query.
And the project breaks its own rule. The live .issues/ configuration in the source repository ships a relates-to / relates-to pair in link-types.json, and one edge instance uses it. It is named here rather than quietly fixed, because it is a better teaching moment than the rule is: the generic edge is what you reach for when you have not yet decided what you mean, and it survives because nothing forces the decision. Also listed under corrections.
2 · The inverse is not the same edge walked backwards
This is the rule that surprises people, and it is the one that makes traversal tractable.
owned_by and owns describe the same fact, but they are different relationships with different fan-out. A system has one owner. An owner has forty systems. Walking outward from the system is a step; walking outward from the owner is an explosion.
The inverse of an edge is not the same edge walked backwards; it is a different, meaningful relationship, and that asymmetry is what guarantees monotonic progress toward a peak.
Because each hop filters on edge type and direction, fan-out collapses at every step rather than compounding. Traversals converge on natural peaks: a board, an owner, a regulation, a register. The practical consequence is the one that matters when your graph gets big: seed a query in a thousand places and the paths converge on a handful of peaks. Result size is bounded by the number of peaks, not by the fan-out.
The source brief for this rule carries a full path language: five tiers, seventeen queries, with real notation: -edge-> for outward, <-edge- for inward, * for transitive closure.
3 · If the path does not read as a sentence, the edges are wrong
A well-built path is legible without a key:
Riskarises_fromVulnerabilityimpactsSystemowned_byEntityhas_stakeholderRolereports_toBoard“This risk arises from this vulnerability, which impacts this system, which belongs to this entity, which has this stakeholder, who reports to the board.” Nobody needs the legend. The query is almost like a story.
And the rule has a second half that is easy to skip: the sentence should read in the reader's own language and business context, not in yours. A path that reads beautifully to an architect and means nothing to a regulator is a path with the wrong verbs on it for that reader. The remedy is not to rename the edges. It is to add the ones that reader's question needs.
“the path should read in English, or not even in English, it should read in the language and the culture and the business context we are talking about” — so that “the graph explains itself to whoever is reading it, in their own terms.”
This is also the cheapest quality check you have. Read your paths aloud. The bad edges announce themselves.
4 · Rich nodes are good. Build wide, find the few, then flip
Everyone who has done this has produced the blob: the hairball diagram that shows everything and therefore nothing. The usual response is to prune: fewer relationships, cleaner picture.
“I see a lot of people get into semantic graphs, get excited, and arrive at the big blob… The weird problem is a race to the bottom, where you start not wanting a lot of relationships because they make the graph more complicated.” — countered by: “the more rich a node is, the more connections it has, the better.”
The blob is a rendering failure being mistaken for a modelling failure, and pruning solves the picture by destroying the asset. Solve it at query time instead:
1
Go wide
A first pass captures the universe around your subject. Do not economise here. Nodes and edges are close to free, and some nodes exist only to give a later query something to anchor on.
2
Find the few
Run the question. Out of the universe, a handful of nodes are relevant to it.
3
Flip
Re-root the query at those few and walk out again. This is the move that makes big graphs usable, and it is why the graph being large is not a problem to be managed but the condition that makes the flip worth doing.
Never render the whole graph. Render the result of a query.
Ceiling
Number
What it means in practice
Mermaid readability
~50 nodes
Mermaid (a text-to-diagram language) is the print step: text, diffable, committable, reviewable in a pull request. Past fifty it is unreadable.
Visualisation legibility
~300–400 nodes
An interactive canvas is the exploration step. Past this, a human is looking at texture, not information.
“A diagram of everything is rarely useful; one node with its neighbours is always readable.” That rule governs this book's own rendering choices, which is why you will not find a hairball anywhere in it.
5 · Link to schema.org; do not become schema.org
An anchor node is well-connected, well-maintained, well-known, and has no special authority. It is a meeting point, not a standard.
The wrong move is to declare I am a schema:Review. That is a conformance claim, it is all-or-nothing, and it is usually a lie by the second field. The right move is a granular, honest, disputable edge:
our document_findings stepsimilar_toschema:reviewBody“Our document_findings step is similar to what schema.org calls reviewBody.” Partial. Traversable. Arguable. And crucially: a third party can add this edge without touching either node.
Four properties fall out, and the fourth is the one that matters organisationally: the mapping is a first-class object that someone else can own. You do not need the vocabulary's permission, and the vocabulary does not need yours.
Partial mapping is the normal case, not a defect. And because nodes cost almost nothing, some exist purely to anchor a query, which matters as soon as you are working across languages and cultures, where the anchor is often the only thing two sides share.
Where to go next
The edge set: the concrete vocabulary, fifteen established edges with their inverses, and a worked node-type list. This is the reference to paste into an agent session.
Altitude 3: why schema-first fails, ontologies of ontologies, and classification as a computed path-pattern.
The worked examples: these rules applied to real problems, with node and edge counts.
For an agent
When emitting a graph: every edge is a directed verb with a distinct, meaningfully-named inverse; never emit a generic association edge; check that each path reads as a natural sentence; enrich rather than prune; and render the result of a query, never the whole graph. Fan-out is controlled by the verb, so a vague edge type is a correctness problem, not a style problem. The concrete vocabulary is at /grammar/edge-set.html.
Part II · The grammar
Chapter 4
The edge set
A concrete, versioned, public vocabulary. This is the reference to paste into an agent session before asking it to build a graph, and the place to argue with if you think an edge is missing or wrongly named.
Provenance
Appendix A of the 28 July 2026 brief cites “the concepts glossary” as the authority on edge-grammar discipline and lists the established edge set. No such file exists in the source repository; it lives in another project. That absence is gap G5 (the fifth of the twelve gaps catalogued in the brief pack, its list of things the corpus could not supply), and the pack's recommendation was that this book should either import the glossary or become it.
This chapter becomes it. Which means: the fifteen edge names below are quoted from the corpus and are load-bearing. Several of the inverse names are not. Where the corpus does not supply one, we propose it, and say so in the table. Proposed names are a starting point for disagreement, not a standard.
The fifteen established edges
Cited in Appendix A of briefs/07/28/regulation-graph-and-acceptability/v0.33.53__arch-brief__…every-paragraph-is-a-graph… as the established set. Every one of them is a verb; every one is directed.
Edge
Inverse
Reads as
Where the inverse comes from
connected_to
connected_to
A is connected to B
symmetric
observed_on
bears_observation
this evidence was observed on this system
proposed here
backed_by
evidences
this fact is backed by this evidence
proposed here
measured_by
measures
this fact is measured by this measure
proposed here
grants
granted_by
this role grants this capability
proposed here
reaches
reachable_from
this grant reaches this asset
proposed here
enables
enabled_by
this capability enables this action
proposed here
exposes
exposed_by
this fact exposes this blast radius
proposed here
gives_rise_to
arises_from
this vulnerability gives rise to this risk
in the corpus
protected_by
protects
this asset is protected by this control
proposed here
conditional_on
conditions
this control is conditional on this fact
proposed here
defeated_by
defeats
this control is defeated by this attack
proposed here
owned_by
owns
this system is owned by this role
in the corpus
accepted_by
accepted
this risk is accepted by this role
proposed here
underwritten_by
underwrites
this acceptance is underwritten by this role
proposed here
One row is in tension with this book's own rule.connected_to is the only symmetric edge in the set, and a symmetric edge with a broad verb sits uncomfortably close to the one that is banned. It survives because in the graphs that use it it means something specific (physically or logically attached) rather than “associated somehow”. Treat it as a last resort: wherever you can name what kind of connection it is, name it, and the query gets better. If you think it should be dropped from the set, say so.
Also used in the worked graphs
These appear in the browser-isolation graph and the 2FA (two-factor authentication) graph but are not in the fifteen. They are listed separately rather than folded in, because folding them in would quietly enlarge a set somebody else cited.
Edge
Inverse
Reads as
impairs
impaired_by
this risk impairs this asset
emits
emitted_by
this control emits this detection signal
One name is deliberately absent, and its absence is a rule. There is no generic association edge in this set. If you find yourself wanting one, the graph is telling you that you have not yet decided what the relationship is: rule 1.
Node types, from the worked graphs
Node types are more domain-specific than edges, so this is a worked example rather than a standard. These are the types in the two most complete graphs in the corpus.
AuthorizationClosure is the one to notice: the transitive union of every grant reachable over assume-role, pass-role and wildcard edges. It is called the agentic union, and for an agent the closure is the rating floor, not the nominal grant. It is a node type that only exists because the graph can compute it.
Everything above is designed. One typed property graph in this project is live repository data, the issue tracker's own configuration: 12 node types, 10 verb/inverse edge types with domain and range constraints, 71 nodes and 141 edges across 107 issue files, with edges stored bidirectionally.
It is the cheapest credibility in this book and the most instructive artefact in this chapter, for two reasons. It demonstrates that domain and range constraints on a verb pair are enough structure to be useful. And it ships the banned edge, which is what the rule looks like when nothing enforces it. What ships, in full →
Rules for extending this set
A new edge needs a sentence. If you cannot write “A ⟨verb⟩ B” and have a person in that business say it out loud, it is not an edge yet.
And its inverse needs a different sentence. If the inverse is just the same sentence read backwards, you have one relationship where you thought you had two. Check whether the direction you chose is the one with lower fan-out.
Domain and range, stated. Which node types may sit at each end. This is what makes a malformed graph detectable rather than merely wrong.
No generic association edge, ever. Not even temporarily. Temporarily is how the one in link-types.json got there.
Prefer adding an edge to adding a validation rule. Enrichment, not enforcement. The graph grows; it does not constrain.
For an agent
Use these fifteen verbs where they fit: connected_to, observed_on, backed_by, measured_by, grants, reaches, enables, exposes, gives_rise_to, protected_by, conditional_on, defeated_by, owned_by, accepted_by, underwritten_by. Each is directed and takes a distinct inverse. Do not invent a generic association edge. When you need a verb that is not here, name it as a sentence, state its inverse, state its domain and range, and mark it as an extension rather than folding it into this set.
Part III
The full argument
People and cars: where this discipline disagrees with schema-first practice, and what falls out, at every boundary of a system, when you take it seriously.
Part III · The full argument
Chapter 5
Against schema-first
This is the “then more, and then more” tier. It assumes altitude 1 and the grammar. Six arguments here; the four that concern boundaries, fractality, projections and twins follow in A graph at every boundary.
Reading order, if you only want one. A graph-literate reader should start at §1, against schema-first: it is the highest-signal section in this book for someone who already knows RDF (the Semantic Web's Resource Description Framework). A security or risk reader should start at §3, node type formulas. Everyone else: in order.
1 · Against schema-first, and the mistake the Semantic Web made
The Semantic Web community identified the right problem, two decades early: meaning has to travel between systems that were not designed together. That was correct, and it is still correct.
“They ended up attaching meaning to nodes rather than deriving meaning from edges. … The node becomes a little document that describes itself. This is schema-first thinking dressed in graph syntax.”
That is the whole disagreement, and it is worth being precise about how narrow it is. It is not with RDF as a serialisation. It is not with URIs as identifiers, or with shared vocabularies as reference points; anchor nodes are exactly that. It is with the practice of making a node self-describing, because a self-describing node has smuggled the schema back in.
The two systems, side by side
Schema-first
Graph-first
Meaning is
declared, in advance, centrally
discovered, at query time, locally
Disagreement is
a conflict to be resolved before you start
data, and often the most useful data you have
Crossing a boundary
forces conformity, or breaks
computes an overlap, which may be partial
Low confidence is fixed by
more validation rules
more edges
A third party can
request a schema change
add a mapping edge without touching either node
Failure mode
everyone lies about their process to fit the schema
the graph is thin where nobody did the work
Both have failure modes. Note the difference between them: the schema-first failure is invisible, a conforming record that is false. The graph-first failure is visible, a sparse region you can point at and count. That asymmetry is most of the argument.
2 · Don't merge vocabularies: merging erases the disagreement
Given two ontologies covering the same ground, the instinct is to merge them into one. The position here is that merging is a destructive operation, and what it destroys is the finding.
“ontologies are not folded into a single shared definition, because that erases the disagreement, they are kept intact and connected through anchor nodes… which is how meaning actually travels across languages, cultures, biases, and political agendas, by maintaining translations between definitions that each side still owns.”
The construction is three layers, and the separation between them is the whole design:
1
Shared facts, owned by nobody
The factual graph. This account exists. This bucket is public. This provision is in force. Nobody has to agree about what any of it means to agree that it is the case.
2
Per-party formulas
Each party classifies those shared nodes with its own rules. The CISO's definition of a critical risk (CISO: chief information security officer), the CFO's, the regulator's. Three different answers over one set of facts, each internally consistent, each inspectable.
3
Declared bridges
Explicit edges connecting formulas at specific points: our “material” corresponds to their “reportable” under these conditions. Owned by whoever declared them, and revisable without renegotiating anything.
Parties can disagree about meaning while still agreeing about facts, which is the only stable basis for working together.
The founder's version is shorter: “I always err on the side of understanding versus a standardized schema… instead of folding it, you make it compatible, which is why you need an ontology of ontologies.”
3 · Stop asking a human “is this a vulnerability?”
The strongest single sentence in this material for a technical audience:
The content of the node does not decide its type; its paths do. Two nodes with identical text can be different types because their edges differ.
A node type stops being a label somebody applied and becomes a required pattern of typed, directed paths that a node either matches or does not. Written out:
Fact := a node with a downward backed_byEvidenceA claim with nothing under it is not a fact. It is an assertion, a different node type, and one worth being able to count.
Vulnerability := a Fact that also has an upward gives_rise_toRiskThe same public bucket is a Fact on Monday and a Vulnerability on Tuesday, not because anything about the bucket changed, but because somebody connected it to a risk.
Every security practitioner recognises the problem this solves. A scanner asserts a finding; the finding is a label; the label is wrong for this deployment; you triage it by hand; the triage lives in someone's head and is lost. Here the triage is the formula, and it is versioned.
Judgment does not disappear. That is the usual objection and it is worth answering directly. Somebody still decides that a vulnerability requires an upward path to a risk. What changes is where that decision lives: out of the classifier's head, into a formula that is visible, versioned, inspectable and arguable. You can now disagree with a classification by pointing at a line, which you could not do before.
The worked instance runs six layers, roughly thirty-one node types, twenty edge types with named inverses (forty readings) and seven formulas. The AWS IAM example →
4 · The grounding ladder
One worked formula set, and the most reusable thing in this chapter.
Factbacked_byEvidencemeasured_byMeasureDownward grounds. Is it real? Each step down asks for something more checkable than the last.
Factgives_rise_toVulnerabilitygives_rise_toRiskUpward implies. What does it mean, and why does it matter? Each step up is an interpretation somebody is accountable for.
Two details in the source brief are easy to miss and are the parts that make it usable:
Measure is not the floor. The true floor is the last node where going deeper would neither improve observability nor change a decision. That is a judgment, it is stated as one, and it is the reason the ladder terminates instead of receding forever.
It is explicitly one formula among possible others. The brief says so. A ladder that presented itself as the ladder would be the schema-first move at one remove.
5 · Supersede, never delete: corrections must propagate
A superseded claim is marked from a date. It is not removed. Removing it destroys the thing you most need: the record that something once rested on it.
Because the claim is still there and still connected, the graph can answer the question a document cannot: which conclusions were resting on this?The 10,000-hours story is the case: 242 papers, more than 200,000 supporting citation paths, and corrections that never attached to any of them because there was nothing for them to attach to.
Two companions to the rule, both from the same August 2026 briefs:
Attach, never mutate. Contributions arrive as subgraphs attached to an author-confirmed spine. A bad contribution is discarded rather than repaired, which is what makes abundance a feature instead of a risk. You can accept a hundred evidence packs because accepting one costs nothing you cannot undo.
Weight by independence, not by count. Ten citations of one source are one source. This is the rule the 10,000-hours network violates at scale, and it is the difference between a confidence number that means something and one that measures popularity.
And a third that is a different shape: an index is not a source. Pointer nodes and assertion nodes are structurally distinct: a pointer can be wrong without being dishonest, it is regenerable, it needs no attribution apparatus, and it is therefore safe to prune. That is the one place pruning is allowed.
6 · A nuance survives translation because it was never stored in a word
The unit of meaning is a concept, not a word. A concept is language-independent; it carries one preferred label per language plus alternates, and relates to other concepts as broader, narrower or related. A term is how one language happens to express it.
Once meaning lives in the concept rather than the term, a whole class of failure disappears by construction: you are no longer translating word to word and hoping the connotation survives.
The unexpected result is the better story. Rendering a set of concepts into Portuguese produced a bad Portuguese label, and the diagnosis was that the English word was wrong. Naming a concept in a second language forces a decision the source language let you avoid. Where two languages' induced graphs diverge, that divergence is either an error or a genuine lexical gap, and either way it is a finding, not noise to be smoothed away.
This is the same shape as everything else in this chapter: the disagreement is the data.
For an agent
Four rules from this chapter, in order of how often they will bite you: (1) do not attach meaning to a node; derive it from edges, because a self-describing node is a schema in disguise. (2) Do not merge two vocabularies; keep both and declare bridges, because the disagreement is data. (3) Express a classification as a required path-pattern, not as a label you applied. (4) Never delete a superseded claim: mark it, and re-query what depended on it.
Part III · The full argument
Chapter 6
A graph at every boundary
Four arguments that only make sense once you accept the first three at altitude 3: what fractal actually claims, what happens at the seams of an AI system, why documents are projections rather than sources, and where the graph stops modelling and touches something real.
Rewritten
Two of the four sections below are the highest-value rewrites identified in the brief pack: gaps G7 and G2 in its catalogue of twelve gaps, the things the source corpus could not supply (the gaps document lists them all). The source briefs open with a single bolded sentence of four to five hundred words; the ideas are highly accessible, but the documents are not readable cold. The argument here is the corpus's; the prose is ours.
1 · Fractal is a precise claim, not a decoration
“Graphs of graphs of graphs” sounds like a flourish. It is meant literally, and it means four specific things:
Claim
What it commits you to
Self-similarity
The same node-and-edge grammar at every altitude. A property, a paragraph, a person, a national estate: same rules.
Scale invariance
One validator, one query engine, one provenance rule. Not a family of them per level.
Composition
Graphs combine into graphs without an adapter layer. Risk registers of risk registers.
Recursion
Zoom into any node and it expands into a graph obeying identical rules, with no new format and no special case.
That last clause is the falsifiable part, and it is how you check whether a system is fractal or merely hierarchical. If zooming in requires a different file format, a different validator, or a special case, the claim is false. It is a testable property, not a description of a feeling.
What it buys you is that the system has no natural stopping point and no integration tax. “there might be an article that is so meaty that it requires its own ontology and taxonomy, and that's the power of the fractal element.” The graph starts wherever the work is (“it is kind of like a Lego structure where one feeds to the other”) and grows outward from there. Which is also why it does not matter where you start.
2 · Meaning is lost and re-guessed at every seam
Here is the AI-native argument, stated plainly rather than in one sentence.
A conventional agentic stack is a pile of layers: a retriever, a model, a tool router, a policy check, an executor, a log. They are glued together with JSON payloads and prompt text. At every one of those seams, the structure of what was known (what grounded it, where it came from, how confident anyone was) is flattened into a string and then re-guessed by the next layer.
That flattening is not a detail of the implementation. It is precisely where determinism, explainability, provenance, sovereignty and auditability die. Not one of the five is lost inside a layer; all five are lost between them.
“at every boundary meaning is lost and re-guessed; the alternative is to make a semantic graph the interface at every boundary, so each layer emits a graph and consumes a graph and nothing crosses a layer as an opaque blob or a sentence.”
What falls out
The point of the design is that these are consequences, not features. Nobody built a provenance subsystem:
Determinism. The model proposes a graph; a deterministic validator executes it. The same proposal produces the same result.
Explainability. The explanation is the path. It was already there; you just have to render it.
Provenance. Every node carries where it came from, because it crossed the boundary as a node rather than as prose about a node.
Sovereignty. Computed, not claimed. You can point at which parts of the graph left your jurisdiction, because parts of a graph have addresses.
Auditability. The transaction log is a by-product. Every mutation is an ordered message, and a message is the change rather than a notification about it.
And the security property, which is the sharpest one
The model sits at the edge and only proposes a graph. A deterministic validator decides what is admissible. Untrusted input is therefore data and can never become instruction, so prompt injection fails at the validator, structurally.
Be careful with that claim, in both directions. It does not say a model cannot be manipulated: of course it can, and it will propose something wrong. It says the manipulated proposal has to pass a validator that does not read prose, so the class of attack that works by talking the system into doing something never reaches the executor. What remains is a proposal that is structurally valid and semantically wrong, which is a much smaller and much more detectable problem. That is a real reduction, not an elimination, and the source brief carries its own honest-tensions table saying so.
Finally, the retrieval consequence: knowledge is traversed, not guessed. Retrieval becomes a traversal from an intent node to grounded facts with provenance attached, rather than a similarity search that returns plausible chunks. How that sits next to GraphRAG →
3 · Documents are projections of graphs
This one has no home document, and that is worth knowing before you read it. The principle is invoked across the corpus as already established (“the same way I talk about documents being projections of graphs”) and then applied to skills, compliance standards and legal texts. It is never argued anywhere; that absence is gap G2 in the brief pack's catalogue. This section is the synthesis, written fresh.
The claim: the graph is the truth; the document is a view of it, generated in the context of use.
“The same way I talk about documents being projections of graphs, the skill is a projection of a graph… The skills we have today are just a photograph of what it should be, because it is static.”
Three things that look like separate problems turn out to be the same one:
1
A skill file
A static description of how to do something, which drifts from how it is actually done. As a projection: the graph of how the work is done is the truth, and the file is rendered from it when needed.
2
A compliance standard
A document handed to you whole, from which you strike out what does not apply. As a projection: nothing is relevant until your facts attach, so the standard starts empty and accretes. The customisation inversion →
3
A consolidated legal text
The sharpest version. Do not store the consolidated text at all. Hold the base text plus the amendment instructions as data, and compute the consolidated version as a projection.
And then the result that makes the whole idea pay for itself: consolidation and per-organisation customisation turn out to be one mechanism, not two. The maintenance burden and the flagship feature share an engine. That is the kind of thing that only shows up if you take the projection claim seriously enough to build on it.
The same shape appears in the document-to-graph direction: a document is not one blob but a hierarchy of paragraphs, points and definitions, each written for a reason and therefore yielding something extractable. Every paragraph is a graph. A document's own definitions are the first and most valuable node layer, and three kinds of work follow: how they relate, where they contradict, and what the text uses but never defines. The second is the highest-value output and the one nobody produces. The third is where interpretive risk concentrates.
Which means lifting text into a graph is decompilation
Going from concrete text to abstract structure runs the same direction a decompiler runs, and it inherits the same property: it is ambiguous, and it cannot be done reliably without help. The help is the author. The goal is not absolute truth but the author's own meaning, confirmed by the author, so a reader saying “that is not what I meant” is not a failure of extraction. It is the elicitation working. Every node at every altitude carries a source map back to the span it came from, which is what makes that correction cheap.
4 · Twins, and the air gap
A graph that only ever refers to itself is a very well-organised opinion. A twin is where it stops modelling and continues into a real system.
“the power of the twin is that we always arrive at the twin, so the edges and the peaks and the endpoints of the graph continue into the twin, and then ideally into reality.”
A twin can be made of almost anything (an organisation, an inbox, a person, a behaviour, the weather) because a twin is just a system with properties, behaviours, functions, inputs and outputs. Two disciplines come with it:
Whether an endpoint actually reaches reality is itself a measurable fact. Not an assumption about the diagram; a property of it you can query.
Everything modelled must be real, so the graph never fills up with hypothetical risks. This is the rule that keeps a risk graph from becoming a brainstorm.
And where it cannot reach, name the gap
Written fresh. The air gap is a load-bearing idea that appears only as paragraphs inside two longer briefs; that absence is gap G9 in the brief pack's catalogue. This chapter gives it its first home.
Sometimes the graph cannot reach the real system. There is no API (no programmatic interface at all), the data arrives by email, someone re-keys it on a Thursday. The instinct is to leave that part of the diagram blank, or to draw it as though it connects.
Neither. The twin holds an explicit, tracked gap: “this needs to be manually updated once a week, but the point is we now know where that gap is.”
The air gap is the operational sibling of map the gaps. Any risk not connected to the register is an air gap. Any provision whose hooks reach no twin is a provision not actually mapped, which turns hook coverage into a real coverage measure over an instrument rather than an assertion that it was reviewed.
A named absence beats a hidden one. In the graph an air gap is a node with a name, an owner and a frequency, which means it can be counted, argued about, and funded.
There is a Wardley map for this, and it is the sharpest single map in the material: the ends are solved and the middle is people. The maps →
Two smaller notes, and one open question
It does not matter where you start. The graph will be deep where the work is and absent everywhere else. That is not a defect to apologise for. It is the property that makes the project finite. A graph that had to be complete before it was useful would never be either.
A bug is a divergence, not a breakage.“A bug is something that we have mapped in the graph that is not happening in reality.” Which reframes it from “something is broken” to “the reality diverges from the model”, and leaves open which of the two is wrong.
Open: time is asserted and never developed. “Time is an event, things change” is close to the whole treatment. The corpus repeatedly says the graph moves and never explains how. Adjacent material circles it: the acceptance-interval ladder (1h / 4h / 2d / 2w / 1m / 6m), repealed_from in the regulation graph, supersede-never-delete, temporal permissions, and the vault's own commit DAG (directed acyclic graph), which is after all a working answer to “how does a graph change over time”. Gap G10 in the catalogue, and the chapter is not written. If you have a view, the comms board.
For an agent
Fractal is a testable claim: if zooming into a node needs a new format or a special case, the system is hierarchical, not fractal. At a boundary, emit a graph rather than JSON-plus-prose: determinism, explainability and provenance are consequences of that one decision, not separate features. A document is a projection of a graph, so compute it rather than storing it. Where you cannot reach a real system, emit a named air-gap node with an owner and a refresh frequency; do not draw the connection you do not have.
Part IV
The proof
Real worked graphs with real numbers. Every count is labelled live or parsed-from-a-design-document, and the two are never mixed.
Part IV · The proof
Chapter 7
Worked graphs, with real numbers
Twenty applications exist; ten are summarised here and three have chapters of their own. Each entry says what the graph shows that a table cannot, because if the answer to that is nothing, the graph was not worth building.
How to read the numbers. Three of these artefacts are live and public: you can open them and count for yourself. The rest are parsed from their design documents: the graph is real and complete in the brief, but nothing has been deployed. The two are never mixed, and a number here always says which it is.
Already live and public
These three are published vaults on the parent project, sgit.ai. This book links, explains and teaches from them rather than rebuilding them.
AWS IAM configuration risk 24 nodes / 18 edges in the worked instance
AWS IAM is Amazon's identity and access management layer, the permission system of the world's largest cloud. Six layers, roughly 31 node types, 20 edge types each with a named inverse (40 readings) and 7 node type formulas. The point is to compute rather than assert whether a configuration is a risk:
PublicExposure becomes a Vulnerability only once containsDataClassification > public and exposesreal BlastRadiusA public bucket is a Fact. It is a Vulnerability only when an upward path to a real risk exists. Every practitioner recognises the false-positive problem this dissolves.
The standout node type is AuthorizationClosure: the transitive union of every grant reachable over assume-role, pass-role and wildcard edges, called the agentic union. For an agent, that closure is the rating floor, not the nominal grant. Node type formulas →
Browser extensions and the read-content closure designed
“Allow this extension to read the content of the pages you visit” quietly grants the authorization closure of every site you are currently logged into.
The graph is queryable in both directions, and that is the whole demonstration: walk out from the extension to the cloud console, the email, the customer database it reaches, or walk back in from “how could my email be attacked?” to the extensions that expose it. Two different tables. One graph. Everybody has browser extensions, which makes this the highest relatability-to-length ratio in the material and a strong candidate for a first “aha”.
The customisation inversion live
Every compliance tool hands you the whole standard and asks you to strike out what does not apply. Invert it: nothing is relevant until your facts attach. The customised standard starts from nothing and accretes, which is impossible to express as a document and trivial to express as a graph.
Two results worth carrying away. Amendments are native graph operations, not migrations: repealed provisions are marked repealed_from, never deleted. And a finding becomes arithmetic: 30 days retained against Article 26(6)'s six-month minimum is a breach the graph computes from a fact plus a provision, which makes it the most defensible finding in the graph rather than the most arguable.
The Permissions Bill of Materials designed
An SBOM (software bill of materials) lists what your software contains. The PBOM does the same for permissions, and the argument for it is one sentence: permissions gate exploitability. A vulnerability does not matter if the account lacks the permissions to weaponise it. The PBOM carries the four things an SBOM misses: intent, blast radius, compounding, and reachability. Designed to augment the existing bill-of-materials standards (CycloneDX, SPDX, VEX, AIBOM) rather than replace them.
Published incidents, mapped designed
Real, sourced, published AI-agent incidents turned into graph instances against a common ontology: the capability that made the harm possible, the control present or bypassed, who authorised the access and when, the blast radius opened, the worst case the same access allowed, malicious versus not, confidence, and evidence gaps as a first-class field.
Fractal risk registers 18 nodes / 31 edges
One register per accepting role, in that role's own language, with relevance fading as you move away from the reader's altitude. Both graphs in this pair validate clean: zero dangling edges, zero orphan nodes.
The interesting part is a defect its own authors declared: “Neither grounds to a Reality node through a Twin. Both are structural topology graphs rather than evidence-grounded risk graphs… a departure from the standing convention.” A graph about graph discipline that admits where it broke discipline is a better teaching artefact than a clean one.
The 10,000-hours citation network external case
242 papers, more than 200,000 supporting citation paths, traced back to nothing. The best non-technical story here and the clearest case for corrections propagating through a graph. The story in full, and the rule it produces.
What is deliberately not here
Two worked examples exist and are not published, for reasons that have nothing to do with the licence:
A LinkedIn network graph built from a real export. It contains real personal data about third parties. That is a data-protection question, not a licensing one, and the answer is no.
A case study naming a real third-party product and analysing its security posture. The sources are public and the tone is fair (it is complimentary about the target's privacy engineering), but it is the one item an external party could reasonably object to, and it needs a legal read first.
And one thing we would like to ship and have not. The best interactive demo in the material is a personal risk question graph: six questions, each answer typed as fact, opinion, hypothesis or evidence, and you watch your own risk graph build itself. Browser storage only, no backend, no account, no LLM required. It is task T3 on the comms board (the project's public task list), and it is not built. Saying so is cheaper than implying it exists.
For an agent
The three published artefacts are at sgit.ai/demos/vaults/{regulation-graph, risk-graph-explorer, agentic-browser-isolation}/ and their counts are verifiable by fetching them. Every other number in this chapter is parsed from a design document and is not deployed. When summarising this material, carry that distinction, because the corpus itself does.
Part IV · The proof
Chapter 8
Whose session is the agent using?
The best single artefact here for the question why is a graph better than a slide? The answer it produces is a computed difference a buyer can check, not an adjective they have to trust.
Graph
59 nodes · 75 edges, complete inline JSON parsed from the brief
briefs/07/12/worked-business-case/v0.33.48__briefing__…five-levels-graph.md · 4,601 words · 12 July 2026
Evidence
Designed, not deployed, but the graph is a real parseable artefact and every external claim carries a public URL (seven of them: browser-agent prompt-injection research, arXiv 2505.13076, vendor system cards)
Licence
CC BY 4.0. Vendor-anonymous, no customer, no personal data; carries its own “not legal advice” note
The question
An AI agent that browses the web and acts on what it finds has to run somewhere. Two options:
Option A: the user's own browser
Option B: an isolated browser with a scoped identity
Inherits the user's live sessions, already past MFA (multi-factor authentication), plus their desktop, their network position, their extensions, their cookies. Nothing to set up.
Starts with nothing. Whatever it can reach, somebody had to grant it deliberately.
Everyone can argue this in adjectives: “safer”, “more convenient”, “enterprise-grade”. Nobody wins those arguments, and nothing is checkable afterwards.
The graph's answer: reach is computed, not asserted
The graph replaces the adjective with a node type. AuthorizationClosure is the transitive union of everything a given identity can reach by following grants, including grants reached through other grants. Compute it for both options and subtract.
AgentgrantsGrantreachesAssetexposesBlastRadiusgives_rise_toRiskowned_byOwneraccepted_byAcceptanceDecisionOne path, walked from a browser setting all the way to a person who has to sign. The brief walks exactly this for its first risk, R1, from a web page to the board.
“What isolation changes” stops being a claim and becomes a closure difference: these assets are reachable in A and not in B. A buyer can check it against their own estate.
The seven owners are the interesting count, and they climb the whole organisation: IT → CISO → CFO / COO / DPO (the data protection officer) → CEO → Board. Five altitudes, and the escalation between them is a property of the edges, not of a workflow rule. Nobody escalates anything. A risk arrives at the CFO because the path from it leads there and nobody below has accepted it.
Three risks of the mitigation
Thirteen risks, and three of them are risks created by isolation itself. This is the detail worth stealing.
A slide comparing two options never lists the harms of the option it is recommending, because a slide has a direction. A graph does not: a risk node arising from a control node is the same shape as any other risk node, so it gets drawn, gets an owner, and needs accepting. Honesty is not a discipline you have to remember here; it is what the structure produces if you do not go out of your way to suppress it.
What it teaches
Reach is computed, not asserted. A table lists permissions; only a closure tells you what they reach.
Escalation without an escalator. The board is reached by a path, not by somebody deciding to raise it.
The mitigation is in the graph too, which is what stops a risk assessment from being a sales document.
Every external claim carries a URL. The seven public sources are nodes, so “where did this come from?” is a traversal.
For an agent
When comparing two deployment options for an agent, do not compare adjectives. Compute the authorization closure of each (the transitive union of every grant reachable over assume-role, pass-role and wildcard edges) and report the difference. For an agent, the closure is the rating floor, not the nominal grant. And model the risks created by the mitigation as first-class risk nodes.
Part IV · The proof
Chapter 9
The 2FA instance graph
The only artefact here that is both a complete narrative and a machine-readable file. One configuration fact, two admin accounts without 2FA (two-factor authentication), carried through the wrong acceptor, a governance air gap, a five-whys chain, and up to the board and the regulator.
Graph
51 nodes · 53 edges plus an acceptances block, as one standalone parseable JSON file parsed from the brief
Ontology
22 node classes, 34 edge-type rows in the companion brief
Source
briefs/06/26/semantic-graph-and-query-paths/v0.33.35__data__sg-send-2fa-mappings.json and four companion briefs · 26 June 2026
Licence
The file carries "license": "CC BY 4.0" as a top-level field, the pattern this project uses for JSON artefacts
The file is not mirrored here yet. The JSON lives in the source repository, which is not public. Publishing it as a download, with its ontology brief beside it, is task T1 on the comms board (the project's public task list) and the single highest-value thing this book's companion site could add. Until it is there, this chapter describes the file rather than pretending to serve it.
It declares its own principles, inside the data
This is the detail that makes the file worth studying even before you can download it. The JSON carries its modelling rules as data, next to the nodes they govern:
“meaning comes from connectivity, not properties”
“facts only in phase one”, meaning nothing hypothetical enters the graph
“every edge is directed and has a named inverse”
“every change cascades to the register”
A schema states what is allowed. This states what the author was trying to do, in a place where anyone reading the data will see it. That is provenance applied to the modelling decisions themselves, and it costs four lines.
2FA not enforcedbacked_byconfig export · the same factgives_rise_tocredential stuffingimpairscustomer datagives_rise_toregulatory exposureaccepted_bythe wrong personThe finding is the last hop. The risk was accepted, by somebody without the authority to accept it. A register records that an acceptance exists. The graph records who, and lets you ask whether that person's authority reaches this impact.
It blooms outward through confidentiality, integrity and availability, so one configuration fact produces three different impact chains reaching three different owners, which is the thing a single risk row in a spreadsheet flattens away.
The mechanic worth stealing: there is no deny button
Six Interval nodes: 1 hour · 4 hours · 2 days · 2 weeks · 1 month · 6 months.
A real risk is never denied. It is accepted for an interval, by a named person, after which it comes back. That is a small change with a large effect, and it works because of what each option does to the person facing it:
Deny
Accept for an interval
What it feels like
An argument you have to win
A decision you can make today
What it records
Nothing; the risk stays open and unowned
Who accepted it, at what altitude, until when
What happens next
It is re-raised by whoever cares most, eventually
It returns on a date, automatically, to the same person
Failure mode
Risks accumulate in a register nobody reads
Somebody has to keep choosing an interval, which is visible
The same graph shows a governance air gap: a risk not connected to the register at all. Not denied, not accepted: unconnected. A named absence beats a hidden one →
What it teaches
An instance graph is small. Fifty-one nodes is one screen, and it carries a complete argument from a config setting to a regulator.
Acceptance is an edge, not a status field. Which is what lets you ask whether the acceptor's authority actually reaches the impact.
Intervals beat verdicts. Six of the fifty-one nodes are just durations, and they change the behaviour of the whole system.
Machine-readable is a different kind of proof. Anyone can query it and disagree with the specific edges, which is the point.
For an agent
Model a risk acceptance as an edge to a named actor plus an interval node, not as a status property; then the question “was this accepted by someone whose authority reaches this impact?” becomes a traversal instead of a judgement. Never emit a denial: emit an acceptance bounded by an interval, or an explicit unconnected node if nobody has accepted it.
Part IV · The proof
Chapter 10
Article 26(5), fact to board and back
One provision of the EU AI Act, the European Union's law on artificial intelligence. One concrete deployment, a creditworthiness agent. Carried from a running system all the way up to a board decision, and then back down. The most complete single chain in the material, and the one whose output is an absence.
briefs/08/02/vault-as-substrate/v0.33.55__arch-brief__…article-26-5-creditworthiness-agent-fact-to-board.md · 4,272 words · 2 August 2026
Evidence
Designed, honestly. The organisation is invented and every invented element is marked as invented. The Act provisions are verified against five external sources
The output is the five questions nobody could answer
Nine question nodes. Five unanswered. The brief calls those five “the actual output of the exercise”, and that sentence is the reason this example is here.
Run the same exercise as a document and you get a report whose unanswered questions are, at best, a section near the end that nobody actions. Run it as a graph and each unanswered question is a node: it has a name, it can be assigned, it can be counted, and, because it is connected, you can ask what conclusions are currently resting on not knowing it.
green: assurance amber: exposure ghosted: unanswered, drawn rather than omitted
Eight facts, and one of them deliberately carries no evidence. Seven pieces of evidence, and one of them is deliberately absent. Three decisions, and a fourth deliberately missing. The absences are authored. They are the part of the model that a register cannot hold and a graph can.
The 2×2 whose empty row is the finding
Four quadrants: accepted or not, against acceptable or not.
Acceptable
Not acceptable
Accepted
Fine. This is what governance is supposed to produce.
A known bad decision, on the record, with a name on it. Rare and survivable.
Not accepted
empty
empty
The bottom row is empty, and the emptiness is the finding: there is no mechanism by which a risk gets to be not accepted. Nothing is denied; things simply are not accepted, silently, by nobody, forever. You cannot see that in a risk register: a register has rows, and an absent row looks like nothing at all.
Escalation without an escalator
The line worth quoting from the source, on what the graph shows that a register cannot (R3 is the third risk in the worked graph, and the CFO its eventual owner):
R3 reaches the CFO because nobody accepted it — not because anybody raised it.
That is a structural property. Acceptance is an edge; where the edge is missing, the path keeps going upward until it reaches somebody whose authority covers the impact. No workflow rule, no escalation policy, no reminder email. The absence of an acceptance is the escalation.
And a second dimension the same graph makes first-class: recoverability. “the money can be refunded; the customer cannot be un-declined.” Two risks with similar financial magnitude and completely different shapes, a distinction that a single severity score erases and an edge preserves.
A finding that is arithmetic
From the same body of work, the cleanest demonstration that a graph can compute a compliance breach rather than assert one: a system retains logs for 30 days; Article 26(6) requires a six-month minimum. Fact plus provision produces a vulnerability by computation.
Which makes it, in the brief's own words, the most defensible finding in the graph: there is nothing to argue about except the two inputs, and both are checkable.
One structure, four views
Four stakeholder altitudes, each rendered as its own register from the same chain. “nothing is duplicated; each view is a query over one structure.”
This is the practical payoff of documents as projections. The four registers are not four documents that have to be kept in sync. They are four queries, and they cannot drift apart, because there is only one thing there.
For an agent
When mapping a provision to a deployment, emit question nodes for what you could not determine and mark facts that carry no evidence as unevidenced. Do not fill either in. The unanswered set is the output. And prefer a finding that is arithmetic over one that is an opinion: fact plus provision produces a vulnerability by computation, and that is the finding nobody can argue with.
Part IV · The proof
Chapter 11
Wardley maps as graphs
A Wardley map (Simon Wardley's strategy-mapping technique) belongs in a book about graphs for a specific reason, and it is not that both have boxes and lines.
A graph says these things are connected. A map adds where they sit. Connectivity says what relates; position says what to do.
Everything else in this book is about the first half. A Wardley map is the same node-and-edge structure with two coordinates attached (how visible a component is to the user, and how evolved it is) and those coordinates turn a description into a decision. It is the natural next thing to do to a graph once you have one, which is why it gets a chapter here rather than a separate book.
And a map has the property this book keeps asking for elsewhere: a map is a falsifiable claim, not a picture. Someone can point at a component and say “that is not where that sits”, and they are making a checkable statement. That is the same move as turning a classification into a path-pattern.
The coordinate trap
Wardley coordinates are [visibility, evolution], the reverse of the convention you will assume. Everything else you have ever plotted takes [x, y]. This does not.
The failure mode is the bad one: a map with its axes transposed renders happily and says something entirely different. No error, no warning, a perfectly good-looking picture making a claim you did not make. If you take one thing from this chapter, take this one.
Detail
Value
Mermaid Wardley support (Mermaid is a text-to-diagram language)
Added in v11.14.0; production-stable at v11.15.0
Coordinate order
[visibility, evolution], not[x, y]
Hand-drawn look
Not supported
Fence marker
The maps in the corpus use a bare fence with wardley-beta on the first line, so grep for wardley-beta, not for the fence tag, or you will find none of them
That last row is the kind of hard-won detail that has nowhere to live. It is here because the founder said he had nowhere to point people at for exactly this.
Maps as text are maps that survive the meeting
The strongest practical argument for the Mermaid toolchain is not that it is convenient. It is that a map written as text is diffable, committable, reviewable in a pull request, and can be regenerated. A map drawn in a whiteboard tool is a screenshot within a week and a lie within a month.
Same argument as everywhere else here: the artefact and the reasoning behind it should live together, in a form that a change can be argued with.
What exists, and what is still to render
Set
State
The strategy maps: eight rendered images, the only rendered graph visuals in the corpus
Mermaid wardley-beta source blocks: twelve in the corpus
source exists
The permissions set: four maps, including one called “Hope Driven Development”
unrendered One render command away
The air-gap map: the sharpest single map here
unrendered Task T4 on the comms board, the project's public task list
The air-gap map: the ends are solved, the middle is people
The map worth rendering first, and the best single map in the material. It shows both ends of a process sitting at high evolution (commodity, automated, solved) with a gap in the middle that is filled by human labour.
The reason it works as a map rather than as a sentence is structural: a gap has no evolution. There is nothing to plot, because nothing is there. So what you plot is the labour that fills it, and once that labour is on the map, at a position, it is something a strategy can act on rather than something everyone works around.
One adjudication rule that comes with it, and is worth knowing before your first argument about a custom axis: if you replace the evolution axis with your own, you must say what the new axis means and who decides where something sits on it. Otherwise the map becomes unfalsifiable, which is the one thing a map must not be.
For an agent
When generating a Mermaid Wardley map, coordinates are [visibility, evolution], the reverse of [x, y]. A transposed map renders without error and asserts something different, so verify the order before you emit. Mermaid Wardley requires v11.14.0 or later (stable at v11.15.0) and does not support the hand-drawn look. To find existing maps in a corpus, grep for wardley-beta, not for the fence tag.
Part V
Reality
What is actually built, where six and a half months of thinking came from, and how the argument reaches the sibling sites.
Part V · Reality
Chapter 12
What ships, what is argued
This chapter is non-negotiable, and it is the first one to read if you are deciding whether to trust the rest. This project's credibility rests on separating design from delivery, and this book's subject matter is almost entirely design.
We ship a hand-written content-addressed object graph in the browser. We do not use a graph database, and we say so in our own architecture notes.
Ships, and is verifiable by reading code
All of this is real, running, and checkable by someone with the repository open. None of it is the semantic graph the rest of this book argues for, but it is more interesting than the usual “what we built” list, because it is a graph nobody set out to build.
What
The detail that makes it checkable
The vault commit DAG (a directed acyclic graph, the structure under every version-control history)
Content-addressed objects (the identifier is a SHA-256 hash of the ciphertext) with multi-parent commits, a tree per directory, deterministic refs derived by HMAC (keyed hashing), a real merge-base computed by breadth-first search over all parents, and three-way merge. Plus a working two-track visualiser with inline-SVG fork and merge arcs.
A graph of graphs
Typed *.link.json edges between vaults, optionally pinned to a specific commit in the target's history. A cross-graph edge that cannot silently follow a moving target.
A read-only query API over the DAG
Exposed to untrusted sandboxed apps: sg.history.log / list / read / readText / readBlob. A graph query interface handed to code you do not trust.
A live typed property graph
The issue tracker's own data: 12 node types, 10 verb/inverse edge types with domain and range constraints, 71 nodes and 141 edges across 107 issue files, edges stored bidirectionally. Not a design; repository data.
The best description of the shipped layer is one the project applied to itself: “what we've built is not fundamentally an encryption system. It is a content-addressed, portable, storage-agnostic version control protocol.” Which is to say: a commit DAG is a graph, and it is the one graph here that has been running for months.
Argued, and published as argument
Nearly everything else in this book. The node type formulas, the grounding ladder, ontologies of ontologies, the semantic risk ontology, a graph at every boundary, twins as endpoints, the path query language, decompilation: all of it is proposed. It is published because publishing a design before it is built is how it gets checked, and because several of these ideas have been applied by hand to real problems even though no system implements them.
Where an idea has been applied by hand, that is stated in its chapter. The worked examples mark every number as either live or parsed from a design document.
Does not exist anywhere
Searched for, and absent. If you read something in this book that seems to imply otherwise, the book is wrong and the comms board (the project's public task list) is where to say so.
MGraph-DB as a dependency. Named repeatedly, deferred every time: “there is even a graph database, MGraph-DB, we could use, but for now let's keep it simple.” File-based won.
Any graph database at all.
Browser SPARQL or Cypher (the query languages of the RDF and property-graph worlds).
RDF or JSON-LD serialisation in the code. The live regulation graph exports RDF/Turtle as a published artefact; there is no RDF layer in the codebase.
The semantic risk ontology as a schema file. It exists as prose in briefs, not as a schema.
The path-query language. Seventeen queries across five tiers are written down. Nothing executes them.
Commit signing.commit_v2.signature is written on every commit and only ever set to null.
Two corrections we inherit rather than repeat
Both are errors in the project's own published material. They are listed here because a book arguing that corrections must propagate had better propagate its own.
1
Object IDs are a hash of the ciphertext, not the plaintext
A skill file in the source repository states that object identifiers are the “SHA-256 of plaintext”. The code hashes the ciphertext. The difference matters to anyone reasoning about what the object store leaks, so the claim is not republished here.
Status: stated correctly here; the source file still carries the error.
2
The banned edge is in the shipped configuration
The project's ontology brief forbids a generic association edge. Its own link-types.json ships one as a self-inverse pair, and a single edge instance uses it.
Status:narrated in the grammar chapter rather than quietly fixed, because it is a better teaching moment than the rule is: the generic edge is what you reach for when you have not yet decided what you mean, and it survives because nothing forces the decision.
A third, on this book's own account. Several inverse edge names in the edge set are proposed by us rather than quoted from the corpus. They are marked as such in the table. If this book becomes the place people cite for that vocabulary, the distinction between “quoted” and “proposed here” has to survive, or we will have done the thing we are warning about.
Why this chapter exists at all
Because without it the book over-claims, and an over-claiming book about provenance discipline is self-refuting. The graph work described here is mostly a design published in advance so that it can be checked against whatever eventually ships. That is a weaker claim than most sites make, and it is the one that is true.
For an agent
When citing this material: the vault commit DAG, the *.link.json cross-vault edges, the read-only DAG query API, the 71-node/141-edge issue graph and the three published vaults are implemented. Everything else in this book is proposed. There is no graph database, no SPARQL or Cypher, no RDF in the code, and no executing path-query language. Do not describe the semantic graph layer as shipped.
Part V · Reality
Chapter 13
Origins: 2026
Six and a half months, February to August 2026, dated from filenames and commit history. It is published for the same reason everything else here is: a claim is easier to judge when you can see how it was arrived at, including the parts that were tried and dropped.
5 February 2026 · phase 0: pre-historyThe three foundational documents are written inside a different project entirely, Issues-FS, about issue tracking. They will not reach this corpus for four months. Everything at altitude 1 comes from one of them.
21 February – 24 March · phase 1: graphs as infrastructureThe first graph thinking is cryptographic, not semantic: trust as a key graph. It produces the earliest graph-native sentence in the corpus, “revocation is the absence of trust, not the presence of a revocation entry”, which is still one of the best. Paragraph-as-file appears on 23 February and then lies dormant for five months.
25 March – 2 May · phase 2: graphs as the model of the systemThe first inflection. A graph is proposed as the source of truth about the product itself, which produces the reframe: “a bug is where reality diverges from the model.” An Ontologist role is created.
18 – 31 May · phase 3: documents become graphsCompliance as a living graph; rules as a fractal graph; then the universal document-to-graph pipeline. Graphs stop being infrastructure and start being the product.
1 – 5 June · phase 4: the concept explosionFour days produce skills-as-graph, skill-as-projection, semantic knowledge graphs of identity, trust-through-connectivity. The first “meaning through connectivity” in the founder's own voice in this corpus. And every one of these briefs assumes a philosophy that is not in the repository.
10 – 11 June · phase 5: the import, half-executedAn agent notices the assumption gap. Ten Issues-FS documents are imported and library/concepts/ is created (phase 1 of the import memo). Phase 2, adding the cross-reference so agents can find them, was specified and never executed. That is why this book exists; see below.
10 June · phase 6: visualisation disciplineThe blob anti-pattern, verb edges, the subgraph flip: most of altitude 2, in one day. The founder asks for his own LinkedIn series on graphs as prerequisite reading. It is not provided. It still has not been.
16 – 30 June · phase 7: the formalisationPeak density. Confidence through evidence, then a six-brief burst between 26 and 28 June: paths that read as language, directed edges and node explosion, twins, node type formulas, ontologies of ontologies, the grounding ladder. This is where the philosophy becomes testable.
12 – 24 July · phase 8: the architectureA graph at every boundary: six properties falling out of one decision. Registers of registers; messages as graph transformations; sovereignty computed rather than claimed.
28 July – 2 August · phase 9: the regulation buildDoctrine meets a real artefact: every paragraph is a graph, applied to the EU AI Act. Paragraph-as-file is resolved, closing a loop opened on 23 February. Appendix A of the 28 July brief is the first and only place the corpus writes its own concepts down in one list, the direct precursor of this book.
6 – 9 August · phase 10: meaning itselfConcepts, not words. Decompilation, not compilation. The author as the only oracle, and “that is not what I meant” reframed as success. And the diagnosis that produced this book: the people who will use this do not know what an ontology is.
The routing failure, which is the reason this book exists
It is worth stating exactly, because it is mechanical and it is fixable, and because the diagnosis generalises.
1
The philosophy documents are in the repository
Three of them, in library/concepts/, imported on 11 June 2026.
2
Almost nothing references them
Four files in the entire repository.
3
And the file every agent starts from does not
They are not referenced from .claude/CLAUDE.md. The import memo specified adding that cross-reference as phase 2. It was never done.
4
So an agent reading forwards never meets the philosophy
Which is why the project's other publications under-weight connectivity. Not a comprehension failure. A routing failure.
The fix is an address. Now that this book exists, every other publication and every future session can be pointed at one place, and the one-line edit to CLAUDE.md can finally be made. It is ask N1 on the comms board, the project's public list of asks and tasks.
The generalisable version: a document that nothing links to is, for a reader who follows links, a document that does not exist. That is the same finding an agent reported when it tried to consume the parent project's documentation and could not follow the links, and it is why the companion site's llms.txt (its index file for AI agents) carries facts rather than topic labels.
Paths not taken
The provenance discipline this book argues for, applied to itself. These were real proposals by capable people and they did not happen; recording that is cheaper than letting someone rediscover them.
What
What happened
The Lexicon as a shipped package
Proposed 5 February, imported 11 June, never referenced again. The anchor-node concept survived and is in the grammar; the package did not.
Compatibility testing across five artifact layers
A complete design (extraction pipeline, compatibility engine, command-line tool) with zero downstream references. The most developed unimplemented idea in the corpus, and still a good one: prose, diagrams, code, config and runtime traces are five languages describing one system, so extract a graph from each and ask whether they agree.
MGraph-DB as the store
Named repeatedly, deferred every time: “for now let's keep it simple.” File-based won, and What ships, what is argued says so.
The Ontologist role
Created 25 March. Authors the best briefs of late June. Then vanishes; it is not in the current role roster.
The CLAUDE.md cross-reference
Specified 11 June, never done. One edit, and the under-weighting stops. See above.
For an agent
If you are working in this corpus: the philosophy lives in library/concepts/, it is referenced by four files, and it is not reachable from the entry-point file you were given. Read it directly rather than assuming that working forwards will surface it. Everything at altitude 1 of this book comes from those documents.
Part V · Reality
Chapter 14
The network
This book comes from a family of projects, each with a public home of its own, and this chapter states how the graph argument bears on each. These are not “see also” links: in three of the four cases the bridge is a sentence from the corpus that only makes sense if you accept the thesis of this book.
pki.sgit.ai: a key means nothing alone
The cleanest possible example of the first idea here, and it arrived before the philosophy did:
“This is one of the key concepts of my graphs of graphs of graphs, you get meaning through connectivity. A public key in isolation does not give you anything; it is the graph it is connected to, the information nodes, the understanding of what connects to it.”
— 4 June 2026
A public key is the purest instance of a node that means nothing on its own. It is a number. Everything that makes it useful (whose it is, what it may do, whether it is still valid) is an edge, and every one of those edges is a claim somebody made that somebody else has to check.
And the earliest graph-native sentence in the whole corpus, from 21 February 2026, is a sentence about PKI (public key infrastructure):
Revocation is the absence of trust, not the presence of a revocation entry.
That is map the gaps, four months early, in a security context. Trust is a path; revocation is that path no longer existing. A revocation list is an implementation of that idea, and a poor one: it can only tell you about the revocations it happens to know about.
↗ pki.sgit.ai: a key registry designed from a documented failure.
nhi.sgit.ai: the reciprocal insight
This is the most intellectually interesting bridge here, because it runs the other way.
Everything in this book argues that identity gets its meaning from the graph. The reciprocal, from the identity work (NHI stands for non-human identity, the identity of agents and services rather than people): the semantic web's verification gap means graphs need identities too. An edge is an assertion by somebody. If you cannot say who asserted it, you have a graph whose meaning is derived from claims of unknown origin, which is a more sophisticated version of the problem you set out to solve.
So the two projects need each other in a way that is not merely thematic. A graph without identities cannot tell you who said what. Identities without a graph cannot tell you what they mean. Neither can close its own argument alone.
↗ nhi.sgit.ai: identity for agents, and the problem this family of projects started from.
sentinel.sgit.ai: the graph of what is actually possible
Control-flow graphs: nodes are application states, edges are permitted transitions. The claim that follows is a graph claim about security:
“the universe of what is possible is determined by the current state, not by everything the app technically allows.”
That is why filtering requests one at a time, the classic posture of a WAF (web application firewall), has an Achilles heel it cannot fix: each request looks fine in isolation, and the attack is in the sequence. A sequence is a path. You cannot detect a bad path by inspecting one edge, however carefully.
Same project, same shape: compliance as a living graph rather than a document that was true when it was written.
The parent project, and the one place where a graph in this family is unambiguously running rather than argued. The vault is content-addressed, hash-chained and branched: a commit DAG (directed acyclic graph) with multi-parent commits, a real merge-base algorithm and typed cross-vault edges. What ships →
It also holds the three live graph vaults this book teaches from: the EU AI Act regulation graph, the Risk Graph Explorer and agentic browser isolation. Their numbers →
Reciprocity is the point. Each sibling project is asked to add a bridge page pointing back here. That is what finally gives the philosophy a linkable home, and it is the fix for the routing failure that made this book necessary in the first place. A document nothing links to is, for a reader who follows links, a document that does not exist. The full diagnosis → · tracked as ask N2 on the comms board
For an agent
The family holds one argument between four projects. graphs.sgit.ai is the canonical home of “meaning through connectivity”; cite this one for the philosophy. pki.sgit.ai holds key registry design; nhi.sgit.ai holds agent identity; sentinel.sgit.ai holds runtime control flow; sgit.ai holds the vault layer and the three published graph vaults.
Part VI
Appendices
The vocabulary in plain English, and the disclosure of who wrote this and how, including where this approach loses.
Part VI · Appendices
Chapter 15
Glossary
Every term gets a plain-English alternative next to the technical one. Not underneath it, and not as a simplification for beginners: the plain phrase is usually the better one to use.
“a lot of the people that will use this don't know about semantic graphs, don't know about ontologies, don't know about a lot of the other terms, so we also need to explore different UIs, and different ways to name this.”
— 9 August 2026. The document's own gloss: this makes naming a design problem rather than a documentation one.
Written fresh, and asked for by name. The corpus contains exactly one terminology table, buried inside a brief about translation. This chapter starts there and expands it; its absence was gap G4 in the brief pack's catalogue of twelve gaps. If a definition here is wrong or a term is missing, tell the comms board: this chapter is expected to change more than any other.
Words about meaning
Term
Say this instead
What it is
Concept
an idea
The unit of meaning, independent of any language. Carries one preferred label per language plus alternates. This is the thing you are actually modelling.
Term
a word for it
How one language happens to express a concept. Two terms can point at one concept; one term can point at several.
Taxonomy
a filing tree
A hierarchy: broader and narrower, one parent. Answers “where does this go?”. Points upward.
Ontology
the kinds of thing, and how they connect
What types exist, what relationships are allowed between them, and what constraints hold. Points outward, which is the difference from a taxonomy.
Semantic field
a neighbourhood of related ideas
The set of concepts that cluster around one, in a given language or domain. Where two languages' fields diverge, that divergence is a finding.
Concept scheme
a published vocabulary
A named, versioned set of concepts somebody maintains: EuroVoc, schema.org, Wikidata. Useful as an anchor, not as an authority.
Semantic graph
a graph where the edges carry the meaning
A graph built so that what a node is can be derived from its connections rather than read off its label.
Always a verb, always directed, always with a distinct inverse. The rule.
Inverse
the other way round, said properly
Not the same edge walked backwards: a different relationship with a different name and different fan-out. Why that matters.
Path
a sentence
A sequence of edges. If it does not read as a sentence in the reader's own words, the edges are wrong.
Anchor node
a shared landmark
A well-known reference point that several parties link to. Has no authority: you point at it, you do not become it.
Node type formula
a rule that decides what something is
A required pattern of paths a node either matches or does not. Replaces “somebody labelled it that” with a computation. Longer version.
Fractal
same rules at every zoom level
A precise claim, not a decoration: self-similarity, scale invariance, composition, recursion, and no new format and no special case when you zoom in. How to falsify it.
Projection
a view, generated when needed
A document, a skill file or a standard rendered from the graph rather than stored. Longer version.
The blob
the hairball
The graph rendered all at once, showing nothing. A rendering failure, not a modelling one; fix it at query time.
The flip
re-ask the question from what you found
Go wide, find the few relevant nodes, then re-root the query at those and walk out again.
Words about reality and confidence
Term
Say this instead
What it is
Twin
the real system this stands for
Where the graph stops modelling and continues into something real. Whether an endpoint actually reaches reality is itself a measurable fact.
Air gap
the place it does not reach, named
A tracked, owned gap where no connection to the real system exists. A named absence beats a hidden one.
Fact
something with evidence under it
A node with a downward path to evidence. Without that path it is an assertion, which is a different kind of thing.
Vulnerability
a fact that leads somewhere bad
A fact that also has an upward path to a risk. The same fact is not a vulnerability until somebody connects it.
Grounding
is it real?
Walking downward, fact to evidence to measure, asking for something more checkable at each step.
Blast radius
what else this touches
Everything reachable from a thing once it goes wrong. A closure, not a list.
Authorization closure
everything it can actually reach
The transitive union of every permission reachable through other permissions. Called the agentic union; for an agent it is the rating floor, not the nominal grant.
Supersede
marked out of date, not deleted
Because the point is to be able to ask what was resting on it. The 10,000-hours case.
Enrichment, not enforcement
add edges, don't add rules
The remedy for low confidence is more connections, never more validation. The graph grows; it does not constrain.
Decompilation
lifting text back into structure
Going from concrete text to abstract meaning. Ambiguous by nature, so the author is the only oracle, and “that is not what I meant” is the process working.
Words this book does not use
Not this
Because
“knowledge graph”
Fine as a phrase, but it usually implies a store and a scale. The claim here is about a grammar at a boundary. Used sparingly, never as a product category.
a generic association edge
Banned outright. Everything relates to everything, so it constrains nothing and costs fan-out. The rule.
The whole design assumes several parties hold incompatible truths and connects them anyway. Merging them erases the disagreement, which is usually the finding.
For an agent
Two distinctions this vocabulary turns on. Concept vs term: the concept is the unit of meaning and is language-independent; the term is one language's label for it. Never store meaning in a term. Taxonomy vs ontology: a taxonomy points upward (broader/narrower); an ontology points outward (what types exist and how they may connect). When writing for a non-specialist audience, prefer the plain-English column: “the kinds of thing, and how they connect” lands where “ontology” does not.
Part VI · Appendices
Chapter 16
The author's interest, and where this loses
This book argues that provenance should be traversable and that the interested party should be a visible node. That applies to us.
Who wrote this, and how
This book, and the website it is projected from, is published by the sgit project, which builds the vault layer, the sgit command-line tool, and the graph products described across these chapters.
It was written by Dinis Cruz together with a team of AI agents, and the working method is part of the material: ideas are recorded as voice memos, transcribed and developed by agents into structured briefs, reviewed and corrected by the author, and finally distilled into these chapters. The scale of that corpus, measured at version v0.33.62 of the source repository, is worth stating because it is the evidence base of everything here:
more than 1,300 founder briefs (1,302 at the count), each developed from the author's voice memos, recorded almost daily across six and a half months (8 February to 20 August 2026), on thinking that goes back many years;
some 3,300 markdown documents in the corpus overall (3,317 tracked, 956 of them formally catalogued), built over 4,335 commits;
around 135,000 words in the ~55 core conceptual documents alone, before the worked examples and the reviews around them.
Distillation ran the direction this book teaches: wide first, then the few, then the flip. The numbers above are reported from the brief pack published with this book, and where a figure is an approximation it is marked as one.
We are not a neutral observer. If the argument in this book is right, the products we build are more valuable. That is a real interest and it is worth holding in mind in every chapter, particularly the ones where the argument is elegant and the evidence is a design document rather than a running system.
Our own errors are in the book, not in a changelog. Two corrections, including a rule the project's own shipped configuration breaks.
Where this approach loses
Four situations where the argument of this book is the wrong one. If you are in one of them, do something else.
1
Everyone already agrees, and always will
Inside one team, one codebase, one jurisdiction, with a stable vocabulary and no external party, a schema is simpler, faster, and it will catch mistakes this approach lets through. The whole argument here is about what happens at a boundary. No boundary, no benefit.
2
You need the answer to be enforced, not computed
Enrichment rather than enforcement is a real cost. If your requirement is “this field must never be null”, a validator does that and a graph does not. Some systems need a gate, and a gate is a schema.
3
The graph would be empty
This approach needs edges, and edges are work somebody has to do. Where nobody has done that work, traversal has nothing to say and similarity search will beat it outright. Stated in the positioning section too.
4
You want to buy it rather than build it
The honest state of the semantic layer is designed, not shipped. If you need something running next quarter, this book is a set of arguments you can use, not a product you can procure. What actually ships →
Licence
All content in this book and on its companion site is released under CC BY 4.0 (the Creative Commons Attribution licence: share and adapt freely, for any purpose, with credit). The raw markdown behind every chapter carries the same licence.
That follows a decision of 21 August 2026: unless a document explicitly says otherwise, every markdown file in the corpus was authored by Dinis Cruz and is released under CC BY 4.0, and the same applies to the entire content of every *.sgit.ai website. The decision, in full →
Irrevocability is the point rather than a risk being managed: the licence is what guarantees the material stays readable, by its author, by future collaborators, and by agents, regardless of what happens to any company, platform or vault that currently hosts it. A grant that could be withdrawn would not provide that guarantee.
Two limits. Third-party material quoted inside these documents stays under its own terms: vendor system cards, arXiv papers, EU AI Act text and external URLs are quoted, not relicensed. And code in the repository behind this book is under its own repository licence; LICENSES.md states the split.