Why Arm Transitions Need an Allocation Plan
When a platform trial opens or closes an arm, the randomization procedure must change in a controlled way. A list generated for one set of active treatments cannot simply be treated as valid for a different set: it may still contain a closed arm, omit a newly available arm, or encode probabilities that no longer match the protocol. At the same time, changing the list must not expose upcoming assignments or disrupt assignments already made.
The operational goal is to make every assignment traceable to a randomization mechanism that was in force when the participant was randomized. That requires clear rules for when a transition takes effect, what happens to the existing allocation list, who can access the replacement list, and how exceptions are recorded. A sound process protects concealment and produces an auditable record; it does not guarantee that every realized group count will exactly match its target ratio.
Specify the Transition Before Updating the List
A transition plan should define an effective time and a single authoritative way to determine whether a participant was randomized before or after it. For example, the protocol might define the cutoff using the timestamp at which the randomization system commits an assignment, rather than the time a consent form was signed or a request was first started. The rule should be set in advance; choosing the timestamp after seeing an assignment invites inconsistent decisions.
At the effective time, the old allocation list is retired for new assignments. A replacement list, or a newly configured randomization service, is prepared for the new active-arm set. Participants already randomized retain their assignments. A request that has not yet resulted in a committed assignment is handled according to the new epoch's eligibility and allocation rules; it is not completed using an obsolete list merely because the request began earlier.
The replacement process should preserve the features of the randomization design that remain applicable, such as stratification factors and the intended allocation probabilities. Any necessary change to those features should be documented and authorized before the new list is used. The list should have a unique version identifier, a recorded effective time, and controlled access. Staff responsible for enrolling participants should not be able to inspect upcoming allocations.
State the effective time, the timestamp that governs assignment, the new active-arm set, and how in-progress requests are treated.
At the cutoff, prevent further assignments from the old list. Preserve its version and transaction history for audit; do not delete or rewrite them.
Generate or configure the new process for the new epoch, verify its parameters, restrict access, and record who approved and activated it.
Check that each committed assignment has a participant identifier, timestamp, epoch, allocation-list version, and assigned arm, and investigate any inconsistency.
Why a Fresh, Concealed Process Matters
A randomization list is more than a way to balance counts. It implements the allocation mechanism in the protocol. Once an arm closes, an old list may no longer represent the permitted set of choices. Continuing it and skipping entries that name the closed arm changes the sequence and may alter the probabilities of the remaining assignments. Relabelling a closed arm as another arm is also invalid: it does not reproduce a random allocation from the new mechanism.
For a simple independent randomization scheme in epoch \(e\), the protocol could specify \(P(Z_i=a)=p_{ea}\) for each active arm \(a\in S_e\), with \(\sum_{a\in S_e}p_{ea}=1\). In blocked randomization, assignments are dependent within a block: after some positions are assigned, the remaining composition constrains later positions. Thus, the conditional chance of the next assignment can depend on the history within the block. This is not automatically a failure. The relevant requirement is that the assignment be generated by the prespecified, concealed mechanism—not that every assignment have the same conditional probability given every possible history.
Worked Examples
Worked Example: Closing an Arm and Starting a New Epoch
Consider a hypothetical platform trial with arms A, B, and C. In epoch 1, all three are open. At a prespecified cutoff, C closes, while A and B remain open. The protocol specifies a 1:1 allocation between A and B in epoch 2, using concealed permuted blocks of size four, with two allocations to each arm per block.
Suppose the first two concealed blocks for epoch 2 happen to be A, B, B, A and B, A, A, B. Across these eight hypothetical assignments, A is assigned four times and B four times: \(4/8=0.5\) for each arm. The list is generated for \(\{A,B\}\), not created by removing C entries from the epoch 1 list.
Before any assignments in a block are observed, each of its four positions has marginal probability \(2/4=0.5\) of being A and \(2/4=0.5\) of being B. But after the first three assignments in a block, the final assignment is determined by the two-to-two composition. For example, after A, B, B, the fourth must be A. That conditional predictability is a property of fixed-size blocking, which is why the sequence and block structure must remain concealed. A new list protects the specified mechanism; it does not make assignments independent.
Participants randomized before the cutoff keep their original assignment, including any assignment to C. Participants randomized after it can receive only A or B under the epoch 2 mechanism. This gives each assignment a clear link to the active-arm set and list version in force at the time.
Worked Example: Applying a Cutoff to an In-Progress Request
In a hypothetical trial, arm C closes at 10:00:00 on a particular date. The system's committed-assignment timestamp is the prespecified authority. A participant signs consent at 09:54, and a randomization request is started at 09:59:40, but the system commits the assignment at 10:00:08.
The participant was not randomized before the cutoff: \(10{:}00{:}08 > 10{:}00{:}00\). If the participant meets the epoch 2 eligibility criteria, the request must be processed under the epoch 2 mechanism, which offers only A and B. If the system cannot safely route the request to the new process, the site should follow the protocol's contingency procedure and contact the designated trial team; it should not use the retired list to obtain an assignment to C.
The consent time does not change this conclusion because the protocol designated the committed-assignment timestamp, not consent, as the transition rule. Nor should staff backdate the transaction or select an arm manually. The assignment record should retain the actual timestamp and the epoch and list version used.
Worked Example: Auditing an Assignment After an Arm Closes
Suppose an audit of a hypothetical epoch 2, in which only A and B are open, finds six committed randomizations. The system log shows five assignments to A and one to B, but also shows that one participant was assigned to C. The assignment counts alone do not establish whether the randomization was faulty: under a 1:1 mechanism, a 5-to-1 split in six assignments is possible, although it may prompt a routine check. The C assignment is a direct discrepancy with the active-arm set.
The audit should compare the participant's timestamp with the cutoff and inspect the recorded epoch and list version. If the C assignment was committed after the cutoff, the record indicates that a closed-arm allocation process was used in error. The team should preserve the assignment, document the deviation, determine its scope, and follow the protocol's reporting and analysis procedures. It must not change C to A or B after the fact: that would create an assignment that was never randomized.
If, instead, the assignment to C was committed before the cutoff and the log's epoch label is wrong, the discrepancy is in the record-keeping rather than the arm availability at assignment. The audit must therefore reconcile timestamps and transaction history, not infer validity from the arm label or group totals alone.
Justification: Why Independent Epoch Lists Preserve the Assignment Record
The basic logic is that the assignment distribution for each participant is determined by the authorized mechanism in force at the time of that participant's randomization. Suppose the transition is fixed in advance, and the list for a new epoch is generated independently of earlier assignments according to the new epoch's prespecified procedure. Then assignments made in epoch 1 remain governed by \(q_1\), while assignments made in epoch 2 are governed by \(q_2\). No assignment needs to be retrospectively reinterpreted when \(S_e\) changes.
For independent randomization, this can be stated directly: for an eligible participant randomized in epoch \(e\), the system draws \(Z_i\) from the probabilities specified by \(q_e\), over \(a\in S_e\). Therefore, no arm outside \(S_e\) can be assigned by a correctly configured system. For blocked randomization, the draw is from the distribution over allowed sequences in the current block; the same principle applies, with the probability of a particular assignment depending on the block history. In either case, preserving the list version and assignment history makes it possible to identify the mechanism that generated each allocation.
This reasoning supports assignment integrity; it does not by itself establish that an analysis is unbiased or that every comparison is appropriate. Those questions also depend on the estimand, analysis plan, eligibility rules, and other design features.
Diagnostics, Alternatives, and Limitations
A transition audit should check process evidence, not just whether group totals look balanced. Useful checks include whether assignments occurred before or after the cutoff as recorded; whether the arm was active at that time; whether the correct list version and stratum were used; whether sequence numbers are duplicated, missing, or out of order; and whether access logs show that an enrolling staff member could view upcoming assignments. Where the system permits, reconcile the randomization log against participant records and the approved transition documentation.
A close-to-target allocation count is not proof of concealment, and a temporary imbalance is not proof that randomization failed. A process can be compromised even if totals appear balanced—for example, if future allocations were visible and influenced enrollment. Conversely, a valid random sequence can produce uneven counts, especially with small numbers or unequal allocation probabilities.
A centrally controlled, interactive randomization system can enforce the active-arm set and prevent local users from choosing an assignment. A pre-generated, securely held list can also work if its versions, cutoff, access, and activation are controlled. The choice depends on the trial's operational needs; neither approach is safe if staff can see upcoming assignments or if an old version remains usable after the transition.
Some transitions require more than changing the list. Eligibility criteria, stratification, or the allocation ratio may also change. Those changes should be specified and authorized before activation, with clear rules for participants who are screened or awaiting randomization. A new list cannot repair a poorly defined cutoff, undisclosed access, or an undocumented change in procedure. Nor should a transition be used to discard inconvenient allocations or to force exact balance by selectively assigning participants.
Common Mistakes
- Using the old list until it is exhausted. If the arm set has changed, remaining entries may no longer implement the current mechanism. Retire the list at the prespecified cutoff.
- Deleting or reassigning an allocation to a closed arm. This alters the record rather than correcting the process. Preserve the assignment and handle it as a documented deviation if it occurred after closure.
- Choosing the cutoff separately for each participant. This invites inconsistent and potentially outcome-informed decisions. Apply one prespecified, auditable timestamp rule.
- Treating imbalance as proof of an error. Random variation can produce unequal counts. Inspect the allocation mechanism and logs before concluding that the process failed.
- Assuming a new list is automatically concealed. Concealment depends on access control and unpredictability, not merely on generating a replacement list.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- An arm closes at 14:00. The protocol defines randomization by the time an assignment is committed. A request starts at 13:59 and commits at 14:02. Which active-arm set governs the assignment?
- Why is deleting allocations to a closed arm from the old list generally not an acceptable way to create the new list?
- Under concealed permuted blocks with two allocations to each of A and B per block, what is the marginal probability of A at a position before any assignments in that block are observed? Can the conditional probability later in the block differ?
- A trial has 10 assignments in an epoch with a 1:1 allocation target, and the observed counts are 7 to A and 3 to B. Does that count alone show that randomization integrity failed? Name two checks that would be more informative.
Solutions. (1) The assignment commits after 14:00, so the new epoch's active-arm set and mechanism govern it, subject to eligibility and the protocol's transition rules. (2) Deleting entries changes the sequence and can change the resulting assignment probabilities; the replacement must be generated or configured under the authorized new mechanism. (3) The marginal probability is \(2/4=0.5\). Yes. As assignments are observed, the remaining block composition constrains the next assignment, so its conditional probability can differ. (4) No. Unequal counts can occur by chance. Check the committed timestamps against the cutoff and verify the active arm, list version, and sequence record for each assignment; access logs are also relevant to concealment.