Everyone promises the AI will remember. Here is the arithmetic that decides what it reads first.

The cell of the graph: one node and one edge

Knowledge here is not a document. It is a set of typed assertions, each with an identifier whose prefix already says what kind of thing it is — because a hunch and a measurement must not look like the same sentence.

A whole example, from a fictional company — Café Aroma — that decided discounts are capped at 10%:

nodes:
  - id: D_desconto_max_10
    node_type: decision
    impact: 5              # the price of being wrong here: high
    confidence: 0.9
    status: confirmed
    label: "Discount cap: 10%, no exceptions"
    verified_at: 2026-08-25
    verified_against: "current sales playbook"

  - id: E_black_friday_2024
    node_type: evidence
    impact: 4
    confidence: 1.0
    status: confirmed
    label: "BF 2024: 30% off -> churn 3x within 6 months"

edges:
  - from: E_black_friday_2024
    to:   D_desconto_max_10
    edge_type: SUPPORTS   # the decision is not floating: it has ground

The four numbers every node carries

The radar on paper

A graph with hundreds of assertions makes "read everything" an empty instruction. So every node gets a number — its attention — and that number is computed, not opined:

That is all of it. Four fields that were already in the file, three multiplications and one addition. The (1 + connections) term is centrality: the more things touch a node, the more expensive it is to be wrong there — an isolated decision is wrong on its own, a decision holding up four others is wrong in five places.

Move the controls. The example is preloaded with the 10% cap from the previous section — impact 5, confidence 0.9, confirmed, four edges touching it:

Drag the status to refuted and watch attention fall to zero with nothing else changing: that is the map saying "this is still on record, and it is no longer where you look". Drag it to drifted and it climbs above confirmed — a node that just proved the world moved is more urgent than one that is merely up to date, because somebody has to reconcile.

The loop: read → verify → act → write

The graph is not a dead file someone consults. It is the first and the last act of every piece of work: you read before deciding, you measure against the world before believing, you act, and what was learned goes back stamped. The best way to show that is a case where the victim of the mistake was this very site.

For roughly a month, the home page here lied — it advertised an inventory of 98 commands when the real number was already 102. Nobody had written anything wrong.

1. read

   The graph already had a node about it, from July: "the site is out of date", with the cause pinned on lagging authorship — somebody needed to rewrite the page. The node was there, plausible, and would have been enough to generate the wrong task.

2. verify

   Instead of believing the node, we measured. We fetched the live page and compared it with the source in the repository. The source was right: a commit from 30 July had updated the inventory and the page in the same commit, and the old string no longer existed in the file at all. The node was right about the symptom and wrong about the cause. What was broken was not the writing — it was publishing, which existed only as prose: a procedure someone was supposed to remember to run.

3. act

   The obvious fix — rewrite the page — would have fixed nothing. And republishing by hand is the same failure waiting for next month. So what shipped was not a republish: it was the publishing mechanism, with a closed list of what may go live, a hash check that compares source against the live site and fails on divergence, and a self-test that freezes the attacks found across two rounds of adversarial review — including the worst of them: an empty source that wiped the entire site while returning a green verdict.

4. write

   The old node was neither corrected nor deleted: it was marked superseded, with the date it was measured and against what. A new node, linked to it, records the mechanism that was born and what it now serves. If the drift ever returns, whoever arrives finds the whole story — the symptom, the wrong cause, the right cause, and the guard that stayed.

The stack: who acts, what it knows how to do, in what order

Three pieces, and the distinction between them is what keeps the whole thing from collapsing into one giant prompt:

Economy of Motors: use the cheapest motor that can do the job

None of that decides on its own what to execute with. That choice is explicit, and there are three motors:

1. Transformer (the large model) — judgement, synthesis, trade-offs, prose, orchestration. Expensive, slow and non-deterministic. Use it when the task requires understanding intent.
2. SLM as a tool — a small, specialised model behind an interface, for a narrow repetitive task (extract, classify, redact sensitive data locally). It never orchestrates: it is a tool, not an agent.
3. Shell — the deterministic one — plain scripts for everything the model gets wrong: counting, diffing, detecting drift, applying a fixed format. Same input, same output, zero cost, auditable.

The rule is one line: the cheapest motor that can do the job. And the most common mistake is not reaching for too small a model — it is using the model to count. The radar in the previous section is shell for exactly that reason: if the attention queue depended on inference, it would change its mind between two identical runs, and an instrument that does that is not an instrument.

2026's three criticisms, answered with mechanism

Knowledge graphs wired to agents took three serious objections this year. They are criticisms of the category — not of any named product — and all three are right about a real failure mode. They deserve an answer in terms of what the machine does, not in adjectives.

Try it in your own domain (15 minutes)

None of this requires installing the framework, creating an account, or handing over any data. The method travels as schema + method. Take one decision you made this week — one still warm enough that you remember the argument — and write down four things:

1. What I decided. One sentence, in the indicative. That becomes a D_ node. Give it an impact from 1 to 5 by answering "how much does it cost if this is wrong?".
2. What holds it up. The facts you used — a number, an incident, a test, a customer conversation. Each becomes an E_ node linked to the decision by SUPPORTS.
3. What I refuted. The alternative that looked reasonable and was discarded. It is the most valuable of the four and the one every document loses: it becomes a C_ node with status: refuted and a REFUTES edge coming from the evidence that knocked it down. Three months from now, when somebody proposes exactly that again, the answer is already written.
4. What is still open. The doubt you did not resolve and decided anyway. It becomes a Q_ node. That is not a weakness of the map — it is the most honest part of it. A map of certainties only is a map that forgot to mark where it ends.

Run the attention arithmetic on each node, by hand or with the widget above, and sort. Whatever lands on top is where your team's next hour should go. If the result surprises you, the exercise already paid for itself: that surprise is the gap between the queue you think you have and the one your own numbers describe.