Documentation index

Fifteen documents, grouped by what you are trying to do. Start with the row that matches your reason for being here.

If you want to...	Read
Understand the claim	WHITEPAPER.md
Judge whether the claim holds	REVIEWER_GUIDE.md
Know what is not true yet	STATUS.md
Run it	GETTING_STARTED.md

Understanding it

WHITEPAPER.md — the v1 design paper: thesis, system model, mechanisms, evaluation, novelty, limitations.
ARCHITECTURE.md — boot flow, process model, IPC, service registry, the user-space driver path, package lifecycle; with the Mermaid diagrams and the repository layout.
RELATED_WORK.md — where Dezh sits in the literature (capabilities, DIFC/provenance, sagas), what is reused, and the precise novelty claim.
SECURITY_MODEL.md — the threat model first (it scopes every other claim), then the enforcement model: capability boundaries, the bitmask-vs-object-capability question, revocation.
SUBSYSTEMS.md — designs that carry their own trust argument: Marz, the guarded egress boundary, and package signing.

REVIEWER_GUIDE.md — what to inspect and in what order, how to run each demo, and the FAQ.
STATUS.md — one honest page of what is and is not true today.
transcripts/ — captured output from real runs: riscv64, agent-f1, overnight. These files are generated by the kernel under QEMU, not written by hand; tools/demo/ regenerates them in place.

ROADMAP.md — the near-term milestone sequence with acceptance criteria, plus the slower-moving strategic direction that produced it.
DECISIONS.md — the decision log; entries are referenced by ID from commits and other docs.
RELEASING.md — release process, packages vs releases, git workflow, GitHub profile.
RELEASE_NOTES.md — notes for the current release. Kept separate because the release workflow feeds this file to GitHub verbatim.
OUTREACH.md — review-request drafts. Every claim in them must stay true to STATUS.md.

Note: ../SECURITY.md at the repository root is the GitHub vulnerability reporting policy. The design document is docs/SECURITY_MODEL.md above.