The Board
Read Pulse AI board state as the operating source of truth for dispatch, blockers, review, and done.
Operating model outline
| Page | Reader job | Unique section | Media need |
|---|---|---|---|
| Workday | Run eligible work from the board | Session signals | Workday screenshot |
| Dispatch | Move selected work into a pool or direct run | Duplicate safeguards | Dispatch diagram |
| Board | Decide what status means | Lifecycle flow | Status flow visual |
| Review Queue | Convert evidence into the next board move | Verdicts and movement | Review checklist |
Read status as an operating signal
The board is the durable ledger. Each item should name the request, owner role, dependencies, acceptance criteria, validation evidence, deliverables, review history, and lifecycle timestamps.
Status tells the dispatcher and the operator what can happen next. Treat status as an instruction, not decoration:
- todo: planned work that can dispatch when dependencies allow.
- in-progress: work currently owned by an agent or active session.
- blocked: work waiting for a prerequisite, decision, provider, or proof.
- review: agent-submitted work waiting for approval or revision.
- done: work approved after review.
Lifecycle flow
todo -> in-progress -> review -> done
| |
v v
blocked needs revision -> in-progress
Blocked is not a failure state. It protects order when dependencies are real. Review is not done. It means the work has been submitted and needs a verdict.
Dependency and blocker rules
Dependencies decide whether downstream work is eligible to run. Before dispatching QA, launch copy, or public-surface proof, check that the upstream implementation and review state are current.
When a blocker exists, update or dispatch the existing owner when possible. Create a new task only when no current item owns the missing decision, source fix, media capture, validation script, or launch proof.
Review movement on the board
A review verdict changes the next dispatch:
- Approved: the user or delegated lead can move the item to done.
- Needs revision: dispatch the existing owner with the review findings.
- Rejected: keep the findings on the same item and create a focused owner only if the current task cannot safely absorb the correction.
Do not erase prior review notes. They are part of the operating record.