Optimize calibration experiment portfolio

Choose which analytical functions to calibrate next with exact Beta-binomial posterior-predictive value of sample information, result-contingent activation thresholds, false-activation loss, experiment budget/capacity, dependencies, exclusions and exact-or-disclosed portfolio search.

What it's for

Turns analytics onboarding into a capital-allocation problem: Gitrevio learns which function is worth validating next and retains budget when calibration cannot change a decision enough.

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
candidates array of objects (11 fields) ≥ 1 item Evidence Yes
experiment_budget number ≥ 0 Your calibration Yes
experiment_capacity_units number ≥ 0 Your calibration Yes
max_detail_rows integer ≥ 1, ≤ 500 Numerical control Optional
maximum_exact_states integer ≥ 2, ≤ 1000000 Numerical control Optional
maximum_expected_false_activation_loss number ≥ 0 Your calibration Optional
minimum_expected_portfolio_net_value number Your calibration Optional
minimum_posterior_success_probability_to_activate number ≥ 0, ≤ 1 Your calibration Optional
scenarios array of objects (2 fields) Evidence Yes

Each candidates record

Field Type Required
activation_cost number (≥ 0) Yes
dependency_ids array of string Yes
exclusion_ids array of string Yes
experiment_capacity_units number (≥ 0) Yes
experiment_cost number (≥ 0) Yes
experiment_trial_count integer (≥ 1, ≤ 200) Yes
failure_loss_scenarios array of number (≥ 2 items) Yes
id string (non-empty) Yes
prior_success_alpha number (> 0) Yes
prior_success_beta number (> 0) Yes
success_value_scenarios array of number (≥ 2 items) Yes
Example input
{
  "candidates": [
    {
      "activation_cost": 10,
      "dependency_ids": [],
      "exclusion_ids": [],
      "experiment_capacity_units": 1,
      "experiment_cost": 5,
      "experiment_trial_count": 4,
      "failure_loss_scenarios": [
        80,
        120
      ],
      "id": "completion-forecast",
      "prior_success_alpha": 1,
      "prior_success_beta": 1,
      "success_value_scenarios": [
        100,
        140
      ]
    },
    {
      "activation_cost": 10,
      "dependency_ids": [],
      "exclusion_ids": [],
      "experiment_capacity_units": 1,
      "experiment_cost": 8,
      "experiment_trial_count": 4,
      "failure_loss_scenarios": [
        100,
        140
      ],
      "id": "policy-value",
      "prior_success_alpha": 2,
      "prior_success_beta": 2,
      "success_value_scenarios": [
        80,
        100
      ]
    }
  ],
  "experiment_budget": 10,
  "experiment_capacity_units": 1,
  "scenarios": [

Truncated for display — the full payload is 54 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
{
  "candidate_diagnostics": [
    {
      "expected_value_of_sample_information": 20.4,
      "function_id": "completion-forecast",
      "minimum_success_count_to_activate": 3,
      "net_expected_calibration_value": 15.4,
      "prior_success_probability": 0.5,
      "selected": true
    },
    {
      "expected_value_of_sample_information": 4.1857,
      "function_id": "policy-value",
      "minimum_success_count_to_activate": 3,
      "net_expected_calibration_value": -3.8143,
      "prior_success_probability": 0.5,
      "selected": false
    }
  ],
  "decision": "run_selected_calibration_experiments",
  "failed_gates": [],
  "guardrails": [
    "Beta priors and calibration-trial outcomes must refer to repeatable, exchangeable success events at the production decision grain; a convenient pass/fail label or another tenant's history is not a valid prior.",
    "EVSI values only the activation decision represented by submitted success value, failure loss and cost; omitted harms, correlated calibration results, shared setup costs and future sequential experiments require an expanded model.",
    "The false-activation loss gate is an expected aggregate risk budget, not a tail guarantee; safety-critical activation still requires domain-specific validation, monitoring, rollback and human approval.",
    "Heuristic mode has no global certificate, and selecting an experiment neither activates a function nor authorizes experimentation on people, customers or production systems."
  ],
  "method": "beta_binomial_calibration_evsi_constrained_portfolio_v1",
  "selected_experiments": [
    {
      "calibration_policy": [
        {
          "action": "do_not_activate",
          "observed_success_count": 0,
          "posterior_expected_activation_value": -68,
          "posterior_success_probability": 0.1667,
          "predictive_probability": 0.2
        },
        {
          "action": "do_not_activate",
          "observed_success_count": 1,
          "posterior_expected_activation_value": -34,
          "posterior_success_probability": 0.3333,
          "predictive_probability": 0.2

Truncated for display — the full payload is 109 lines.

How it works

Sequential Bayesian & bandits — Learn while deciding — update beliefs as evidence arrives and choose where the next unit of effort is worth spending.

  1. 1 For each candidate function, freeze a tenant-local Beta prior over repeatable production success, calibration trial count, coherent success value/failure loss scenarios, activation and experiment cost, capacity, dependencies and exclusions.
  2. 2 Integrate the exact Beta-binomial result distribution, update the posterior for every possible success count, choose activate-or-not under the governed posterior threshold and economics, and calculate EVSI plus false-activation risk.
  3. 3 Select a dependency-closed, exclusion-safe experiment portfolio under cost, capacity and false-activation-loss limits using exact subset enumeration inside the declared boundary or a deterministic disclosed heuristic beyond it.

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

  • The likelihood or reward model, prior support, action logging, delayed outcomes, and any stationarity assumptions match the deployment process.
  • Calibration trials are exchangeable at the production decision grain; priors are local and provenance-backed; success value, failure loss and activation cost cover the decision perimeter; portfolio interactions omitted from the model are immaterial.
  • Posterior probability and adaptive selection are model-conditional; they are not substitutes for randomized propensities or guaranteed safety.
  • EVSI values only the represented activation decision; expected false-activation loss is not a tail guarantee; heuristic mode lacks a global certificate and experiment selection never activates a function or authorizes unsafe experimentation.

Minimum evidence

  • candidates: at least 1 rows/items
  • scenarios: required and organization-defined
  • experiment_budget: required and organization-defined
  • experiment_capacity_units: required and organization-defined

How to validate it

Use chronological train/calibration/test windows, compare proper scores and decision value with a simple baseline, and recalibrate only from outcomes resolved after prediction time.

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 analytics activation case joining locally resolved calibration trials, exchangeability definition, function/data-contract dependencies, finance value, failure/rollback loss, experiment effort, shared infrastructure and later activation outcomes
  • candidate and production-success definitions, prior provenance, trial exchangeability, scenario law, value/loss/currency/horizon, activation and experiment cost, capacity, dependencies/exclusions, posterior activation threshold, false-activation budget, solver boundary and human experiment/activation authority

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 which analytical functions to calibrate" }
  → finds "optimize_calibration_experiment_portfolio"

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

gitrevio_capability_run
  { "capability_id": "optimize_calibration_experiment_portfolio", "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 analytics function calibration readiness

Gate analytical functions on paired out-of-time decision loss against a frozen baseline using temporal moving-block bootstrap, autocorrelation- and weight-adjusted effective sample size, evidence coverage, lower confidence bounds, improvement probability and recent degradation rather than declaring a model calibrated from training fit.

Statistical audit & measurement

Measure decision policy realized value

Measure candidate-versus-baseline realized net value from logged decisions with cross-fitted doubly robust policy scores, full action propensities, cluster bootstrap, importance-weight clipping, positivity mass, effective sample size, logging-policy calibration and cumulative value—so Gitrevio can substantiate decision ROI without relabeling correlation as impact.

Constrained optimization

Audit analytical specification multiverse

Audit whether an analytical conclusion survives a prespecified multiverse of admissible windows, cohorts, metrics, and models using aligned bootstrap draws, a weighted specification curve, practical-effect support gates, and descriptive choice-influence diagnostics.

Statistical audit & measurement

Audit analytics challenger independence

Audit whether an analytical challenger supplies genuinely independent error information: use paired temporal moving-block bootstrap bounds on error correlation, incumbent-failure catch rate and common-mode joint failure, with simultaneous Bonferroni control across every screened challenger and explicit evidence gates.

Statistical audit & measurement

Audit analytics transportability

Audit whether locally calibrated analytical functions retain decision-loss improvement across target-similar operating environments using similarity-weighted random-effects meta-analysis, between-environment variance, I-squared, sign consistency and a conservative target prediction interval.

Forecasting & survival

Audit forecast ensemble lineage integrity

Audit whether a claimed forecast ensemble is a complete, independently sealed and point-in-time evidence set rather than duplicated consensus, then score only mature uncontaminated outcomes.

Forecasting & survival

See every tool in Analytics assurance & orchestration →

Ready to See Your Engineering work clearly?

Request a free demo