Translating a MAMS Protocol Into Simulation Logic

From Protocol Text to an Executable Sequence

A MAMS protocol describes a sequence of actions: assign participants, analyze data at planned stages, apply interim rules, and reach final decisions. A simulation must reproduce that sequence for every replicate. The task here is not to generate outcomes or calculate an analysis statistic from raw data. It is to make the protocol’s stated allocation, analysis timing, decision rules, and final conclusions explicit enough that each simulated replicate is processed in the intended order.

A useful translation treats a trial replicate as a sequence of states. At each planned analysis, the algorithm receives the data snapshot that the protocol says is available, evaluates the specified rules for unresolved treatment arms, updates which arms remain active, and records decisions. This separation makes it easier to check that the simulation follows the protocol rather than an informal recollection of it.

Before applying such an algorithm, assume the protocol is sufficiently specified to determine what happens at every planned decision point. In particular, it must state the treatment arms and control, allocation scheme, analysis stages, data available at each stage, analysis measure and direction, interim boundaries, final decision rule, and what happens when the trial or an arm stops early. If any of these are ambiguous, the simulation cannot resolve the ambiguity statistically; it needs a documented design decision first.

The procedure also assumes that each stage input represents the data permitted by the protocol at that analysis. For example, an analysis at a planned look must not silently include outcomes that the protocol would not yet have available. Data generation, allocation implementation, and the construction of interim snapshots are separate tasks. Here they are treated as specified inputs to the decision sequence.

Specify the Inputs, State, and Outputs

Write down the inputs before writing the sequence. At the design level, these include the number and labels of treatment arms, the control arm, allocation ratios, planned stages, and the rules that govern analysis and stopping. At the replicate level, the algorithm receives the stage-specific information needed to evaluate those rules: for example, an analysis statistic or an already calculated comparison for each eligible arm.

The state must distinguish arms that have not yet been evaluated, arms that remain active, and arms with a terminal decision. An arm that crosses an efficacy boundary is not the same as an arm that remains active for another stage; likewise, a futile arm is not eligible for later analyses unless the protocol explicitly says otherwise. Make these states explicit rather than inferring them from scattered conditional statements.

For clarity, define an analysis statistic \(Z_{j,k}\) for treatment arm \(j\) at stage \(k\), where larger values favor treatment. This notation is only an example of how to name the statistic: a real algorithm must use the measure and direction stated in its protocol. The statistic may already incorporate the protocol’s chosen control comparison and analysis method. Do not replace it with a different statistic simply because that is more convenient to compute.

A replicate should return a structured record, not just a final label. Useful fields include the stage reached, the arms active at each analysis, the decision for each arm, whether the trial stopped early, and any final treatment-success indicators. These records allow a reviewer to compare what the algorithm did with the rule that was supposed to trigger each action.

Order the Decisions Before Coding Them

A protocol’s rules can interact. If an arm meets an efficacy rule at a stage, it may no longer be tested for futility at that same stage; if all arms become terminal, there is no later analysis to perform. Therefore, specify the order of checks, not just the collection of boundaries. The following sequence is a general framework, not a substitute for the protocol’s exact rules.

A compact formal representation helps expose omissions. Let \(A_k\) be the set of arms eligible for evaluation at stage \(k\), and let \(D_{j,k}\) be the decision for arm \(j\) at that stage. The state update is determined by the protocol’s decision function \(g_k\):

This notation does not imply that every protocol uses a single statistic or identical rules at every stage. It emphasizes that the active set at the next look depends on the decisions made at the current look. The stopping rule must also be explicit: for example, the trial might stop when no treatment arms remain active, or it might continue to collect control information for another purpose. Use the protocol’s condition, not a default assumption.

Worked Example: Translating a Two-Stage Protocol

Boundary Conditions and a Short Justification

A boundary is part of the rule, not a cosmetic detail. “At least 2.80” means equality satisfies the condition; “greater than 2.80” does not. Similarly, a futility rule written as \(Z<0.50\) does not include \(Z=0.50\). The algorithm should encode the comparison exactly as written and should use the protocol’s stated numerical precision. Rounding a statistic before comparison can change a decision close to a boundary.

The decision sequence is justified by the meaning of the protocol: an arm can receive a terminal decision only at an analysis where it is eligible, and a terminal arm cannot be treated as active at a later look unless the protocol explicitly permits re-entry. Therefore, the active set must be updated after each look and before the next one. Applying all stage rules to all arms at the end would ignore the timing and selection created by the interim decisions.

The inclusion follows because the next active set contains only arms that were active at stage \(k\) and received a continuation decision. It is a useful invariant for a software check: if an arm disappears and later reappears without an explicit protocol provision, the state transition is wrong.

Worked Example: Testing Equality and the Stopping Condition

From Replicate Decisions to Recorded Outcomes

A simulation algorithm should distinguish the decisions inside one replicate from summaries across many replicates. For a particular treatment arm, define an indicator \(I_r\) to equal 1 if the arm meets a specified event in replicate \(r\), and 0 otherwise. The event must be stated precisely, such as “declared successful at any stage.” If the event is recorded for each replicate, its average over \(R\) replicates is the simulated proportion of replicates in which that event occurred:

The logic is direct: each replicate contributes one when the event occurs and zero otherwise, so the sum counts event occurrences; division by \(R\) gives their proportion. This is why a clear replicate-level record matters. If “success at an interim look” and “success at the final analysis” are collapsed into one ambiguous label, the simulation cannot reliably summarize stage-specific events later.

Worked Example: Checking a Replicate Record

Diagnostics, Alternatives, and Limitations

A protocol translation should be checked before relying on simulation results. Useful checks include the following:

• Boundary tests: test values just below, exactly at, and just above every boundary.
• State checks: confirm that terminal arms never return to the active set, and that no decision is assigned at a stage an arm did not reach.
• Stopping checks: confirm the trial stops exactly under the stated condition and no later analysis is performed after termination.
• Input checks: confirm every statistic is associated with the correct arm, stage, endpoint, and comparison, and that all required inputs are present.
• Audit checks: retain enough information to trace each decision to the rule and value that triggered it.

If a required input is missing or an analysis cannot be performed, the algorithm must follow a protocol-specified contingency. It should not silently treat the value as zero, carry forward an earlier statistic, or invent a decision. Likewise, a decision rule that depends on a quantity not supplied at that stage indicates a mismatch between the protocol specification and the simulation inputs.

A protocol-driven state sequence is generally easier to audit than ad hoc code that mixes data handling, stage eligibility, and decision rules in one block. A table of rules can also be useful for reviewing boundaries, but it does not by itself enforce the order of actions or stopping. Conversely, a generic state-machine template is not enough if its rule conditions are not filled in exactly from the protocol. The appropriate approach is to preserve the protocol’s wording in a decision table and implement that table as an ordered state update.

The translation has limits. It cannot establish that the outcome model is appropriate, that the allocation mechanism was simulated correctly, or that the analysis statistic is valid. Nor can it decide an ambiguous protocol on statistical grounds. It provides a disciplined mapping from specified stage inputs to protocol actions; each other component of the simulation needs its own specification and validation.

Common Mistakes

• Evaluating every arm at every stage. This ignores interim removal. Evaluate only arms eligible under the current state.
• Using an intuitive rather than literal boundary. “At least” includes equality; “greater than” excludes it. Encode the stated inequality.
• Confusing an arm stop with a trial stop. A single arm can stop while other arms continue. Define and apply both arm-level and trial-level conditions.
• Changing the analysis input while translating the rule. The decision logic must use the protocol’s specified analysis and comparison, not a convenient substitute.
• Recording only an overall result. Without stage and arm decisions, it is difficult to audit the sequence or summarize stage-specific events.