A chat with Reid Westwood about document control
Reid Westwood sent me a message that began:
Dude I've been thinking a LOT about git-like human-facing document control. It's been really bugging me, to the point I have been thinking about building it.
I knew roughly what he meant before I reached the second paragraph. I had been building Stet around the problem of an agent editing a document and leaving the person responsible for it with no good way to see what happened. Reid's problem was wider. He was working on a cybersecurity concept design at Rondo. The design lived across several documents, Claude Code and markdown made the work dramatically faster, and nearly everyone who needed to review it lived in Office 365.
I wrote back that I thought our problems were basically the same, then we got on a call and spent the next hour working out how they were the same and where they were not. Reid's cleanest description came in that first message:
The crux of the issue in my mind is SETS of documents which need to be kept in lock-step. Superpower for AI; annoying for humans.
That line has stayed with me because most document software treats a file as the unit of work, and I had mostly been doing the same. Stet watches a file, catches a change, and shows it for review. Reid was describing the point where that model starts to bend. The real unit of work was one decision and every place that decision had to land, even when those places were spread across five documents written for five different readers.
One change, five documents
Reid wanted to work in Claude Code and markdown partly because he could give the agent reference material, investigate an unfamiliar cybersecurity problem, and use the findings to shape the design. The other reason was more mechanical:
A conceptual change or change in signal name has to propagate to 5 different docs. Claude is great at that.
The documents served different readers and purposes, but together they described one system. A changed name, requirement, assumption, or interface could make several of them wrong at once. This is an unusually good job for an agent. It can read the whole set, find the places where the idea appears in different language, and revise all five before a person has finished opening the second one. It can also spread a bad decision just as efficiently as a good one, which is where the appeal and the problem start to become the same thing.
Reid gave me an example from an operator interface. Someone wanted to remove a timer because it was annoying. It sounded like a small UX request, and somebody said it would be no problem. Another person then realized that the timer was the fallback for several operating conditions. Remove it and the system would need to detect and manage four cases another way. The visible edit was a timer, but the decision crossed the operating concept, controls, interface, and instructions. Five perfectly synchronized documents would still be a bad result if they all carried the wrong decision.
That is the part a normal file diff cannot show very well. You do not need one more red and green rendering of the timer sentence. You need the timer, the reason it exists, the four conditions exposed by removing it, and the places where the eventual decision has to be reflected.
The last five percent
On our call, Reid estimated that AI got the cybersecurity package to about 95 percent complete ten times faster than his old process. Then the work had to cross into Office, which he described in his first message like this:
A lot of my reviewers aren't in github, so I'd have to use a script to generate docx files to upload to 365. And then the fun of taking comments and suggested edits and keeping in sync with the real source of truth (.md)
The conversion itself was not the hard part. Pandoc can turn markdown into a Word document. The hard part was returning with the work around the words intact. Who wrote this paragraph? Which comment prompted that revision? What did the reviewer accept? Did the markdown source change while the Word copy was out for review? Which version now stands? On the call Reid said the process had “just hit mud,” which is a much better description of the last five percent than synchronization architecture.
I knew the mud because I had built my own version of this workflow at Pulse. Important specifications lived in markdown so agents and engineers could work across them. Our technical writer preferred Google Docs. I first tried the reasonable user-centered answer, which was to leave her in the tool she liked and make the systems talk to each other. I wrote scripts to push material into Google Docs and compare what had been requested, what engineering had built, and what the documentation said. The outbound trip worked pretty well. The return trip became a second source of truth, and keeping both copies honest was most of the work.
That failure was one of the seeds for Stet. Instead of trying to make Google Docs the front end for my markdown files, I started asking what it would take to make the markdown workflow comfortable for someone who did not care about markdown or git. Reid had arrived from the other direction and built a VS Code extension for comments, stored in sidecar files. We had both independently made small document-control systems because the ordinary tools divided one body of work into incompatible pieces. This is usually a sign that a problem is real. It is not yet evidence that either homemade answer is the right product.
Changes come in waves
Reid also named what git got right:
I actually DO like the git commit feature, because changes can captured in waves, and each wave is a version number on the doc package.
A wave is one meaningful change moving through a set of documents. Rename the register. Change the operating assumption. Remove the timer. Each may touch several files, involve several people, and take several rounds of work. The commit gives that work a shared release point. Word gives a reviewer discrete changes to accept or reject. A useful document workflow probably needs both.
I told Reid that Stet was already using the mechanics of waves while pretending they were discrete changes. Underneath, an agent's work arrives as a branch or a batch. In the interface, I break that work apart so a person can address each edit on its own. I had over-indexed on an earlier lesson that anything git-like scares off people who just want to write, so I kept pulling the product toward smaller and smaller visible units.
That is still right for someone reading one document. It is wrong for the person responsible for a change that crosses the package. If an agent updates twenty places for one reason, presenting twenty equal changes forces the reviewer to reconstruct that reason twenty times. It also produces exactly the kind of approval fatigue I have already been trying to remove from Stet.
I do not think the answer is to take away the individual decisions. A person should still be able to accept one edit, reject another, and refine a third. Those decisions can sit inside one larger wave, though, and the wave can preserve why the files changed together. When it is ready, every affected document advances as one version of the package. “Wave” is still a working word. I am not convinced it is what the button should say.
The horizontal document
The most useful turn in our call came when we stopped treating the files as the review surface. Reid called the alternative “the horizontal as a document.” If one decision affects seven places, the reviewer should not have to open seven files and reconstruct the connection. A useful view would pull in the relevant section from each source. It might show an overview from one document, a detailed requirement from another, an interface table, an operator instruction, and a QA case.
The section matters here. A sentence is usually too small to carry the reason something exists. A whole document contains too much unrelated material. The useful boundary is the passage where the concept, behavior, requirement, or decision is actually explained, and that boundary will not always line up neatly with one markdown heading. One document might contribute the overview, a detailed subsection, and a table in an appendix. Another might need no edit at all but should still appear so the reviewer can confirm that it remains correct.
I keep picturing this as a board that pins those sections beside the originating change. Each card explains why it is there. The person can update it, confirm it, mark it superseded, dismiss the connection, or defer the work. If seven sections need revision, Stet can assemble the paths, the source change, and the relevant context into a prompt for the person's agent. The agent prepares the edits, and the resulting proposals return to the same board for review.
Later in the conversation we wandered into an analogy with Excel. A spreadsheet often starts as both the data and the view of the data, then eventually a company realizes those should be separate. The database becomes the record. A dashboard gets generated for the question somebody is trying to answer. A set of documents may be moving toward the same split. The files remain the durable sources. The horizontal review is a temporary view assembled for one decision, which means nobody has to maintain it as another document that can also become stale.
What Stet should and should not do
I do not want Stet to prescribe how somebody develops a concept, writes a specification, or plans the work. Reid has a fairly elaborate artifact-driven process. I have accumulated my own collection of specs, decision records, plans, QA documents, and backlog items. Another team will have different names and a much looser sequence. Stet should be a good interface for whatever process they are already using, not the manager standing over it.
What it can do is understand that those artifacts have relationships. Some documents are current sources of truth. Some are historical decisions that should be superseded rather than rewritten. Some are generated views that should simply be regenerated. A user guide may depend on several specifications, and one specification may drive architecture, implementation, QA, and documentation. I would rather have Stet infer those relationships and let the person confirm them than ask everyone to build and maintain a requirements graph before anything useful happens.
When one of those sources changes, Stet can show the documents and sections that may be affected and offer to start a version wave. The person can see the relevant material together, send the assembled context to their agent, review the proposals, and release the package when it is coherent enough to stand. Unresolved impacts should remain visible, but Stet should not pretend it has the authority to block a decision the owner understands better than it does.
This is not what Stet does today. Today it makes edits to plain files visible and reviewable, one document at a time. That remains the useful starting point for a writer or designer who may never need anything else. The conversation with Reid made me see a cross-document version of the same job for the PM, founder, engineer, or package owner who is already using agents across a body of work and then rebuilding the connections in their head.
Reid's phrase is the cleanest description I have found:
SETS of documents which need to be kept in lock-step. Superpower for AI; annoying for humans.
I think the opportunity is to keep the superpower and remove the annoying part without asking every reviewer to become a release engineer. I am less certain about how much structure this needs, when Stet should suggest a wave, or whether “wave” survives contact with a normal person. Those are product questions I can test. Reid gave me a much clearer description of the work they need to support.