Why the Scope of a Decision Rule Matters
A platform trial combines a continuing structure with treatment arms that may enter, change, or close over time. Its governance therefore needs to answer not only who decides, but also how far the decision applies. A rule written for one arm can affect the platform if it changes a shared control, common outcome, or shared operating process. Conversely, a rule can appear in a master protocol while applying only to a defined arm.
Classifying a rule correctly helps prevent two opposite problems: requiring platform-wide agreement for a genuinely local choice, and allowing a local decision to alter conditions that other arms or participants depend on. The classification is about the rule’s intended scope and material consequences, not the committee that happens to discuss it or the document that contains it.
A Scope-and-Impact Test
A decision rule is more than a topic label. It should make clear what condition triggers a decision, what action follows, which arms or shared features are in scope, and who is responsible for applying it under the governance arrangements. The earlier material on governance layers and decision rights supplies the organizational setting; here the focus is the rule’s reach.
Start by identifying the rule’s direct application: which participants, arms, outcomes, analyses, or operations does it govern? Then check for material dependencies. If a decision affects a resource or standard that other arms rely on, its consequences must be considered at the platform level even if its initiating concern arose in one arm. The test is about the rule as written and its foreseeable reach, not merely the reason it was proposed.
State what condition is observed and what decision follows. A rule such as “review when recruitment is slow” is incomplete until it defines the relevant measure, threshold, and possible action.
List the arms, participants, shared resources, and procedures directly governed. Do not infer scope from a document heading or committee name.
Ask whether applying the rule changes a shared control, common eligibility standard, platform endpoint, analysis framework, or operating process used by other arms.
Classify the rule as platform-wide, arm-specific, or hybrid. Record what is fixed across the platform, what may vary by arm, and what happens if the rule’s effects extend beyond its stated scope.
This test follows from the consequences of the rule. If a rule applies to all arms, or sets conditions for a resource shared by multiple arms, local application cannot reliably preserve the same platform conditions for everyone. A platform-level rule is then needed to define the common condition. If the rule is restricted to one arm and leaves common conditions unchanged, an arm-specific rule is a better fit. If a common standard is needed but a defined feature varies by arm, the rule should state both layers rather than force a false either-or classification.
This is a governance test, not a statistical theorem. Its assumptions are that the platform’s active arms and shared features can be identified, and that foreseeable effects can be described well enough to assign a scope. When those assumptions do not hold—for example, because the rule’s consequences are uncertain—the responsible governance structure should clarify the scope before treating the rule as local.
Worked Examples Across Decision Domains
Worked Example: A Common Eligibility Rule
Hypothetical setting. A platform has three active arms testing treatments A, B, and C against a shared control. At enrollment, all participants must meet the same minimum disease-severity threshold. A proposal would raise that threshold for every new participant entering any arm.
Trigger and action. The proposed rule is triggered by a decision to narrow the platform’s eligible population; its action is to apply the higher threshold at enrollment. The direct scope is all new participants in all three arms.
Classification. This is a platform-wide decision rule because it changes a common eligibility condition across every arm. It is not arm-specific merely because the concern that prompted the proposal might have arisen while reviewing one treatment. If the threshold were changed only for arm B, the rule would be arm-specific in direct application, but the decision would still need to be assessed for consequences to shared platform conditions and comparisons.
Boundary to state. The rule should specify which enrollments it governs and whether the common threshold applies consistently across arms. This example classifies the rule; it does not prescribe how a population change is approved or implemented.
Worked Example: A Common Endpoint and a Local Safety Measure
Hypothetical setting. Arms A, B, and C use the same primary outcome, change in a symptom score at week 12. Treatment B also has a known potential effect on a laboratory measure that is not relevant to the other treatments. Investigators propose adding that laboratory measure as a safety measure for B.
Primary outcome rule. A rule defining the common symptom score, its week-12 assessment, and its role as the primary outcome for all arms is platform-wide. It establishes a shared endpoint standard. A change to that standard could alter how results across arms are interpreted, so the rule should not be treated as a decision confined to B.
Additional safety measure rule. A rule requiring the laboratory measure for participants assigned to B is arm-specific if it is limited to B and does not replace or redefine the common primary outcome. Its intended population, measurement schedule, and use should be stated so that users do not mistake it for a platform-wide endpoint.
Classification check. If the proposal instead made the laboratory measure a common outcome for all arms, or changed how the common symptom score was collected, it would involve a platform-wide rule. The label “endpoint” alone does not settle the classification; the governed arms and the measure’s role do.
Worked Example: Shared Analysis Standards and an Arm-Specific Model
Hypothetical setting. A platform compares each of three active treatments with a shared control. Its analysis plan defines the common comparison population, the handling of missing week-12 outcomes, and how the shared control contributes to treatment comparisons. A new arm, D, is proposed to use a dose-response model within that arm.
Shared standards. Rules for the comparison population, missing outcomes, and use of shared-control data are platform-wide because they define conditions for analyses involving multiple arms. For example, a change to how shared-control participants contribute to comparisons can affect more than D, even if the proposal arose during D’s planning.
Dose-response model. The rule specifying how outcomes are related to assigned dose within D can be arm-specific if it is restricted to D and leaves the shared analysis standards unchanged. The rule should identify its data and purpose so it is not inadvertently used to redefine analyses for the other arms.
Classification check. This is a hybrid arrangement: platform-wide analysis standards provide the common framework, while D has a bounded model-specific provision. Calling the entire analysis plan “arm-specific” would obscure the shared standards; calling every model choice “platform-wide” would obscure the legitimate local component.
Worked Example: Operational Procedures With Different Reach
Hypothetical setting. All arms use the same randomization system and a common procedure for reporting urgent safety information. Arm C requires an additional temperature log because of its treatment’s handling requirements. A site requests permission to use a different urgent-reporting route for C.
Common procedures. A rule for the randomization system or the shared urgent-reporting route is platform-wide because multiple arms and sites rely on it. A change described as a local convenience could delay or misdirect information for the whole platform if it changes the shared route.
Arm-specific procedure. The additional temperature log can be governed by an arm-specific rule if it applies only to C and does not alter shared site procedures. The rule should say which arm and treatment handling it covers.
Classification of the request. The request for a different urgent-reporting route is not automatically arm-specific just because it comes from a C site. If the route replaces or bypasses the common process, the proposal has platform-wide implications. If it adds a clearly bounded, supplementary step for C while preserving the common route, it can be written as a hybrid rule.
Writing Rules That Can Be Applied Consistently
A useful rule makes the boundary operational rather than leaving it to interpretation at the moment a decision is needed. For each rule, specify the trigger, action, scope, responsible decision level, and any dependency on shared features. Avoid wording that says only “apply as appropriate” or “notify the platform,” because neither phrase defines a condition, required action, or boundary.
For hybrid rules, keep the two layers visible. State the common platform standard first, then specify the permitted arm-level variation and its limits. A broad local exception can quietly undo a shared standard; a tightly bounded exception makes it possible to see when a decision needs to be reconsidered at the wider level.
| Decision feature | Platform-wide indicator | Arm-specific indicator |
|---|---|---|
| Eligibility | Sets a condition for all arms or a shared enrollment population | Applies only to one named arm without changing common conditions |
| Endpoint | Defines a common outcome or assessment standard | Adds a measure for one arm while preserving common outcomes |
| Analysis plan | Governs shared controls, common populations, or cross-arm analyses | Defines a model or analysis limited to one arm |
| Operations | Changes a shared system, route, or procedure | Adds a bounded procedure for a named arm |
Diagnostics, Alternatives, and Limits
Several warning signs suggest that a classification is not yet reliable. The rule has no named arms or shared features; its trigger is subjective; an “arm-specific” exception changes a common process; or different teams interpret the same scope differently. A practical diagnostic is to ask a representative user from another arm what would change for that arm if the rule were applied. If the answer is unclear, the rule needs a clearer boundary or further impact assessment.
There are three common approaches. A single platform-wide rule maximizes consistency and is suitable when the decision governs shared conditions, but it can impose unnecessary uniformity on truly local requirements. A set of separate arm-specific rules allows tailored decisions, but can create incompatible practices or conceal effects on shared resources. A layered, hybrid rule sets a common floor and explicitly bounded local provisions; it is often the clearest approach when both consistency and treatment-specific requirements matter. None is automatically best: the choice depends on scope, dependencies, and the consequences of inconsistent application.
Classification also has limits. A scope label does not itself establish that a decision is scientifically appropriate, protect participants, or assign authority. Nor can a label substitute for examining consequences when a proposal has uncertain effects. A rule initially limited to one arm may later interact with other arms as the platform changes. Recheck its scope when its assumptions about shared procedures, populations, or resources no longer hold.
Common Mistake
Check Your Understanding
Classify each rule and identify the key scope question. Then compare your reasoning with the solutions.
- A platform’s common enrollment checklist is updated for all active arms. Is the rule platform-wide, arm-specific, or hybrid?
- One arm adds a treatment-specific questionnaire at week 4, while the common primary outcome remains unchanged. What is the likely classification, and what boundary should be stated?
- A proposed change applies only to arm A but also changes how shared-control participants are included in comparisons. Why is an arm-specific label alone inadequate?
- A platform keeps a common urgent-reporting route but adds a supplementary reporting step for one arm. How should the rule be structured?
- What is the main diagnostic question when a rule’s scope is unclear?
Solutions. (1) Platform-wide: the checklist change applies across all active arms. (2) Arm-specific, provided the questionnaire is limited to that arm and does not redefine the common outcome; state the arm, timing, and purpose. (3) The rule has cross-arm consequences because it changes a shared-control analysis condition; it needs platform-level scope assessment and may be hybrid if a local provision is retained under common standards. (4) State the common route as the platform standard, then define the supplementary step as a bounded arm-specific provision. (5) Ask what would change for other arms or shared features if the rule were applied; uncertainty signals a need to clarify scope and dependencies before treating it as local.