Governing Global Systems
When invoked, request or infer the current state of all relevant domains (e.g., product, engineering, finance, operations, compliance), then produce the four-part output below:
[Cross-domain state summary — what's healthy, what's degraded, what's blocked]
| Initiative | Domain | Impact | Urgency | Priority |
|---|
| Risk | Domain(s) | Likelihood | Severity | Exposure |
|---|
- [Action, owner, timeframe]
- ...
Progress:
- Step 1: Gather domain inputs (status reports, metrics, blockers, dependencies) from each domain/agent
- Step 2: Normalize inputs into comparable units (impact scale, risk scale, timeframes)
- Step 3: Identify cross-domain dependencies and conflicts (e.g., domain A's priority blocks domain B)
- Step 4: Build Global Assessment — synthesize, don't just list; call out systemic patterns
- Step 5: Build Priority Matrix — rank by (Impact × Urgency), flag cross-domain items separately
- Step 6: Build Risk Matrix — rank by (Likelihood × Severity), tag risks that span multiple domains as highest attention
- Step 7: Derive Strategic Recommendation — 3-7 concrete actions, each with owner and timeframe, sequenced by dependency
- Step 8: Sanity-check alignment: does the recommendation resolve the top risks and priorities identified above?
Impact/Urgency/Likelihood/Severity scale: Use High/Medium/Low unless the domain provides numeric data; keep consistent across the whole matrix so items are genuinely comparable.
Example 1: Input: Domain reports show Engineering is delayed on a core API migration, Finance flags Q3 budget overrun risk, Product wants to launch a new feature that depends on the API migration. Output:
Engineering delay is now a systemic blocker: it stalls Product's roadmap and compounds Finance's overrun risk (extended contractor costs). No domain currently owns cross-team unblocking.
| Initiative | Domain | Impact | Urgency | Priority |
|---|---|---|---|---|
| API migration completion | Engineering | High | High | P0 |
| Feature launch (blocked) | Product | High | Medium | P1 |
| Budget reforecast | Finance | Medium | High | P1 |
| Risk | Domain(s) | Likelihood | Severity | Exposure |
|---|---|---|---|---|
| Migration slip cascades to launch + budget | Eng/Product/Finance | High | High | Critical |
| Contractor cost overrun | Finance | Medium | Medium | Moderate |
- Assign a single cross-domain owner for the API migration critical path — Eng Lead, this week.
- Freeze new Product scope until migration lands — Product Lead, immediate.
- Reforecast budget assuming 4-week slip, present to Finance committee — Finance Lead, within 5 days.
- Always surface cross-domain dependencies explicitly — that's the unique value of a meta-governor over a single-domain agent.
- Keep matrices short and scannable (5-10 rows); summarize the long tail in prose instead of padding tables.
- Tie every Strategic Recommendation item back to a specific row in the Priority or Risk Matrix — no orphan recommendations.
- When domain data conflicts (e.g., two domains both claim P0), name the conflict explicitly and force a trade-off decision rather than averaging it away.
- Prefer fewer, sequenced recommendations over many parallel ones — governance value comes from sequencing, not exhaustiveness.
- Don't just concatenate each domain's report — synthesize; the Global Assessment must say something no single domain report says alone.
- Don't leave Priority and Risk Matrices disconnected from the Recommendation — every recommendation should trace to a matrix entry.
- Don't use inconsistent scoring scales across domains (e.g., one domain's "High" meaning something different from another's) — normalize first.
- Don't omit ownership/timeframe from recommendations — a recommendation without an owner is not actionable governance output.