How This Site Is Governed

Chapter thirteen says you should be able to hand someone three things: a policy that says what is allowed, a register that says what is running, and a procedure for when something goes wrong. It would be poor form to ask that of a reader and not publish my own. This page is the whole set, for the system that maintains this guide.

The policy

Everything here is public tier. Nothing internal or restricted goes near this pipeline. That single decision removes most of the risk before any control is needed, and it is the reason the rest of this page is short.

What the agents may do: read from the watched sources, read the current text of the guide, and write drafts into one folder.

What they may not do: publish, deploy, send anything outward, touch any other directory, or hold any credential of mine. These are not instructions given to a model. They are the access the accounts have.

The register

One row per automation that touches this system. Same six columns chapter thirteen asks for.

What gets watched

Two classes of source, because this guide has two halves and they do not live in the same places.

• Tooling and capability. Vendor release notes and changelogs, model provider documentation, notable repositories, and the parts of X, YouTube, Reddit, and Hacker News where practitioners publish before anyone writes it up.
• Governance and risk. OWASP and NIST publications, vendor terms of service, retention and training policy changes, subprocessor updates, published incident writeups and postmortems, and regulatory movement.

The second class was added on 10 August 2026, when the guide was recut for companies. Before that the pipeline watched tooling only, which would have left chapters five, six, and twelve going stale without anyone noticing. A feed that only watches what is easy to watch produces a guide about what is easy to write.

Cadence

• Chapters one to twelve: revised monthly, or sooner when something in the governance class moves. These change slowly by design.
• The current landscape: revised as often as the field moves. It is the page to be most skeptical of.
• The glossary and this page: revised when a rule changes, which is rarer and more consequential.
• Every revision is dated in that chapter's revision trail and in the changelog on the home page. Nothing is edited silently.

House style, and how it is enforced

Eight rules govern the prose. No em dashes. One idea per sentence, under twenty five words unless the length is deliberate. Active voice. One meaning per word. Cut clutter. Concrete beats abstract. Keep the humanity. Do not hedge, and always say what would change my mind.

Rules two through six are the useful half of Simplified Technical English, a controlled language written for aerospace maintenance manuals. Rule seven is where this guide parts company with it. STE exists to remove interpretation, which is correct for a procedure and wrong for an argument. The ladders and checklists get STE. Everything else gets Zinsser.

The rules are not a document the agents are asked to follow. They are a linter. It flags em dashes, long sentences, clutter phrases, and comma pileups, and it runs before any publish. It reports rather than rewrites, because a long sentence is sometimes long on purpose and that call needs a person. Chapter thirteen, applied to my own prose: a rule in a document is a preference, a rule in the machinery is a control.

Infrastructure

• The site is static HTML with inline CSS. No build step, no framework, no dependencies, no database. Every page is one file.
• Hosting is a static host with a CDN in front. There is no server to compromise and no application layer to attack, which is a security decision as much as a cost one.
• No accounts, no tracking of individual readers, no paywall. The newsletter is the only thing that collects an address, and it collects nothing else.
• The drafting agents run on hardware I own, in an environment with no access to my accounts.

Incidents

Decided in the quiet, before anything happens. Any of these counts:

• Something published that I did not review.
• A factual claim that turns out to be wrong, in a way that would change a reader's decision.
• The pipeline reaching something outside its declared scope.
• A source cited that I cannot verify.

In each case: the page is corrected within the day, the correction is dated in that chapter's revision trail rather than made silently, and if the error was consequential it gets its own line in the changelog. An error you cannot see the history of is an error the reader has no reason to believe was rare.

What I would change

The honest limitations, since chapter thirteen says a register that only ever adds becomes an archive.

• One approver, no backup. If I am unavailable, nothing ships. Correct for now at this scale, and it would not survive a second author.
• No formal eval on the drafting. I read every revision, which catches errors but does not measure whether draft quality is improving or degrading over time. Chapter ten asks for a number here and I do not have one yet.
• The source list is curated by me, which means the guide inherits my blind spots. I have not solved this and I am not sure it is solvable by one person.

If you spot something this page claims that the site does not do, tell me. That is the most useful message I could get about this project.