Verbatim — Structured Project Memory: Index

Entry point for docs/.ai/. Read this first. It says which file answers which question, so nothing has to be inferred by reading everything.

Read in this order

#	File	The one question it answers	Authoritative for
1	`state.json`	What is actually built right now?	Everything factual about the current state. Generated by `make status` from the repository itself — module list, test count, ADR count, git HEAD. It is the only file here that cannot be stale, because no human writes it. Where any prose in this folder disagrees with `state.json`, `state.json` is right.
2	`decisions.html`	Why was it built this way and not the obvious other way?	Every technology and design choice, with alternatives, trade-off accepted, and what would overturn it. One `<div class="d" id="adr-00N">` per decision, carrying `data-*` attributes so a reader does not have to parse prose to get status, date, or relationships.
3	`tasks.html`	What is planned, in what order, and what gets cut first?	The 48-hour build board, the cut list, and the standing risks. Task ids `T1..T25` are referenced from ADRs and commit messages.
4	`findings.html`	What went wrong, and what was decided under pressure?	Every defect found during the build with how it was found and whether it is fixed, every false claim caught in a document, and every judgement call with its reversal condition. Eleven defects; seven were found by review rather than by a failing test. Read this before believing the test count means the code is safe.
5	`briefing.html`	How does this submission score against the rubric it is judged by?	The four evaluation dimensions with an honest assessment of each, the questions the panel asks with written answers, and the limits to concede before being asked.
6	`interview-bank.html`	How do we survive adversarial technical questions without overclaiming?	Internal prep: traps, follow-up chains, do-not-say list, and founder-behaviour notes. Cross-references the public `docs/tech-questions-faq.html`, which is the source of truth for citations.

File

The one question it answers

Authoritative for

state.json

What is actually built right now?

Everything factual about the current state. Generated by make status from the repository itself — module list, test count, ADR count, git HEAD. It is the only file here that cannot be stale, because no human writes it. Where any prose in this folder disagrees with state.json, state.json is right.

decisions.html

Why was it built this way and not the obvious other way?

Every technology and design choice, with alternatives, trade-off accepted, and what would overturn it. One <div class="d" id="adr-00N"> per decision, carrying data-* attributes so a reader does not have to parse prose to get status, date, or relationships.

tasks.html

What is planned, in what order, and what gets cut first?

The 48-hour build board, the cut list, and the standing risks. Task ids T1..T25 are referenced from ADRs and commit messages.

findings.html

What went wrong, and what was decided under pressure?

Every defect found during the build with how it was found and whether it is fixed, every false claim caught in a document, and every judgement call with its reversal condition. Eleven defects; seven were found by review rather than by a failing test. Read this before believing the test count means the code is safe.

briefing.html

How does this submission score against the rubric it is judged by?

The four evaluation dimensions with an honest assessment of each, the questions the panel asks with written answers, and the limits to concede before being asked.

interview-bank.html

How do we survive adversarial technical questions without overclaiming?

Internal prep: traps, follow-up chains, do-not-say list, and founder-behaviour notes. Cross-references the public docs/tech-questions-faq.html, which is the source of truth for citations.

What is deliberately not here

This folder holds decisions, state and plans. It does not duplicate anything that lives in the code or in the wider docs, because two copies of one fact drift apart and the copy nobody reads becomes wrong first.

Looking for	It lives in
How the system is put together — modules, data flow, boundaries	`docs/tdd.html`, Part A
Who the user is and what problem this solves	`docs/prd.html`
Whether the market is real	`docs/mrd.html`, which also carries the outreach log
Threat model, isolation, what reaches a model vendor	`docs/security.html`
Who was interviewed and what changed because of it	`docs/user-research.html`
The web surface and its deployment	`docs/web-design.html`
Portable engineering principles, each with the failure that taught it	`docs/best-practices.html`
What was built, reused, and what the AI wrote versus what was rewritten	`docs/submission.html`

Looking for

It lives in

How the system is put together — modules, data flow, boundaries

docs/tdd.html, Part A

Who the user is and what problem this solves

docs/prd.html

Whether the market is real

docs/mrd.html, which also carries the outreach log

Threat model, isolation, what reaches a model vendor

docs/security.html

Who was interviewed and what changed because of it

docs/user-research.html

The web surface and its deployment

docs/web-design.html

Portable engineering principles, each with the failure that taught it

docs/best-practices.html

What was built, reused, and what the AI wrote versus what was rewritten

docs/submission.html

How the decisions relate

Most ADRs stand alone. Five do not, and the dependencies are the interesting part of the design. Each is declared on the ADR itself as data-depends-on, data-revisits or data-implements, so the graph below can be rebuilt from the file rather than trusted from this drawing.

  ADR-001  one user: the regulatory-affairs analyst
     |
     +--> ADR-002  the wedge is change-to-action, not search or alerts
              |
              +--> ADR-003  citations verified against source offsets   <-- THE HARD BET
              |        |
              |        +--> ADR-013  four screens; the citation chip is where it becomes visible
              |        +--> ADR-006  low confidence escalates rather than guesses
              |
              +--> ADR-004  deterministic diff first, model interpretation second
              +--> ADR-005  draft versus final is a first-class field

  ADR-007  Python, FastAPI, SQLite, server-rendered
     ^
     |  revisited under pressure, and upheld
     +---- ADR-012  a designed interface does not require a framework

  ADR-009  hosted instance is primary; the local run stays the contract
     |
     +--> ADR-010  its own disposable droplet, not the shared host
              |
              +--> ADR-011  Caddy and Compose, not Coolify

The one worth reading if you read one. ADR-003. Every other decision is downstream of it, and it is the only one the product is designed to make visible rather than merely correct: a reviewer can watch a claim refuse to assert itself when its citation does not verify.

How to tell designed from built

This project's own rule is absence is denial — nothing asserts itself without evidence. That applies to these documents about themselves. Several controls described in docs/security.html are designed and not built, and the documents say so in those words rather than using the present tense. If a document here states a capability in the present tense, it is claiming that capability exists in app/, and state.json is how you check.

Known-false claims are corrected in place, not deleted. Where a document here once said something untrue, the correction stays visible with its reasoning — see the audit trail section of docs/security.html, which retracts a control that is unavailable on SQLite. A repository that quietly edits its own errors teaches a reader nothing about how carefully it was built.

Conventions that govern this repository

If you are an automated reader