{"path":"research/corpus-graph/README.md","content":"# The corpus graph: what the notes say about each other, and what somebody found\n\n**Date**: 2026-10-10 · **Type**: specification of a built tool, with the research and the measurements\nbehind its shape · **State**: built small and live on the keeper's machine; the shape is Claude's and the\nfounder's to change. Nothing here is a ruling on the product.\n\n**The question, verbatim** (founder, 2026-10-10): *\"Could we use a separate graph DB that would model the\nconnections and ideas inside the corpus, ideally the whole corpus, with links to the md docs etc, in a way\nthat is purpose-built to assist us in our daily work in Deliberus? Perhaps using Jev where appropriate.\nThat way, we wouldn't be using Graphiti's interpreting-everything-as-facts machinery necessarily, we'd use a\nsort of graph that serves our purposes as best we can see fit. Sort of like GraphRAG, I guess. Is this\nfeasible?\"*\n\n**The go-ahead, verbatim**: *\"Yes build it, small first. Excited to see how this may help, feels like it\nshould be a power-up. Research gotchas and insights a bit online and locally to keep in mind here first.\"*\n\n**This is an index of documents. It is not the claim graph**, holds no claims, and stores no belief about\nDeliberus inside Deliberus (that is held by his ruling of 2026-08-30).\n\n---\n\n## 1. What it is for\n\nOn 7 October a session read the note that is home to a ruling, and 49 minutes later proposed against that\nruling. Three things that would have stopped it were on disk, each in a different file: the ledger row\nnaming that note as its home, two other documents that corrected the note, and (since 10 October) a\nreader's finding that the proposal reverses the ruling. Nothing put them in front of the session when it\nopened the note.\n\nThe graph does that one job first. **When a session opens a note, it is told what others have judged about\nthat note, in other files.** Everything else the graph holds is there to be asked for.\n\n## 2. What it holds\n\nThree kinds of tie, and each says how it is known.\n\n| Kind | Where it comes from | Kept how |\n|---|---|---|\n| **Written** | a link from one note to another; a note naming a ledger row; a ledger row naming a note as its home | derived from the files each time, never stored |\n| **Judged** | a written tie whose sentence corrects, narrows, withdraws or retires what it names; a finding of the outside reader (`../outside-checks/`); a ledger row's state | derived |\n| **Found** | a connection that a person or a reader found: between two notes, or from a note to a ledger row it bears on | kept in `found.jsonl`, with who found it, when, why in their words, and the passages it rests on |\n\nCounts drift, so ask: `uv run python scripts/corpus_graph.py stats`. On the day it was built it read 345\nnotes and 414 ledger rows, 6,477 links, 1,261 places where a note names a row, and 226 sentences that\ncorrect something, about 131 notes and rows.\n\n## 3. The three rules of its shape\n\n1. **Derived, never maintained.** Every written tie is read out of the files. The cache is thrown away\n   whenever a file changes. So a written tie cannot go stale and nobody keeps it up.\n2. **What somebody found is the only thing stored.** A found connection is a line appended to\n   `found.jsonl` and is never edited. A connection proposed by a model is stored as a candidate and is\n   delivered to nobody until a person or a reader keeps it. A rejected proposal is kept too, so the same\n   pair is not proposed again. When a found connection has since been written into the notes it bears\n   on, a later line says so (`written`): it stays on record and is no longer handed to a session, since\n   the fault it describes is gone.\n3. **Delivered when the note is opened, and only what was judged.** A note's plain links are in the note. What\n   a session cannot see from inside a note is what other files say about it.\n\n## 4. The measurements that decided this\n\nReaders had found 57 notes that bore on the week's ten proposals, out of 316 that could be ranked. That set\nis the test. Chance is 15 of the 57 in a list of 84.\n\n| Way of finding them | Of the 57 |\n|---|---|\n| Search, three results for each of 72 paragraphs of the pieces (84 notes shown) | 25 |\n| One step along written ties from the six notes that made the proposals (65 notes reached) | 20 |\n| Two steps along links (221 notes reached, most of the corpus) | 52 |\n| A walk over the written ties from the six notes, first 84 | 23 to 25 |\n| Notes citing the same things, or cited by the same notes, first 84 | 20 to 21 |\n| Likeness of meaning between whole notes, first 84 | 20 |\n| All of those rankings fused, first 84 | 24 |\n| One reader given a one-line card for each of the 316 notes | 16 |\n\nOf the 40 bearing notes with no written tie to the six, the best ranking held 10 in its first 84.\n\n**What this says.** No signal that can be computed from the files finds the connections the founder calls\nunexpected, and neither does a reader working from one line a note. Readers who read the notes found them.\nSo the graph is not built to discover connections. It is built to **keep a connection once somebody has\nfound it, and to hand it over at the moment it matters**. That is the part nothing did before.\n\nSearching the notes by one's own words is a different tool, and it exists: `mannaminne -d \"<question>\" -P deliberus` (keyword and meaning search over the same notes). The graph is asked by note or row name. The founder's point when a free-text search of the graph was floated as a separate build, 2026-10-10: *\"Det kan vi ju redan göra med mannaminne I guess dock\"*.\n\nThe scripts and what they printed are in the keeper's working notes, outside this repository\n(`graph_feasibility.py`, `graph_ranking_test.py`, `card_reader_test.py` and the search test, each beside\nits printed output).\n\n## 5. What the research said, and what was done about each point\n\nTwo helpers read the outside literature before anything was built. Their reports are beside this file word\nfor word: [graph indexes against plain retrieval](graph-retrieval-measured-gotchas-as-a-helper-read-it.md)\nand [finding connections nobody wrote](finding-unwritten-connections-as-a-helper-read-it.md). Claude did not\ncheck their sources. Three earlier notes of the keeper's own said the same from experience.\n\n| What was reported | What the build does |\n|---|---|\n| A graph extracted from loose prose by a model is noise that looks like signal; a graph pays where the kinds of thing can be named beforehand | No extraction. The kinds are named: note, section, ledger row, connection. All of them are already in the files |\n| A graph adds little on questions one passage answers and helps where two notes must be joined; plain search stays the base | Search is untouched. The graph answers a different question: what bears on this note |\n| Adding every one-step neighbour made retrieval worse (42 against 51 on one measure) | Plain links are never delivered. Only judged ties are |\n| Hubs take most of the weight in a walk; here the ledger and the overview files are hubs | No walk is used in delivery. The always-loaded instruction file is left out as a source of corrections |\n| An edge with no stated reason is noise; a note with eighty backlinks is noisier than one with eight | Every delivered line carries the sentence it rests on and where it stands. A delivery is capped at four lines of each kind |\n| Edges proposed by a model are the least proven kind (one to three points) | A model's connection waits as a candidate |\n| Rewriting a memory makes it drift; appending small dated additions does not | `found.jsonl` is only ever added to. A later line about the same pair by the same finder replaces the earlier one in what is shown |\n| A memory that is present goes unused unless the harness delivers it | Delivery is a hook, and the session does not have to ask |\n| Discovery systems that offer long candidate lists were abandoned; the kind that lasted starts from two ends a person brings | No list of candidate pairs is ever generated. `add` records a pair somebody already holds |\n| Serendipity is relative to a person and a time | A found connection records who judged it and when |\n| Upstream graph tools recommend rebuilding from source over updating in place | The index is rebuilt from the files (between one and two seconds; a third of a second from cache) |\n| Results judged by a model's preference do not hold up; measure against known evidence | The test is the 57 notes, and the test in § 8 |\n\n## 6. Using it\n\n```\nuv run python scripts/corpus_graph.py around relevance-and-the-two-factors   # everything about a note or a row, with where each line stands\nuv run python scripts/corpus_graph.py around Q33\nuv run python scripts/corpus_graph.py names how-far-a-premise-is-from-its-claim   # what a note links to and names\nuv run python scripts/corpus_graph.py deliver docs/research/some-note.md     # what a session is told on opening it; prints nothing for most notes\nuv run python scripts/corpus_graph.py add --from note-a --to note-b --why \"…\" --by fredrik --where \"session of 10 Oct\" --kind contradicts --at docs/research/note-a.md:40\nuv run python scripts/corpus_graph.py reject --from note-a --to note-b --why \"…\" --by session\nuv run python scripts/corpus_graph.py written --from note-a --to note-b --why \"what was written, and where\" --by session\nuv run python scripts/corpus_graph.py search \"how likely is the next contribution to say something new\"   # search by meaning, then the graph on each note returned\nuv run python scripts/corpus_graph.py read note-a note-b --report docs/research/corpus-graph/readers/a-report.md   # a reader went through these notes\nuv run python scripts/corpus_graph.py unread            # the notes no reader has gone through, most open proposals first\nuv run python scripts/corpus_graph.py stats\n```\n\n`--by` is one of `fredrik`, `reader`, `session`, `model`. A note is named by its file name without the\nending; a ledger row by its id.\n\n**From a search hit to the graph** (`search`, built 2026-10-10 on the founder's word: *\"we should I guess\nimplement the one direction that makes obvious sense first\"*). The command runs the keeper's search over the\nnotes, by keyword and by meaning, and then asks the graph about every note the search returned. It prints,\nfor each note, the passage the search found and what other files have judged about that note. Then it\nlists the notes that did the judging and that the search did not return, the ones somebody read and kept\nfirst: those are the notes to open next. A hook that has already run the search can hand over the search's\nown lines with `--hits -` and take the result as data with `--json`. Where the search tool is not installed\n(a cloud session), the command says so and names `around`. § 11 has the reasoning and a worked case.\n\n**Delivery.** A hook in the keeper's own settings (`corpus-graph-nudge`, tested beside it) runs `deliver` the\nfirst time in a session that a note under `docs/` is read or edited (since 2026-10-10 also when a shell\ncommand or the search tool reads it; the hook then also names a line that the command cut short). Before the first fill 94 of the 345\nnotes had something to be told (28 home to a settled ruling, 80 corrected or narrowed somewhere else, 3\nholding a ruling that a proposal was found to reverse). After it, 166 of 349 do. A delivery shows at most\nthree found connections, each reason cut to about 230 characters, and says how many more there are; the\nmiddle delivery is 88 words and the longest 310. `around` shows everything, whole. For the other notes the\nhook is silent.\n\nThe founder's own register of connections (`connection-add`, in his dotfiles) is read where an entry for\nthis project names a note. Since 2026-10-10 the reminder that watches his messages for a connection or a pointer\n(`connection-nudge`, in his dotfiles) names the graph in any checkout that carries this script: when he points\nat a note or a row the session is told to ask `around` it, and when he joins two notes to put their file\nnames in the register line, so that the line is shown at both.\n\n## 7. Decided by Claude without asking, and his to change\n\n- **Files and no database.** He asked about a separate graph database. At 345 notes the whole index is\n  built in a second or two from the files, and a database would be a second copy to keep in step. The\n  one stored part is a text file in the repository. A database becomes worth it when something must be\n  asked that a rebuild cannot answer, and nothing yet is.\n- **No model anywhere in it.** The decision model he named was tried that day as a judge of search results\n  and of a conflict, and failed both (the keeper's working note). A model's place here is to propose a\n  connection, and what it proposes waits.\n- **The hook delivers on opening a note, unasked.** The cost is up to about 200 words in a session's\n  context, once a note, on a quarter of the notes.\n- **A sentence counts as a correction by its words** (*corrected, withdrawn, narrowed, superseded, retired,\n  overstated* and their like, near the name). Read by hand on a sample, about two in three were corrections\n  of the thing named. The rest name it near a correction of something else. The sentence is shown, so a\n  session can tell.\n- **A single-letter ledger id** (A1, J5) counts only in a paragraph that speaks of the ledger, a ruling, a\n  row or an arc, since such ids are also section numbers.\n- **Three readers were sent for the fill**, about one and a quarter million tokens on the keeper's plan.\n  He asked for the fill; how it was done and what it cost were not put to him first.\n- **All 42 of their findings were kept on Claude's reading of both passages.** He has read none of them.\n  A finding he disagrees with is set aside by a later line (`reject`), and the first line stays.\n- **What a session is handed is cut short**: three found connections at most and about 230 characters of\n  each reason, so that a note with many findings does not fill a session's context.\n\n## 8. How to know whether it helps\n\nThe 57 notes were found before the graph existed, so they cannot test what it keeps. The test is forward:\n**each time readers are sent to find what bears on a proposal, ask the graph first and write down how many\nof the notes they then found it already held.** If that number does not rise as connections are kept, the\ngraph is a record and no help.\n\nTwo smaller checks are already true. The note behind the collision of 7 October now announces the ruling it\nis home to (pinned in `tests/test_corpus_graph.py` and in the hook's own tests), and, for as long as the\noutside reader's record holds that finding, the proposal found to reverse it. And a zero count in `stats` for found connections is an alarm after the first time\nreaders are run, never a pass.\n\n**First use by another session, the same evening** (the founder's report, with a screenshot: *\"Seems like\nthe corpus graph is doing its job 🙂 (this is from a separate session)\"*). A session asked how much of what\nlies under a link the machine should write out began by asking the graph, and then told him that he had\nalready ruled on the matter twice in August (the machine works out what is under every claim; nothing that\ncan be judged apart stays bundled) and that its own October proposals had narrowed both without saying so.\nThat is one use, described by the session that made it. It is not the count this section asks for, and it\nis the first sign that the count is worth keeping.\n\n**The first count, 2026-10-10 in the evening** (the session that had sent those three readers). Before\nthey were sent, the graph was asked about 42 ledger rows and notes on how machine passes are checked, and\nits answers named 67 notes. The three readers' reports then cited 77 notes. **The graph had named 33 of\nthe 77.** The 44 it had not named are mostly notes on what a person's checking can be relied on for, the\npublic pages, and the red-team notes, which no written link joins to the notes on machine passes. The\ncount is crude: *cited* includes a note a reader opened and found nothing in, and *named* is any mention\nin the graph's answers. Twenty-three of the readers' findings were then opened at both ends and kept, so\nthe next count on this subject starts higher\n([quality-control-for-deeper-steps.md](../quality-control-for-deeper-steps.md) § 10).\n\n## 9. The first fill (2026-10-10)\n\n**His word**, the same afternoon, when the build was reported: *\"This could be a breakthrough? Here's\nhoping... If it looks promising, fill up the graph with more substantial connections that you see clearly\nafter reading through the corpus.\"*\n\nWhether it looks promising was Claude's to judge: the one real case works, discovery was measured not to,\nand a fill is itself the test. **How much was read, said plainly: the corpus was not read through.** Three\nreaders read 27 recent notes in full and searched the rest for what bears on them. Claude opened the\npassages on both sides of every finding and of 45 pairs. For the other notes nobody has yet read.\n\nWhat was put in, and how each kind is known (`stats` gives the live count; 121 kept after the first fill, 166 by the evening, after the second round below):\n\n- **56 from three readers of 8 October**: from 52 older notes (the other five of the 57 of § 4 are not\n  named in the rows of the reports) to the eight proposals they bear on (ledger rows AD22 to AD29), each with the reader's own sentence on what it would change and the line of the\n  report it stands on. Put in by `import_readers_of_2026-10-08.py`, beside this file, which reads the three\n  reports in `../what-a-rule-rests-on/` and finds each walkthrough sentence by its quoted words. A\n  connection to a ledger row is told at the row (`around AD25`) and at the note the row calls its home.\n- **42 from three readers sent that afternoon.** Each was given eight to ten recent notes that hold\n  unruled proposals and asked which older notes bear on a specific passage and are not named by the note.\n  Each returned fourteen findings with both passages quoted. `keep_reader_findings.py`, beside this file,\n  checked every quoted passage against the file it names (all 84 stood), and Claude then read both passages\n  of each. All 42 were kept, seven with a note on what that reading added. The reports are in `readers/`,\n  word for word. The three together used about one and a quarter million tokens of a mid-size model and\n  took 15 to 20 minutes each.\n- **23 from Claude's reading of pairs that lie near in meaning and that neither note names.**\n  `near_and_unlinked.py`, beside this file, lists such pairs with their two nearest passages; it proposes\n  and keeps nothing. Of 45 pairs read, 22 were kept, 22 were set aside and one could not be judged (three\n  files share its name). One more connection came out of a pair that was itself set aside. A pair set\n  aside is recorded so that it is not listed again. This list finds one class only: two notes on the same matter that do not\n  know of each other (two audits of the conceptual threads, written in March and in July; two notes on\n  whether what is weighed can be decomposed; the two halves of the science question).\n\n**A second round, the same evening.** His word on the connections that neither note states: *\"I want\nmore of these.\"* Three more readers were sent, to 28 files this time: eight notes on sameness and\nconcepts, nine on strength and the ontology, and five public pages with six notes on convictions and\ndaemons. Each returned fourteen findings; all 84 quoted passages stood; all 42 were kept, eight with a\nnote on what the second reading added. They used about 1.1 million tokens of a mid-size model together.\nThe readers were also asked to mark the same mechanism found in another field or at another scale: 3 of\nthe 42 are that, and what was learnt from it is in [the-analogy-daemon.md](../the-analogy-daemon.md) § 8,\nsince the founder saw the likeness (*\"this is quite analogous (haha) to the analogy daemon, innit?\"*).\nBy kind, the 42: 17 narrow a passage, 8 supply a piece it lacks, 6 are a later correction, 5 show the\npassage already answered, 3 are the same mechanism elsewhere, 2 the same idea earlier, 1 a contradiction.\nTwelve of them, where a later ruling or measurement had left a line out of date, were written into the\nnote as one dated sentence the same evening and marked `written`. Six concern a sentence on a public\npage or a line every session loads and are listed for the founder in `TODO.md` § The corpus graph.\n\n**What the fill showed.**\n\n- **A reader who reads finds a different kind of thing than search does.** Most of the 42 are of one\n  shape: a recent note states something that an earlier ruling, measurement or design already answers,\n  narrows or contradicts. None of the six rankings of § 4 is built to find that.\n- **Four findings touch a line every session loads, or a public front page.** They are filed for the\n  founder in `TODO.md` § The corpus graph, since a canon line is his to rule.\n- **The hook reaches helpers too.** One reader's report ends by saying that each note it opened came with\n  what other files had judged about it.\n- **The list of near pairs often shows the wrong passages.** The nearest two passages of a pair are\n  frequently the two notes' lists of sources. Leaving such passages out is the next repair to that script.\n- **Kept findings are delivered and, fourteen excepted, not yet written in.** A finding is told to a session\n  that opens either note. The lasting form is a sentence in the note itself, after which the tie is a\n  written one. Two were written in on 2026-10-10, on the founder's word (*\"Go for it\"*): the statement\n  that a debate's crux is stated on one side and implicit on the other, reworded in 22 places to what\n  the run's own text shows, and the price of a whole extraction on Claude Sonnet. Each is marked\n  `written`, which keeps it on record and stops handing it to sessions. The other twelve are the\n  second round's, above.\n\n## 10. What it does not do\n\n- **It does not find an unexpected connection.** § 4 is the evidence. The only thing shown to find them is\n  a reader reading the notes, which costs what it costs.\n- **What it holds is what was looked for.** The found connections are about the proposals of 7 October\n  and the notes later readers were sent to (§ 9). A note with nothing found about it has not been read\n  for, which is different from nothing bearing on it. `around` says for each note whether a reader has\n  been through it, and `unread` lists the notes where none has (§ 12).\n- **Its correction list is words.** It misses a correction phrased any other way.\n- **It knows a note's section only by the heading above a line.** Ties are between notes; a section is\n  where a tie was written.\n- **It is delivered on one machine.** A cloud session has the script and the files and no hook; it can ask\n  with `around`.\n\n## 11. Beside search by meaning (2026-10-10)\n\nHis question, the evening of the fill, with a plan open in another session for the same kind of graph over\nhis other repositories: *\"…all this about corpus graphs and how it can dovetail with mannaminne meaning\nsearches. What's your take?\"*\n\n**The two answer different questions and are entered by different keys.** Search by meaning takes a\nsentence and returns the passages nearest to it. The graph takes the name of a note or a row and returns\nwhat other files have judged about it. Search is how a session finds a note it cannot name. The graph is\nhow it learns whether what it found still stands.\n\n**The join that pays runs from search to graph, and it is built** (`search`, § 6). A worked case from the\nday it was built. The question *how likely is the next contribution to say something new* returned seven\nnotes. One was the note that proposes a gauge for exactly that, read off how many claims have been seen\nonly once. The graph added what a reader had found that afternoon: another note measured that almost no two\nclaims in the graph have yet been found to be the same claim, so nearly every claim counts as seen once and\nthe gauge would say *still new* everywhere. The note holding that measurement was not among the seven.\n\n**Why it pays.** A search hit is a passage at rest: it comes back the\nsame whether or not a later note corrected it. Every hit carries a path, and the path is the graph's key,\nso asking the graph about each hit is one lookup. The case from this corpus: the sentence that a debate's\ncrux is stated on one side and implicit on the other stood in 22 places, and a search on that subject\nreturned any of them with no sign that the run's own text said otherwise. This is the join in the plan for\nthe other repositories, made in the check that follows a reply which advises him, and the idea is his.\n\n**The other direction is weak, and measured** (it would be: take a note, ask the search which notes are most\nlike it, and treat those as the notes that bear on it). A worked case from the same day: the passage that\ntells a refinement from a retreat to a safer definition was put to the search. Its twelve nearest notes did\nnot include the note with Lakatos on barring a counterexample, which a reader had found to describe the same\nmechanism. The two share a structure and no vocabulary. Likeness of meaning as a way to *find* which notes bear on\neach other held 20 to 25 of 57 known connections against 15 by chance (§ 4). The second round of readers\nshows why in small: three of its findings join a note to the same mechanism in another field, and such\npairs share no vocabulary. One of those three is itself the warning, since selection by similarity keeps\nwhat is common and loses what is rare. So search by meaning should not choose what a reader reads.\n\n**A third join, untried: what the graph keeps can be searched.** A kept finding says in one sentence how\ntwo notes relate, in the words of both. Once those sentences are in the search index, a search from one\nnote's vocabulary can reach the far note through the finding. The readers' reports are ordinary notes in\nthis repository, so the nightly index should take them in with no work. Whether a search then returns\nthem is unverified; the check is one search after the next index run.\n\n**The two are a day apart.** The graph is read from the files at the moment it is asked. The search index\nis built nightly: on the evening of 10 October a search describing this graph returned nothing written\nthat day. Corrections sit mostly in the newest notes, so for a day the graph is the only one of the two\nthat knows of them, which is a second reason for the join from search to graph.\n\n**Two copies of the code.** The engine for the other repositories was lifted from this script, and this\nscript stays in this repository so that a cloud session can run it. What keeps the two from drifting is\nthe check that they print the same for every note here. It was run once when the engine was built;\nproposed: keep it as a standing test.\n\n## 12. When to send a reader, now that the graph exists (2026-10-10)\n\nHis question, on seeing another session send three readers through the corpus that evening: *\"Silently\nwondering if that's just plain good practice or if it's wasteful when we have this fresh corpus graph that\ntracks the links between all the ideas in the corpus basically already... What's your take?\"*\n\n**The graph does not hold the links between all the ideas.** It holds every link an author wrote, and the\nconnections that readers found in the notes they were sent to: 56 of 353 notes by that evening (`stats` has\nthe live count). For the other notes nothing unwritten is on record, because nobody has looked. A reader\nreading the notes is still the only thing measured to find a connection that nobody wrote (§ 4).\n\n**So a reader is good practice where the graph is blind, and waste in three cases.**\n\n- **The notes were read for already.** Until that evening the graph could not say so: a note with nothing\n  found looked the same whether a reader had been through it or nobody had. Now `around <note>` says\n  whether a reader went through the note and when, `unread` lists the notes where none has, those holding\n  the most open proposals first, and `read` records a reading (`read-for.jsonl`, beside this file). The\n  first six readings were recorded from their reports, three of them from the findings alone, so a note\n  one of those three read and found nothing on is missing.\n- **The job is a topic scan.** *What does the corpus hold on this subject* is what search by meaning does\n  well, in seconds, and `search` (§ 6) adds what was judged about each note it returns. A reader earns its\n  cost on what bears without sharing words (§ 11).\n- **What the reader finds is not kept.** A report left beside one note is met again only by whoever opens\n  that note. Checked and kept (`keep_reader_findings.py`), each finding is handed to every later session\n  that opens either of its two notes, so nobody pays for that reading twice.\n\n**The order that follows.** Ask the graph by name about the notes and rows the work builds on. Search by\nmeaning for the subject. Send readers only to notes that `around` says nobody has read for. Keep what they\nfind, and record the reading. A reader costs about 400,000 tokens of a mid-size model for fourteen\nfindings, which is the price the three checks are there to spend well.\n\n## 13. The widening (begun 2026-10-10, evening)\n\nHis words, on reading that readers had been through 56 of 353 notes: *\"Only 56 out of 353 notes have been\nmined? If I'm not misunderstanding, then let's drastically increase that coverage now.\"* And, the same hour:\n*\"in most sessions in Deliberus, what's being discussed has many existing connections to the rest of the\ncorpus. So instead of launching expensive subagents, the main agent should always search in the corpus graph\nfirst, am I right?!\"*\n\nHe is right on both, and the two belong together. **A session asks the graph first, always** (`around` for\nthe notes and rows it builds on, `search` for the subject), and that is only worth as much as what readers\nhave put into the graph. So the notes are read once, now, and every later session asks instead of sending\nits own readers.\n\n**What is read.** The notes that hold positions and that no reader has been through (216 when the widening began; `plan_readings.py` lists what is left): the public pages and the research notes. Left\nout as reports and records: readers' and helpers' reports, listening pieces, session notes, dossier side\nfiles and the generated frontier page (137 files; `plan_readings.py --all-kinds` includes the session notes\nand side files).\n\n**How.** `plan_readings.py` groups the unread notes into batches of about 300 KB, each built from notes that\nalready name each other, the ones holding open proposals first. Three readers run at a time, each on the\nbrief in `reader_brief.md`. When one returns:\n\n1. `file_reader_report.py <the helper's output file> --slug … --what \"…\"` files the report unchanged under\n   `readers/` and records the reading.\n2. `keep_reader_findings.py <report> --width 1 --cut 600` checks every quoted passage and shows both ends.\n3. Both passages of each finding are read, and the finding is kept (`--keep`, with a `--note` where the\n   reading adds something) or set aside with its reason (`--reject`).\n4. Commit, and send the next three (`plan_readings.py --brief 1`, `2`, `3`: the plan moves on as readings\n   are recorded).\n\n**What is done with a finding.** It is kept in the graph and handed to any session that opens either\nnote. Beyond that, by what it touches. Where it shows a statement in the always-loaded instruction file to be\nout of date against a ruling or the code, the ruling or the code is checked and the statement gets a dated\nmark: a repair. Where it concerns a sentence on a public page or a line of the convictions, the page is left\nalone and the finding goes on the list in `TODO.md` § The corpus graph, which the founder goes through one at a\ntime (his word, 2026-10-10: *\"let's go through these, one by one, briefly\"*).\n\n**Where it stops.** When `plan_readings.py` lists no batch. Claude first set a pause at 35% of the plan's weekly\nmeter. The founder lifted it the same evening: *\"The cost is fine, it can eat some of my weekly usage. It feels very much worth it for the long-term work in Deliberus (same for the other corpus graphs; this widening should pay off)\"*. The first three readers\nmoved the weekly meter by about two points. One practical pause is left: if the five-hour meter nears its\nlimit, wait for it to reset, since reaching it stops his other sessions too. A reader costs about 400,000\ntokens of a mid-size model.\n\n**After the widening.** A note written later has had no reader. The proposed rule, unruled: a new note gets\none reading when it is written, as a proposal row gets its outside check.\n\n## 14. Beside the open reviews (2026-10-10)\n\nShown the first sentences from the widening that were his to rule, the founder asked:\n\n> \"The list of inconsistencies you're surfacing for my word on here... Isn't this quite similar to\n> what I've been trying to accomplish with the four reviews etc that are documented as high priority\n> since a while back now?\"\n\n**It is the same job, reached from the other end.** The register of the reviews (`TODO.md` § OPEN\nREVIEWS) says what the job is: *deciding what the project's canon is and where it lives*. A review\nstarts from a position and asks whether he holds it, whether it can be said plainly to a stranger,\nand whether it must be loaded in every session. A reader starts from a page and asks whether a\nsentence on it still agrees with what is held. A reader's finding on a public page, or on a line\nevery session loads, is a place where the canon and the page have come apart.\n\n**What the readers show that the reviews had no step for.** A ruling changes a ledger row, and\nsometimes a line every session loads. Nothing then carries it to the pages that still state the\nearlier version. The corpus has named this gap twice before, on other surfaces:\n\n- the review of rulings filed as to-do items (2026-09-21): *a misfiled ruling is a ruling that does\n  not fire*, and compressing more positions into a stage that leaks is work spent upstream of the leak;\n- ledger row R1 (2026-09-26, open): the bottleneck is integration, since ideas do not reach the\n  ledger, the ledger does not reach the code, and nothing checks one against the other. Row R6\n  proposes tests where a ruled position has a checkable form in code. A reader is the corresponding\n  check for prose, and the only one so far.\n\n**Four kinds of finding, and where each belongs.** Proposed 2026-10-10. **He allowed the first two the same evening and then drew the\nline more closely**: only where he himself has ruled, and with every sentence on a public page going\nto him one at a time (§ 15 has his words). Where the last two go is still a proposal.\n\n| A finding says | What it is | Where it goes |\n|---|---|---|\n| a ruling of his exists, and a page, a resident line or a note has not caught up | a repair | in a research note, a dated line with his words, added by Claude and logged; on a public page or a resident line, put to him one sentence at a time (§ 15) |\n| an open question, in a note or a ledger row, that a later ruling of his already answers | a closed loop nobody closed | the note is marked with a pointer to the ruling; a ledger row gets the pointer and keeps its state, which is his to change |\n| a page says more than a measurement supports, about a position he holds | wording of a conviction | the constellation tile or the resident line for that position, ruled once there, and the pages follow |\n| a page asserts what nothing has ruled | an unruled position | a ledger row, if it is not one already |\n\nThe last two need him, and arrive inside a review he already runs, as a tile or a row, and not as a\nfifth queue. So does any sentence on a public page.\n\n**Counted that evening**, with three waves of the widening in: 344 connections kept; in about a\nquarter of them the reader's reason names a ruling (86 by a word search over the reasons, which is\ncrude); about one in eight touches a public page.\n\n**What a reader cannot do.** It finds where a page and the record disagree. It does not say what he\nholds, and where nothing is ruled it can only show that. So the readers shorten the reviews and do\nnot replace them: the open rows of the ledger still need his word, fewer of them once the rows a\nlater ruling already answers are marked.\n\n**What it has given, in his words** (2026-10-10, three sentences into the walk-through of § 15):\n*\"We're making such great progress! I'm so happy with how the corpus graph has helped us get a\nholistic, integrated sense of the whole project's ideas and visions and inconsistencies and dilemmas.\"*\nThat is the use to keep in view when deciding what the graph should do next: its worth so far has\nbeen less in any single connection than in showing the whole corpus against itself, where a position\nwas ruled, where a page still says the earlier thing, and where two notes pull apart.\n\n**A consequence for when the reviews are done.** Ledger row R5 asks for an exit condition for the\nreviews. If a ruling is not finished until the pages agree with it, the exit condition has a\ncheckable half: every public page has had a reader through it since the last ruling that touches it\n(`corpus_graph.py unread`, and `around <page>` for what is still delivered there).\n\n## 15. Repairs: what he allowed, where he drew the line, and how one is made (2026-10-10)\n\n**What he said, in order.** Asked whether Claude may repair the first two kinds in § 14 and report\neach: *\"You may do those repairs. We can always undo them if I'm dissatisfied.\"* Then, on the same\nanswer of Claude's: *\"As long as I actually myself have ruled something. But ofc a doc can also be\nspeculative or touch on something visionary or talk about potential, in which case I wanna go through\nit consciously I think\"*. And on the sentences the readers had found on public pages: *\"I wanna go\nthrough all of these carefully one by one\"*.\n\n**So the line runs here:**\n\n- **A repair without a new word from him needs a ruling he himself made**, on record in his words. A\n  later build, a measurement, or another note's analysis is not enough, however clear it looks.\n- **A sentence on a public page, or on a line every session loads, goes to him, one at a time**,\n  whether or not a ruling exists. Those pages are where the project speaks about its vision and about\n  what could be, and he goes through each change consciously. One sentence a turn, in plain words,\n  with what the record says and a proposed wording; the page is edited on his word.\n- **What Claude does alone**: where a passage in a research note is answered or overtaken by a ruling\n  of his, a dated ⚠ line is added after the passage, with his words and a pointer. The note's own text\n  is left as written, since a note is a dated record of what was thought that day.\n- **Everything else stays a kept finding.** Nothing is lost by that: the graph hands it to any session\n  that opens the note (`around`).\n\n**A reader's reason is a pointer, not a reading.** The first sentence prepared for him under this rule\nwas the vision page's passage on convergence. A reader had reported it, and Claude had passed it on,\nas stating the thesis *flat*. Read in its paragraph it says the values *may be* universal and goes on\n*if this convergence thesis holds*. So before a sentence is put to him, or a line is added to a note,\nboth passages are read in their sections, and where a phrase is at stake, the page where it was born.\n\n**The steps for a line added to a research note:**\n\n1. `repair.py candidates` lists the kept findings that qualify by their kind or by naming a ruling. It\n   only lists. Read both passages in their sections, and check that the ruling is his and what its\n   words are.\n2. `repair.py mark ROW --say \"…\"`, with his ruling quoted. The tool adds the dated line, says in the\n   graph that the finding is written in (so it is no longer handed to a session), and adds an entry to\n   [repairs-made.md](repairs-made.md), which is the report he was promised and what he reads to undo one.\n3. Search for other places that repeat the overtaken statement. Where one is a public page or a\n   resident line, it joins the list for him and is not edited.\n4. Commit with the prefix `correction:`.\n\n**How a sentence is put to him** (the shape that has worked, and his briefing protocol): first its\nwhole record is gathered with `repair.py record` (§ 16), since a reader's finding is one witness; then\none sentence a turn; the sentence quoted; what the record says in plain words with one concrete example; two\nwordings Claude would stand behind, one marked as its pick; then his word, written down in his words\nbefore the page is touched. **He may answer with what he believes instead of picking**, and then the\nwording is built from his words and put back to him. The second sentence went that way: shown a study\nin which experts who disagreed did not converge, he answered *\"Well, they didn't use Deliberus. :)\"*\nand said what he believes it will add; the wording kept what research shows, what the wager is, and\nwhat the system aims to do apart, and he blessed it. A page states a belief of his as a belief or a\nwager, and a capability as an aim until it is built. **And where the record is about what the system\ndoes, it is checked against the code before it is said to him.** On the fourth sentence Claude told him\nthe system issues no verdicts any more; read in the code, a label called a verdict survives in the\ncompleteness check, and a person can still record that a claim has stopped holding. The correction went\nto him before he ruled.\n\n**For a sentence he has ruled on in the walk-through**, `repair.py swap ROW --file … --old … --new …\n--because \"…\"` replaces it and logs it the same way. The first one made (the design-principles page,\non composing as retrieval) had two other places that repeated it, a candidate tile and the landing\npage's draft wording, and both were corrected with it. A change to a page shows on the site only at\nthe next deploy, and no deploy is made for one.\n\n## 16. The whole record of a sentence, before it is put to him (2026-10-10)\n\n**What happened.** The sixth sentence of the walk-through was the positioning page's *\"An\ninfrastructure layer that audits its own distortions has no precedent at all.\"* It was put to the\nfounder on one reader's finding (the July review points to Registered Reports), with a proposed\nwording that still said *has no precedent*. He asked twice for more: *\"Can you think a bit more\ndeeply on this and see if there are other parts of the corpus that bears on this?\"*, and then *\"Did\nyou look into the fractal priors docs?\"* Each question changed the proposed wording. Then: *\"And we\nneed to look at why these repeated prods from me were necessary...\"*\n\n**The count.** One kept finding bore on the sentence before he asked. Seven do now: four found after\nhis first question (the July review's own section on self-audit, the ledger with audit, his conviction\nthat checking comes from outside, the open-problems page), two after his second (a channel that\nreports its own errors recurs at every scale that accumulates; the chart and the ledger each had half\nof a shared record that checks itself).\n\n**Why he had to ask, as far as the record shows.**\n\n1. **One finding was treated as the record.** The reader that covered this page had eleven notes and\n   room for eighteen findings. It kept three on the page and one on this sentence. The steps in § 15\n   said to read the passage in its section, the finding's source, and the code. No step said to look\n   for what else bears on the sentence.\n2. **The index reads as coverage.** It says a reader has been through the page, which reads as done.\n   It keeps what was found and cannot show what no reader looked for, which is the corpus's own\n   *coherent absence*, in the tool built against it.\n3. **The search was made in the sentence's own words.** The notes that bore on it most say *confess*,\n   *monitor*, *sensor* and *the books must balance*, never *audit* or *precedent*. They are reached by\n   asking what kind of claim the sentence makes: a claim of no precedent is a claim about patterns\n   across cases, which is those notes' job. The topic index that every session loads points at both,\n   and it was not consulted.\n4. **A finding that arrives with a ready wording ends the search.** The July review offered a narrower\n   claim, and the first pick took it. Claude's standing rule that a pick goes out only when its own\n   thinking is exhausted asks for a judgment (would more thinking change the options), and with a ready\n   fix in hand that judgment answers no. Three earlier corrections in this walk-through had the same\n   shape and were each patched alone (read the passage in its section; check the code; read where the\n   word was born).\n\n**What changed.** A sentence's record is gathered by a command, before any wording is written:\n\n    uv run python docs/research/corpus-graph/repair.py record ROW --kind precedent \\\n        --ask \"the sentence's question, as another author would put it\" --ask \"a second way\" \\\n        [--phrase \"words of the sentence\"]\n\nIt refuses fewer than two questions, refuses a question that mostly reuses the sentence's own words,\nand refuses until the kind of claim is named (`precedent`, `system`, `people`, `belief`, `word`). It\nprints the paragraph, the reader's finding as one witness, the notes to open first for that kind, what\nother files have judged about the page, the rows of the topic index that share words with the\nquestions, a search for each question, and every other public page or resident line that repeats the\nphrases. Run on the sentence that prompted it, it names both notes that had been missed, by kind and\nthrough the topic index (`tests/test_corpus_graph_repair.py` holds that case).\n\n**What it does not do.** It prints, and cannot know which notes were then opened. The notes listed for\neach kind are a short hand-made list and a starting point. Where search by meaning cannot run (a cloud\nsession), it says that part of the record is missing.\n\n**A question from him for more depth is a measurement.** When he has to ask, the note that was missed\nis recorded as a connection, and the reason the step did not reach it is added here: a kind whose\nlist lacked the note, or a question nobody thought to ask.\n\n## 17. Why the index did not hold them, and what would (2026-10-10, his question)\n\n**His words**, on the six connections of § 16: *\"Weren't these connections that you unearthed mapped by\nthe new corpus graph? Quite curious about this. I want to make it as close to bullet-proof, even about\nmapping more \"distant\" analogy-based connections...\"*\n\n**They were not, and the count says why.**\n\n- Of the seven connections that bear on the sentence, the index held one. For the other six it held\n  nothing in any form: no reader's finding, and no written link in either direction (the page names none\n  of the five notes, and none of them names the page).\n- The index holds what a note says outright about another note, and what a reader found. So each of\n  these connections had one chance: the one reader sent through that page.\n- That reader had eleven notes and room for eighteen findings. Over the whole widening, readers kept a\n  median of two findings a note (549 findings on 277 notes).\n- **Every reader was sent to the note being judged, and all six missed connections are notes that judge\n  something the page states.** From the judging side the page is easy to find: the cross-scale note's\n  section is headed with the conviction's own name. From the page's side, a reader has to guess that a\n  note about cells and ledgers has a view on a sentence about infrastructure.\n- Of the 549 findings, 34 are *the same mechanism elsewhere*, about one in sixteen, which agrees with the\n  counts in [the analogy daemon](../the-analogy-daemon.md) § 8. § 4 above already measured that no ranking\n  computed from the files finds such connections, and that a reader working from a one-line card for\n  each note does not either.\n- About half of the six are plain bearing that a deeper search finds (another section of the July\n  review, his conviction about who does the checking, the other public page). The other half rest on an\n  analogy (the ledger, the sea chart, the cell).\n\n**What would get closer** (proposals, unruled), in the order tonight's miss points to:\n\n1. **The project's named ideas as points in the index.** The convictions and principles every session\n   loads, the eight classes of error, the lenses of the success prior: each is an idea with a name, which\n   many notes test and many page sentences state. Each would be tied to the notes that test or narrow it\n   (much of that can be read from headings, since the cross-scale note has a section for each\n   conviction) and to each public sentence that states it (one reading of each public page). A page\n   sentence then reaches every note that judged the idea it states, through the idea, with no shared\n   words needed. Tonight's sentence states the confession conviction, and the note that tests that\n   conviction against cells and flight recorders would have been one step away. This is how a distant\n   connection becomes a near one: both ends are instances of something that has a name. It is kept in\n   this index of notes. Nothing is stored in the claim graph, and his hold on storing beliefs about\n   Deliberus inside Deliberus stands.\n2. **Reading from the judging side.** A reader goes through each note whose job is to judge others (the\n   cross-scale tests, the red-team notes, the syntheses, the audits, and each ruled row of the ledger)\n   and is asked where the thing it judged is stated, on a public page or a line every session loads.\n3. **A number for what one reading misses.** A second reader goes through one batch, blind to what the\n   first kept. The overlap between the two says how many connections a single pass leaves behind, by the\n   same reasoning the corpus proposes for claims (the share of findings seen only once). Until that is\n   measured, *read once* is the honest label, and § 16's step is the guard at the moment a sentence is\n   used.\n4. **For kinship that no named idea covers**: the card stating the move a note makes without its\n   subject, held on 2026-10-10 and untested in that form (the one-line card of § 4 was another card);\n   the connections he draws himself, which are delivered first; and the measured yield, which says to\n   expect few.\n\n**What bullet-proof can mean here.** An index of findings cannot show what nobody looked for. What can\nbe had is a measured miss rate that falls, and a guard at the moment of use.\n\n## See also\n\n- [The analogy daemon](../the-analogy-daemon.md) § 8: the readers who fill this graph, read as a rehearsal\n  of that design.\n\n- [The outside check](../outside-checks/README.md): the reader whose findings the graph delivers.\n- [Practices for interconnected research](../practices-for-interconnected-research.md): what peers do\n  about the same problem; lessons 2, 3 and 5 are what this tool serves.\n"}