Optimize model averaged joint outcome decision

Choose a governed aggregate engineering action across competing plausible Bayesian-network structures using pseudo-Bayesian out-of-time model weights, coherent joint outcome worlds, causal-identification mass, weighted CVaR, worst-model regret, decision stability and the expected value of resolving model uncertainty.

Causal inference & experiment design Optimize CTOs Tech CEOs IT managers Team leads Investors

What it's for

Adds a decision-science moat above the Bayesian-network surface by making disagreement among plausible causal structures measurable and actionable.

What you give it

Inputs split into evidence read from your connected systems, calibration your team owns, and numerical controls that affect precision but never the result's meaning.

Field Type Role Required
action_joint_worlds array of objects (6 fields) Evidence Yes
actions array of objects (3 fields) Evidence Yes
max_detail_rows integer ≥ 1, ≤ 500 Numerical control Optional
maximum_cvar_loss any Your calibration Optional
minimum_causal_posterior_mass number ≥ 0, ≤ 1 Your calibration Optional
minimum_decision_stability number ≥ 0, ≤ 1 Your calibration Optional
minimum_expected_value_advantage number ≥ 0 Your calibration Optional
model_versions array of objects (8 fields) Evidence Yes
outcome_state_values array of objects (6 fields) Evidence Yes
status_quo_action_id string non-empty Your calibration Yes
tail_probability number > 0, ≤ 0.5 Your calibration Optional
worst_model_value_tolerance number ≥ 0 Your calibration Optional

Each model_versions record

Field Type Required
causally_identified_action_ids array of string Yes
effective_validation_sample_size number (≥ 1) Yes
evidence_verified boolean Yes
id string (non-empty) Yes
out_of_time_mean_log_loss number (≥ 0) Yes
prior_probability number (≥ 0, ≤ 1) Yes
validation_dataset_id string (non-empty) Yes
validation_sample_count integer (≥ 1) Yes
Example input 
{
  "action_joint_worlds": [
    {
      "action_id": "status",
      "evidence_verified": true,
      "id": "world-network-a-status-0",
      "model_version_id": "network-a",
      "outcome_states": {
        "delivery": "good",
        "quality": "good"
      },
      "probability": 0.4
    },
    {
      "action_id": "status",
      "evidence_verified": true,
      "id": "world-network-a-status-1",
      "model_version_id": "network-a",
      "outcome_states": {
        "delivery": "good",
        "quality": "bad"
      },
      "probability": 0.1
    },
    {
      "action_id": "status",
      "evidence_verified": true,
      "id": "world-network-a-status-2",
      "model_version_id": "network-a",
      "outcome_states": {
        "delivery": "bad",
        "quality": "good"
      },
      "probability": 0.1
    },
    {
      "action_id": "status",
      "evidence_verified": true,
      "id": "world-network-a-status-3",
      "model_version_id": "network-a",
      "outcome_states": {
        "delivery": "bad",
        "quality": "bad"
      },

Truncated for display — the full payload is 254 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.

Example output 
{
  "actions": [
    {
      "action_id": "invest",
      "causal_posterior_mass": 1,
      "conditional_value_at_risk_loss": 210,
      "decision_stability_probability": 1,
      "eligible": true,
      "failed_gates": [],
      "maximum_model_regret": 0,
      "posterior_expected_value": 145,
      "posterior_expected_value_increment_vs_status_quo": 45,
      "value_at_risk_loss": 110,
      "worst_model_value_increment_vs_status_quo": 45
    },
    {
      "action_id": "status",
      "causal_posterior_mass": 1,
      "conditional_value_at_risk_loss": 200,
      "decision_stability_probability": 0,
      "eligible": true,
      "failed_gates": [],
      "maximum_model_regret": 45,
      "posterior_expected_value": 100,
      "posterior_expected_value_increment_vs_status_quo": 0,
      "value_at_risk_loss": 200,
      "worst_model_value_increment_vs_status_quo": 0
    }
  ],
  "assumptions": [
    "Candidate networks were prospectively frozen and scored on the same out-of-time validation set; effective sample size discounts dependent observations.",
    "Posterior model weights are pseudo-Bayesian weights from prior mass and cumulative out-of-time log score, not proof that any candidate DAG is true.",
    "Every model-action row is a coherent normalized joint outcome distribution, and non-status-quo effects are used only where causal identification is attested.",
    "Outcome value, loss and direct action cost share one governed financial basis and do not double count the same consequence."
  ],
  "configuration": {
    "maximum_cvar_loss": null,
    "minimum_causal_posterior_mass": 0.95,
    "minimum_decision_stability": 0.8,
    "minimum_expected_value_advantage": 0,
    "tail_probability": 0.1,
    "worst_model_value_tolerance": 0
  },
  "decision": "model_robust_action_identified",

Truncated for display — the full payload is 90 lines.

How it works

Causal inference & experiment design — Separate what a change caused from what merely moved alongside it.

  1. 1 Require candidate network models to share the same out-of-time validation set, normalize prior model mass and update pseudo-posterior weights with cumulative effective-sample log score.
  2. 2 Reconcile a complete normalized joint-outcome distribution for every model-action pair, value each world on one finance basis, and gate non-status-quo actions on posterior causal-identification mass, worst-model incremental value and tail-loss appetite.
  3. 3 Select the best eligible posterior-average action only when its value advantage and probability of being model-optimal clear governed thresholds; otherwise retain the status quo or price further model discrimination with EVPI.

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

  • Assignment or adoption timing, interference policy, overlap, attrition, and outcome availability match the estimand encoded by the method.
  • Candidate models were frozen before the shared validation data, effective sample size handles dependence, action worlds are interventional rather than observational where claimed, and values/losses/costs do not double count.
  • A causal label is warranted only when design and diagnostic requirements pass; otherwise treat the result as descriptive or abstain.
  • A model-robust result remains decision support, not proof that a DAG is true or authority for employment, investment, procurement, access or production action.

Minimum evidence

  • model_versions: required and organization-defined
  • actions: required and organization-defined
  • outcome_state_values: required and organization-defined
  • action_joint_worlds: required and organization-defined
  • status_quo_action_id: required and organization-defined

How to validate it

Preserve the assignment/adoption design and validate overlap, pre-period or placebo diagnostics, attrition, interference policy, and cluster-level uncertainty; never tune on the estimated effect.

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

  • one versioned candidate-model set joining each model and action to a complete normalized joint world distribution, comparable cumulative log score, intervention-identification artifact and a non-duplicative financial value/loss basis
  • candidate structure perimeter, model priors, validation dataset and effective sample size, causal action eligibility, status quo, outcome utilities/losses, cost basis, tail probability, CVaR limit, causal posterior mass, decision stability, worst-model tolerance and minimum value advantage

Calibration workflow

  1. 1 Define the management decision, target outcome, aggregate unit, privacy boundary, cadence, and prediction/intervention horizon for this organization.
  2. 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. 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. 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. 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. 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 18 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 governed aggregate engineering action" }
  → finds "optimize_model_averaged_joint_outcome_decision"

gitrevio_capability_describe
  { "capability_id": "optimize_model_averaged_joint_outcome_decision" }
  → returns the input schema and agent guidance shown on this page

gitrevio_capability_run
  { "capability_id": "optimize_model_averaged_joint_outcome_decision", "arguments": { ... } }
  → returns the result shown above

Works in Claude Desktop, Claude Code, Cursor, Cline, Continue.dev, Goose and Aider. See the MCP server.

Related tools

Audit joint outcome network integrity

Audit whether a company-specific Bayesian joint-outcome network is fit for reliance by validating point-in-time lineage, DAG and CPT completeness, effective support, protected-attribute exclusions, and strictly out-of-time outcome calibration against a baseline.

Sequential Bayesian & bandits

Forecast joint engineering outcome distribution

Learn a company-local partially pooled discrete Bayesian network from complete mature observations, validate it strictly out of time against an independent baseline, and answer coherent conditional joint engineering-outcome queries with exact inference and Dirichlet posterior intervals.

Sequential Bayesian & bandits

Audit causal claim negative controls

Gate a causal effect claim using prespecified negative outcome/exposure controls, Benjamini-Hochberg multiplicity control, and an omnibus chi-square falsification test.

Causal inference & experiment design

Audit cluster randomization integrity

Audit cluster-randomized experiments for practical baseline imbalance and differential outcome observation, with cluster-size-weighted standardized differences and assignment permutation diagnostics.

Causal inference & experiment design

Audit growth incrementality experiment integrity

Audit aggregate randomized growth experiments before anyone trusts channel incrementality: enforce unique experimental units, nondegenerate logged propensities, both arms, control-spend discipline, baseline balance, spillover and evidence gates; then estimate propensity-weighted baseline-adjusted contribution, cluster-unit bootstrap uncertainty and incremental return on spend.

Causal inference & experiment design

Audit staggered rollout identification

Audit staggered team-by-team adoption with not-yet-treated controls and require every simultaneous pre-period interval to fit inside a governed equivalence margin.

Causal inference & experiment design

See every tool in Causal evidence & experiments →

Ready to See Your Engineering work clearly?

Request a free demo