{ "id": "r001", "title": "First reading of the book", "reviewer": "Dinis Cruz", "received": "22 August 2026", "source_kind": "voice memo (transcript preserved verbatim)", "source": "briefs/11__founder-review__first-reading.md", "version_reviewed": "v0.3.7", "state": "discussing", "state_note": "In discussion: on 22 August the librarian of the source repository answered this review's needs (brief 13). Eleven of the twelve needs across r001 and r002 are met; only the reviewer's reading screenshots remain outstanding. The founder decisions are unchanged and open, with one reframed: the title choice is now three-way, because the concept already carries the published name G3. A founder pointer then added a third estate: sgraph.ai's library (served from a public vault, every page machine-readable), which upgrades the EmailFS case study to a live deployment and adds four more public vaults. The reviewer then calibrated the librarian's finding: docs.diniscruz.ai predates the workflow that produced the newer corpus, where the meaning-through-connectivity documents were written, so the title decision weighs recency of thinking alongside publication history (item 2's thread). Review r003 (22 August) then reordered the sequencing: the evidence programme precedes the next book version, and the decoupling of book from website is proposed as the enabling refactor. Nudged by the calibration, the librarian then issued addendum 01 (brief 15), correcting its own pack: the title phrase has a dated single origin (the foundational Issues-FS document of 5 February 2026, whose Part 3 also carries the fractal principle, so both candidate titles come from one file), the chapter audit gains a measurable dilution (ten principles at source, five in chapter 2), the lineage chapter's primary source moves to that document's Part 4, the database correction gains four shipped backends, and the IssuesFS case study is fully resourced. Decision D1 is reframed accordingly. This review's open decisions are explicit in the register above. On 22 August the Issues-FS estate published its own site, which meets item 8's largest need in full, moves item 5's evidence into public view, makes item 2's origin document citable, and raises one numbers discrepancy between the two estates (ask N15). On 22 August the title decision was answered: Fractal Semantic Graphs: Meaning Through Connectivity, for humans and agents. Item 5's verification need is met by the vault analyses.", "decisions": [ { "n": 1, "item": 2, "question": "The title, reframed twice since the review (item 2's thread has the full history). The phrase 'meaning through connectivity' has a dated, single origin: it is the subtitle of the foundational Issues-FS document **Thinking in Graphs: Meaning Through Connectivity** (5 February 2026), and the fractal candidate traces to Part 3 of the **same document**, The Fractal Principle. So the choice is which half of the foundational document's own vocabulary leads the cover, with **G3** (the published name, May 2025) as the outsider third option. With it, the three sub-questions from the proposal: exact casing and order; whether the site's own identity follows the book's; and whether the PDF files rename with forwards kept, or keep their URLs and retitle content only. Whichever wins, the lineage chapter records both terms coined in one Issues-FS document on 5 February 2026, and G3's May 2025 naming before them. **Now decidable against a public citation:** since 22 August the Issues-FS site publishes that foundational document as C1 with its core definition quoted, so the colophon the librarian wanted in front of the founder is public.", "options": [ "Meaning Through Connectivity (the document's subtitle, as is)", "Fractal Semantic Graphs: Meaning Through Connectivity (leading with Part 3)", "Elevate G3 (the published name, alone or combined)" ], "state": "answered", "answer": "**Fractal Semantic Graphs: Meaning Through Connectivity**, with **for humans and agents** as the subtitle. Both halves come from the foundational document of 5 February 2026: the title from Part 3, the phrase after the colon from the document's own subtitle. G3 stays as history for the lineage chapter. Decided by the founder on 22 August 2026, and the propagation (cover, spine, wrap, half-title, colophon, running heads, metadata sheet, PDF filenames, site identity) is staged for the v0.4.0 identity release, which the founder deprioritised in favour of the vault analyses.", "date": "22 August 2026" }, { "n": 2, "item": 9, "question": "Sign off the sequencing, as reshaped by review r003: the evidence programme (vault case studies at full site granularity) runs first; the identity release (title, lineage and fractal chapters) follows, distilling from that evidence; the no-dependency corrections land as agreed along the way; the chapter audit runs throughout.", "options": [ "Sign off as reshaped", "Adjust the order (say what moves)" ], "state": "open" } ], "items": [ { "n": 1, "topic": "The verdict, and what it decides", "reviewer_says": "My first comment is it's brilliant. What this convinced me is it's worth me now spending time cleaning up this book, because it could be really good positioning for a lot of the projects we're working on, and a much more organic way to develop a book that we can now scale.", "comment": "Recorded as the review's disposition, and it changes the book's status: from a projection of the site to a work being invested in. Two consequences follow for everything below: the bar per chapter rises (item 3), and the workflow being exercised right now is itself a deliverable (item 9).", "proposal": "No change from this item alone; it sets the intent the other items serve.", "needs": [], "impact": [], "state": "noted" }, { "n": 2, "topic": "Retitle: Fractal Semantic Graphs — Meaning Through Connectivity", "reviewer_says": "The name of the book really should be fractal semantic graphs, colon, meaning through connectivity, because the fractal concept permeates throughout just about everything I have, and it is one of the key concepts I want to describe.", "comment": "Agree, and the reviewer has spotted a real imbalance: the fractal claim is currently one section (chapter 6, where it is called a precise, falsifiable claim) in a book whose organising metaphor it should be. The title fix and the weight fix belong together: retitling without expanding the fractal treatment would put a promise on the cover the interior underdelivers.", "proposal": "A major release (v0.4.0, because the identity changes): title **Fractal Semantic Graphs**, subtitle **Meaning Through Connectivity**, with the current discipline line kept as the cover's descriptor strip. Propagates to the front cover, spine, wrap, half-title, title page, colophon, running heads, the metadata sheet, and every self-reference. Alongside it, grow the fractal treatment: the chapter 6 section becomes a full early chapter (paired with the lineage chapter of item 4), and 'graphs of graphs of graphs, ontologies of ontologies, taxonomies of taxonomies' gets stated as the spine of the argument rather than mentioned in passing. Three questions before it lands: (a) confirm exact casing and order; (b) does the site's own identity follow (the hero eyebrow currently reads 'Semantic graphs · meaning through connectivity'); (c) the PDF filenames carry the old title in their URLs, so either they are renamed with the old files kept for one release as forwards, or the URLs stay stable and only the content retitles. Recommendation: rename, keep forwards.", "needs": [], "impact": [ "cover", "print interior", "metadata sheet", "site identity", "store listings" ], "state": "agreed", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "The search reframes this decision: the concept already has a published name with a two-year track record. **Graphs of Graphs of Graphs (G3)** was defined in a May 2025 white paper on docs.diniscruz.ai and carried through the Luhmann, FIST and regulatory follow-ups; the corpus says the phrase in prose sixteen times but never uses the G3 name, because the naming happened on a site the corpus does not reference. The choice is now three-way: keep Meaning Through Connectivity, adopt Fractal Semantic Graphs, or adopt the name that is already public and citable (or combine them: Fractal Semantic Graphs with G3 carried as the established shorthand). Whichever wins, the lineage chapter records that the concept was named G3 in May 2025. See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "[Graphs of Graphs of Graphs (G3) in Threat Modeling, May 2025](https://docs.diniscruz.ai/2025/05/30/graphs-of-graphs-of-graphs-g3-in-threat-modeling.html)" ] }, { "date": "22 August 2026", "from": "Dinis Cruz, the reviewer", "note": "\"I think that agentic review was a bit bias on the content that I published on docs.diniscruz.ai which was created before I developed the workflow that I use on the __Send repo, which is where those 'meaning through connectivity' docs were created.\"", "sources": [] }, { "date": "22 August 2026", "from": "the agent", "note": "What the calibration changes: the two corpora are not equal witnesses, they are two stages of the same thinking. docs.diniscruz.ai, where G3 was named in May 2025, predates the workflow that later produced the source repository's corpus, and that newer corpus is where the meaning-through-connectivity documents were written. So the librarian's observation that the corpus says the phrase in prose sixteen times but never uses the G3 name reads differently now: not a failure to adopt an established name, but the evolved vocabulary of the later stage. Publication history and current position point at different names. The reweighing, for the reviewer to accept or reject: G3's May 2025 naming is settled history and belongs in the lineage chapter whatever the cover says; the title itself should be judged on where the thinking is now, which favours the two newer candidates (**Meaning Through Connectivity** standing, or **Fractal Semantic Graphs** with it as subtitle) over elevating G3 to the cover. The choice stays three-way and stays the reviewer's; only the weights moved.", "sources": [] }, { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send (addendum 01)", "note": "Nudged by the calibration above, the librarian re-ran the search with the __Send and Issues-FS corpora restored, and opens with the admission: the original resolution was biased toward docs.diniscruz.ai, 'the same class of error the site itself is about'. The discovery that reframes this decision again: **the phrase has a precise, dated, single origin**. 'Meaning Through Connectivity' is the subtitle of the foundational Issues-FS document *Thinking in Graphs: Meaning Through Connectivity* (commit 70916cf, **5 February 2026**, 5,013 words), a byte-identical copy of which has sat in the source repository's `library/concepts/` since 11 June 2026. And the fractal candidate traces to **the same file**: Part 3 is *The Fractal Principle* ('the same structural pattern — nodes with edges, meaning through connectivity — repeats at every level of zoom'). Both candidate titles come from one document, so the question is no longer 'should we rename to something better' but 'which half of the foundational document's own vocabulary do we lead with'. G3 remains the third option as the published name (May 2025), now the outsider rather than the incumbent's rival. Recommendation: put the document's colophon in front of the founder before v0.4.0. Decision D1's framing is updated accordingly. See [brief 15](../briefs/15__librarian__source-resolution-addendum-01.md), the addendum, with the machine-readable index [15__addendum-01-sources.csv](../briefs/15__addendum-01-sources.csv).", "sources": [ "Thinking in Graphs: Meaning Through Connectivity: `Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__thinking-in-graphs.md`, commit 70916cf, 5 February 2026; byte-identical (md5 51b67d93) at `SGraph-AI__App__Send/library/concepts/v0_4_0__thinking-in-graphs.md`" ] }, { "date": "22 August 2026", "from": "the agent, on the launch of issues-fs.sgit.ai", "note": "The origin document is now **public and citable**, which is what this decision was waiting on. Issues-FS has its own site as of 22 August 2026, and its concepts section publishes *Thinking in Graphs* as C1 (5,013 words, v1.0, 5 February 2026) with its core definition quoted: \"A node has no inherent meaning. Meaning is discovered through the edges you can trace from it — and confidence in that meaning is proportional to how richly the node connects to others that supply context.\" That is this book's thesis in the source document's own words, at a public URL. The librarian's recommendation was to put the document's colophon in front of the founder before v0.4.0; the colophon is now effectively published, so D1 can be settled against a citation rather than a repository path, and the lineage chapter can cite a live page for the 5 February 2026 coinage of both candidate titles.", "sources": [ "[The five foundational concepts](https://issues-fs.sgit.ai/concepts/index.html), C1 Thinking in Graphs" ] }, { "date": "22 August 2026", "from": "Dinis Cruz, the reviewer", "note": "\"The official title will be **Fractal Semantic Graphs: Meaning Through Connectivity** with **for humans and agents** as the sub-title.\" Decision D1 answered; item agreed and staged for v0.4.0.", "sources": [] } ] }, { "n": 3, "topic": "Every chapter must carry an idea that challenges the reader", "reviewer_says": "Every chapter, every page should have an interesting idea, should challenge the reader. A lot of documents I've created have been distilled and diluted a little bit. Let's go back to them to make sure these concepts really shine through.", "comment": "Agree, and this is the highest-effort item because it is editorial judgment chapter by chapter, not a mechanical pass. The honest starting point is an audit, not a rewrite: some chapters already lead with a sharp challenge (the 10,000 hours story, the banned edge, node type formulas); others summarise more than they provoke.", "proposal": "A chapter-by-chapter audit table delivered as this review's first follow-up: for each of the seventeen units, the one interesting idea, the sentence that challenges the reader, the source document behind it, and a verdict (sharp, or diluted relative to its source). Rewrites then target the diluted rows only, each traced to its source brief so the sharpness comes from the corpus, not from invention. The version diff view shows each rewrite as its own delta.", "needs": [ "The source documents behind the diluted concepts, where they are not already in the published brief pack: the reviewer's own originals, exported the way the pack was." ], "impact": [ "all chapters, selectively" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "The undiluted originals are public on docs.diniscruz.ai and can now anchor the audit: top-down versus organic ontologies (March 2025), the customised-standard originals (Semantic OWASP and Scaling Europe's Regulatory Superpower), LETS (used in the corpus, never defined), and Time as a Calibrator of Credibility (October 2025, which also supplies the source for queued task T8). See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "[From Top-Down to Organic Evolving Graphs, Ontologies, and Taxonomies](https://docs.diniscruz.ai/2025/03/29/from-top-down-to-organic-evolving-graphs-ontologies-and-taxonomies.html)", "[Semantic OWASP](https://docs.diniscruz.ai/2025/04/02/semantic-owasp__leveraging-genai-and-graphs-to-customise-and-scale-security-knowledge.html) and [Scaling Europe's Regulatory Superpower](https://docs.diniscruz.ai/2025/03/31/scaling-europe-regulatory-superpower.html)", "[LETS: Load, Extract, Transform, Save](https://docs.diniscruz.ai/2025/05/27/lets__load-extract-transform-save__a-deterministic-and-debuggable-data-pipeline_architecture.html)", "[Time as a Calibrator of Credibility and Trust](https://docs.diniscruz.ai/2025/10/02/time-as-a-calibrator-of-credibility-and-trust-in-information-systems.html)" ] }, { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send (addendum 01)", "note": "Corrected: the entry above answered this item entirely with docs.diniscruz.ai articles, and the addendum restores the actual chapter-by-chapter mapping from the __Send and Issues-FS corpora. The sharpest instrument in it: **chapter 2 is 'The five ideas', and the source document's summary lists TEN core principles.** The five that did not make it, verbatim from the source: compatibility is computed, not declared; honest uncertainty is the default; enrichment, not enforcement; cross-graph edges are first-class; no node is aware of how it's used. That turns this item from 'some concepts feel diluted' into a checkable measurement, with the missing five quoted and ready. Also from the corrected mapping: chapter 13's origins chapter is pre-written (*The Journey: From Voice Memos to Compatibility Testing*, 5 February 2026, Status: Historical Record) and starts four months earlier than the book currently does; chapter 4's edge grammar is shipped, typed and domain/range-constrained in code (`Schema__Link__Type.py`: verb, inverse_verb, source_types, target_types); and chapter 12 can name a second, independently shipped implementation (issues-fs 0.7.0 and issues-fs-cli 0.3.0 on PyPI, 604 + 94 tests). See [brief 15](../briefs/15__librarian__source-resolution-addendum-01.md).", "sources": [ "The ten principles: `Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__thinking-in-graphs.md`, Summary: Core Principles", "The origins chapter: `Issues-FS__Docs/docs/to_classify/6-feb-other/v0_4_0__issues-fs__the-journey.md` (3,483 words)", "The shipped edge grammar: `Issues-FS/issues_fs/schemas/graph/Schema__Link__Type.py`" ] } ] }, { "n": 4, "topic": "Homage: the lineage chapter", "reviewer_says": "It's important that we pay homage and acknowledgement to the amazing work that was done before. I was massively inspired by semantic graphs. We should acknowledge graph theory. Graph databases are amazing. I just build our serverless approach on top.", "comment": "Agree, and it corrects a tonal imbalance: chapter 5 credits the Semantic Web with identifying the right problem in one paragraph, then argues against schema-first for six sections. The disagreement is real and stays; the debt deserves equal ink. It also sharpens the book's own position: you can only claim a delta against work you have honoured accurately.", "proposal": "A new chapter, 'On the shoulders': graph theory from Euler forward; the Semantic Web's correct problem and its real achievements (RDF, URIs, shared vocabularies, the vision); graph databases as excellent tools this work deliberately does not run live (connecting to item 5); knowledge graphs; then the stated delta: fractal, serverless, edges over properties, ontologies of ontologies rather than one ontology. Placed early (Part I or opening Part III) so the argument chapters read as a position within a tradition, not a rejection of it.", "needs": [ "The reviewer's earlier document about being inspired by semantic graphs ('I think I wrote about it, there's a document'): identify and export it.", "Ask N3, the LinkedIn series, remains open and is the canonical statement of several of these acknowledgements in the reviewer's own voice." ], "impact": [ "new chapter", "chapter 5 framing", "table of contents" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "All three needs met. The Semantic Web inspiration document is the Solid protocol integration brief (24 February 2026, 3,278 words, four Turtle/RDF blocks, engaging Solid, RDF and Berners-Lee directly). The disagreement half is Part 4 of the thinking-in-graphs concept document, which must be attributed to Issues-FS explicitly, since the file carries no CC BY footer. The wider lineage is already public: the Luhmann/Zettelkasten bridge is the single best homage source, and the FIST article positions the approach against an existing tradition. And ask N3 itself, open since 10 June, is answered: the series is docs.diniscruz.ai, sixteen articles, 122,741 words, ten with their LinkedIn post URLs recorded in front matter. See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "Solid protocol integration brief: `briefs/02/24/v0.6.17__architecture__solid-protocol-integration-complementary-architectures.md` in the source repository", "[Bridging Niklas Luhmann's Ideas with Semantic Knowledge Graphs and G3](https://docs.diniscruz.ai/2025/06/18/bridging-niklas-luhmanns-ideas-with-semantic-knowledge-graphs-and-g3.html)", "[FIST Meets the Semantic Knowledge Graph](https://docs.diniscruz.ai/2025/06/22/fist-meets-the-semantic-knowledge-graph-aligning-fast-inexpensive-simple-tiny-with-dinis-cruzs-g3-approach.html)" ] }, { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send (addendum 01)", "note": "Corrected: the primary lineage source is not the Solid brief but **Part 4 of the foundational document itself**, which carries the homage and the disagreement in one passage and names four predecessors by name: schema.org, SKOS, Dublin Core and PROV-O. Verbatim: 'The Semantic Web community identified the right problem... Their answer — shared ontologies, RDF triples, linked data — was architecturally sound. The implementations produced genuinely useful reference vocabularies. But the community made a subtle mistake in practice. They ended up attaching meaning to nodes rather than deriving meaning from edges.' The ordered source list for the chapter: Part 4 first; the Solid brief second (its four Turtle/RDF blocks as the code exhibits); the Lexicon architecture third (anchor nodes as reference without authority, the positive form of the argument); the Luhmann article fourth (the Zettelkasten lineage, the non-computing ancestor, and its only source); the PKI historical analysis fifth (the 'is this the right primitive?' self-challenge). The docs.diniscruz.ai articles stay in the chapter as positioning against contemporaries, not as the lineage source. See [brief 15](../briefs/15__librarian__source-resolution-addendum-01.md).", "sources": [ "Part 4, The Semantic Web's Insight (and Mistake): `Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__thinking-in-graphs.md`, lines 266 to 316", "Lexicon Architecture v2: `Issues-FS__Docs/docs/to_classify/v0_4_0__issues-fs__lexicon-architecture-v2.md` (4,485 words)" ] }, { "date": "22 August 2026", "from": "the agent, on the launch of issues-fs.sgit.ai", "note": "Two of the lineage chapter's ordered sources are now public. *Lexicon Architecture* (C4, 4,485 words) is published with the framing this chapter needs: a lexicon is not a schema registry but \"the most well-connected graph in the ecosystem\", anchor nodes enabling interoperability without authority, and its status is stated honestly as **argued but never built**. That is the positive form of the Semantic Web argument, citable, with its own unbuilt status disclosed, which is exactly the tone this chapter needs to strike about a tradition it both honours and departs from.", "sources": [ "[Lexicon Architecture](https://issues-fs.sgit.ai/concepts/index.html), C4 — argued but never built" ] } ] }, { "n": 5, "topic": "Correction: 'we don't use databases' overstates it", "reviewer_says": "A mistake in some of the comments is when we say we don't use databases. I have used graph databases. What I mean is that I don't have live graph databases. One of the vaults has a full-blown SPARQL and RDF sort of query, one even has SQLite in the browser: we load stuff, we delete stuff, we load on demand. It's about serverless and ephemeral infrastructure.", "comment": "Agree, and the book already half-knows it: chapter 7 describes the regulation vault's SQLite interface and RDF/Turtle export while the honesty table says 'No SPARQL or Cypher in the browser. No RDF or JSON-LD in the code.' Both sentences are true of the source repository's code and false as a description of the work as experienced, which is exactly the kind of reading a correction exists for. The accurate claim is stronger, not weaker: databases and query languages are used deliberately as ephemeral, in-browser, serverless instruments, spun up on demand and thrown away, and that ephemerality is the argument.", "proposal": "Reword at the sources and let every projection inherit: the front page honesty cell and chapter 12's absent-list change from absolute abstinence to the precise claim ('no live, persistent graph database anywhere; ephemeral in-browser engines, including SQLite and RDF querying in the vaults, are used and demonstrated, loaded on demand and discarded'). The 'not a graph database pitch' note stays, because it is about the thesis, and it remains true. Before landing: open the vaults and record exactly which one carries the SPARQL/RDF querying and which the in-browser SQLite, so the correction cites what it names.", "needs": [], "impact": [ "front page", "chapter 12", "honesty table", "possibly chapter 1 positioning" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "The exact correction exists in the founder's own words, in The Browser Is The Database (12 July 2026): 'when I say we do not use databases, we use a file system as a database, it does not mean the system has no databases, it just means the source of data is the file system that gets loaded.' Supporting: the browser query layer brief cites Oxigraph (SPARQL compiled to WebAssembly) and Kuzu-WASM; the MGraph-DB deferral quote; and four public articles on ephemeral Neo4j instances and MGraph-DB. One precision to keep: mgraph-db is NOT a dependency of the source repository (the only import is a vendored benchmark CI never runs), so the honesty table's 'No MGraph-DB dependency' line stays true as written. The correction can now land fully cited; the remaining step is opening the regulation vault to attribute the SQLite interface and RDF/Turtle export precisely. See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "The Browser Is The Database: `briefs/07/12/architecture/v0.33.48__arch-brief__sg-send-browser-local-databases-query-engine-vault-source-of-truth-incremental-sync-no-backend.md` in the source repository", "[Using LLMs as Ephemeral Graph Databases](https://docs.diniscruz.ai/2025/06/19/using-llms-as-ephemeral-graph-databases--empowering-the-graph-thinkers-in-the-age-of-generative-ai.html)", "[Ephemeral Neo4j Instances for On-Demand Graph Analytics](https://docs.diniscruz.ai/2025/06/25/ephemeral-neo4j-instances-for-on-demand-graph-analytics.html)", "[FAQ: Evolving Semantic Graphs and Ontologies with LLMs and MGraph-DB](https://docs.diniscruz.ai/2025/07/04/faq-evolving-semantic-graphs-and-ontologies-with-llms-and-mgraph-db.html)" ] }, { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send (addendum 01)", "note": "Extended: beyond the browser evidence above, **Issues-FS ships four storage backends in code today** (memory, local disk, SQLite, ZIP: `Enum__Graph__Storage__Backend.py`, constructed via a repository factory over the memory-fs abstraction, 604 tests). That sharpens the corrected claim to its strongest form, the librarian's wording: 'We use databases, SQLite among them, as ephemeral engines loaded from a durable file-system source of truth. What we do not have is a database as the source of truth.' Two warnings the book must not inherit: three Issues-FS documents claim an MGraph-DB integration that does not exist in code (mgraph-db appears in zero pyproject.toml files and zero imports; the mgraph module is a hand-rolled in-memory graph borrowing the four-layer naming convention only), and S3 is claimed in four documents and does not exist. If the chapter cites Issues-FS as evidence, cite the enum and the factory, not the READMEs. The honesty table's 'No MGraph-DB dependency' line stays true, and now has a second corpus making the same point. See [brief 15](../briefs/15__librarian__source-resolution-addendum-01.md).", "sources": [ "The four backends: `Issues-FS/issues_fs/schemas/enums/Enum__Graph__Storage__Backend.py` and `Graph__Repository__Factory`" ] }, { "date": "22 August 2026", "from": "the agent, on the launch of issues-fs.sgit.ai", "note": "The correction's evidence moves from private repository paths to a **public estate that publishes the correction itself**. The Issues-FS site states the four storage backends in its own terms (memory, local disk, SQLite, ZIP) and carries a corrections page naming four false claims in its upstream READMEs, including the two this review already flagged: **no S3 or cloud backend exists**, and **no MGraph-DB integration exists** (a hand-rolled ~220-line in-memory graph borrowing the naming convention). Its instruction to agents is the same discipline this book argues for: \"Before repeating any capability claim from an Issues-FS README, check it against /shipped/corrections.html.\" The honesty table's MGraph-DB line stays true and now has a sibling estate publishing the same correction independently.", "sources": [ "[What ships](https://issues-fs.sgit.ai/shipped/index.html) and its corrections page", "Two real packages (issues-fs 0.7.0, issues-fs-cli 0.3.0); two published-but-empty wheels; four unpublished" ] }, { "date": "22 August 2026", "from": "the agent", "note": "**The verification need is met.** This item asked for a pass over the public vaults to attribute the query capabilities precisely before any wording changed. That analysis is now published at [the query engines](../vaults/regulation-graph/engines.html): the Regulation Graph's eleven views include **SQLite compiled to WebAssembly (sql.js), in memory**, and **rdflib with Turtle export**, both client-side over the vault bridge, with the vault never written by the app. Proposed wording is on that page, offered for agreement rather than applied, and it keeps the MGraph-DB line unchanged. The correction can land whenever you agree the sentence.", "sources": [ "[The query engines, and what they settle](../vaults/regulation-graph/engines.html)" ] } ] }, { "n": 6, "topic": "Screenshots, everywhere they earn their place", "reviewer_says": "Really missing from here is screenshots. A screenshot is worth a thousand words, and there are concepts that won't make sense to people unless you slap a screenshot in there. Every time we talk about a vault, we should have a screenshot of it.", "comment": "Strongly agree, and it fits the house discipline as screenshots-as-code: captured by the pipeline from the live artefacts, not pasted by hand, so they regenerate and cannot rot. Print consequences are manageable: the interior is monochrome, so screenshots print as greyscale halftones (to be proofed for density), the screen edition keeps colour, and the page count and spine follow automatically as always.", "proposal": "A capture manifest plus a generator (gen_shots.py): each entry names a URL, viewport and crop; captures land in the repo with captions carrying the source, capture date and the vault's own version; markdown references them like any image; the gate fails on a referenced image that does not exist. Start with a proposed shot list covering the three vaults' signature views plus the site's own diff view, for the reviewer to confirm and extend. The reviewer's own reading screenshots join this review as attachments and can seed the list.", "needs": [ "The reviewer's screenshots from the reading, as review attachments.", "Confirmation or extension of the starter shot list once drafted." ], "impact": [ "pipeline", "print interior", "screen edition", "page count and spine" ], "state": "proposed" }, { "n": 7, "topic": "A chapter on the vaults, opened", "reviewer_says": "If you look at the great work in the vaults, there's a section there that describes what the vaults do, and we should be showing that. We should have a whole section just on the vaults, because they are real-life examples of a lot of these graphs.", "comment": "Agree. The book currently lists the three vaults as cards with numbers (chapter 7) and never shows one working, which is backwards for the strongest evidence the material has: they are the live proof, and they are public.", "proposal": "A new chapter in Part IV, 'The vaults, opened': one section per vault with screenshots (item 6), what each demonstrates about the discipline (the regulation graph's customisation inversion and its ephemeral query engines; the Risk Graph Explorer's seven simultaneous views and ghosted unanswered edges; browser isolation's acceptance-gated escalation), the verifiable numbers, and the vault descriptions from the parent site read for alignment. Chapter 7's cards then point into it.", "needs": [ "Read sgit.ai's own vault-section text for alignment (public; no blockers)." ], "impact": [ "new chapter", "chapter 7", "table of contents" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "The vault-section text is live and fetchable as markdown: sgit.ai/vault/ (index, vault-apps, sub-vaults, content-authoring, sg-bridge, git-and-vaults, static-hosting) and the demos index. Nothing blocks this chapter except the screenshots of item 6. See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "[sgit.ai/vault/](https://sgit.ai/vault/) and [the demo vaults index](https://sgit.ai/demos/vaults/)" ] }, { "date": "22 August 2026", "from": "the agent, on a founder pointer to sgraph.ai", "note": "A second estate widens this chapter: sgraph.ai's own library is served live from a public vault, and its registry pattern is itself vault evidence. The site publishes /core/public-vaults.json, four vaults with read keys published by design (the server holds only ciphertext; the browser decrypts), including the Library Content vault the site's articles are served from, with per-vault _vault-meta.json enrichment. That is four more live vaults beyond the three sgit.ai demos, and a different demonstration: not a vault as an exhibit, but a production website whose content IS a vault. The Building on sgraph.ai section documents the vault content model and edge rendering that make it work. Fetched and verified today.", "sources": [ "[The open vaults page](https://sgraph.ai/en-gb/dev/vaults/) and the registry at sgraph.ai/core/public-vaults.json", "[Building on sgraph.ai](https://sgraph.ai/en-gb/library/building-on-sgraph.md)" ] } ] }, { "n": 8, "topic": "New case studies: SGit, IssuesFS, EmailFS, and the team itself", "reviewer_says": "SGit is an encrypted version control, graph-based structure, and a really nice way to explain how to think about a graph. IssuesFS was one of the first to really connect the fractal element: issues of issues, ontologies defined at a top level, overridden at lower levels, arriving at consensus; it deserves a whole section, works off a CLI and a file system. EmailFS, especially EmailFS Lite, shows the power of graph-like structures that let things communicate and be linked. And the way the main project is organised, the librarian's research that found the first documents, the way we keep the web pages and the print PDFs in synchronisation: that's a graph in itself.", "comment": "Agree on all four, with one honesty condition inherited from the house rules: each case study needs its sources in hand before it is written, so every number and mechanism is parsed from a real document rather than remembered. SGit is partly covered (the commit DAG is already the book's strongest shipped evidence) and can grow; IssuesFS is the purest fractal-in-action story and, per the memo, may also become its own site, with this book carrying the case study either way; EmailFS and the team-as-a-graph are new ground. The making-of angle also feeds the how-we-publish section the previous memo asked for.", "proposal": "Four case-study additions, sequenced by source availability rather than all at once: (a) SGit deepened in chapter 12 or split out, using architecture briefs; (b) IssuesFS as its own section or chapter, centred on the ontology-consensus model (top level defines, lower levels override, consensus emerges), with the CLI and file-system operation shown, screenshots included; (c) EmailFS and EmailFS Lite as a section on graph-structured communication; (d) the making-of: the librarian's research, the brief pack, and the site-book-PDF synchronisation described as the graph it is. Each lands as its own release with its own diff.", "needs": [ "IssuesFS: the ontologies-of-ontologies documents and repository access, or a brief-pack style export.", "EmailFS and EmailFS Lite: the design documents and, if live anywhere, access to see them.", "SGit: the architecture briefs beyond what the published pack carries.", "The making-of: the librarian's original research task and its outputs, to cite rather than paraphrase." ], "impact": [ "new chapters or sections", "Part IV or a new part", "table of contents" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send", "note": "All four case studies now have their sources, mapped path by path in the resolution pack. SGit: fourteen briefs, about 22,600 words, led by the four-layer model ('what we've built is not fundamentally an encryption system. It is a content-addressed, portable, storage-agnostic version control protocol'), with the shipped vault DAG code as the evidence. IssuesFS: the ontology is live in the source repository (12 node types, 10 verb/inverse edge types with domain-range constraints, 71 nodes and 141 edges, plus the Lexicon's 97-row anchor-node tree out to schema.org, SKOS and W3C PROV-O, flagged as the book's signature diagram once redrawn as SVG, with the relates-to violation narrated rather than hidden). EmailFS: six documents, about 26,100 words, plus the origin response. The team as a graph is instantiated, not just documented: 17 role directories, 59 reality files, 213 librarian reviews, 956 documents catalogued, and the public Explorers, Villagers and Town Planners essay as the year-early statement. Each case study starts when its export lands in this repository or access is granted. See [brief 13](../briefs/13__librarian__source-resolution.md), the librarian's resolution pack, with machine-readable indexes [13__sources__graph-articles.json](../briefs/13__sources__graph-articles.json) and [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv).", "sources": [ "[Explorers, Villagers, and Town Planners](https://docs.diniscruz.ai/2025/06/10/explorers-villagers-and-town-planners-understanding-the-generative-ai-divide.html)", "Full path map: [13__send-repo-sources.csv](../briefs/13__send-repo-sources.csv), 24 paths verified at v0.33.62" ] }, { "date": "22 August 2026", "from": "the agent, on a founder pointer to sgraph.ai", "note": "The EmailFS case study upgrades from design documents to a live, publicly documented deployment: sgraph.ai's library carries Email-FS-lite as a full protocol section (overview plus seven pages: big picture, message lifecycle, check-in cycle, vault ownership and write boundaries, issues workflow, audit and recovery, identity and addressing), and the protocol runs the site's own agent team in production. Core design: agents coordinate by exchanging RFC 2822 messages through shared filesystem vaults, no broker, a single-writer rule, SEND to DELIVER to DONE lifecycle, sgit commits as the audit trail, 'everything is a filesystem operation'. One calibration for the writing: the sgraph.ai docs present it in filesystem and message-flow terms; the graph reading (linked structures that let things communicate) comes from the design briefs, so the case study should bridge both framings rather than assume one. The team-as-a-graph case study also gains a second public instantiation: the sgraph.ai roster of seven agents (@Content, @Dev, @Comms, @Ontologist, @Observer, @AppSec, @Journalist) with coordination, roles and bootstrap guides. Every library page is fetchable as .md, so all of this is citable directly. Fetched and verified today.", "sources": [ "[Email-FS-lite, the protocol section](https://sgraph.ai/en-gb/library/how-it-works/email-fs-lite.md)", "[SG Teams](https://sgraph.ai/en-gb/library/sg-teams.md) and [the agentic team roster](https://sgraph.ai/en-gb/library/agentic-teams/sgraph-ai-team.md)", "[Adding Email-FS-lite to your team](https://sgraph.ai/en-gb/library/guides/adopt-email-fs-lite.md)" ] }, { "date": "22 August 2026", "from": "the agent, from review r003", "note": "[Review r003](r003.html) settles where these case studies live: on the website, at full granularity, as the evidence estate, with the book carrying the distilled best-of and provenance links back. In the reviewer's words there: 'that will provide the body of work, will provide the evidence, will provide the examples... so that when you want to make a statement in a book, you are supported by the evidence.' The sources mapped above stay the inputs; the output surface changed, and the programme now runs **before** the next book version rather than after the identity release.", "sources": [ "[Review r003, items 1 and 3](r003.html)" ] }, { "date": "22 August 2026", "from": "the librarian, SGraph-AI__App__Send (addendum 01)", "note": "The IssuesFS case study is properly resourced, and it becomes the strongest of the four: the only one with a shipped, installable, independently testable implementation. **issues-fs 0.7.0 and issues-fs-cli 0.3.0 are on PyPI**: 5,401 lines, 604 + 94 tests, 14 CLI commands, every one carrying `--for-agent`. The ontology is in code: `Schema__Node` (13 fields, two identities per node, machine node_id plus human label), `Schema__Node__Link` (bidirectional and denormalised, **which is why 71 nodes report 141 link entries**, a fact the case study should state before readers count), `Schema__Link__Type` (verb, inverse_verb, source_types, target_types), and `Safe_Str__Graph_Types`' five regex-validated ID primitives, which the addendum calls the single best teaching artefact in the codebase. Two undocumented surfaces worth surfacing: the .issues flat-file DSL (built, around 55 tests, three live examples, zero prose documentation) and Issues-FS-lite (agent mode, no binary, specified inside an email manual in a different repo). And one honest tension to narrate, not hide: the live link-types.json ships a relates-to self-inverse pair, and one edge instance uses it, while the book's own grammar chapter bans relates-to as meaningless. Doctrine versus shipped data, on the record. See [brief 15](../briefs/15__librarian__source-resolution-addendum-01.md).", "sources": [ "The shipped surface: issues-fs 0.7.0 and issues-fs-cli 0.3.0 on PyPI; `owasp-sbot/Issues-FS__Docs` and `owasp-sbot/Issues-FS__Dev`", "The live graph: `SGraph-AI__App__Send/.issues/` (71 nodes, 141 link entries, 12 node types, 10 verb pairs, depth 8)", "Machine-readable path map: [15__addendum-01-sources.csv](../briefs/15__addendum-01-sources.csv)" ] }, { "date": "22 August 2026", "from": "the agent, on the launch of issues-fs.sgit.ai", "note": "**The IssuesFS case study's need is met in full, and its shape changes.** Issues-FS now has its own published site, so the case study is no longer a write-up from repository paths: it is a distillation from a sibling estate that already holds the granularity, with provenance links back — precisely the arrangement [review r003](r003.html) proposes for this book and the research estate. Written from scratch it would duplicate a live site and drift from it within a release. What the site supplies that this book cannot get elsewhere: the **ten verb/inverse pairs enumerated** (blocks/blocked-by, contains/contained-by, has-task/task-of, has-project/project-of, assigned-to/assignee-of, has-phase/phase-of, depends-on/dependency-of, has-feature/feature-of, asks/asked-by, and relates-to/relates-to); the **two identities per node** (a 10-character GUID for storage, a human label like Bug-27 for the CLI), which is the concepts-not-words argument implemented; **three agent-operable surfaces**; and four real graphs totalling 147 nodes. Two consequences for accuracy. First, **this book's grammar chapter is corroborated in public**: the sibling enumerates relates-to/relates-to as pair ten and narrates the same tension, \"passes every structural check the type system makes\" while being semantically empty, rather than hiding it — so the chapter can cite a live page instead of a repository file. Second, **a numbers discrepancy needs settling before either estate is cited**: this book reports 71 nodes and **141 edges**; the sibling reports **141 link entries for roughly 70 logical relationships**, because one link command writes an entry at both endpoints. Both measured the same repository. Proposed wording, for agreement before it lands: \"71 nodes, 141 link entries, roughly 70 relationships (each link is stored on both endpoints)\", which is true under either convention and teaches the denormalisation in passing. Recorded as finding 6 on [the altitude ladder](../altitudes/index.html#findings) and as ask N15, because 141 is odd and only the sibling estate can explain the remainder.", "sources": [ "[The data model](https://issues-fs.sgit.ai/model/index.html), the ten verb/inverse pairs and the link model", "[The four real graphs](https://issues-fs.sgit.ai/examples/index.html): 71 nodes / 141 link entries / ~70 relationships", "[issues-fs.sgit.ai](https://issues-fs.sgit.ai/) — \"the issues are files and the files are a graph\"" ] } ] }, { "n": 9, "topic": "The workflow is the other deliverable", "reviewer_says": "You should write a review of this, then write the approach you would take, including what else you need, so we can have a conversation and create the brief for you to make the changes. We should be setting up the agentic team on this project, which would include the researcher. Let's do a review, and then let's do the next version.", "comment": "This page is that review, and its existence is the workflow's first full turn: memo preserved verbatim, items normalised, comments and proposals written, needs listed, nothing changed. The conversation happens next, in chat or by memo, item by item; agreed items land in releases and each one links the exact delta it produced in the version diff view.", "proposal": "The approach, sequenced: first the correction (item 5) plus any quick agreements, as the next minor release; then the retitle plus the lineage and fractal chapters (items 2 and 4) as v0.4.0 once the three title questions are answered; then screenshots and the vaults chapter (items 6 and 7); then case studies as their sources arrive (item 8); with the chapter audit (item 3) running through all of it. On the team: the needs lists above are the researcher's first task queue, and research agents fire as soon as the sources are reachable.", "needs": [ "Answers to the three title questions in item 2.", "The source materials listed in items 3, 4 and 8.", "The reading screenshots for item 6." ], "impact": [ "process" ], "state": "discussing", "thread": [ { "date": "22 August 2026", "from": "the agent, from review r003", "note": "The sequencing proposed here is reordered by [review r003](r003.html): the evidence programme runs first (in-depth case studies of the existing vaults, on the website, founder-guided), and the identity release (the retitle with the lineage and fractal chapters) follows, distilling from that evidence rather than preceding it. The correction (item 5) and the other no-dependency pieces still land as soon as agreed. What this review waits on is now explicit in its decisions register: D1 the title, D2 the reshaped sequencing.", "sources": [ "[Review r003, item 3](r003.html)" ] } ] } ] }