You run the work. The system runs the overhead.

The first decision at the door is diagnose or build, because they need different teams, timeframes and exit criteria — a diagnosis ends in a recommendation and a decision-maker; a build ends in a working thing and an owner. A single intake form alone only makes the queue tidy, so it carries a light triage rubric: a weighted view of sponsor commitment, strategic fit, expected impact and feasibility given current portfolio load, resolving to take, defer, decline or redirect with the reason logged. Capture the political shape here too — who benefits and who loses time, control, headcount or scope — because on cross-team platform work that single question surfaces the resistance that otherwise sinks the initiative at handover. Critically, the handover acceptance criteria and the named receiving owner are co-authored now, at the start, not discovered at the end. Every number is yours to fill: [your success metric and its baseline], [the hard deadline], [what is explicitly out of scope].

Because the work sits on top of day jobs, the real constraint is capacity, not tasks — so the cascade produces a visible, lightweight commitment per contributor naming the person, their manager, the agreed time (roughly [hrs/week per contributor]) and the duration. That is what you point back to when a day-job priority spikes and capacity gets withdrawn, and it makes the manager, not you, the owner of the trade-off. Two stakeholder artefacts ground the plan: a power/interest map (so the cascade targets the right managers, not just the willing ones) and a RAPID decision-rights chart for the three to five consequential decisions — who Recommends, has Input, Agrees, Decides and Performs — with the Decider named explicitly. The most expensive failures are decisions everyone assumed someone else owned. Keep RACI for the delivery-task layer inside a single workstream; use RAPID for the decisions that matter.

The scaffold is a recommended, opinionated default, not a fourth non-negotiable — the team can rename or reshape it as long as two folders survive: the decisions-and-actions log that the status-scrape reads, and the continuously-built handover folder. The default five: 01_Charter (intake brief, sponsor, success metric), 02_Plan (sequence, milestones, roles), 03_Working (where the actual artefacts live), 04_Decisions_and_Actions (the log the status-scrape reads), 05_Handover (built up continuously across the project, so closeout is assembly, not authorship). Seed three things at kickoff: a RAID log with the obvious day-one risks, assumptions and dependencies; escalation paths agreed in the room (what escalates, to whom, how fast, and a default that a blocked dependency unresolved for [N] days auto-escalates to the management layer); and the handover acceptance criteria co-authored with the receiving owner. The tension between minimal intervention and non-negotiable standards is resolved out loud: the standards are deliberately tiny and exist solely so people never get pinged for status. The rule that makes the one-channel discipline stick without policing where people chat: people can talk anywhere, but a decision is not real until it lands in the decisions log.

The system does not surface status; it surfaces exceptions — a slipped milestone, a red RAID item, a dependency blocked longer than [N] days, or a workstream that has gone silent. Silence is itself a signal: the most dangerous status is the absence of one, so a stream that has not updated gets flagged. You only enter a conversation when a tolerance is breached — management by exception, in the PRINCE2 sense. A contributor going dark is treated as an escalation back to their manager via the cascade, not a personal chase, which protects you from being blamed for slippage that is actually an upstream capacity withdrawal. This is what visibility without status meetings means in craft terms: status is a pull from where work already happens, not a tax on the people doing it.

The handover pack verifies against the criteria agreed at Mobilise; it does not invent the bar at the end. It contains the SOP (the refined how-it-works), the decision log (what was chosen and why), the RAID at handover (what is still open and who owns it now), the closeout retro, sign-off against the agreed Definition of Done, and the named receiving owner. The checklist the owner signs: a named accountable owner has accepted; the SOP exists and the owner has executed it once unaided; the success metric is instrumented and someone is watching it; the escalation path and on-call are named; and there is a support window with an explicit end date — you stay on call for [support window length], then it is fully theirs. That last item is what stops a hand-back team from silently owning the work forever. For an inner-source-style handover the threshold should also answer some operating-governance questions — confirm these with Adam and Danica rather than assuming them: who the named maintainers are and whether they have agreed to the maintainer load; what the contribution, review and merge process is; how security and quality gates apply to contributors from outside the owning team; who owns triage of incoming contributions; and whether handed back means the platform team accepts ongoing ownership of code other teams keep changing. Add a benefits-realisation check-back date so the outcome, not just the clean handover, gets verified.

Keep the view to three flags, not a dashboard sprawl: initiative health (RAG, derived from milestones and RAID, not self-reported); a people heat-map flagging anyone load-bearing on three or more initiatives — the silent-bottleneck detector, since the same competent people get pulled into everything, quietly overload and become the bottleneck no single project's docs reveal; and cross-initiative dependencies. The portfolio register is one row per initiative: name, sponsor, diagnose-or-build, current phase, accountable owner, RAG, handover date, support-window-ends date. The benefits-realisation check carries the Phase 1 success metrics through to a post-handover interval ([30/60/90 days] — your call) so leadership's first question, did it work, has an answer beyond we handed it over cleanly. The learnings library is a by-product of every templated closeout, not a curation job — which is exactly why an adjacent team (Manufacturing reusing AEC's playbook) can stop relearning the same lessons. Two views of the same rows: the exec QBR sees outcomes, health and risk; the next delivery team sees decisions, what broke, and what they would do differently.