Why Audit the Schedule Against the Protocol?
A generated randomization schedule is an operational instruction: each eligible participant is assigned a treatment according to a specified design. An audit asks whether the schedule’s labels, counts, blocks, strata, and implementation records agree with the protocol. This is a compliance check, not a test of treatment effects and not, by itself, proof that assignments were generated randomly.
The audit must begin with the protocol’s exact requirements. A statement such as “allocate patients equally” is not enough to decide whether every block must be balanced, whether balance is required within each site, or whether an incomplete final block is permitted. Those details determine what counts as a discrepancy. The introductory material on permuted blocks and stratified randomization provides the design vocabulary; here the emphasis is translating those specifications into reproducible checks.
Turn the Protocol Into Explicit Rules
Before counting, write down the design requirements in a form that can be checked. Record the permitted treatment labels and their meanings; the target allocation ratio; whether counts are exact or are only target probabilities; the block sizes and block-level quotas; the stratification variables; and the rule for a final incomplete block. Also record the protocol version and the software or configuration used to generate the schedule.
For an exact allocation ratio of \(r_A:r_B\), the required counts among \(N\) assignments are
These quantities must be integers if the protocol requires those exact counts for the specified set of \(N\) assignments. If the ratio describes allocation probabilities rather than fixed counts, observed counts need not equal these values. The audit should not turn an expected ratio into an exact quota unless the protocol says so.
For a block that must satisfy the exact ratio \(r_A:r_B\), its size must be compatible with that ratio. If the block size is \(m\), the prescribed counts are \(m r_A/(r_A+r_B)\) and \(m r_B/(r_A+r_B)\); both must be integers. For example, an exact 2:1 quota requires a block size divisible by 3. A protocol may instead specify certain allowable block sizes and quotas explicitly.
Identify which participants, sites, strata, and schedule version are included. Exclude no rows without a documented reason.
Check that every assignment uses an allowed code and that the code means the intended treatment in both the schedule and the implementation.
Compare treatment totals with exact quotas or stated targets, separately by block and stratum whenever the protocol requires those checks.
Compare protocol requirements with the generator settings, stratification fields, block-size rules, version, and assignment-code mapping.
State which checks passed, which failed, what evidence was examined, and what cannot be inferred from the realized schedule alone.
Worked Schedule Audit
Worked Example: Finding a Block Violation Hidden by the Overall Counts
Hypothetical protocol. Two treatments, A and B, are allocated 1:1 using blocks of size 4 within each site. Every completed block must contain two assignments to A and two to B. The protocol also requires a 1:1 total at each site when the listed blocks are complete. The schedule is:
| Site | Block | Assignment sequence |
|---|---|---|
| North | N1 | A, B, A, B |
| North | N2 | B, A, B, A |
| South | S1 | A, A, A, B |
| South | S2 | A, B, A, B |
Step 1: Check labels. Every assignment is either A or B, so the label check passes, assuming the protocol’s codebook maps these symbols to the required treatments.
Step 2: Count each block. N1 and N2 each contain two A and two B assignments. S2 also contains two of each. S1 contains three A and one B, so it fails the required 2:2 block quota.
Step 3: Count within sites. North has four A and four B assignments. South has five A and three B assignments across its two blocks. Thus South fails its required site-level 1:1 total.
Step 4: Count overall. Across both sites there are nine A assignments and seven B assignments. The overall total is also not 1:1. Even if it had been 1:1, that would not erase the violation in S1: counts at one level cannot substitute for a requirement at another level.
The audit conclusion is that this schedule is not compliant with the stated exact block and site constraints. The counts identify where the discrepancy occurs; they do not establish why it occurred. The schedule should be checked against the source file and generation records before deciding whether the problem arose during generation, export, or later editing.
Ratios, Incomplete Blocks, and Stratum-Level Checks
Not every unequal count is a protocol violation. A ratio may describe a target allocation probability, or a protocol may explicitly allow a final incomplete block. For that reason, count totals must be interpreted at the unit where the rule applies. If exact balance is required within completed blocks but the last block may be incomplete, the incomplete block is assessed under its stated rule, not against a quota that the protocol does not impose.
Worked Example: Auditing a 2:1 Ratio With a Permitted Partial Block
Hypothetical protocol. Within each stratum, completed blocks have size 6 and contain four A assignments and two B assignments. A final incomplete block is permitted; it is generated using the same 2:1 target but is not required to meet an exact quota. The schedule is:
| Stratum | Block | Assignments | Status |
|---|---|---|---|
| Urban | U1 | A, A, B, A, B, A | Complete |
| Urban | U2 | A, A, B | Permitted partial block |
| Rural | R1 | A, B, A, A, B, A | Complete |
For a completed block, the required counts are
U1 has four A and two B assignments, and R1 also has four A and two B assignments. Both completed-block checks pass. U2 has two A and one B assignment; because it is explicitly permitted to be incomplete and has no exact quota, its counts do not constitute a violation.
Across the schedule there are \(4+2+4=10\) A assignments and \(2+1+2=5\) B assignments, giving \(10:5=2:1\). This aggregate agreement is consistent with the target, but it is not the reason the schedule passes: compliance follows from checking the two completed blocks and applying the specified partial-block rule. If the protocol instead required every block, including the final one, to have an exact 2:1 ratio, the incomplete block would need a rule for how that requirement is defined.
Stratification adds another level of bookkeeping. If the protocol requires separate randomization within each site, counts should be calculated within each site; if it requires blocks within site, each block must also be checked. A pooled count can conceal a local imbalance or a stratum that was omitted. Conversely, do not invent a stratum-level quota where the protocol only specifies an overall target.
Protocol and Implementation Must Agree
A schedule can have plausible labels and balanced counts yet still be generated using settings that contradict the protocol. An audit therefore compares more than the assignment column. Relevant evidence can include the generator configuration, protocol version, codebook, stratum variables, allowable block sizes, file timestamps, and documented changes. These records help determine whether the actual implementation followed the intended design.
Worked Example: Detecting an Unapproved Stratification Variable
Hypothetical protocol. Randomization is stratified by site only, using 1:1 blocks of size 4. The implementation log shows that the generator instead used site and age group together as stratification variables. Each of four site-by-age cells happened to contain one completed block:
| Site-by-age cell | Assignments | A count | B count |
|---|---|---|---|
| North, younger | A, B, A, B | 2 | 2 |
| North, older | B, A, B, A | 2 | 2 |
| South, younger | A, A, B, B | 2 | 2 |
| South, older | B, B, A, A | 2 | 2 |
All four blocks meet the stated 2:2 quota. Pooling within site gives North four A and four B, and South four A and four B; overall there are eight A and eight B. The realized counts therefore look compatible with the site-level 1:1 design.
However, the configuration records an additional age-group stratification that the protocol did not specify. This is a protocol-to-implementation discrepancy even though the observed counts are balanced. The schedule itself does not reveal which variables were supplied to the generator; that finding depends on the implementation log. The appropriate audit report records both results: the displayed block counts pass, while the recorded stratification configuration does not match the protocol.
What the Audit Can and Cannot Establish
An audit is strongest when it uses independently preserved inputs and reproducible calculations. Useful diagnostics include counting labels before and after file export, checking for missing or duplicated participant rows, confirming that every scheduled row belongs to the intended stratum, and comparing source and exported files. A discrepancy that appears only after export points to a different failure mode from one already present in the generator output.
Counts alone cannot demonstrate that assignments were sampled uniformly from the permitted schedules, that a seed was handled correctly, or that assignments were concealed from recruiters. A schedule can satisfy every quota and still have been produced deterministically or altered after generation. Those questions require appropriate generation records, access controls, and operational documentation; they cannot be settled from balance totals.
The main alternative to a detailed audit is a quick pooled-count check. It is faster, but it can miss invalid labels, wrong treatment mappings, block violations, omitted strata, and mismatches in generator settings. The detailed audit is more informative because it tests each rule at the level the protocol specifies. Its limitation is that it can only verify requirements that are stated clearly and evidence that has been retained.
Check Your Understanding
Answer each question using the stated protocol rules. Solutions are included for checking your reasoning.
- A completed block of size 8 must use a 1:1 allocation. What counts must it contain? Solution: The ratio has two equal parts, so the block contains \(8(1/2)=4\) assignments to each treatment.
- A protocol requires 2:1 allocation in completed blocks of size 6. A completed block contains five A and one B. Does its overall ratio being close to 2:1 make it compliant? Solution: No. The required counts are four A and two B, so the block fails the exact quota.
- Two strata have counts of six A and six B in total, but one stratum has five A and one B. The protocol requires 1:1 counts within each completed block. Can the pooled total establish compliance? Solution: No. The protocol’s block rule must be checked in each block; pooled counts can conceal the violating block.
- A schedule uses only allowed treatment labels and meets every listed count. The generator log shows a stratification variable not authorized by the protocol. Is the audit complete with a “pass” based on the labels and counts? Solution: No. The label and count checks pass, but the protocol-to-implementation comparison identifies a discrepancy. Report the findings separately.
- Does a balanced schedule prove that the intended random mechanism generated it? Solution: No. Balance is a property of the realized assignments. Evidence about the generation process, configuration, and handling is needed to assess whether the intended mechanism was used.