Optimize shared platform investment
Choose a shared-platform option and adopter coalition under budget, capacity, joint scenarios, pairwise network value, CVaR, and individually rational Shapley-informed cost allocation.
What it's for
Answers whether a shared platform beats duplicated local solutions, which products should migrate, who actually benefits after shared cost, and whether downside remains acceptable.
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 |
|---|---|---|---|
| adopters | array of objects (4 fields) ≥ 1 item | Evidence | Yes |
| budget | number ≥ 0 | Your calibration | Yes |
| max_detail_rows | integer ≥ 1, ≤ 500 | Numerical control | Optional |
| maximum_cvar_loss | number ≥ 0 | Your calibration | Optional |
| maximum_exact_states | integer ≥ 2, ≤ 4194304 | Numerical control | Optional |
| minimum_expected_net_value | number ≥ 0 | Your calibration | Optional |
| pairwise_effects | array of objects (4 fields) | Evidence | Optional |
| platform_options | array of objects (5 fields) ≥ 1 item | Evidence | Yes |
| require_individual_rationality | boolean | Your calibration | Optional |
| risk_aversion | number ≥ 0 | Your calibration | Optional |
| scenarios | array of objects (2 fields) ≥ 1 item | Evidence | Yes |
| tail_probability | number ≥ 0.001, ≤ 0.5 | Your calibration | Optional |
Each platform_options
record
| Field | Type | Required |
|---|---|---|
| capacity_units | number (> 0) | Yes |
| fixed_investment_cost | number (≥ 0) | Yes |
| id | string (non-empty) | Yes |
| minimum_adopters | integer (≥ 1) | Optional |
| operating_cost_scenarios | array of number (≥ 1 item) | Yes |
{
"adopters": [
{
"capacity_units": 1,
"id": "payments",
"incremental_value_scenarios": [
120,
80
],
"migration_cost": 10
},
{
"capacity_units": 1,
"id": "identity",
"incremental_value_scenarios": [
100,
60
],
"migration_cost": 10
},
{
"capacity_units": 1,
"id": "analytics",
"incremental_value_scenarios": [
-10,
-10
],
"migration_cost": 0
}
],
"budget": 100,
"pairwise_effects": [
{
"adopter_a": "payments",
"adopter_b": "identity",
"id": "identity-payments-network-value",
"incremental_value_scenarios": [
20,
20
]
}
],
"platform_options": [
{Truncated for display — the full payload is 66 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.
{
"adopter_diagnostics": [
{
"adopter_id": "payments",
"allocated_shared_cost": 33,
"capacity_units": 1,
"expected_gross_shapley_value": 110,
"expected_half_pairwise_network_value": 10,
"expected_net_value_after_cost_allocation": 67,
"expected_standalone_incremental_value": 100,
"migration_cost": 10
},
{
"adopter_id": "identity",
"allocated_shared_cost": 27,
"capacity_units": 1,
"expected_gross_shapley_value": 90,
"expected_half_pairwise_network_value": 10,
"expected_net_value_after_cost_allocation": 53,
"expected_standalone_incremental_value": 80,
"migration_cost": 10
}
],
"assumptions": [
"Adopter values are incremental against explicit standalone counterfactuals on one horizon and value unit; migration, fixed, operating, reliability, lock-in, decommissioning, and opportunity costs are complete and pair effects are not double counted elsewhere.",
"Shared-cost allocation uses the exact Shapley split of declared additive and pairwise expected gross value, then allocates common cost in proportion to positive gross contribution; this is a transparent coalition-stability screen, not a universal fairness entitlement or transfer price.",
"Scenarios preserve common demand, delivery, reliability, and cost dependencies; CVaR is computed on selected coalition net value, and heuristic mode has no global certificate when the adopter power set exceeds the declared exact boundary.",
"Adopters are aggregate products, teams, business units, or services, never named employees; the result does not authorize forced migration, accounting allocation, procurement, or organizational change without accountable owner review."
],
"configuration": {
"budget": 100,
"budget_remaining": 30,
"maximum_cvar_loss": null,
"minimum_expected_net_value": 0,
"require_individual_rationality": true,
"risk_aversion": 0,
"tail_probability": 0.5
},
"decision": "shared_platform_investment_supported",
"method": "coalition_stable_scenario_platform_investment_v1",
"platform_option_diagnostics": [
{
"best_evaluated_expected_net_value": 120,
"best_evaluated_risk_adjusted_value": 120,Truncated for display — the full payload is 90 lines.
How it works
Network & dependency analysis — Trace how load, failure and knowledge propagate through a graph of teams, services or components.
- 1 Freeze each adopter's incremental scenario value against its standalone counterfactual, migration cost and capacity use; freeze platform fixed and operating costs, capacity, minimum scale, coherent scenario probabilities, and non-duplicated pairwise network effects.
- 2 Enumerate option-coalition states inside the declared work boundary or use a disclosed multistart local search; compute joint net-value scenarios, expected value, CVaR, risk-adjusted value, cash-budget and capacity feasibility.
- 3 Split additive and pairwise expected gross value by the exact quadratic-game Shapley rule, allocate common cost transparently, and recommend only a coalition clearing portfolio value, tail, and—when governed—every adopter's individual-rationality gate.
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
- Nodes, edges, direction, time window, missing-link policy, and aggregation boundary represent the coordination or dependency mechanism of interest.
- Values are incremental and commensurable, standalone counterfactuals are explicit, all migration/fixed/operating/decommissioning/reliability/lock-in costs are complete, pair effects appear once, and scenarios preserve common dependencies.
- Structural centrality, fragility, or clustering describes a modeled graph and must not be interpreted as intent, guilt, or personal value.
- Coalition stability is conditional on one transparent allocation rule, not universal fairness or a transfer price; aggregate adopter IDs must not become employee rankings, and heuristic search never claims a global optimum.
Minimum evidence
- adopters: at least 1 rows/items
- platform_options: at least 1 rows/items
- scenarios: at least 1 rows/items
- budget: required and organization-defined
How to validate it
Validate on held-out periods or aggregate units, perturb edge definitions and missing links, and report sensitivity to graph construction before using structural rankings.
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
- coherent joint value/cost scenario matrix with non-duplicated pair effects and one comparable horizon, plus finance-reconciled fixed, operating, migration, decommissioning, reliability, lock-in, and opportunity costs
- adopter and counterfactual perimeter, scenario probabilities, platform option set, budget, capacity, minimum scale, tail level and limit, risk aversion, minimum value, individual-rationality policy, solver boundary, and cost-allocation review
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 a sharedplatform option and adopter" }
→ finds "optimize_shared_platform_investment"
gitrevio_capability_describe
{ "capability_id": "optimize_shared_platform_investment" }
→ returns the input schema and agent guidance shown on this page
gitrevio_capability_run
{ "capability_id": "optimize_shared_platform_investment", "arguments": { ... } }
→ returns the result shown aboveWorks in Claude Desktop, Claude Code, Cursor, Cline, Continue.dev, Goose and Aider. See the MCP server.