A Presentation on a Throughline

The product, and the contract

Throughline is a Git-native requirements tool: one YAML file per item, a permanent UID, typed links, composition of other graphs by reference, and a validator that fails the build on an orphan, a dangling link or an unaccepted item. The first example's technical page sets out the working contract in full. Here it ran at a scale the other examples did not: eleven graphs, four repositories, fourteen sessions on the person's machine and an unmeasured number in the cloud, sometimes three at once on the same repository, over ten days. Everything an agent wrote entered proposed; only the person ratified; a commit names the items it serves; a signed item whose words move goes stale and is reported.

The subject is unusual in one way. The product's job is to take a graph of claims, sources, threads and slides and make a deck from it, narrate it, make it a video and present it; so the product's behaviour is on eight graphs, and the decks it makes are on three more, and the two kinds compose. A deck's graph borrows the product's rules graph as a source, so the rules every deck must pass are written once, ratified once, and cited by every series.

Eleven graphs, and what they compose

The first eight live in one repository; a job there runs tl check on all eight on every pull request and push that changes a graph. The three series graphs are each in a repository of their own, from which the product's builder reads them. Two of the three began life inside the product's rules graph and were moved out on 14 October, when the person asked why a deck's record should live inside the product at all; the commit that moved them tombstoned 599 items in the rules graph and left 91.

The rules graph, shaped before the first edition

The person's second message of the first day asked for a record rather than a deck. The shape pass proposed thirteen registers and the reasoning behind each: an audience's interests, topics, sources with the day each was checked, claims, threads, slides, editions, requirements, tests, non-goals, an intent, and later roles and series. He agreed the shape in two messages and signed 36 items twenty-nine minutes after his first message; seven minutes later, the first 75 of the rules graph. The rules say what every deck must satisfy: a claim rests on at least one source; a news claim rests on a source published inside the edition's window; every thread carries news; a slide that states a number shows its claim; a slide holds its layout, its place and its words; the same graph gives the same deck; one command checks an edition and names what failed. A second kind of series, training by role, added twelve rules the next day: a training claim is guidance or product, a product claim rests on the maker's own source, a role deck answers every question of its series, a section shared between decks is written once and included by link.

The series graphs, and the talk that was not signed

A series is a graph at a repository, branch and path of its own, declared to the product by a tenant's administrator. The monthly briefing's graph holds three editions and is fully ratified. The training series holds twelve decks and 521 items, 220 of them still proposed, because seven of the decks were written in a cloud session on 13 October and never read. The talk's graph was shaped on 7 October for a different purpose, became a series the product could build on 14 October, and carries two editions and 55 slide items. The person ratified exactly one of its items, the series itself, on 14 October at 19:17, and did so by accident twice over: he had meant to sign that item alone, found he had signed everything, and had the rest reverted.

Nothing else in it is signed, by his decision. The product's rule, ratified on 9 October, is that a deck of a series whose decks wait for a person is listed only when every item it shows is ratified. On 16 October a second rule let a deck set its own approval ahead of its series', and the talk was set not to wait. So the product built, narrated and published a deck whose every claim is unsigned, and said nothing about it on the slides, because the person asked it not to. The record of what the talk claims and where each claim comes from is complete; nobody has put their name to it. That is a legitimate use of the tool and this page records it as one.

The builder and the narration rules

The builder is a script that renders an edition from its graph into slides, speaker notes and a slide file, byte-for-byte the same for the same graph, and its graph was signed on the first day before the October edition was built with it. The narration graph was shaped on the fourth day, after the person listened to a deck read aloud and heard that a speech service reading notes misses what they mean. Sixteen rules say how a spoken script is written from a slide and its notes: it refers to what is on the slide, it says figures for the ear, it does not read a URL aloud, it keeps a note's claims and adds none. Eight safeguards bound the rules; three examples show them applied. On 15 October a second decision split the script in two, one written for the reader and one said for the listener, so that a tenant's rules for how words are said, an acronym spelled out or a surname respelled, change what the speech service hears and never what the subtitles show.

The site and the service

The site graph began as eighteen items on the first evening, signed an hour and a quarter after the site they describe was live, which is the one place in this work where the code preceded its record. It grew to 249 as the presenter, the worker, the voice-over, the take editor, subtitles, the builder in the cluster, drafts and the queue were each proposed, read and signed before being built. The service graph was shaped on the first night with a security standard composed at its second level, after the person asked for it by name, and the tenants, the roles and the estate's shared sign-in were added on the third night, the night he found the product did not look like its siblings and said the rule was never up for debate. The standard was not decoration: 263 of its clauses are cited, each clause read beside the requirement that claims it when the requirement was written.

The page graph, and the shape graphs

Two shape graphs record why the other graphs have the registers they have. Both were written by the shape pass, both are entirely root types, and both compose the graphs they explain without citing them. The page graph was shaped on 10 October to be held to the same two standards as the service and to three published conventions, an appearance convention the estate's other applications follow, a general audience and a purpose of instruction; the person's answer when the second of those was proposed was to choose instruct over explain because "the intention is to help people use the tool itself". Its registers are pages, components, requirements, checks and conformance claims, and a requirement derives from an intent and names the page it is for, which is the rule the person asked for on the fourth day when he read the take editor's requirements and asked whether they should not link to the page they belong to.

The product's own gate

The product enforces the record on the decks it builds, independently of the tool's check. Four mechanisms, each a ratified requirement:

• A deck of a series that waits for a person is listed only when every item it shows is ratified. Site rule, 9 October. The builder reads each slide's item and its status from the series' graph, and a deck with an unsigned slide is not published to that series' tenants.
• Such a deck is built as a draft instead: one still per slide, beside the item it comes from, whether that item is signed, its notes, the claims it rests on and their sources, and an appendix of items no slide shows. Site rule, 15 October, asked for the evening before: "can I see a draft before I start signing, perhaps with item UID references". Signing happens from that page in the name of the person's linked code-host account, and the product opens a pull request into the series' repository carrying the signatures; nothing is merged by the product.
• A deck that does not wait is marked nowhere, 16 October, after a talk was stamped with a briefing's marking and a line saying nobody had approved it. The marking is the series' own word; a deck may set its own approval ahead of its series'.
• The builder refuses a deck that breaks a rule and says which. On 15 October it refused the talk at a new revision, a rows slide takes two to three item lines, found five, and the deck dropped off the site instead of keeping its last good build. The refusal was right; dropping the deck was a fault, written up with its cause, and open.

And one pass that was not a mechanism but a reading. On 13 October the person asked that every claim be read against its source. All 228 claims in the rules graph were checked against the 81 sources they cite; every source was real; 214 claims were supported; 14 stated something their source did not, and were amended with tl amend, each item's rationale recording what the source actually says, together with the six slides that repeated the wording. Nothing in the gate could have found those fourteen. A link from a claim to a source resolves whether or not the claim is true.

Ratification, in three channels

The person signed 1,432 items over ten days, in three channels, and the AI committed the signatures.

In his terminal, one item at a time. From the first hour the hand-over named the repository, the branch, the graph directory and the items, and gave the full-screen assistant that shows each item before asking; the session record carries the shell lines where he ran it, at least ten times on the first day. Fifty-four commits over the ten days carry signatures given this way, eight of them from 15 October saying so in their subject. Asked on the first day to "ratify the builder graph too", the AI declined, because a signature has to be his, and found he had already signed it.

In his terminal, as a list. Some sessions handed over this form instead, which signs a list unread. On 14 October at 19:16, in the talk's repository, he signed a whole graph when he meant to sign one item: "I think I inadvertently ratified everything can you revert that and I'll ratify SER-0001 alone". On 15 October a session handed him a list at three in the morning and, after a merge renumbered the items, another at a quarter to five: "I hate this ratification of multiple items without an opportunity to read you should be using tl-ratify the TUI". The project's standing instruction to every session was rewritten one minute later, at 04:52, and the third signing of those items that morning was in the assistant.

From the browser. Fifty-five pull requests titled "Review of graph … by the person", 12 to 17 October, each carrying the signatures made in the browser editor on one graph of one branch. This is how the cloud sessions got their signatures, since the person could not reach their terminal, and how the overnight list of 15 October was signed from a phone at 04:50 the next morning: "I'm not at the keyboard yet but if you give me links I'll take a look at any items that need ratifying". Thirty-three of the fifty-five were on 16 October. The rule for a cloud session is now written down: one link per graph, opening on just what can be signed now.

And never by proxy. On 13 October at 21:28, away from his computer, he asked the AI to read him the sharing and branding items and sign on his behalf with his authority. The AI read them and he corrected two; the pull request was pushed with its items amended and a note that ratification was asked for again, and he signed them in his terminal the next day. The two refusals, on the first day and the sixth, are the AI's, and the record shows both.

Three sessions on one graph: UIDs collide

Throughline allocates the next UID in a register when an item is made. Two sessions on two branches of the same repository both allocate the same number, and the merge resolves it by renumbering one side with tl resolve and repointing every link. A renumbered item keeps its fingerprint but not its number, and a signature given under the old number is given again under the new one. The draft-for-signing items were signed three times on the morning of 15 October, at three sets of numbers, as two other branches merged ahead of them. On 16 October the person asked "can I proceed or do we have a REQ UID clash?" before signing, which is the right question and should not have been his to ask. The working rule now is to fetch and rebase before tl new, and to expect an add/add conflict on an item file when two sessions have been busy.

The gate, in the pipeline from the sixth day

For the first five days the check ran only where a session ran it. On 13 October the person noticed that three signing sessions on three graphs had started three builds of the product's images, and two workflow changes landed within an hour: a change to a graph alone starts no build, and a job runs tl check on every graph on every pull request and push that touches one, non-strict, so that a proposed item waits rather than fails. A branch-protection rule requiring the build was asked for on 14 October and refused by the code host, which does not offer it on a private repository under the free plan; main is unprotected by a signed decision from the first night, and every merge since the job landed has passed the check; the strict form, which the assessment requires, does not pass today, and the next section says why.

Signatures that moved

Thirty-four ratified items were amended after their signature, in sixty-six amending commits, and each amend was reported by the tool at the moment it was made: the host wording in three site items when the product was renamed; the series items when a series gained a repository of its own; a test's tolerance; a requirement reworded when a second decision narrowed it. All but one have been signed again. The one that has not is a test in the rules graph whose words moved and which the strict check names today.

The one amendment that matters most was not a defect in the record but a decision the record lacked. "Not yet approved by a person" on the cover of a deck that waits for sign-off was a ratified requirement, built, tested and correct. The talk did not wait, and the record had no way to say so. The fix added the missing decision rather than weakening the rule: a deck may set its own approval, and a deck that does not wait is marked nowhere.

The assessment

The work is not at the point the assessment script calls done, so no record is filed in the collection; the figures below are the script's individual measures taken on 17 October 2026 at the last commit of the morning, and will be recorded properly when the work reaches done. What stands in the way: two pull requests open; eleven requirements across three graphs with no incoming verifies link; one test in the rules graph ratified-stale; two service requirements deferred without ever having been ratified; and 387 proposed items in the series graphs, 220 of them the seven unread training decks and 167 the talk, which by decision will stay so.

The session figures count the fourteen records on the person's machine whose main subject was this product or its decks, and leave out five adjacent sessions that built the speech service's tenancy, the shared sign-in and a graph explorer, and every cloud session, which left no transcript here. The two shape graphs' items are counted in the product's 1,060.

What the tooling taught

The account. What happened, who did what, what it cost and what went wrong is on the account for a general reader.