Domain · Intake and triage
What it covers
Receiving platform specs and requests from the primary loops, triaging by impact, and maintaining a visible queue that loop owners can see and contribute to.
Activities
- Receiving platform specs and requests from the primary loops.
- Triaging by impact — which unblock will produce the largest primary-loop leverage.
- Maintaining a visible queue that loop owners can see and contribute to.
Operations
Spec intake operation
Spec received from loop owner → validated against template (signal, closed state, impact) → categorised (infra, integration, data model, product surface) → logged in queue. A spec missing signal or closed state is returned for revision before being accepted.
Queue prioritisation operation
New specs and scheduled re-ranks → impact scored against primary-loop closure rate → queue re-ranked → top items moved to design/build.
Queue visibility operation
Queue state published to all loop owners → status and ETA kept current → updates pushed when priorities change → feedback loop from loop owners on whether the queue reflects their real blockers.
Notes
Intake is the gate that keeps the Platform Loop honest. If specs enter the queue without a defined closed state, the Platform Loop cannot validate its own work, and loop owners cannot confirm that a ship actually unblocked them.
A queue that only tracks effort (not impact) will default to building what is easiest, not what unblocks the most. Impact-based prioritisation is the discipline that prevents this drift.