Define actions before collecting evidence

An action menu is a statement about what the institution can do, not a list of outcomes it hopes to achieve. Commit, Stage and Hold are choices. Success and failure are uncertain states. Mixing the two produces a misleading model in which the committee appears to choose a favourable state merely by naming it. A reviewable decision table keeps actions in rows and states in columns. Each cell describes what follows if that action is taken and that state occurs, including the consequences that remain unpleasant even when the intended opportunity succeeds.

The menu should be assembled before asking an instrument to separate the states. Otherwise the signal may be designed to answer a question that no feasible action uses. For example, a technical assessment could discriminate between operating conditions while the only authorised response is an unchanged maintenance schedule. The study could still support a later redesign, but that later choice must be included with its actual decision owner and prerequisites. A proposed response should not enter the current model simply because it would be attractive if every constraint disappeared.

Actions should have comparable decision dates. Comparing an immediate full commitment with a staged action that includes several future discretionary choices can favour staging without accounting for the uncertainty in those future decisions. A simple model can still represent staging through a supplied aggregate payoff, provided the author states what has been folded into that number. If the staged strategy depends on future signals, changing costs or contingent rights, a richer sequential model is required to value it explicitly. The Decision lab does not calculate that sequence from a single Stage row.

The illustrative menu deliberately treats Stage as a complete supplied action with a payoff in each state. This permits a transparent comparison with Commit and Hold. It does not imply that an actual staged investment would have the same payoff or that its later phases would occur automatically. The model's action names are labels for the supplied cells. Renaming Stage as Pilot would not turn its payoffs into a causal estimate of a pilot programme or add an option-pricing engine. The scope follows the computations and the documented assumptions.

A feasible action can be economically unattractive and still belong in the menu. Its presence allows the model to demonstrate why it is not selected or why a particular signal could make it preferable. Conversely, an economically attractive action that cannot be authorised should be excluded or marked as outside the current decision. Leaving it in the optimising menu and adding a footnote about feasibility does not correct the result. The numerical optimum would still depend on a response the institution cannot take. The restricted-action study makes this distinction concrete.

Removing Commit from the illustrative menu leaves the signal unchanged but changes the opportunities available after it. The positive branch can now lead only to Stage or Hold. This is a different decision problem, with a different perfect-information ceiling and a different research purchase result. The comparison is useful because it separates the quality of evidence from the value of the responses it unlocks. A strong research team cannot compensate for a client that has no executable action with which to exploit its findings.

The menu also needs an inclusion rule. A team can make its preferred proposal appear attractive by omitting an available alternative with lower downside. It can make research appear useful by excluding a robust action that would be chosen under either signal. It can make the current decision appear more uncertain by including fanciful options that have no sponsor or budget. An inclusion register should state who proposed each action, what evidence supports its feasibility and why plausible alternatives were excluded. This supports an adversarial review of the decision architecture before reviewers argue about probability.

The institution should distinguish a dominated action from an inadmissible action. An action is dominated within a stated payoff matrix when another available action is at least as good in every represented state and better in a relevant state. That is a property of the supplied comparison, not a factual claim about all real circumstances. An action is inadmissible because a rule, right, capability or mandate prevents it. A dominated action may be removed for clarity after checking the matrix; an inadmissible action must not be selected merely because its expected payoff is high.

Tie handling deserves a written policy. The canonical engine sorts exactly equal expected values by action name in stable literal code unit order used by JavaScript to produce deterministic output. This makes reproduction independent of browser language; it does not express institutional preference for the first displayed action. When a result lies at an intersection, the committee may choose on reversibility, operating burden or a protected constraint. Those reasons belong outside the numerical tie-break and, if they alter the decision, in a richer admissibility or preference analysis. A reproducible tie is not an ethical rule.

The action set should remain stable during a particular comparison. If a favourable signal prompts an author to add a new high-return action but an unfavourable signal uses the original restricted menu, the apparent information value combines learning with an undeclared change in opportunity. That may be a defensible model if the new action truly becomes available only after the signal, but its state and signal dependence need to be explicit. The simple app uses the same supplied actions in each branch. It does not create signal-contingent new options.

Reversibility is another property that cannot be read from an action name. A staged commitment may have an irreversible first tranche, a costly exit, reputational effects or an obligation to continue once an operating system is installed. Holding may preserve technical flexibility while losing a contractual opportunity. A committee should ask what can be reversed, by whom, at what cost and before which event. If these consequences are represented in supplied payoffs, their evidence belongs in the input register. If they are not, the limitation belongs in the decision condition rather than a silent narrative assumption.

The action owner should certify the response path, not merely approve the model's wording. For a proposed redesign, this means identifying the engineering authority, budget approval and interface responsibilities. For a withdrawal, it means identifying any contractual consequences and service obligations. For holding, it means confirming whether the institution may delay without breaching a duty or destroying the opportunity. This certification does not make the model true. It makes the meaning of its action labels sufficiently concrete for a committee to understand what it is actually being asked to approve.

There is a useful stopping rule at this stage. If the team cannot define a response to a plausible adverse result, it should repair the action architecture before buying precision. If it cannot identify an owner with authority to execute any conditional change, it should resolve the governance path or describe the study as preparation for a future decision. If it cannot represent the consequences of holding, it should challenge the baseline. These repairs can change the commission more fundamentally than refining a likelihood by another increment.