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.

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.

All the worked examples, with what each one teaches →

What is built, and what is argued

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.

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.

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.

Three different things people mean by “graph”

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

“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

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.

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.

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.

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.

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:

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.

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.

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.

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.

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:

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:

Never render the whole graph. Render the result of a query.

“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:

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.

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.

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.

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.

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.

The risk / assurance chain (browser isolation, 59 nodes / 75 edges)

Reality · Twin · Asset · Evidence · Measure · Fact · Grant · AuthorizationClosure · BlastRadius · Vulnerability · Risk · PreventiveControl · DetectiveControl · Owner · AcceptanceDecision

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.

The instance graph (2FA, 51 nodes / 53 edges)

Risk (9) · Actor (9) · Evidence (6) · Interval (6) · Fact (5) · Impact (3) · System (2) · Vulnerability (2) · DataClass (2) · Asset · ThreatAgent · Attack · Obligation · Register · Twin · Agent

The 2FA graph in full →

The one that is actually running

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

1. 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.
2. 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.
3. Domain and range, stated. Which node types may sit at each end. This is what makes a malformed graph detectable rather than merely wrong.
4. No generic association edge, ever. Not even temporarily. Temporarily is how the one in link-types.json got there.
5. Prefer adding an edge to adding a validation rule. Enrichment, not enforcement. The graph grows; it does not constrain.

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.

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

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:

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:

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.

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.

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.

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:

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

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:

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

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.

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.

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.

The three with chapters of their own

And seven more

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:

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

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.

The question

An AI agent that browses the web and acts on what it finds has to run somewhere. Two options:

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.

“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 shape of the graph

Node types. Reality · Twin · Asset (4) · Evidence (6) · Measure (4) · Fact (5) · Grant (2) · AuthorizationClosure (2) · BlastRadius (2) · Vulnerability (6) · Risk (13) · PreventiveControl (3) · DetectiveControl · Owner (7) · AcceptanceDecision (2)

Edge types. backed_by · observed_on · measured_by · grants · exposes · reaches · impairs · gives_rise_to · owned_by · protected_by · conditional_on · emits · accepted_by · underwritten_by · connected_to (the edge set)

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.

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.

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.

What is in it

Risk (9) · Actor (9) · Evidence (6) · Interval (6) · Fact (5) · Impact (3) · System (2) · Vulnerability (2) · DataClass (2) · Asset · ThreatAgent · Attack (MITRE ATT&CK technique T1110.004, credential stuffing) · Obligation · Register · Twin · Agent

The chain, walked as a sentence:

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:

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.

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.

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.

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.

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.

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

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

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.

It is the same argument as the air gap in the graph, drawn: a named absence beats a hidden one.

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.

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.

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.

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.

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.

1. 5 February 2026 · phase 0: pre-history The 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.
2. 21 February – 24 March · phase 1: graphs as infrastructure The 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.
3. 25 March – 2 May · phase 2: graphs as the model of the system The 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.
4. 18 – 31 May · phase 3: documents become graphs Compliance 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.
5. 1 – 5 June · phase 4: the concept explosion Four 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.
6. 10 – 11 June · phase 5: the import, half-executed An 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.
7. 10 June · phase 6: visualisation discipline The 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.
8. 16 – 30 June · phase 7: the formalisation Peak 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.
9. 12 – 24 July · phase 8: the architecture A graph at every boundary: six properties falling out of one decision. Registers of registers; messages as graph transformations; sovereignty computed rather than claimed.
10. 28 July – 2 August · phase 9: the regulation build Doctrine 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.
11. 6 – 9 August · phase 10: meaning itself Concepts, 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.

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.

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.

↗ sentinel.sgit.ai

sgit.ai: the vault is a graph

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 →

↗ sgit.ai · ↗ the network page

The ask that closes the loop

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.

Words about meaning

Words about structure

Words about reality and confidence

Words this book does not use

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.

What we do about it

• A chapter that separates what ships from what is argued, listing what does not exist anywhere, including the absence of any graph database, which is the thing a vendor would most want to imply.
• Every number is labelled live or parsed-from-a-design-document, and the two are never mixed.
• Every chapter written fresh says so, and names which gap it fills. The bar for those is lower and you should hold them to it.
• The source documents are published in full, raw, with the three redactions recorded. You can check any quotation against its source.
• 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.

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.

Corrections

If something here is wrong, the fastest route is the comms board or an issue on the repository. Corrections that change a claim get a row in the release history, not a silent edit: this book's own rule.