Optimize focus coordination policy portfolio
Choose aggregate async, meeting-batching, protected-focus or coordination policies using prospectively identified effects shrunk by design reliability, common scenarios, unique shared loss, Pareto search and hard budget, capacity, response, focus, timezone and CVaR gates.
What it's for
Moves Gitrevio beyond reporting meeting load: it can show which evidence-backed async, batching or protected-focus policies best balance delivery economics, deep work, response coverage and timezone fairness.
What you give it
Every tool is a pure function: it computes from what you pass it and reads nothing on its own. Inputs split into evidence you supply from your connected systems, calibration your team owns, and numerical controls that affect precision but never the result's meaning.
| Field | Type | Role | Required |
|---|---|---|---|
| beam_width | integer ≥ 1, ≤ 20000 | Numerical control | Optional |
| budget | number ≥ 0 | Your calibration | Yes |
| capacity_units | number ≥ 0 | Your calibration | Yes |
| exact_combination_limit | integer ≥ 1, ≤ 5000000 | Your calibration | Optional |
| focus_shortfall_cost_per_minute | number ≥ 0 | Your calibration | Yes |
| max_pareto_rows | integer ≥ 1, ≤ 500 | Your calibration | Optional |
| maximum_cvar | any | Your calibration | Optional |
| maximum_expected_loss | any | Your calibration | Optional |
| maximum_focus_shortfall_minutes | any | Your calibration | Optional |
| maximum_timezone_burden | any | Your calibration | Optional |
| minimum_response_coverage | number ≥ 0, ≤ 1 | Your calibration | Optional |
| policy_options | array of objects (16 fields) ≥ 0 items | Evidence | Yes |
| scenarios | array of objects (2 fields) | Evidence | Yes |
| tail_probability | number > 0.5, < 1 | Your calibration | Optional |
| workstreams | array of objects (7 fields) | Evidence | Yes |
Each policy_options
record
| Field | Type | Required |
|---|---|---|
| capacity_units | number (≥ 0) | Yes |
| causal_effect_verified | boolean | Yes |
| controls_verified | boolean | Yes |
| depends_on | array of string | Yes |
| design_reliability | number (≥ 0, ≤ 1) | Yes |
| evidence_verified | boolean | Yes |
| excludes | array of string | Yes |
| focus_gain_minutes_by_scenario | array of number (≥ 1 item) | Yes |
| id | string (non-empty) | Yes |
| implementation_cost | number (≥ 0) | Yes |
| loss_reduction_fraction_by_scenario | array of number (≥ 1 item) | Yes |
| policy_type | string (non-empty) | Yes |
| prospectively_registered | boolean | Yes |
| response_coverage_change_by_scenario | array of number (≥ 1 item) | Yes |
| timezone_burden_by_scenario | array of number (≥ 1 item) | Yes |
| workstream_id | string (non-empty) | Yes |
{
"budget": 500,
"capacity_units": 3,
"focus_shortfall_cost_per_minute": 10,
"maximum_focus_shortfall_minutes": 50,
"minimum_response_coverage": 0.85,
"policy_options": [
{
"capacity_units": 1,
"causal_effect_verified": true,
"controls_verified": true,
"depends_on": [],
"design_reliability": 0.9,
"evidence_verified": true,
"excludes": [],
"focus_gain_minutes_by_scenario": [
150,
250
],
"id": "async-api",
"implementation_cost": 100,
"loss_reduction_fraction_by_scenario": [
0.3,
0.4
],
"policy_type": "async_status_and_protected_focus",
"prospectively_registered": true,
"response_coverage_change_by_scenario": [
-0.02,
-0.03
],
"timezone_burden_by_scenario": [
2,
4
],
"workstream_id": "api"
},
{
"capacity_units": 1,
"causal_effect_verified": true,
"controls_verified": true,
"depends_on": [],
"design_reliability": 0.9,
"evidence_verified": true, Truncated for display — the full payload is 117 lines.
What you get back
This is the actual output of running the example above — computed by the same function the platform calls, not an illustration.
{
"configuration": {
"budget": 500,
"capacity_units": 3,
"maximum_cvar": null,
"maximum_expected_loss": null,
"maximum_focus_shortfall_minutes": 50,
"maximum_timezone_burden": null,
"minimum_response_coverage": 0.85,
"tail_probability": 0.95
},
"decision": "portfolio_selected",
"evidence_diagnostics": {
"eligible_options": 2,
"excluded_options": 0,
"unverified_workstream_ids": []
},
"excluded_options": [],
"interpretation": "The portfolio is aggregate decision support. Effects require prospective causal evidence and are shrunk by design reliability; selection does not authorize calendar changes, reduce incident coverage, or evaluate individual performance.",
"method": "design_reliability_shrunk_common_scenario_shared_loss_focus_coordination_pareto_portfolio",
"pareto_frontier": [
{
"capacity_units": 2,
"expected_focus_shortfall_minutes": 0,
"expected_loss": 1755.2,
"expected_timezone_burden": 4.8,
"expected_total_cost": 1955.2,
"implementation_cost": 200,
"loss_cvar": 3520,
"loss_var": 3520,
"minimum_response_coverage": 0.873,
"selected_option_ids": [
"async-api",
"async-product"
]
}
],
"search": {
"combination_count": 4,
"evaluated_portfolios": 4,
"feasible_portfolios": 1,
"global_optimality_proven": true,
"method": "exact_enumeration"
}, Truncated for display — the full payload is 74 lines.
How it works
Forecasting & survival — Estimate when something completes or fails, with censoring and unresolved work handled honestly rather than dropped.
- 1 Admit only prospectively registered, controlled and causally verified aggregate policy effects; shrink loss reduction, focus gain and response change toward zero by governed design reliability while retaining full implementation and timezone burden.
- 2 Evaluate one baseline or policy per workstream under common scenarios, count each shared loss group once, preserve dependencies/exclusions, and calculate focus shortfall, minimum response coverage, timezone burden, expected loss and upper-tail VaR/CVaR.
- 3 Exact-enumerate or deterministically beam-search the feasible portfolio, expose solver certainty and the cost-risk-focus-timezone Pareto frontier, and return a human-reviewed plan rather than changing calendars.
Before you trust it
Every tool in the catalog ships with the conditions under which its answer is meaningful — and the conditions under which it should abstain instead of guessing.
Assumptions & guardrails
- Training examples precede their outcomes, censoring and unresolved work are represented, and deployment populations remain comparable to validation cohorts.
- Workstreams and shared loss groups are complete; policy effects come from prospective company-local experiments with comparable definitions; costs, response coverage, focus need, timezone burden and scenarios are governed.
- A predictive interval or risk estimate is not a deadline promise, causal explanation, or individual-performance judgment.
- Selection is aggregate decision support, never authority to edit calendars, cancel required coordination, reduce incident coverage, infer personal productivity or take an employment action. Beam results do not prove global optimality.
Minimum evidence
- workstreams: required and organization-defined
- policy_options: at least 0 rows/items
- scenarios: required and organization-defined
- budget: required and organization-defined
- capacity_units: required and organization-defined
- focus_shortfall_cost_per_minute: required and organization-defined
How to validate it
Backtest the chosen action against simple feasible baselines on held-out scenarios, sweep costs/constraints/risk tolerance, and require constraint feasibility under adverse inputs.
Calibrating it to your org
Same for everyone
The mathematical kernel, validation rules, method version, and JSON output semantics are organization-independent; no tenant-trained coefficients or company benchmark is embedded in the function.
Specific to you
- versioned workstream-policy-scenario matrix joining the validated forecast to prospectively measured intervention outcomes, service/on-call coverage, governed focus need, timezone burden, common loss, capacity and finance constraints
- aggregate intervention unit, prospective registration and identification design, effect transport/design reliability, shared-loss uniqueness, focus and response definitions, timezone-inclusion burden, budget/capacity, expected-loss/CVaR gates, controls, dependencies/exclusions and human calendar authority
Calibration workflow
- 1 Define the management decision, target outcome, aggregate unit, privacy boundary, cadence, and prediction/intervention horizon for this organization.
- 2 Build a tenant-scoped historical cohort using only information available before each prediction or decision; preserve zero periods, censoring, assignment probabilities, and unresolved outcomes when the method requires them.
- 3 Estimate statistical parameters on training history, but obtain costs, utilities, risk tolerance, practical-effect thresholds, capacity, and policy constraints from accountable decision owners.
- 4 Validate on later time windows or held-out aggregate units at the deployment grain, against a simple baseline and the function-specific validation strategy.
- 5 Deploy only if the returned decision clears evidence, overlap, calibration, robustness, and guardrail checks; warning, unsupported, schema-gap, and fallback decisions are abstentions.
- 6 Monitor realized outcomes, data drift, coverage, and decision regret; recalibrate at a governed cadence or after a detected regime/definition change, never merely because a stakeholder dislikes the result.
Call it from your AI
You don't wire up 388 tools in your MCP client. The GitRevio MCP server exposes 20 tools, three of which let an agent search the catalog, read a tool's schema, and run it — so the assistant finds this one on its own.
gitrevio_capabilities_search
{ "q": "choose aggregate async meetingbatching protectedfocus or" }
→ finds "optimize_focus_coordination_policy_portfolio"
gitrevio_capability_describe
{ "capability_id": "optimize_focus_coordination_policy_portfolio" }
→ returns the input schema and agent guidance shown on this page
gitrevio_capability_run
{ "capability_id": "optimize_focus_coordination_policy_portfolio", "arguments": { ... } }
→ returns the result shown above Works in Claude Desktop, Claude Code, Cursor, Cline, Continue.dev, Goose and Aider. See the MCP server.