How to read the program board
Use this guide when you want to see, across the whole program, what waits on whom. You start on the program
home; you end reading /p/<slug>/board, four or five columns of cards headed “Waiting on scientists”,
“Waiting on QA”, “Waiting on the lead”, “Waiting on the owner” and, where a manufacturing specialist works on
the program, “Waiting on manufacturing”. Reading the board needs a program persona; whose name a card shows
depends on program.twins.read. Every surface here carries the status word
designed until the R3 gates pass.
Cards are records, not messages. The board is a read over inbox items joined to their records, filtered by what you may read; it never lets you decide someone else’s item, and nothing on it can be sent. Decisions happen in the deciding person’s inbox with their own permission.
Prerequisites
- A program persona. Viewers read the board too; they see origins as personas, never as named people.
Open the board
From the program home choose Board (/p/<slug>/board, GET /programs/{program_id}/board). Columns are
personas in the fixed order above; each column lists cards oldest first. A table alternative with the same
rows is one keystroke away for screen readers.
Read a card
Each card names the record (title where the thread rule allows it, otherwise “From a private thread”), its
kind (proposal, approval request, hand-off, question, mention), its age, the permission the decision needs and
its origin. For holders of program.twins.read (owner, lead, quality reviewer) the origin reads “Maya N.’s
twin (agent) · scientist” (illustrative); for everyone else it reads “a scientist’s twin (agent)” with the
persona chip, so the board discloses nothing the escalation rule protects. A card whose record changed since
the proposal reads “Changed since proposed”. Cards from your own inbox link to the item so you can decide
there; other cards open the record page only.
Read related proposals
Two twins of different people may propose on the same record. Proposals never resolve each other; the board groups them under the record as “related proposals” so both deciding people see the overlap. Contradictory accepted records are a human matter, resolved in the hand-off thread, with the audit trail showing the order.
Read the counts and the metrics
Column headers carry counts. Owners, leads and quality reviewers additionally see reminders “Waiting on
<Name> for N days: N decisions” for items past their due date (raised at most once per item per day and only
to holders of program.twins.read). GET /programs/{program_id}/metrics/decisions behind the header shows
decisions per persona for the week, “counted from records”; the per-person breakdown is present only for
holders of program.twins.read. Per-person throughput rows exist only in the organisation audit export and
are named in the data-processing agreement.
Act on what you read
Send a hand-off to the persona whose column is long (how to send a hand-off), reassign an open item’s owner, or ask the deciding person. If the person is away, they can delegate (how to delegate while away); you cannot decide for them, whatever you read.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| A card reads “From a private thread” | the record was proposed in a private thread you may not read | the thread rule applies; the deciding person sees the title |
| Origins show personas, not names | you lack program.twins.read | by design; oversight of named twins belongs to owners, leads and quality reviewers |
| A column is missing | no member holds that persona in the program | columns follow the program’s personas |
| A card shows “Changed since proposed” | the linked record changed after the twin filed | the decider sees the diff; the twin may re-file on its next pass |
| The board shows nothing for a viewer | a viewer has nothing to decide; the board still lists other personas’ cards | “Viewers have no twin. Nothing waits for you.” refers to the viewer’s own inbox |
Related
- How to decide from your inbox.
- About personas and twins.
- ADR 0025 for what the counts are and are not.
Source: PRODUCT-PLAN.md Part 7 sections 4 (program board, escalation, conflicts) and 7.4 (GET P/board, GET P/metrics/decisions); PRODUCT-CONTRACT.md sections 11.4 and 11.7; api/scripts/designed-routes.json; web/lib/api/types.ts (BoardOut, BoardColumnOut, BoardCardOut, DecisionMetricsOut); web/lib/content.ts (boardColumns, consoleCopy.personaTwinOf, consoleCopy.waitingOnFor, consoleCopy.decisionsPerPersonaLabel); decisions/0022-inbox-escalation-and-delegation.md; decisions/0025-event-anchored-metrics.md