graphs.sgit.ai → admin → Release history

Release history

Every push to dev is a release. The version is owned by admin/build/version.txt, must appear in the release commit’s subject, and is tagged automatically by CI once validation passes. How that works →
This page holds the v0.6 era: review as change control. The past is kept whole, each closed era with its retrospective: the v0.5 era (24 releases, three books came out of the surface, weighed here) · the v0.4 era (41 releases, the working surface, weighed here) · the beginnings, v0.1–v0.3.

VersionDateWhat changed
v0.6.22 20 September 2026 The evidence estate gets four more graph vaults, and a second cross-vault finding. The second half of brief 47. The first edition analysed five published vaults and froze with them, so /v1/vaults/ cannot take a new one; /v2/vaults/ is the live evidence estate and holds the four rungs of the sgit.ai ladder this site had never looked at: Standards Atlas: GDPR, Provenance is not conformance, Licence to Operate and Scaling Threat Modeling with Semantic Knowledge Graphs. The honesty problem, and the gate built for it. The first edition’s five analyses were written by opening the vaults. This agent cannot open a vault: the read key is the whole credential and nothing in the build can decrypt one. So every number on these pages is a second-hand reading of the page sgit.ai publishes about that vault, and saying so once in small print is not enough. Each fact carries the sentence it came from, all five source pages are carried whole in v2/vaults/sources/ with their SHA-256 and the timestamp they were fetched at, and gen_vaults.py fails the build if a quotation is not in its carried file byte for byte. Thirty-two facts, thirty-two verified quotations. Every page says on itself that it was read from a page rather than from a vault. The second cross-vault finding, which is of a different kind from the first. The capability scale came out of comparing five vaults. This one comes out of a join: AIUC-1 publishes 1,126 crosswalks as text, the conformance layer resolves the EU AI Act ones into node ids in a second published vault, 62 resolve onto 27 articles, and the traversal then returns what neither vault knew alone, that 8 of those 27 articles have since been amended, so the crosswalk was written against the pre-amendment text. Two organisations, two vocabularies, nobody merged anything, somebody named the edges. That is meaning through connectivity producing a fact. Three diagrams, lifted rather than redrawn. The zoom, the jump and the eleven-rung ladder are inline SVG taken from the sgit.ai page source, carried with a credits file saying exactly what was taken and what was not. Redrawing a picture that is already correct produces two things to keep in step. The ladder is inlined rather than embedded because its twelve links are live; they were written relative to the page they were published on, so the generator resolves them against their origin at render time and leaves the carried file alone. validate.js caught that on the first build, which is the right order of events. What the vaults say about themselves travels with them. Standards Atlas carries a not-legal-advice banner on every view and calls its overlays a seed; the AIUC-1 layer is explicit that it is unofficial, derivative, not endorsed, that its subjects are invented, and that a removal request will be honoured. Those caveats are reproduced on our pages rather than summarised away, which is the same rule this estate applies to its own corpus. One of them is a finding about us: the Standards Atlas graph has six edges typed relates, the one verb this site’s grammar bans, and the vault records it rather than fixing it because its seed graph is deliberately immutable.
v0.6.21 19 September 2026 The fractal claim, corrected, after a sibling site read the book and said the invariant was backwards. sgit.ai published Fractal Semantic Graphs the same day: a definition, three diagrams and seven live vaults walked as one ladder from the text of a law to a threat on a compute instance. Its agent sent a brief, carried here verbatim, whose one-line version is that where this site says identical rules at every altitude it should say the same grammar at every altitude, and a different ontology at each. That is right. What survives a zoom is the grammar, verb edges with inverses, meaning in connectivity, supersede never delete, provenance kept; the ontology is meant to change, and a system whose types and verbs are identical all the way down is a hierarchy. The book moves to v0.3.0. Chapter 6’s four-row table, its zoom test, the front matter’s third learning outcome and the reference card entry are all restated. The zoom test now has two halves: same types all the way down is a hierarchy, a different grammar makes the claim false, and a new ontology joined by a named edge is the claim working. The brief was right about the claim and wrong about how it got there, and the review says so. The book was not contradicting the corpus, it was quoting it without carrying its definition: the 12 July 2026 architecture brief names the rules in the same sentence that demands them, “the same node and edge grammar, the same validators, the same query engine, and the same provenance rule apply at every altitude”, and the vocabulary is not among the four. The chapter now quotes that definition instead of assuming it, and anchors the correction to the corpus document that states it outright sixteen days later: “some articles will be substantial enough to need their own ontology and taxonomy rather than fitting the one above, which is not a complication but the expected fractal behaviour”. The uncomfortable finding, which nobody asked for. This estate had already made this exact correction. On 23 August 2026 the founder recorded that uniformity is the mechanism and not the claim, and the Universe volume carries it in full with the superseded definition dated. It never reached the other book, and never reached the agent surface, where it stood for four more weeks. A correction recorded in one book and not propagated to the other two is a document drifting from its source, one layer up, and nothing in the build was watching. A sibling site’s reader found it. Sharpening the test cost the book a verdict. Chapter 6 re-runs its own test on this estate and the answer is worse than before: the document-to-word zoom is five altitudes in one vocabulary, which by the first half of the test is a folder tree with very good addressing, and it had been scored a pass since v0.1.0 because the old test never asked. The fractal move here is across the decomposition rather than down it, the pilot document’s core graph and extraction being two ontologies over one document. The front page said the same wrong thing as of yesterday and now says this instead. Declined, and why. The brief asks for four first-edition pages to be rewritten. /v1/ froze at v0.3.26, is hashed per file in /v1/MANIFEST.json, and gate 14 refuses a changed byte. The first edition is evidence of what was believed in August 2026; retro-fitting a correct claim into it destroys the only thing it is for. llms.txt now carries a note at the frozen page’s entry saying what it says, that it is deliberately not corrected in place, and where the live statement is. The review workflow had a book-shaped hole. gen_reviews.py was hard-coded to the making-of book, so the first reading of the other book had nowhere to go; it now builds any book with a reviews/ folder. Three small corrections from the brief, each checked against its source today: agentic browser isolation is 7 stakeholder altitudes and not 5 (its own page says so), sentinel.sgit.ai does not resolve and sg-sentinel.sgit.ai does, and sgit.ai now publishes 30 vaults. The dead hostname was in the footer of every live page on this site, 175 of them, because the link checker only resolves internal links. The 92 frozen pages keep it, as they keep everything else.
v0.6.20 19 September 2026 The front page splits in two, because it was answering the wrong person. A reader commented on LinkedIn that he had never heard of fractal semantic graphs and was going down a rabbit hole on it; the reply pointed him here. What he would have met was the word graphs.sgit.ai as a headline, 1,525 words about books, versions and gates, and the phrase he came for appearing four times, every one of them inside a book title or a filename. Nothing on the page defined it. The page also had no image, no diagram and nothing to click, on a site whose whole argument is that meaning is visible through connectivity. So the archive moved and kept everything. The shelf, the sequence of events, what each section is and the complete first-edition index are now /site/, unchanged in substance, because the archive was never the problem: being the first thing a stranger met was. Every link that page carried still resolves. The front door now answers the question people arrive with. It opens with the claim rather than the domain, and it answers the phrase above the fold in the corpus’s own words: “the same structural pattern — nodes with edges, meaning through connectivity — repeats at every level of zoom”, quoted from the carried pilot document and checked against it byte for byte on every build, so the definition cannot drift into a paraphrase. Then it stops describing and demonstrates. The corpus’s own worked example is on the page as a live graph: a field node holding 8080, six edges you add one at a time, and a list of what the graph becomes able to say as you add them. Every one of those sentences is a quotation from the document, not a rewrite, and the build refuses any that is not. The value never changes; only the edges do, which is the entire point the section makes. The nodes drag. The fractal claim is run rather than asserted. Chapter 6 of Fractal Semantic Graphs makes it falsifiable: zoom into any node, and if the zoom needs a different format, validator or special case, the claim is false. The page runs that test on this estate’s own making-of book and shows the six levels with their real counts, from one book to 27,002 word nodes, one decomposition and one validator between them. Three instruments that were built and then never linked, the state map, the project board and the figure viewer, are now on the front page with the six others, under a heading that says you can open them. A gate, and the drift it found. home.test.mjs fails the build if the front page stops defining the phrase the site is found by, stops demonstrating it, or stops naming its own archive; it was run red against a page with the definition removed before it was trusted. Writing it turned up that gen_front.py had never been in the build chain, so the front page had been regenerated only when someone remembered: its release count had been nine releases stale. It and the new gen_home.py are in the chain now, where the existing tracking gate can see them. And a second ignore trap, found the way nobody should find one. The stock Python .gitignore this repository started from carries /site for mkdocs, which this repository has never used, so the new page was invisible to git while rendering perfectly and passing every gate. It was noticed by reading git status and seeing one folder listed and not the other. Issue 005’s gate asks whether the thing that builds the site is in the repository; the new one asks whether the site is. A third gate refuses a counter that returns zero, after the methods card rendered “0 techniques” above a link to thirty-five of them. The founder’s instruction and the LinkedIn thread behind it are brief 46, verbatim, with the measurements that prompted the split. No book content changed: this is tool work, and no book version moved.
v0.6.19 29 August 2026 The state map, and the door nothing has ever passed. Borrowed from newsroom.sgit.ai's brief 10 §8, which reports that the state map turned out more useful than the room it was built beside, for a reason worth repeating: modelling doors makes one fact impossible to keep soft. Nine states, each naming the one role that can advance it and the door the next role will not take the work without. Seven carry a stage of the seven-stage change control; raised and shipped sit outside it, because work exists before the workflow starts and after it ends. The finding, computed rather than written down: approved has two items waiting and nothing has ever passed through it. A door is shut when work is waiting at it and nothing has gone through, and both halves are read off the board on every build. Everything downstream — implemented, accepted — has therefore never been entered by any pack. That does not mean nothing has shipped. The retitle shipped at v0.6.9 while its pack sat at stage 5, which means it went around the workflow rather than through it, and the map says so: the gap between the process and the practice is the useful part, and which of the two to fix is a decision rather than a bug. Before this page, that fact was stated on the board, in two pack records, in the issue tree and in four replies. The gate is the brief's §7, generalised: every visual claim needs a check that re-derives it from the source. This page draws an order, so the seven stage-bearing states must match, in sequence, the stages gen_board.py declares. Reorder one and forget the other and the build fails. Three more ran red first: an exit naming nothing, a state with no door, and an owner who is not a role. And a hazard found while building it, worth its own line. This is the estate's first cross-generator import, and a plain import gen_board read a stale __pycache__ and passed the gate against a declaration no longer on disk. A gate that can be fed yesterday's constants is not a gate. It now loads the declaration from source on every run and writes no bytecode. And yesterday's gate caught this release's own generator, correctly in spirit and imprecisely in fact: it compared against git ls-files, which fails a new file that is simply not staged yet. It now asks git check-ignore, which is the actual hazard — a file git refuses to track, not one that is merely new. Re-proved by ignoring the new generator by name. 132 tests.
v0.6.18 29 August 2026 A bare build/ in .gitignore matches at every depth, and this repository was one new folder away from losing a generator to it. The postscript to a sibling site’s debrief, acted on the same day it was read: that line had been silently excluding their entire generator from every commit since the section was created, and their site kept deploying correctly the whole time, because the generated HTML was committed and only the thing that generated it was missing. A generated site can be green, deployed and completely unrebuildable at the same time, and nothing in a normal build will tell you. Nothing here was ignored — every generator, test and book builder is tracked, and this repository hit the same line at v0.1.0 and fixed it the way they did, with one re-include by name. Which is precisely why the brief warns it recurs. The exposure was live for anything new, checked with git check-ignore: v2/books/<slug>/build/, governance/build/ and assets/build/ would all have been silently excluded. The first is not hypothetical — every book already owns a build.py, and one whose tooling grew into a folder would have vanished without a warning. The rule is anchored to /build/, which is where Python packaging artefacts actually appear, fixing the class rather than adding a second re-include. And the gate checks the outcome, not the rule, because re-including by name is the thing that failed twice: every generator the README chain runs must be on disk and tracked by git ls-files, plus each book’s own builders. Run red by ignoring gen_board.py, which it reported as unrebuildable rather than missing. 129 tests.
v0.6.17 29 August 2026 The making-of book gets a review register and a version diff, and the answer to “do we have reviews for this book” was no. Four reviews existed and all four read the first edition, at v0.3.7 to v0.3.14. This book had one self-review of its own arithmetic and three change-control packs, and the one substantive human reading of it was never recorded as a review at all: the founder read it, said the title did not hold, and that reading survives only as the retitle it caused. The review register fixes that, and r001 is dated after the work it describes and says so. Five findings, two still open: the title is not earned by the body either (six uses of workflow in 27,002 words), and whether the cover names Claude or agents. One is marked superseded rather than closed, because brief 45 dissolved the villager-versus-explorer contradiction instead of settling it — and a review is never edited to match what happened. A review names the version it READ, not the version it produced. r001 is stamped v0.1.0; the retitle shipped as v0.2.0. The build refuses a review naming a version this book has never been at, and refuses an item whose state is not one of the four declared. Both run red first. The version diff reuses the differ built for the first edition at v0.3.x, pointed at this book: v0.1.0 → v0.2.0, 4 of 17 chapters changed, ~6 modified, +3 added, word-level inside a changed block. Two decisions worth naming. The picker offers book versions, not site releases, because the site has moved 117 times and the book twice, and 117 identical snapshots is a worse answer than two real ones. And the units are the chapter markdown rather than the rendered pages, so a template change cannot appear as a change to the book. It is labelled as the text half. Brief 45 sets the bar at a diff computed from the graphs — “that would be the really test measurement of our success here” — which needs a graph stored per book version, and only the current version has one. The page says so rather than letting the cheaper half stand in for the answer. 128 tests.
v0.6.16 28 August 2026 The sticky banner was hiding the content the page had just scrolled to, everywhere, and had been for a long time. The founder spotted it in a screenshot from the release before, where the banner sat in the middle of the page. The agent's first reading was that this was an artefact of photographing a sticky header full-page. That reading was wrong, and measuring it took two minutes where explaining it away took longer. The nav row wraps, so its height is 104px on a wide desktop, 92px on a phone and 55px on an iPad. The site's convention for scrolling around it was two hard-coded numbers, 64px and 70px, so it was wrong at two of those three widths: every in-page anchor on the site landed 34px under the banner — #rules, #figures, every h2 link. The figure viewer shipped at v0.6.15 had no offset at all, which is why it showed up there first and hid 87px of the figure it had just opened. One rule fixes all of it. nav.js now measures the nav and publishes --navh, refreshed by a ResizeObserver on the nav itself so a wrap updates it, and site.css sets html{scroll-padding-top:var(--navh)}, which corrects every anchor jump and every scrollIntoView at once. Measured after: 16 to 17px of clearance at all three widths, and 0px hidden on the anchor jumps that were 34px under. The fallback is the tallest height, because over-scrolling leaves a gap and under-scrolling hides content, and only one of those is a bug. A gate now refuses a hard-coded nav offset anywhere in the stylesheet, and requires nav.js to publish the variable. Run red against the old 64px before it was trusted. The finding is filed rather than absorbed, in the developer's issue folder, including the part that reflects badly: a screenshot is evidence, and an agent looked at one, saw something wrong, and explained it away as noise from its own tooling. Two of this estate's rules cover exactly that. 126 tests.
v0.6.15 28 August 2026 Every figure gets a JSON entry, its provenance and its cross-links, and the book’s loudest claim about its own screenshots becomes checkable. The link on the book page pointed at a GitHub folder listing. It now points at a viewer: twenty figures across fifteen release tags, filterable by release or by chapter, each one opening on where it came from and where it is used. Every field is derived, and that is the whole design. The figure number, the release tag it was photographed at and its slug come from the filename; the width, height and SHA-256 from the file; the caption, the chapter, the section and the line from the markdown that references it; what shipped in the release it shows from the narrated version table; and the date from the tag’s own commit. Nothing is typed in, because a figure’s provenance is a fact about the repository and a fact should not be re-entered by hand where it can drift. The book has always said none of its figures is a reconstruction. That was a sentence in a colophon. It is now three gates: a figure whose tag is not in this repository fails the build, a figure no chapter uses fails the build, and a chapter referencing a figure that is not on disk fails the build. All three were run red before being trusted — renaming a figure to a v9.9.9 tag, adding an orphan, and pointing a chapter at a file that is not there. The cross-links go both ways. A figure names its chapter, its section and the line that uses it; the chapter filter is built by inverting that. The machine surface is figures/index.json, one entry per image, and the file explorer now links a figure straight through to its provenance rather than showing pixels alone. 125 tests.
v0.6.14 28 August 2026 Every agent gets its own work plan as files, and the status is the folder. MAB-08 from the board, and the coordination layer under it. Each of the seven roles now carries issues/open/, issues/blocked/ and issues/done/ on the Issues-FS-lite pattern — the specification from the project the three February 2026 documents in this corpus were written for, which is complete and needs no implementation, which is why there is none here either. There is no status field. A status change is a git mv, and there are exactly four operations: OPEN, BLOCK, UNBLOCK, CLOSE. A field is a second place the truth can live and the two disagree the first time somebody edits one; a folder cannot disagree with itself. The cost is that a status change shows in a diff as a move, which is the point. Fifteen issues to start: 8 open, 4 blocked, 3 done, every one real and traced to the release or review that raised it. The writer rule, written down: you may READ another role's folder, you must NOT write into it. Tasks arrive by request, and a role that edits another's work plan has taken a decision that was not its to take. No build can check that; the diff can, which is how branch discipline is already enforced here. The board now reads the folders rather than holding a copy. The issues board was authored in gen_board.py for one release; it is now derived, so there is one source of truth and the folder is it. A test pins both directions: every file on disk is on the board, at the status its folder says. The explorer, and a renderer for an issue. The issue tree uses the shell promoted at v0.6.12, with a third pure view module: the front matter as a field table, the body rendered, and the status badge read from the path, because a renderer that showed only fields would hide the one thing that matters by not being a field. Above the tree is find v2/team -path '*/issues/open/*.md', rendered: who is carrying what, which the layout gives away for free. Five gate rules, each run red before it was trusted: no created or priority, a priority outside high/medium/low, a file in blocked/ that does not say what it waits on, a file in done/ with no closed date, and a blocked_on on a file that is not blocked. 122 tests.
v0.6.13 28 August 2026 The work around the making-of book gets a Kanban board, and the two things blocked on the same person for the same reason are finally on one screen. The founder’s framing: Issues-FS for the management of the tasks around the book — the coordination and sync of several agents, and the reviews — not for the book’s content, with Kanban to see the flows. The reference is sgraph.ai’s dev dashboard, and its own guide documents the system in full. The four schemas are adopted verbatim — project-workstreams-v2, project-issues-v1, project-agents-v2, project-releases-v1 — so a board here reads on that dashboard and the reverse. The renderer is this estate’s own, for a stated reason: that guide publishes a defect where card helpers interpolate title and description as raw strings. Every value here is escaped, a colour must match a hex pattern before it reaches a style attribute, and four tests pin it with a payload. The mapping that earns the board. A change-control pack is a workstream and its seven stages are its tasks, so “waiting at stage 5 of 7” stops being a sentence in a record and becomes a progress bar. Eight workstreams, 39 tasks, 8 issues, 7 agents. The naming question and the workflow document both sit at 4 of 7, both blocked on the founder, for decisions of the same kind — true before this page existed and visible nowhere. The board is a projection and cannot be edited in the browser. The workstreams and issues are authored once in gen_board.py, because a stage’s status is a judgement in the same way a version move is, and this estate has held since v0.6.5 that a judgement is written down rather than inferred from prose. The roster is computed from v2/team/: a role is active if it has produced a debrief at the book’s current version, idle if it has only worked at an earlier one, and an empty debriefs folder still says honestly that a role has never run. The release log is the book’s own two-clock changelog. One deliberate deviation from the reference, recorded. Its four columns have no Blocked one, so a pack with four stages done and a blocked fifth fell through to Queued and read as not started. Started-and-stalled now renders as In Progress with the block named on the card; anything else understates work already done. The gate found something on its first run, which is the point of writing it first: it refused the build because making-a-book__v0.1.0__the-book-as-a-graph was not on the board. Three packs, three workstreams, checked by name on every release. Two stale numbers corrected in passing, both in role definitions the board now puts on a public page: QA claimed 97 tests in six suites and a 27-gate validator (it is 116 in seven, and 72 failure conditions), and the developer claimed 24 generators and 64 client modules (28 and 71). Neither would have been noticed if the roster had not been rendered. 116 tests.
v0.6.12 28 August 2026 The book gets the file explorer the pilot document has had since v0.5.1. The founder’s question, and the answer was no: there was a window onto one document’s artefacts and none onto a book’s. Now every book has one at files.html, and for the making-of that is 24 folders and 313 files in one tree: the seventeen markdown chapters that are the source of truth, the Leanpub source material behind them, book.json and build.py, the twenty figures, the publishing artefacts, the graph one folder per chapter, and the generated pages. Raw is the exact bytes; the files the build understands carry their own view. Markdown renders. book.json becomes the two-clock changelog with the site release beside each book version, and the chapter hashes the version gate reads. The graph index becomes the chapter table with sections, blocks, words and forms per chapter. Each chapter’s shards become their blocks with the uids that survive an edit. Python is tinted; images are shown rather than read into a <pre>; the 9MB PDF is a link, not a fetch. Every file deep-links, and a deep link opens the folder it lands in. The explorer became shared machinery rather than a second copy. It existed once, for a document; a book made it twice, which is this estate’s rule for promoting something into the kit. The shell moved to assets/explorer/ and now asks two pure view modules in turn, so a third subject brings its views and not a copy of the shell. The document explorer’s published URL is unchanged and its behaviour is byte-identical. One collision the design had to answer: a book’s graph/index.json and a document’s index.json have the same name and different shapes, so the view now resolves on the folder as well as the name, and a test pins both directions. Folders collapse, because two folders want to be open and twenty-four do not, and which start open is set by the generator rather than guessed. The manifest is generated at build, so a new chapter appears in the tree without anyone listing it, and a new gate checks that promise both ways: every file the page claims is on disk at the size it claims, and every file in content/ is in the tree. 107 tests.
v0.6.11 28 August 2026 The estate writes down what a workflow is, and puts the question of whether it belongs in the book to the founder rather than answering it. Brief 45 gives the definition plainly — a workflow is “how you operate… the steps that you have” — and asks for it in four phases: extract, write a source document, transform it into its own folder of graph materials, then connect it to the book. The first three are additive and are done. The fourth changes a book, so it went through change control instead. The map is computed, and it is uncomfortable. The book is called Creating a Book Using Agentic Workflows, and its own graph counts workflow six times in 27,002 words of prose, against 64 uses across the founder’s memos. Every other word in his account of the idea — villager, zone, pacing, maturity, commoditised — appears zero times in the book. The material to make the title true exists, and it was in the memos rather than in the book. The document. Agentic Workflows: How You Operate, a second document in the universe beside the pilot: eight parts, 3,365 words, decomposed to 39 sections and 203 sentences and extracted to 81 anchored nodes, 18 edges, 6 distinctions and 4 aliases. Its central claim is the founder’s measure of maturity, which inverts how a busy week reads: “can I do a process without making any changes to the workflow?” A stretch of releases that each changed the machinery is the price, not the achievement. It declares its own position on the boundary it argues for. The prose is a one-way projection of a memo, and the document says so in a section of its own, because a reference document arguing for keeping sources in the deterministic layer while presenting itself as a source would fail its own test on the first page. The gate that was missing, found the hard way. Every founder quotation in the document was checked by script against the brief it came from, and eighteen of twenty-five did not match: a comma for a full stop, a repeated word dropped, sentence case imposed. All eighteen were corrected against the brief. The universe has a gate saying an extraction cannot cite words that are not there; authored prose has none, and authored prose is exactly where smoothing happens. QA has asked for it. Two documents is not fan-out, and the release refuses to claim it is. The pilot’s promise moved from one document to two: gen_coregraph gained a register so every folder with a source.md is decomposed, and build() itself needed no change, which is what A1 was for. The pilot’s entire output is byte-identical afterwards. But the new document yielded 81 nodes to the pilot’s 57, and that is a fact about who wrote the prose, not about the method: the pilot was written by a human years before the machinery existed, and this one by the agent that extracted it. Also: a document born here has no frozen original under /v1/, so its folder copy is the original and the hub says so; the queued count now counts carried sources only, because a document born here was never one of the 21. A latent defect fixed: the extraction error path crashed with a NameError instead of printing the errors it had collected, and had never run until this document failed twice on the way in. And a stale path corrected in the researcher’s first debrief, the second instance of the defect QA asked for a gate against at v0.6.3. Waiting on the founder: whether to connect the vocabulary to the book (3,500 to 4,500 words, and the book moves to v0.3.0), what to call the process, and which book part one belongs to.
v0.6.10 28 August 2026 A whole book is taken apart to the word and provably put back together. Brief 43 asked for the machinery built for one pilot document to run at book scale. Activities A1 and A2 are done. A1 made the decomposition a function rather than a script: gen_coregraph.build() now takes the document, its output folder, its ledger and its uid prefix as parameters, and the pilot became its first caller. The proof it was a pure refactor is that the pilot’s entire output is byte-identical afterwards, ledger included. A2 added the level the generator did not have. A book is not a longer document; it is seventeen documents with an order, so the ladder is now book → chapter → section → block → sentence → word, and each chapter is decomposed by the same function — which means all seven of the pilot’s gates run per chapter, unchanged. The result, measured: 17 chapters, 165 sections, 822 blocks, 1,782 sentences, 27,002 words, 160 shards, 3.6MB — and every chapter rebuilt byte-identical. That last clause is the one that matters, because it is the claim brief 42’s restructure rests on: a book whose chapters each come apart and go back together exactly can have its opening moved as a transformation rather than a retype, with a gate proving everything that was not meant to move did not. The estimate written before building was ~4MB against 552KB for the pilot; the measured figure is 3.6MB, so the shard model earns its keep and a reader opening one chapter fetches one chapter. Two design choices are recorded rather than assumed. Sharding is per chapter, because brief 43 flagged size as a strain before any code existed. And each chapter keeps its own identity ledger: one ledger for the book was considered and rejected, because chapter identities are independent, a chapter can be reordered without disturbing another’s uids, and a small carry-forward pass stays obviously correct. A gate came with it, checking the artefact rather than trusting the build: the graph’s book version must match the book’s, the chapter count must match book.json, every chapter must carry its formatting graph (the half that makes the rebuild possible), and the totals must equal the sum of the chapters. It was run against a chapter with a paragraph added, and the existing hash gate caught that too. The graph is readable — a table, not yet the instrument brief 43 asks for, and the page says so. 102 tests green.
v0.6.9 28 August 2026 The book is renamed, and it is the first change to a book this estate has made under its own change control. Brief 44 settles the question opened at v0.6.3: the making-of book is now Creating a Book Using Agentic Workflows. The old name was set in the commission and the review found it unearned by counting rather than arguing — fractal appeared nine times in 31,221 words, six of them quoting the other book’s title. Two clocks moved together for the first time, which is what the machinery built at v0.6.5 exists for: the book to v0.2.0, the repository to v0.6.9, and the changelog records the pair with the reason. The gate proved itself in passing — the changelog entry was refused until this row existed, because a book version may not claim a site release that was never narrated, which also settles the order of the publisher’s workflow: narrate first, then move the book. The rename is recorded in the book rather than applied silently. The front matter used to say the title “was set in the commission”; it now tells the story of being changed, because a book about being able to change things should show itself being changed. Two corrections rode along, on the librarian’s rule that a book already open costs nothing more to fix and a second version move if it waits: the colophon’s “the second book is not written” is scoped to when it was true (it has since been written), and three references to a test file split at v0.5.20 are corrected. Brief 44 also supplies the thing the capability register said part one could not be written without: the Leanpub story, now source material in the book’s own folder. It is sharper than expected. The earlier workflow was already good — markdown, GitHub, reuse of his own writing — and what failed was not the writing but everything after it: “you almost start to be locked by the first version of the content, because making changes becomes quite painful.” That is this book’s argument stated as its opposite, by the person it happened to. And the memo adds the concept that governs the graph work: source materials versus projections, and the two-way door against the one-way. A deterministic projection can be walked back; prose written by a model cannot. So “the source materials and the source data is all in the deterministic layer, and it's the sources that get projected” — which is what makes it safe to “destroy the outputs to refactor… but not lose the core”. One correction is the agent’s own: the claim at v0.6.7 that no existing screenshot showed the workflow was wrong. Checked properly, the book already carries the release history, the memos hub, the front page and the raw-beside-rendered explorer. And the release before this one failed, which is worth recording rather than hiding. v0.6.9’s commit subject was written site v0.6.9 / making-a-book v0.2.0: … to show both clocks moving — and CI parses that subject to find the version, wanting the colon immediately after it. It found nothing, reported that version.txt disagreed with the history, and failed the release. Worse, the backfill used the same strict pattern, so that release became permanently untaggable, which blocks the version diff for every release after it. Three fixes: the backfill is now tolerant, because healing history is its whole job and a release that already happened cannot be un-released by a subject nobody can rewrite; a test enforces the canonical form going forward, naming the one historical subject it cannot fix rather than loosening the pattern to hide it; and CLAUDE.md now says plainly that a book’s version belongs in the commit body. The irony is recorded too: the release that broke the parser was the one about two clocks. 102 tests green.
v0.6.8 28 August 2026 Brief 43: everything is a graph, and the claim that the machinery is ready was tested rather than believed. The memo states the philosophy at full strength — “by everything I literally mean everything, every file format, every type… even stuff that is not connected”; the unit is whatever you choose, from a byte to a whole graph database, and that is the fractal element; even an air gap is representable. With nature as the model and aggregation blindness as the point: “an atom doesn't know that it is made into molecules. A molecule doesn't know it's made into cells.” And the most usable idea in it: a graph's maturity is measurable — “how easy it is to link it, how easy it is to change it, and how easy it is to transform it” — by which test markdown is a graph, just a very hard one to change. The instruction is to put the whole book through the machine built for one pilot document, so JSON becomes the source of truth and everything else is a transformation. The memo asserts “we already have the technology for this”, and rather than take that on trust the pilot’s own decomposition was run over all 17 chapters before answering. It runs clean: 165 sections, 819 blocks, 1,818 sentences, 26,118 words — four to six times the pilot, no failures. One finding fell out that nobody asked for: vocabulary saturates. Words grow 6.3x while distinct forms grow only 3.1x, so a book reuses its own words far more than a document does, and the token analysis will behave differently at this scale. Three strains are visible before a line is written: the graph would be roughly 4MB for one book against 620KB for the pilot; the book carries 13 code blocks, 11 tables, 88 quotes and 63 rules that the pilot exercised only lightly, and the byte-identical rebuild gate is where those will bite; and there is a level the generator does not have — the pilot knows document, section, block, sentence, word, and a book needs book and chapter above them. Seven activities are mapped, each naming what it produces and how it is checked. And because the memo ends on the lesson the WCLM taught — “we don't develop technology because it's a cool idea… there has to be a clear output for it” — the plan names its output first: this exists to make brief 42’s restructure safe. Moving a book’s opening by hand is the consistency-losing edit brief 42 complains about; moving it as a transformation on a graph, with a gate proving every surviving chapter is byte-identical, is the thing this estate can do and a word processor cannot. 101 tests green; no book content changed.
v0.6.7 28 August 2026 Brief 42 states the book’s thesis, answers the structural question, and asks for a feature tour — so the tour got counted before it gets written. The memo is the making-of book’s argument stated outright for the first time: “you can't distinguish the creator from the technology and the workflows and the practices and the scaffolding that you use when you create something.” Brian May built his own guitar because craftsmen always did; the founder is “never just a passive consumer”; and the real power of generative AI here is not writing words but building the environment that makes the writing possible. With the bill named in the same breath — “a lot of people think that you can just vibe code your way out of this. No, you can't. You still need really good engineering” — and an honest limit placed on the method: “I don't think it's realistic to say that somebody without programming experience could provide the prompts and the requests that I have.” The instruction is structural. Part one of the book becomes a feature tour: “here is what writing a book in 2026 looks like”, set against the ordinary process of a Word document where changes are expensive and ideas lock early. And the order flips for a stated reason — “the current book is really cool at providing how we got there, but we need to show what THERE looks like… the art of the possible. Then we show how we got there, because then they're motivated.” That answers the naming question’s first open decision: the next edition is a revision, not a rename, and the record is updated to say so. What shipped is the count, not the chapter. A feature tour written from memory would break the rule this whole estate runs on, so the capability register measures what is actually true on the day: three books built from markdown into 119, 92 and 91-page PDFs; a document decomposed to 39 sections, 186 blocks, 342 sentences and 951 word forms that rebuilds byte-identical or the build fails; 72 distinct failure conditions in the release gate and 101 tests behind them; 101 narrated releases, any of which can be reconstructed from the repository’s own tags; 35 named techniques. It also records the four things that would be false if claimed — this is not a product, no one else has used it, it demands programming judgement, and the founder himself says the method is unfinished. And it names two things part one cannot be written without, neither of which exists: screenshots that show the workflow rather than the reader (the 45 existing figures show the wrong thing), and the founder’s own Leanpub failure story — “most of them I never finished… I had tonnes of notes made, but I didn't have the ability to keep it consistent” — which is the book’s most persuasive evidence and cannot come from this repository. 101 tests green; no book content changed.
v0.6.6 28 August 2026 Brief 41: the structure reviewed rather than moved, and the five workflows written down for the first time. The memo asks for the tree to be rebuilt around books/ at the top level, with v1 and v2 renamed v0.1 and v0.2 as versions of the graph book, and “every folder, every file, everything that we created” filed inside. The principle is endorsed and one part is pushed back on, with measurements. v1/ holds 94 pages of which 22 are the first edition; v2/ holds 142 of which 53 are books. The freeze is sharper still: v1/MANIFEST.json hashes 200 files by path and only 28 sit inside v1/book/. So v1 and v2 are timestamps, not types — each is one edition plus a reference site plus a corpus plus a brief archive that happened to be true at the same moment, and filing the WCLM, the team and twenty-one frozen source documents inside Fractal Semantic Graphs v0.1 would say something untrue about all of them. The memo contains its own correction later in the same recording (“technology that is not shared, and technology that exists per book”), and that is the distinction the proposed four-zone shape follows. The cost is counted rather than guessed: 236 of 258 URLs change, every frozen path moves, 15 of 24 generators need updating, and both books describe the tree in prose — so the move is a content change to two books and therefore three version bumps. Three things break, and one needs designing first: the freeze gate compares hashes at recorded paths, and rewriting the manifest is precisely the act it exists to forbid. The answer proposed is that the content is the freeze and the path was only ever how we found it — a moved_from per file, with a gate proving every frozen file survives relocation byte-for-byte. That is phase 1, recommended now whatever else is decided, because every later phase is blocked on it. The publishing order flips, and it matters for sequencing: the making-of book goes first because it is more mature and has a market, while the graph book “needs the technology advancements that we're going to do in the making-a-book”. Restructure before publishing, or accept the structure is fixed for a while after — those are the two coherent orders. And the workflows are now written down: the memo-to-release loop that has run 41 times, the release ritual, changing a book (which moves two versions), the seven-stage change control, and turning an escaped defect into a gate — each with its trigger, its steps, its done test, and an honest mark on which steps are machine-enforced and which are only habit, because the habits are the next gates. Three things are named as not workflows because they have never been run. 101 tests green; nothing moved; no book content changed.
v0.6.5 28 August 2026 Two clocks move together, and the pair is now on the record. The founder stated the rule plainly: “from now on when you make changes to one of the books you will need to update two versions… those changes were made to v0.1.15 of the book, v0.6.7 of the repo.” Either number alone leaves a reader unable to place a change, so the pairing is now a first-class record. Each book carries a changelog in which every one of its own versions is tied to the site release that carried it and a note saying what moved it — visible on the shelf as a table per book, not only in JSON. It is authored, not derived, and that distinction was learnt the hard way in the previous release. The v0.6.4 generator built its version history by appending to a list on every run, and a sixty-second experiment that bumped a version to prove a gate left two entries behind — one of them a version the book had never really been at. A record of decisions has to be written by whoever made the decision, so the changelog now lives in gen_bookmeta.REGISTER beside the version it explains, and the generator validates it instead of mutating it. That polluted history is gone. Three checks hold the pairing. The build refuses a book whose last changelog entry is not its current version — so a version cannot move without the decision being recorded. It refuses a changelog naming a site release that was never narrated in admin/versions*.html. And the suite refuses a changelog out of order, one whose site releases run backwards, or an entry with no note explaining what moved it. Each was run red before being trusted. The publisher’s workflow now names both bumps as one step, because the failure mode is moving the book and forgetting the repo, or the reverse; and the rule is in CLAUDE.md where a new session reads it before touching a book. 101 tests green; no book content changed — and with this release, the next book change will be able to say exactly which two numbers it belongs to.
v0.6.4 28 August 2026 Three version streams, and names that finally say which one a number belongs to. The founder caught the estate contradicting its own rule one release after writing it: “the url that you used for that name review is then confusing, what book is it about, and we didn’t have v1 of the making book.” He is right. The naming pack shipped as v0.6.3__the-naming-question — the site’s version — for work reviewing a book at v0.1.0, a version that book has never had, and seven role briefs and debriefs carried the same wrong stamp. Per-book versioning was built at v0.5.18 to end exactly that confusion, and then the first artefacts produced under it reintroduced it in their file names. The rule is now explicit. Site work is vX.Y.Z__<slug>; book work is <book-slug>__vX.Y.Z__<slug> carrying that book’s version, which is the version the work reviewed. The pack and all seven role artefacts are renamed, the URL is now mab-naming-00-the-record, and every book-scoped page states the book and its version in its own metadata: “Creating a Book Using Fractal Semantic Graphs v0.1.0 · the book’s version, not the site’s”. Three gates hold it. Every stamped artefact must declare a stream; a book stamp must name a real book; and the version it names must be one that book has actually been at. That last one needed a change in the register: gen_bookmeta.py now carries former_versions, appending the old number whenever a book moves — supersede-never-delete applied to versions, without which the coming rename to v0.2.0 would have made every v0.1.0-stamped artefact unverifiable overnight. gen_devpack.py also refuses a pack whose declared book disagrees with its folder name, and refuses a book-stamped pack whose version does not match the book. And the pack says so itself, at the top, because the record of a change-control process is the wrong place to quietly fix a mistake. 100 tests green; no book content changed.
v0.6.3 28 August 2026 The team runs for the first time, on the founder’s own question, and the map disagrees with him. Brief 40 asked whether the making-of book’s title is right and said the answer should come through a plan naming “which agents should have a voice on this, and which agents we should ask for an opinion”. That is the record: three roles with a voice, three asked for an opinion, one not asked because nothing here is a code question, and no role approving anything. The map is computed, not argued. In a 31,221-word book, fractal appears 9 times and semantic graph 6 — against release 227, graph 193, book 182, agent 173. Six of those nine name the other book; one sits inside a quoted brief; one is a chronology row; exactly one is substantive, and even that one is about the other book’s claim. The book uses the word in its own title once, and not about itself — and it had already flagged the problem in its front matter, where the title is recorded as the one thing it did not choose: “set in the commission”. The map also contradicts the founder, which is what a map is for. Brief 40 judges the book leans explorer; measured, the body carries one code block and no shell commands across twelve chapters, with the technical material quarantined in an appendix worth 21% of the words. As written it leans villager. That is either a finding about the title or a finding about the body, and only the founder can say which. Four candidates are proposed, each built only from words the book actually uses, which rules out workflow (8 uses) as firmly as fractal — and notes that the two words carrying the founder’s own thesis, scaffolding and feedback loop, appear zero times. They are the right ideas with the wrong evidence: a title cannot print an argument the body has not made. Four roles then argued from their own centres of gravity: the publisher costed the rename and confirmed the folder slug must not move; the writer priced the alternative at two to three thousand words; the librarian required the old title be superseded rather than deleted; QA asked for two gates before anything is renamed. The first of those gates is built and shipped, because it protects the rename itself: a book is now checked to be called the same thing in the register, in its builder, and in its own front matter. Nothing checked that before, which made a rename the change most likely to leave one of the three behind. It found a disagreement on its first run — the Universe volume heads its front matter with the series name — which is normal for a volume, so it is now declared in the register as data rather than hidden as a special case in a test, and the gate was run red against a half-finished rename before being trusted. The workflow now sits at stage 5 of 7, waiting on the founder. 98 tests green; no book content changed.
v0.6.2 28 August 2026 The team inherits a proven shape instead of the one invented yesterday. Brief 40 named a reference — “we already have good definitions and good examples from other projects, especially the Send project” — and at v0.6.1 that repository could not be reached, so the seven roles were built from the memo alone and the gap was recorded rather than papered over. It is reachable now (the-cyber-boardroom/SGraph-AI__App__Send, public; the owner guessed at v0.6.1 was wrong), its team/ folder carries seventeen roles under a mature convention, and this release adopts it. What was inherited, because reinventing a proven format is the waste this estate keeps warning about: the Identity table, whose three fields do most of the work — a Core Mission, a Central Claim the role can actually be held to, and a Not Responsible For that stops a role drifting into another’s territory; a Foundation table of principles, each carrying the reason it exists here (most were learnt by getting something wrong); Primary Responsibilities naming real paths; numbered Core Workflows; and version-stamped outputs (vX.Y.Z__<slug>.md), so a debrief can be placed against the release history without being opened. What was deliberately not inherited, and the reasons are stated on the hub: Send’s seventeen roles include AppSec, DevOps, GRC and a data-protection officer, which a three-book publishing estate does not need; its issues filesystem; and its Wardley tier folders (town-planner/, villager/) that split roles by evolution stage — brief 40 names two audiences in Wardley’s terms but does not ask for the roles to be split that way, so they are not. One thing was kept from the memo over the reference: the file stays role.md in lowercase, because brief 40 says so directly; Send uses ROLE.md. The gate moved with the shape, and it is stricter than before: a role now fails the build without a Central Claim or a Not Responsible For, and a Not Responsible For under forty characters fails as too vague to keep the role out of someone else’s work. The companion check — that no role reads the way it would in any other repository — still stands, and was run red against a deliberately generic definition before being trusted. 97 tests green; no book content changed.
v0.6.1 28 August 2026 Brief 40, and the agentic team it asks for. The first memo of the review era arrives with a verdict rather than a complaint: the making-of book’s content, voicing and pacing are approved — “there was actually not that much stuff I felt wanted to change” — and what follows is a change of frame, not a rewrite. The team is now real, at /v2/team/, and its shape is the founder’s to the letter: “every role has a folder. Every role has a role.md, has actions, has briefs, has debriefs, and basically has this work environment.” Seven roles — librarian, researcher, writer, editor, developer, QA, publisher — each with its declared centre of gravity, what it owns, what it refuses, and how to tell when it is wrong. The stated purpose is judgement, not throughput. The memo is precise about why: “it was very powerful when you have agents advocating for certain things, who have specific centres of gravity”. One generalist asked a hard question gives one answer shaped by whatever it read last; seven roles with declared gravity disagree in useful ways, and a decision made against disagreement is worth more than one made against silence. Every role is customised to this estate, and a gate now enforces that: the developer is a developer for this bundler-less stack, these 24 generators, this frozen first edition that fails the build if a byte moves; the researcher researches a closed local corpus and refuses to answer from anywhere else; the writer owns chapter markdown and nothing else, because the rendered pages are projections. A new test fails any role that names fewer than three things only this repository has — it was run red against a deliberately generic QA definition before being trusted. A second test fails a role with no “what it refuses” section and any action with no done test, because a half-defined role is worse than no role: an agent reads it as authoritative and it is not. And the memo’s own instruction about the team is recorded where it will be needed: the team arrived late, and the books must say so. “I’m only introducing these now, not in the beginning.” One person and one agent wrote three books before this folder existed. What the memo asks next — a research project mapping what the making-of book actually is, and a proposal for a better title than one borrowing fractal for a book that does not use it — is the researcher’s first action, and the first real test of the seven-stage workflow. 97 tests green; no book content changed.
v0.6.0 28 August 2026 The review era opens. Brief 39 asked for the seam to fall between finishing the books as they are and changing the books under control, and this is that cut. The v0.5 era is archived whole (24 releases, three books, the WCLM built and parked) with its retrospective beside it, and this register starts again for v0.6: review as change control. What the era is for, in the founder’s own words from brief 39: “whenever we have a review that we want to make, we start by planning, mapping, defining, reviewing, approving, and then implementing, and then approving the implementation” — seven stages, human reviewers and agentic reviewers, because “we are actually making changes to the books… we actually need to be quite thorough”. The books are no longer things being written; they are things being changed, and a change to a published book needs a record, a diff and an approval, not a commit message. What this release deliberately does not do is guess. Brief 39 reading 8 says a separate memo will describe the agent mix, and that memo has not landed. The seven stages are known; who staffs each one is not, and inventing an answer would waste the reason for cutting the era here. So v0.6.0 opens the era and nothing more: the archive, the fresh register, and a stated frame for the first memo to land against. What is already in place to build on, none of it invented for this: per-book versioning with a SHA-256 per chapter and a gate that fails a content change without a version move (and a version move without a content change); a version-diff engine that reconstructs the text of every release from the repository’s own tags; the decisions register with its supersede-never-delete amendments; and the review packs. And one thing the era should fix, named by the retrospective an hour before this release: prose has no freshness gate. A generated page cannot drift from its source and the build proves it on every push, but a sentence that was true in August and false in September passes every check here — which is how the front page came to deny that the books existed for ten releases. Change control over book content is exactly the machinery that could close that hole. 95 tests green; no book content changed.

How a version is decided

← Comms How this site is built →