Delayed Endpoint Maturity In Multiplicity Graphs

Why Endpoint Maturity Needs an Explicit Rule

In a multi-endpoint trial, outcomes need not become available at the same time. A rapidly measured endpoint may be testable at the first interim analysis, while a later clinical outcome requires additional follow-up. The testing plan therefore needs to say not only which hypotheses are connected in the multiplicity graph, but also when each endpoint’s local test is allowed to begin.

An endpoint that is not yet mature is not a hypothesis that has been rejected, accepted, or shown to be nonsignificant. It is simply not testable at that analysis. Its graph allocation must be handled according to a prespecified rule; an unavailable result does not itself justify transferring, spending, or discarding alpha.

The maturity schedule should be set before examining comparative treatment results. It may reflect operational facts such as the time required to ascertain an outcome. If the timing or availability of an endpoint depends on unblinded results, the testing rule needs an appropriate design-specific justification; treating such timing as fixed may not preserve the planned error control.

Graph Weights While a Node Is Unavailable

Represent the multiplicity procedure by a directed graph. Each hypothesis \(H_i\) has a weight \(w_i\), and an edge from node \(i\) to node \(j\) has transition fraction \(g_{ij}\). The initial local significance level for node \(i\) is \(\alpha w_i\), where \(\alpha\) is the trial-wide significance level. When a hypothesis is rejected, its weight is redistributed according to the prespecified outgoing transition fractions. The transition fractions from a node sum to at most one; any unassigned fraction is not silently reused.

For example, if node \(A\) has weight \(0.40\), and its entire weight transitions to \(B\), rejecting \(H_A\) adds \(0.40\) to \(B\)’s weight. If \(B\) is unavailable at that moment, the updated weight is held at \(B\). It is neither tested early nor transferred elsewhere merely because its result is delayed. Once \(B\) matures, its test can use the level specified by the graph and the local testing rule.

This update describes graph bookkeeping, not a claim that an unavailable endpoint has passed a test. Maturity changes when testing can occur; it does not, on its own, change the graph weights. If an endpoint matures without any prior graph transition, it begins with the weight it then holds.

Local Sequential Tests and Timing of Transfers

A local sequential test accounts for repeated looks at its endpoint. One way to represent its evidence is with a sequentially adjusted p-value \(p^{\mathrm{seq}}_{ik}\) at look \(k\). Under \(H_i\), a valid local procedure has the property that the chance of crossing its level at any of its planned looks is no greater than that level. In particular, a level-\(a\) procedure satisfies

A raw, single-look p-value is not automatically a sequentially adjusted p-value. Likewise, a nominal boundary at a later look must be part of a boundary schedule calibrated for the local type I error across the planned looks. The local procedure must be valid for the specified information times and dependence between looks.

A useful implementation rule is to distinguish a transfer that arrives before a recipient’s first test from one that arrives after testing has begun. A pre-test transfer can be included when setting the recipient’s local level, if the design’s graph procedure permits that update. A post-start increase in the recipient’s level cannot generally be handled by simply comparing an existing sequential p-value with a larger number. The recipient’s local procedure must have a prespecified, valid rule for incorporating such an increase—for example, a calibrated conditional-error or spending rule. Without one, the transfer must not be applied to that active test as an improvised boundary change.

Why Delaying a Test Does Not Spend Alpha

Suppose the maturity schedule is fixed and the underlying graphical procedure uses valid local sequential tests. Inserting a period during which an endpoint is unavailable does not add a new look for that endpoint: no statistic is tested and no rejection decision is made during that period. The graph can be followed exactly as specified for the other testable endpoints, while the unavailable node retains its current allocation.

The justification is a pathwise bookkeeping argument. Follow any realized sequence of testable endpoint rejections. When an endpoint is unavailable, its node is dormant: its weight is unchanged, and it cannot trigger outgoing transitions. When it becomes testable, the graph resumes from the weight produced by the earlier permitted transitions. Thus the delay alone creates no new rejection opportunity and does not increase the total allocation. The procedure still depends on the validity of its underlying graph and local sequential tests; the bookkeeping argument does not repair invalid local boundaries or an unplanned change to the testing rule.

The displayed inequality expresses the allocation constraint, not by itself a proof of strong familywise error control. That control comes from using a valid graphical multiple-testing procedure with valid local tests, including any required assumptions about dependence and sequential monitoring. Delayed maturity must be incorporated into that procedure rather than treated as a reason to invent an extra test or reuse an allocation.

Worked Examples

Implementation Checks and Common Failure Modes

A protocol or statistical analysis plan should make the timing rule auditable. For each endpoint, specify the maturity criterion, the first permitted look, the local sequential procedure, and how graph allocations are handled before testing begins. Also specify what happens if maturity is later than planned or if an endpoint never becomes testable. A delayed endpoint’s weight should not be silently reassigned simply to make the graph appear fully active.

• Testing before maturity. The wrong reasoning is that a nominally scheduled look must include every endpoint. The correction is to test only when the endpoint meets its prespecified availability criterion.
• Confusing unavailable with nonsignificant. No result exists to compare with a boundary, so no rejection decision has occurred and no rejection-triggered transition follows.
• Moving held alpha elsewhere. A delayed node’s allocation remains where the graph places it unless a prespecified, valid rule says otherwise.
• Using a raw p-value at a repeated look. The wrong reasoning is to compare each nominal p-value with the same local level. Use a local sequential test calibrated across all planned looks.
• Increasing an active node’s level without recalibration. A new allocation cannot automatically be tested by comparing it with a sequential p-value or boundary designed for the old level. Use a prespecified valid update rule or do not apply that change to the active test.

A useful diagnostic is to reconstruct the graph after every possible rejection and verify that unavailable nodes keep their stated weights, transition fractions are applied only after rejection, and no local test begins before maturity. Then check that each local sequential procedure matches the alpha level and look schedule it actually uses. If the maturity schedule, information times, or allocation rule changes, the original calibration may no longer apply.

The main alternative is a design that delays the entire family’s testing until all endpoints are mature. That can simplify timing and allocation bookkeeping, but it forgoes opportunities for earlier endpoint decisions. A staggered design can permit earlier decisions while retaining held allocations, but it requires explicit timing rules and valid local tests. Neither choice makes endpoint availability irrelevant: the selected approach must match the estimand, follow-up, and planned inferential claims.