The documents behind Verbatim

Written as the work happened, not assembled afterwards to explain it. Several of them say plainly where they are wrong.

Read these two first if you read nothing else. The MRD says who this is for and what their day looks like. The decisions log holds every architectural choice with the alternatives that were rejected and the cost that was accepted — a diagram without reasoning is worth little, so the reasoning is the artefact.

What is being built, and why

MRD — the market Who the user is, what their day looks like, and what the product refuses to do for anybody else. Carries the eleven coverage areas in plain English. PRD — the product The eight-step wedge, with a status marker on each step, because unbuilt work must not be drawn like shipped work. Roadmap Four weeks, twelve weeks, six months, and what is deliberately excluded. Every item names what has to be true first — an item with no precondition is a feature request.

How it is built

Technical design Each subsystem, its failure modes, and the diagrams. Mapped to the eleven coverage areas so a reader can check them off. Architecture — Part A of the TDD Module tree, dependency direction, the tenant chokepoint, the deploy path, and what changes when SQLite runs out. Security The threat model, what is enforced in code, and what is written down and not yet built. Document structure, measured and not wired in A negative result. A parsed document hierarchy was built, wired into alignment confidence, measured on the real corpus and taken back out, because the only thing it moved was moved by the parser failing to read a document. What was kept, and why that is the better artefact. Technical questions FAQ Honest answers to the hard questions, each citing file:line. Verification, scale, what is built, and what is not. Scalability, measured What the diff path costs on a named machine, where it goes quadratic, and the design that follows from the numbers. Section 4 is not built and says so on every claim. Design Glass on the chrome, paper for the record — and why the withheld claim is the one surface with no effect on it at all.

Who it is for, and what we actually know

User research — the weakest page here 45 messages, 0 replies, 0 interviews, 4 bounces. No line of the product was changed by a user, and the page says so on its first line. The synthetic persona Built from public filings when the outreach failed. Labelled a substitute everywhere it is cited, because it is one. The rehearsal What the persona said, and the standing rule that nothing in it may be lifted into the research page as a finding.

The working record

Decisions — the ADRs Every architectural choice with its rejected alternatives and its accepted cost, written at the time rather than reconstructed. Includes the ones that were later overruled. Findings Every defect found during the build, how it was found, and what guards it now. Most were found by adversarial review rather than by a failing test. Remaining gaps What is still missing, ordered by what a reviewer hits first rather than by effort. The board Task by task. The source of truth over any adjective in any other document here. The playbook Thirty-one engineering principles, each with the failure that taught it, and each tied to something checkable in this repository — or saying plainly that there is no instance here. Submission record What was built, what was reused, what the AI wrote versus what was rewritten or rejected, and what broke.
These are generated, not maintained by hand. scripts/publish_docs.py copies docs/ into the site at deploy time and refuses to finish if any internal link goes nowhere. So there is one copy of each document rather than two, and the copy you are reading cannot drift from the one in the repository.