# Founder memo: review packs, and briefing other agents

**Date:** 23 August 2026 · **Source:** voice memo, transcribed live by otter.ai and reproduced
verbatim below (per the house rule: the founder's voice is source material and is not edited)
· **Filed under** logistics and admin, at the founder's direction
· **Status:** a specification follows the transcript. The first pack ships at v0.4.3.

**What it says, in one paragraph:** the next phase needs other agents brought in to review, and
to act as readers the way synthetic users acted as users in an earlier vault. That cannot be done
by pointing a reviewer at a website, because **a website's hyperlink nature means nobody controls
the sequence**: what is seen, in what order, and what is skipped. A site heading for hundreds of
thousands of words cannot be reviewed by saying *go to town*. A PDF is the opposite: it is a
logical grouping in which **the sequence of events is controlled**, it can be read end to end on
an iPad or printed, and because it is not modifiable it survives as a historical record better
than a web page does. So: build a family of packs, generated, designed to help a reviewer and the
author **make decisions, understand the concepts, follow the narrative, see the evidence and get
guidance**. Not the printed book. Supporting material. They carry visualisations, because a
visualisation is itself a **compression**, another way to represent relationships, and so are the
tables. Not all of them are built every time: some on demand, some only at particular phases. And
the wider point behind it: **the tools that make the book are as important as the book**, because
what this project is demonstrating is how graphs can be used to write, and the quality of the
product follows from the quality of the pipeline.

---

## The memo

> Okay, so as we now go into the next phase of the book writing workflow, I want to introduce
> another concept, which again you might want to create it as a separate markdown, more for the
> logistics and admin section. But the concept here, and and I guess the underlying law. and even
> you have to think about that. We need to start thinking of the the concept of briefing other
> agents because I want to start bringing other agents to do reviews of this, and and it's
> actually important not only that they will act as users because when you see the, I think there
> was already a vault that we created where we had syntactic users, which worked really, really
> well, where we basically then simulated what the users saw, what they could do, what even how
> they would respond. So we we need to do the same thing for the book, but but there is one
> concept that I want to explore here, which is the concept that a PDF, which fundamentally it's
> a logical way to group content in a way that we control the sequence of events. See, the problem
> with a website is that the website, because of the hyperlink nature, we sort of don't control
> sort of the narrative. We don't control what the user sees. We don't control what is viewed. So
> in this case, whether it's a human or an agent doing the review, we can't just say, "Yo, go to
> town. Especially in a website like ours, where we now start to have hundreds of 1000s, if not
> more, eventually millions of words, right? Because you know not all is going to be relevant,
> right? So the reason I'm arriving at this is because we need to introduce the concept, and we
> probably not need to create this all the time. And some of these might be created on demand, and
> some of these might be created only at specific phases, doing the book development. Also,
> because the nice thing again of these PDFs when we record is that they also provide a nice
> historical view that survives in a way better than web pages, right? Because they they are now
> not modifiable. So one of the things that my thinking and how I arrive at this is that I, for
> example, like I now need to review a lot of those pages that are going to have the the key
> concepts that we need to Provide and and the narrative and the flows and and all the the
> basically those layer three edges that we are talking about, but if you think about like it
> shouldn't it shouldn't depend like for me for me the ability for me to consume that data should
> now not depend on me clicking on a bunch of stuff. Now, don't get me wrong; the UIs are very
> important because they allow a navigation, they allow a sort of a interactive way of viewing it,
> and and actually, I disagree with some of the thing. One of the things you said also, which is
> the visualisations haven't helped. It has helped a lot, right? I know, especially once you start
> adding things like the visualisation for the, for the, for the decisions and visualisations like
> the the micro visualisations of a particular element, that helped a lot, right? Because it was a
> great way to consume. It's a great way to see the interconnectivity. I really like the one that
> connected all the evidence together, so all the concepts together, so it's it's quite powerful,
> right? And this is kind of what I'm saying. Like what I now want to do is, and even this PDF
> that I'm talking about now should contain some visualisations, because we need to get to the
> point where they become a much better way to connect the dots. Because remember that the
> visualisation is also a compression. It's a way. It's another way to represent the
> relationships, right? Like you know, the same way that we calculate those those paths, which
> again, those tables that were created really good. The visualisation and even the tables that
> you have, they are visualisations, right? Now, so the key concept here is: I think we need to
> define and need to experiment with the creation of a set of PDFs that are designed to help the
> reviewer and the author to basically make decisions, understand the concept, understand the
> narrative, provide evidence, and provide Guidance, and and and think about like even when we
> have, for example, a case where I'm going to have editors reading the book, and maybe if you
> have an agent, these PDFs, which basically provide almost a consolidated way to say, look, here
> is a PDF. It could be big. It could be. 50 or 300 pages, right? Doesn't matter. But here's a PDF
> that now covers the key concepts, bang, bang, bang, bang, of the book, which then was used to
> create level three, which then was used to create level two and level one, and then level four,
> level five. But this is a this is a different shaped PDF. This is a PDF. Fundamental. Think
> about the PDF is just a page, right? It's a web page that is continuous that we can print. That
> basically I can, and that's what I mean by this, right? This that's why we don't have to create
> all the time, but it needs to be in in an easy way that I can export and I can just put on my
> iPad. I can read it end to end, or I can even print it because there's a reason why printed
> materials sometimes are good, especially for review, right? So let's experiment with the
> creation of all sorts of these intermediate PDF that are designed to show us and explain and
> even provide further context, right? And maybe we go deep on a couple, not all the concepts, but
> it's it's about these multiple dimensional views, and this is not the printed version, but it's
> a it's a kind of a supporting material version, and and this is the other thing that I find is
> very important is that the creation of tools to aid the author, because remember that what we're
> also doing here is showing how graphs can be used to create books, right, is as important as the
> book itself. In fact, it's this interesting thing where the technology and the workflows for the
> creation of the content are less important, are more important than the final product, because
> the final product quality depends on this first one. So we know we're going to have a great
> product in the end if our pipeline is really good. Also, this is a good example of CI pipelines
> because it means that by now, from now on, we should be shipping new versions of these PDFs and
> new versions of the book every time, and and it's already this continuous deployment workflow
> where we we know look and also we know we are in a good place where most of our conversations
> move from structure and workflows to the content, and we just have thread after thread after
> thread. Or have agents, you know, again working with this, where they just focus on the content,
> which is what we want to do.

*Transcribed by otter.ai. Reproduced without edit, including transcription artefacts: "syntactic
users" is synthetic users, "less important, are more important" is a self-correction mid-sentence
and the second reading is the intended one.*

---

## A correction I owe

The memo pushes back on something I wrote, and it is right to.

The retrospective at `/v1/documents/what-the-graphs-found.html` says **every aggregate view
produced findings and no per-item ego graph produced any**, and calls ego graphs *reading aids*.
That measurement stands: no discovery in that run came from a per-item view. But the conclusion
drawn from it was too narrow, and *reading aid* was the wrong words.

The founder's framing is better and it is the book's own: **a visualisation is a compression**.
It is another way to represent relationships, in the same family as the path tables and the
concept tables, which are also visualisations. Judging a compression by whether it produced a
novel finding is like judging level 2 of the ladder by the same test: compression's job is to
make a structure consumable at an altitude, and the per-item graphs did that well enough that the
founder names them as what made the interconnectivity legible.

So the corrected statement, and the one that goes into the pack's file 07:

> **Aggregate views produced the findings. Per-item views made the structure consumable.** Both
> are compressions and neither is decoration. What differs is what they compress: an aggregate
> compresses a whole corpus into a shape, a per-item view compresses one node's neighbourhood
> into a glance.

The practical consequence for this memo: a review pack carries **both**, and the tables in it are
not filler between the pictures. They are pictures.

---

## What each instruction commits us to

| # | The instruction | What it commits us to |
|---|---|---|
| 1 | "we need to start thinking of the concept of briefing other agents ... bringing other agents to do reviews" | A **briefing** is an artefact, not a prompt typed twice. It names what the reviewer reads, in what order, and what it is asking them to decide. |
| 2 | "they will act as users ... there was already a vault where we had synthetic users ... we need to do the same thing for the book" | Reviewer personas, each with a stated prior and a stated question. A pack is addressed to one of them. |
| 3 | "a PDF ... is a logical way to group content in a way that we control the sequence of events" | **The pack's defining property is sequence control.** Everything else follows from it. |
| 4 | "the problem with a website is that because of the hyperlink nature we don't control the narrative" | The site keeps its job (navigation, exploration) and stops being asked to do this one. |
| 5 | "we can't just say, go to town ... hundreds of thousands, eventually millions of words, not all is going to be relevant" | A pack is a **selection**, and the selection is the work. A pack that includes everything is a website with page numbers. |
| 6 | "we probably not need to create this all the time ... some on demand, some only at specific phases" | Packs are **not all built every release**. Each declares when it is built. |
| 7 | "they provide a nice historical view that survives better than web pages, because they are not modifiable" | Every pack is stamped with the release and the hashes of the data it drew from, and old ones are kept. |
| 8 | "the ability for me to consume that data should not depend on me clicking on a bunch of stuff" | Linear readability is a requirement, not a nice-to-have. A pack must make sense with no link followed. |
| 9 | "the UIs are very important because they allow navigation, an interactive way of viewing it" | The site is not being replaced or demoted. Two surfaces, two jobs. |
| 10 | "the visualisations have helped a lot ... the decisions visualisations, the micro visualisations ... the one that connected all the evidence together" | See the correction above. |
| 11 | "the visualisation is also a compression ... the tables you have, they are visualisations" | Tables count as figures. A pack's figure budget includes them. |
| 12 | "designed to help the reviewer and the author to make decisions, understand the concept, understand the narrative, provide evidence, and provide guidance" | **The five jobs.** Every pack declares which of the five it is for, and is judged on that one. |
| 13 | "it could be 50 or 300 pages, doesn't matter" | Length is not a constraint. Sequence and relevance are. |
| 14 | "a PDF is just a page, a web page that is continuous that we can print" | Each pack is **one continuous HTML page** first, and the PDF is a projection of it. Same source, two outputs, exactly like the book. |
| 15 | "this is not the printed version, it's a supporting material version" | Packs never claim to be the book, and are marked so on every cover. |
| 16 | "the creation of tools to aid the author ... is as important as the book itself ... the technology and workflows are more important than the final product" | The pack machinery is **first-class work**, not overhead, and it is itself a demonstration of the book's subject. |
| 17 | "from now on we should be shipping new versions of these PDFs and new versions of the book every time" | The always-on packs join the release chain and are gate-checked for staleness, like the book already is. |

---

## The specification

### What a pack is

**One continuous HTML page, and a PDF printed from it.** Same source, two outputs, the mechanism
the book already uses. The HTML is the source of truth and the PDF is the artefact that travels.

Every pack has:

| Part | Rule |
|---|---|
| **Cover** | title, the job it serves, who it is addressed to, the release, the date, and the line *supporting material, not the book* |
| **How to read this** | the sequence, stated, and what the reviewer is being asked to decide |
| **Provenance** | which generated data it drew from, with the SHA-256 of each, so a claim in the pack can be traced to the build that produced it |
| **Body** | the selection, in a controlled order, mixing prose, tables and figures |
| **The asks** | what the reviewer should come back with, numbered, so a review can be answered item by item |
| **Nothing that needs a link** | every figure has a caption that carries its point; every table stands alone |

### The five jobs

From instruction 12. A pack declares one as primary:

1. **Decide.** Put a decision, its options and their consequences in front of someone who can answer it.
2. **Understand the concepts.** The vocabulary, its definitions, and how the concepts relate.
3. **Follow the narrative.** The plot lines, the order, the pacing.
4. **See the evidence.** What is claimed, what backs it, and where the gaps are.
5. **Get guidance.** How to work on this: the rules, the grammar, the method.

### The pack family, as proposed

| Pack | Job | Built | State |
|---|---|---|---|
| **Concepts and evidence** | understand + evidence | every release | **ships at v0.4.3** |
| **The decisions pack** | decide | on demand, when decisions are open | proposed |
| **The universe pack** | understand | at the end of phase 2 | proposed, needs the universe |
| **The plot pack** | narrative | at the end of phase 3 | proposed, needs plot lines |
| **The reviewer's briefing** | guidance | per review round | proposed |
| **The editor's pack** | narrative + guidance | when editors join | proposed |

Only the first is built every release. The rest are on demand or phase-gated, per instruction 6.

### Briefing an agent

A briefing pairs a pack with three things the pack cannot carry:

- **The persona.** Who is reading, what they already believe, and what they are allowed to assume.
- **The question.** One sentence. Not *what do you think* but the specific judgement wanted.
- **The answer shape.** How to come back: the review JSON the workflow already uses, so an
  agent's review lands in the same register as a human's and is threaded the same way.

The synthetic-user vault is the precedent the memo names: simulate what the reader sees, what
they can do, and how they would respond. For a book the equivalent is a reader who has read
exactly the pack and nothing else, which is precisely what sequence control makes possible and
what a website cannot promise.

---

## What ships first, and why that one

**The concepts and evidence pack**, because it is the one the founder said he needs now: *the key
concepts, the narrative and the flows, those level three edges*, without clicking through a site
to assemble them.

It carries the twenty-four concepts with their definitions and near-but-nots, the computed peaks
with the formula that produced them, the measured concept-by-document matrix across the
twenty-one carried sources, the concentration table that separates a concept the corpus
distributes from one that two documents carry, the eight findings with their states, the five
build-time checks with their rules, and the open decisions. With figures: the concept map, the
all-documents graph, and the whole decisions register, captured from the live pages.

It is generated on every release, its provenance block hashes the three data files it draws from,
and it is gate-checked for staleness in the same way the book is.

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).