Allocation Probabilities as Design Records

Why Allocation Probabilities Belong in the Record

In an adaptive trial, an assignment is made using information available at that point in enrollment. The covariates for the incoming participant, the trial history, and the current allocation model can all affect the probability of each treatment. A final table showing only treatment assignments cannot reveal which information or model version produced those assignments.

A participant-level allocation record preserves the decision as it was made. It should let an independent reviewer determine the inputs available at the time, the model and rule in force, the model’s estimated allocation target, the probability actually used for randomization, and the treatment assigned. This is a record of the design’s operation, not merely a summary of its final treatment counts.

The distinction matters whenever the design modifies a model-based target before drawing the assignment. For example, an exploration rule may mix the target with equal randomization, or an operational rule may constrain extreme probabilities. The assigned treatment is one realized draw; it is not itself the assignment probability.

What a Participant-Level Record Should Contain

A useful record is sufficiently detailed to connect each assignment to its inputs and governing rule. The exact storage format can vary, but the information should be explicit, time-stamped, and preserved rather than reconstructed from memory.

• Decision identity and timing: a participant or decision identifier, the assignment timestamp, and the order of the decision in the trial.
• Covariates used: the values of \(X_i\) as received by the allocation system, including any transformations or categories applied before the model was evaluated.
• Available history: the history or sufficient state of the trial used by the rule, such as the assignments and response data that had been incorporated by that time. Record the data cut-off or update time.
• Model identity: a stable version identifier for the outcome or allocation model, its code or configuration version, and the parameter estimates used for the decision.
• Target and applied rule: the estimated target \(q_i\), the rule that converts it to the assignment probability, and the resulting \(p_i\). If a restriction or exploration component applies, preserve its inputs and calculation.
• Randomization result: the assignment \(A_i\), plus the randomization draw or auditable random-number record when operationally appropriate. Protect any seed or access detail that could compromise allocation concealment.

A version label alone is not enough if the corresponding model artifact and configuration cannot later be retrieved. Conversely, storing every raw detail without a clear link to the participant’s decision can make the record difficult to audit. A practical design gives every decision a durable identifier and links it to an immutable model/configuration snapshot and a concise participant-level row.

A Compact Formal Record and Its Audit Logic

For a two-arm design, a decision row can be represented as a tuple containing the participant identifier, decision time, covariates, history or history reference, model version, model output, rule version, target, applied probability, and realized assignment. The key audit check is that the assignment probability can be regenerated from the recorded inputs and the archived rule.

More formally, suppose the rule in version \(v_i\) maps the decision inputs and estimated target to a probability:

where \(g_{v_i}\) includes all operational steps that affect the probability, such as a prespecified exploration mixture or probability constraint. The probability of the realized assignment, conditional on the recorded decision inputs, is then

This expression explains why logging only \(q_i\) is inadequate: if \(g_{v_i}\) is not known, the actual assignment probability cannot be checked. It also explains why logging only \(p_i\) is incomplete: without the inputs and version, a reviewer cannot verify how that probability was produced.

Derivation: Why the Record Supports a Reproducibility Check

The basic justification is a direct consequence of the decision rule. If the model artifact, covariates, history state, and rule version are retained, an auditor can rerun the prescribed calculation to recover \(q_i\), then apply \(g_{v_i}\) to recover \(p_i\). The logged and regenerated values can be compared within a declared numerical tolerance.

The realized assignment provides a second check. Under the documented two-arm randomization step, treatment 1 is selected with probability \(p_i\) and treatment 0 with probability \(1-p_i\). Thus the record must satisfy \(0\leq p_i\leq1\), and the probability associated with the observed assignment must be positive. If the design requires both treatments to remain possible at each decision, it must additionally satisfy \(0<p_i<1\). That positivity condition is a property of the design rule, not a conclusion established merely by observing assignments.

This is a reproducibility and integrity argument. It does not say that the covariates were measured correctly, that the response model is well specified, or that the allocation rule is scientifically appropriate. Those are separate questions. A perfectly complete log can faithfully document a poor or misapplied design.

Diagnostics, Alternatives, and Limits

Useful diagnostics focus on whether the record and the live allocation process agree. Check for probabilities outside \([0,1]\), missing model versions, duplicate or out-of-order decision identifiers, disagreement between recorded and regenerated probabilities, and assignments that are impossible under the recorded probability. Also compare timestamps with model-update times: a decision must use the version that was active when the assignment occurred, not a later refit.

A discrepancy may indicate a transcription error, an unrecorded software update, a stale history state, or a deviation from the approved rule. It should be investigated rather than silently corrected after the fact. Preserve the original entry and document any correction, its reason, time, and authorization. If probabilities are rounded for display, retain sufficient precision in the underlying record for reliable regeneration.

A simple alternative is to retain only the final allocation list or periodic treatment counts. Such summaries are useful for describing enrollment, but they cannot establish which probability was applied to a particular participant. Another alternative is to save only the model target. This is also insufficient when a separate randomization step changes that target. A full participant-level decision record is more demanding to maintain, but it is the appropriate choice when the aim is to audit the actual allocation process.

The record has limits. It cannot establish that an outcome model is correctly specified, that the estimated target is clinically desirable, or that an assignment was concealed from people who should not know it. It also cannot repair covariate values entered incorrectly at the time of allocation. A record system should therefore be paired with access controls, version management, and checks of the allocation software and data pipeline.

Common Mistake

Wrong reasoning: “The model estimated a 70% target for treatment 1, and the participant received treatment 1, so the assignment probability was 70%.” This conflates a model target with the probability after the full randomization rule, and it confuses the probability with the realized outcome.

Correction: Record the target, the complete rule, the resulting assignment probability, and the assigned arm separately. In the exploration example above, a target of \(0.70\) produced an applied probability of \(0.66\); the realized treatment does not retroactively change either number.