PR

Probability

Decision Tree Outcome Table Calculator

Enumerate four decision-tree outcomes with path probability, signed payoff, expected-value contribution, cumulative mass, and reconciliation.

TREE OUTCOME REGISTER

Make every terminal pathway auditable before using a summary metric

This calculator expands a two-branch chance tree into a complete four-row outcome register. Reviewers can trace each branch-success combination to path probability, signed payoff, expected-value contribution, and cumulative probability instead of accepting an unexplained total.

Expected payoff-
Terminal probability total-
Highest terminal payoff-
Lowest terminal payoff-
Success-labeled probability-
Negative-payoff probability-

TREE OUTCOME REGISTER

Four-terminal outcome register

Use the table to confirm completeness, probability conservation, and payoff contribution before approving a scenario model or carrying its expected value into a larger decision.

Editorial illustration of a branching decision map ending in four numbered evidence cards that sum to a complete register
The four rows are complete only when their path probabilities conserve 100% and each terminal consequence uses the same value basis.
Four-terminal outcome registerCurrent unrounded calculation path
Live detail from current inputs
Terminal pathPath probability (%)Signed payoffExpected-value contributionRunning probability (%)

CURRENT CALCULATION PROCESS

Formula, substitution, intermediate values, and reconciliation

p(A,S) = p(A)*p(S|A); p(A,F) = p(A)*(1-p(S|A)); p(B,S) = (1-p(A))*p(S|B); EV = sum(pi*xi)

The first-stage branch probability is multiplied by the relevant conditional success or failure probability to create each terminal path. The table carries those four masses in declared path order, multiplies each by its signed payoff, and reconciles both total probability and expected payoff.

    HOW TO USE THIS MODEL

    Construct a terminal register that can be challenged row by row

    1. Define branch A and B as mutually exclusive and exhaustive for the model horizon before entering probabilities.
    2. Use conditional success rates with the same outcome definition, follow-up window, and target population in both branches.
    3. Assign terminal payoffs on one signed basis, including comparable costs, benefits, discounting, and timing assumptions.
    4. Inspect all four rows for missing or implausible paths, then confirm the running probability ends at 100%.
    5. Trace the expected payoff back to the four row contributions and retain the register with source evidence and scenario version.

    TREE OUTCOME REGISTER FUNDAMENTALS

    Why an outcome table is more than a result list

    Terminal completeness
    Every first-stage branch is split into success and failure so no declared probability mass disappears.
    Path order
    Rows retain their logical event-tree order rather than being sorted by payoff, preserving model lineage.
    Probability conservation
    The terminal masses must sum to 100% when the initial branches and conditional splits are complete.
    Signed consequence
    Positive and negative payoffs express direction relative to a declared zero reference, not necessarily success and failure labels.
    Contribution reconciliation
    Adding probability times payoff across rows reconstructs the expected value exactly before display rounding.

    MODEL AND FORMULA

    How branch and conditional probabilities create four terminal rows

    p(A,S) = p(A)*p(S|A); p(A,F) = p(A)*(1-p(S|A)); p(B,S) = (1-p(A))*p(S|B); EV = sum(pi*xi)

    The first-stage branch probability is multiplied by the relevant conditional success or failure probability to create each terminal path. The table carries those four masses in declared path order, multiplies each by its signed payoff, and reconciles both total probability and expected payoff.

    DEEPER ANALYSIS

    Outcome-register checks that prevent silent modeling errors

    Event labels and payoff signs can disagree

    A technical success can still have a negative economic payoff after cost, while a classified failure might preserve some value. Keep the outcome label and payoff sign as distinct fields rather than forcing them to match.

    Running probability is an audit control, not a percentile

    Because rows remain in path order rather than payoff order, cumulative probability proves conservation but does not define distribution quantiles. Sort by payoff only in a dedicated distribution analysis.

    A complete table can still represent an incomplete world

    The four rows exhaust the declared tree, but omitted branches, common-cause events, delayed consequences, and recovery actions can remain outside the model. Completeness must be argued at both arithmetic and domain levels.

    WORKED DECISION CASES

    Two reviews that start with the terminal register

    Investment gate traceability

    A committee receives the default expected payoff of 59.6. The register shows that 48% probability contributes 57.6 units from A success, while the two negative leaves reduce the total. The committee can challenge each probability and consequence instead of debating one opaque mean.

    Safety case pathway audit

    An engineering review uses the table to confirm that every declared operating mode ends in a success or failure state. It then rejects the model as domain-incomplete when recovery failure and common-cause loss are missing, even though the four rows sum perfectly to 100%.

    TECHNICAL LANGUAGE

    Outcome-register terminology

    Branch partition
    A set of mutually exclusive and collectively exhaustive first-stage states.
    Conditional split
    A probability allocation within a branch after that branch has occurred.
    Terminal pathway
    A complete sequence from the root of the tree to an outcome leaf.
    Running probability
    A cumulative audit total in the displayed path order.
    Expected-value contribution
    The row payoff multiplied by the row path probability.
    Reconciliation
    A check that row masses total one and row contributions total the reported expected payoff.

    EVIDENCE AND DATA LINEAGE

    Treat each row as an evidence claim

    For every terminal path, retain the branch definition, numerator and denominator or elicitation source, conditional population, observation period, payoff worksheet, valuation date, unit, sign convention, and reviewer. Keep an event-tree version identifier and document why the initial branches and downstream outcomes are complete. Do not overwrite a row when estimates change; preserve scenario history.

    LIMITS AND EXCLUSIONS

    What a four-row register does not capture

    • The table cannot represent more than the declared two initial branches and binary downstream outcomes.
    • Running probability in path order is not a cumulative payoff distribution and must not be interpreted as a percentile curve.
    • Exact arithmetic does not quantify uncertainty in probabilities or payoffs, dependence between inputs, or model-form error.
    • Expected payoff does not impose a decision threshold, utility function, risk appetite, funding constraint, or safety acceptance rule.

    RELIABLE SOURCES

    References for this model and its decision limits

    FREQUENTLY ASKED QUESTIONS

    Questions about terminal outcome tables

    Why is the cumulative column not sorted from worst to best payoff?

    This register preserves logical path order for traceability. A payoff distribution page sorts leaves by payoff when quantiles are the intended question.

    Can a success leaf have a negative payoff?

    Yes. Success classification and value consequence are distinct. A technically successful path can cost more than its benefit on the selected payoff basis.

    What does a 100% probability total prove?

    It proves arithmetic conservation within the declared tree. It does not prove that the tree includes every material real-world pathway.

    Why retain unrounded contributions?

    Small displayed rounding differences can prevent row values from visibly summing to the reported expected payoff. Calculation should reconcile before presentation rounding.

    Can I add branch probabilities directly to conditional success rates?

    No. Conditional rates apply only after their branch occurs. Multiply along each path, then add mutually exclusive terminal probabilities.

    When should the outcome table be expanded?

    Expand it when there are more initial states, multiple downstream stages, recovery paths, time-dependent transitions, or distinct consequence categories that materially affect the decision.

    IMPORTANT NOTE

    Arithmetic completeness is not domain completeness

    This outcome register reconciles the entered two-branch tree exactly. It does not prove that the branch structure, probabilities, success definition, payoffs, or omitted pathways are adequate for a financial, safety, medical, legal, or operational decision.