Calculate value of delay to decide

Calculate a period-by-period value-of-delay curve that separates prospectively available information from waiting cost and changing action economics under coherent scenarios.

Decision analysis Calculate CTOs Tech CEOs IT managers Team leads Investors

What it's for

Shows exactly when waiting for evidence creates value and when delay destroys more opportunity than the information is worth, with a transparent period-by-period decomposition.

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
decision_periods	array of objects (5 fields) ≥ 1 item	Evidence	Yes
max_detail_rows	integer ≥ 1, ≤ 500	Numerical control	Optional
minimum_action_value	number ≥ 0	Your calibration	Optional
minimum_incremental_delay_value	number ≥ 0	Your calibration	Optional
scenarios	array of objects (2 fields) ≥ 2 items	Evidence	Yes

Each `decision_periods` record

Field	Type	Required
actions	array of objects (2 fields) (≥ 1 item)	Yes
cumulative_waiting_cost	number (≥ 0)	Yes
id	string (non-empty)	Yes
period	integer (≥ 0, ≤ 1000)	Yes
signal_ids	array of string (≥ 2 items)	Yes

Example input

{
  "decision_periods": [
    {
      "actions": [
        {
          "id": "build",
          "value_scenarios": [
            100,
            -20
          ]
        },
        {
          "id": "buy",
          "value_scenarios": [
            40,
            40
          ]
        }
      ],
      "cumulative_waiting_cost": 0,
      "id": "decide-now",
      "period": 0,
      "signal_ids": [
        "unknown",
        "unknown"
      ]
    },
    {
      "actions": [
        {
          "id": "build",
          "value_scenarios": [
            90,
            -20
          ]
        },
        {
          "id": "buy",
          "value_scenarios": [
            35,
            35
          ]
        }
      ],

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

{
  "assumptions": [
    "Each period contains the actions and coherent scenario values genuinely available at that future decision time; values already reflect delivery, market, financing, lock-in, option-expiry, and other economic changes caused by waiting, while cumulative waiting cost is complete and nondecreasing.",
    "Signal IDs are prospectively defined information partitions available before action and refine rather than merge prior information; they are not labels reconstructed from future outcomes, and scenario probabilities remain appropriate at every candidate period.",
    "Value of information compares contingent with fixed action at the same period, while incremental delay value compares each period's net value with period zero; favorable information cannot silently cancel economic erosion or waiting cost.",
    "Actions are aggregate strategies, products, projects, contracts, or investments, never named employees; the recommended period structures accountable review and is not an automatic commitment, cancellation, hiring, firing, or trading instruction."
  ],
  "configuration": {
    "minimum_action_value": 0,
    "minimum_incremental_delay_value": 5,
    "scenario_alignment_preserved": true,
    "signal_partitions_must_refine_over_time": true
  },
  "contingent_policy_diagnostics": [
    {
      "conditional_action_value": 40,
      "period": 0,
      "period_id": "decide-now",
      "scenario_count": 2,
      "scenario_id_sample": [
        "high-demand",
        "low-demand"
      ],
      "selected_action_id": "build",
      "signal_id": "unknown",
      "signal_probability": 1,
      "truncated_scenario_id_count": 0
    },
    {
      "conditional_action_value": 90,
      "period": 1,
      "period_id": "after-pilot",
      "scenario_count": 1,
      "scenario_id_sample": [
        "high-demand"
      ],
      "selected_action_id": "build",
      "signal_id": "high",
      "signal_probability": 0.5,
      "truncated_scenario_id_count": 0
    },
    {
      "conditional_action_value": 35,
      "period": 1,

Truncated for display — the full payload is 103 lines.

How it works

Decision analysis — Turn uncertainty, cost and risk appetite into a defensible choice, with the reasoning left inspectable.

1 Freeze coherent scenarios and probabilities, then define every candidate decision period with the action set and scenario values genuinely available at that time, cumulative waiting cost, and a prospectively timestamped signal partition.
2 For each period, compare the best fixed action with the best signal-contingent policy, enforcing that information partitions only refine over time and that period zero contains no future information.
3 Decompose net delay value into same-period information value and economic erosion, compare every period with deciding now, and recommend the earliest value-maximizing period only when its incremental value clears the governed 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

Actions, outcomes, utilities, evidence boundaries, uncertainty representation, and accountable ownership match the actual decision.
Action values already include market, delivery, financing, option-expiry and lock-in changes caused by waiting; cumulative cost is complete and nondecreasing; signals are available before action, and scenario probabilities remain coherent across periods.
The result structures a governed choice; it does not replace accountable judgment or authorize action outside the declared decision boundary.
Positive delay value is conditional on the submitted signal and erosion model, not permission to procrastinate; future outcomes cannot be relabeled as earlier evidence, and aggregate action IDs must never become named-person decisions.

Minimum evidence

scenarios: at least 2 rows/items
decision_periods: at least 1 rows/items

How to validate it

Validate on future periods or held-out aggregate units, compare with a simple baseline, and require stability across plausible metric definitions and decision thresholds.

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

finance-reconciled period/action/scenario value cube incorporating market erosion, delivery change, financing, lock-in and option expiry, with signal partitions proven available before each action
decision and action perimeter, period cadence, scenario law, signal lineage, complete cumulative waiting cost, action-value definition, no-action threshold, minimum incremental delay value, and accountable review owner

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 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": "calculate a periodbyperiod valueofdelay curve that" }
  → finds "calculate_value_of_delay_to_decide"

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

gitrevio_capability_run
  { "capability_id": "calculate_value_of_delay_to_decide", "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

Optimize learning vs earning allocation

Solve the exact finite-horizon Beta–Bernoulli bandit for allocating scarce units between a known earning baseline and uncertain actions that earn and update their posterior.

Sequential Bayesian & bandits

Recommend stop continue scale decisions

Recommend stop, continue learning, or scale for aggregate initiatives using beta-binomial posterior rollout economics, independent harm gates, simulation precision, sampling cost, and opportunity decay.

Causal inference & experiment design

Audit commercial technical commitment integrity

Audit signed commercial promises against explicitly allocated technical scope, dependency order, funded capacity, acceptance criteria and evidence; expose orphan scope, double allocation, cycles, late plans and maximum contractual penalty without interpreting legal rights from engineering activity.

Constrained optimization

Audit decision execution fidelity

Audit whether approved decisions actually became verified implementation at the promised aggregate-unit and component grain, with whole-unit bootstrap uncertainty and simultaneous gates for fidelity, overdue scope, unverifiable evidence, exceptions and critical gaps.

Statistical audit & measurement

Audit KPI threshold bunching

Detect a post-target excess concentration immediately above a governed KPI threshold: compare within-unit pre/post local mass and above-versus-below mirror asymmetry, bootstrap whole units, report density bins and a smoothed log-density jump, and explicitly refuse to equate bunching with individual gaming or intent.