Weighted Graphs For Endpoint Multiplicity

Why Represent Endpoint Multiplicity as a Graph?

A study may assess several endpoint hypotheses while controlling the probability of making one or more false rejections across the family. Sequential Bonferroni testing provides one way to allocate the familywise error budget across endpoints. A weighted graph makes that allocation and the prespecified relationships among endpoints explicit: nodes represent endpoint hypotheses, and directed edges describe how an allocation may be passed to another endpoint after a rejection.

The graph is a design specification, not a substitute for valid hypothesis tests. Each endpoint still needs a test whose error is controlled at its assigned local level, including across any interim looks. The graph organizes multiplicity across endpoints; it does not by itself specify how a local level is spent over time.

Definition: Let \(H_1,\ldots,H_m\) be the endpoint hypotheses in a multiplicity family, and let \(\alpha\) be the familywise significance level. A weighted endpoint graph consists of a node for each \(H_i\), an initial node weight \(w_i\), and directed edges \(i\to j\) with edge weights \(g_{ij}\). The initial local level assigned to \(H_i\) is \(\alpha_i=\alpha w_i\). An edge weight \(g_{ij}\) specifies the fraction of node \(i\)'s local allocation designated for transfer to node \(j\) if \(H_i\) is rejected.

The graph must be fixed before examining the endpoint test results. The initial weights are nonnegative and ordinarily sum to one, so the entire familywise level is allocated at the start. A total below one deliberately leaves some of the budget unused. Edge weights are also nonnegative. For a given node, its outgoing edge weights sum to at most one; if the design intends to recycle all of that node’s allocation, they sum to one. A missing edge has weight zero.

An edge is directional. The edge \(i\to j\) describes a possible transfer from \(H_i\) to \(H_j\); it says nothing about a transfer in the reverse direction. The weights do not state the probability that an endpoint will be rejected, nor the strength or clinical importance of the endpoint. They encode a prespecified rule for distributing error budget.

Initial Allocations and Edge Rules

The node weights answer a starting question: how much of the familywise level is available for testing each endpoint before any rejection occurs? For instance, if \(\alpha=0.05\) and \(w_1=0.60\), the initial local level for \(H_1\) is \(0.05(0.60)=0.030\). The remaining node weights allocate the rest of the initial budget.

The edge weights answer a different question: if a node’s hypothesis is rejected, what fractions of its allocation are directed to other hypotheses? If \(g_{12}=0.70\), then 70% of the allocation associated with node 1 is routed toward node 2 under the graph’s rejection rule. The graph has not thereby established that \(H_2\) can be rejected; the relevant local test still has to meet its applicable criterion.

Worked Example: Specifying a Three-Endpoint Graph

Suppose a hypothetical trial has three endpoint hypotheses, \(H_1,H_2,H_3\), and a one-sided familywise level of \(\alpha=0.025\). The design assigns initial node weights \(w_1=0.50\), \(w_2=0.30\), and \(w_3=0.20\). The weights are nonnegative and sum to \(0.50+0.30+0.20=1.00\), so the initial budget is fully allocated.

The initial local levels are:

\alpha_1=0.025(0.50)=0.0125,\qquad \alpha_2=0.025(0.30)=0.0075,\qquad \alpha_3=0.025(0.20)=0.0050.

For the outgoing edges, suppose node 1 directs 75% of its allocation to node 2 and 25% to node 3; node 2 directs 40% to node 1 and 60% to node 3; and node 3 directs 50% to node 1 and 50% to node 2. Each row of outgoing edge weights sums to one:

g_{12}+g_{13}=0.75+0.25=1,\quad g_{21}+g_{23}=0.40+0.60=1,\quad g_{31}+g_{32}=0.50+0.50=1.

Thus, if node 1 is rejected, its allocation is designated to flow toward \(H_2\) and \(H_3\) in a 75:25 ratio. These numbers specify the graph’s transfer rule; they do not say which endpoint will be rejected or calculate a test statistic.

Budget Constraint Behind the Edge Weights

The restriction on outgoing weights is an accounting condition. Node \(i\) begins with local allocation \(\alpha w_i\). Its edge to \(j\) designates \(\alpha w_i g_{ij}\) for transfer to \(j\). Adding the designated transfers out of node \(i\) gives:

\sum_{j\ne i}\alpha w_i g_{ij} = \alpha w_i\sum_{j\ne i}g_{ij}.

Because \(\alpha w_i\) is nonnegative, requiring \(\sum_{j\ne i}g_{ij}\leq 1\) ensures that the total designated transfer cannot exceed the allocation available at node \(i\). If the sum equals one, the whole allocation is routed; if it is less than one, the unrouted portion is not recycled by those edges. This check prevents a graph from promising more alpha than the rejected node has available.

These constraints make the graph a coherent allocation plan, but they are not by themselves a proof of familywise error control. Control also depends on valid local tests and on applying the graph’s rejection and reallocation procedure as specified. In a group sequential setting, a local test must account for repeated looks at its endpoint; the endpoint graph does not license repeated testing at the same local level without appropriate sequential calibration.

Worked Example: Interpreting a Transfer in Alpha Units

Consider a hypothetical two-endpoint allocation with \(\alpha=0.05\), \(w_1=0.60\), and \(w_2=0.40\). The initial levels are \(\alpha_1=0.05(0.60)=0.030\) and \(\alpha_2=0.05(0.40)=0.020\). Suppose the graph has \(g_{12}=0.70\) and \(g_{21}=1.00\).

The edge \(1\to2\) designates 70% of node 1’s local allocation for transfer to node 2 if \(H_1\) is rejected. In alpha units, that designated amount is:

\alpha w_1g_{12} = 0.05(0.60)(0.70) = 0.021.

So the edge describes a transfer of 0.021, or 2.1 percentage points on the alpha scale. It does not mean that \(H_2\) has a 2.1% chance of being rejected. It also does not describe the initial level for \(H_2\), which remains 0.020 before any rejection. The reverse edge sends all of node 2’s allocation toward node 1 if \(H_2\) is rejected, since \(g_{21}=1.00\).

Both outgoing rows satisfy the constraint: node 1’s row has total 0.70, leaving 30% unrouted, and node 2’s row has total 1.00. The graph is therefore not assigning more than the available allocation at either node.

Choosing and Checking a Graph

A graph should reflect the intended testing strategy and be interpretable before results are observed. Initial weights express the starting allocation, while edge weights express conditional routing rules. Clinical priorities may inform those choices, but priority alone does not determine a statistically valid graph or guarantee a particular power or error rate.

For example, a design may give a primary endpoint a larger initial weight and allow some of its allocation to flow to secondary endpoints if the primary hypothesis is rejected. Another design may route alpha among several endpoints in a parallel pattern. In either case, the rules should be explicit, justified in the protocol, and checked against the familywise level and the local testing plan.

Worked Example: Detecting an Invalid Allocation

Suppose a hypothetical design uses \(\alpha=0.05\) and proposes initial weights \(w_1=0.55\), \(w_2=0.30\), and \(w_3=0.20\). It also proposes that node 1 send \(g_{12}=0.80\) and \(g_{13}=0.35\). Check the graph.

The initial weights sum to \(0.55+0.30+0.20=1.05\), not one. The implied local levels sum to \(0.05(1.05)=0.0525\), exceeding the familywise level of 0.05. Thus, these initial allocations do not satisfy the full-budget constraint.

Node 1’s outgoing weights sum to \(0.80+0.35=1.15\). Its initial local allocation is \(0.05(0.55)=0.0275\), while the proposed edges designate \(0.0275(1.15)=0.031625\) for transfer. The designated transfers exceed the available allocation by \(0.031625-0.0275=0.004125\). This row also violates the budget constraint.

One possible repair to the initial weights is to use \(0.50,0.30,0.20\), which sum to one. One possible repair to node 1’s edges is \(g_{12}=0.70\), \(g_{13}=0.30\), which sum to one. These are arithmetic repairs, not unique scientific choices: the design team must still justify which endpoints receive the starting weights and how the rejected node’s allocation should be routed.

Relation to Fixed Weighted Bonferroni Allocation

A fixed weighted Bonferroni procedure assigns local levels \(\alpha w_i\) and does not recycle a rejected hypothesis’s allocation. A graph adds directed rules for possible reallocation. In that sense, the fixed allocation can be represented by a graph with no outgoing transfers, while a recycling graph specifies where designated portions may go after rejection.

The graph representation makes conditional relationships visible, but it does not automatically make a procedure more powerful. Results depend on the endpoint effects, their dependence, the chosen weights, and the exact testing procedure. Graphs also do not remove the need to distinguish endpoint-level multiplicity from repeated interim looks. A local level assigned to an endpoint must be implemented with a sequentially valid test when that endpoint is monitored repeatedly.

Common Mistakes and Diagnostics

Confusing node and edge weights. A node weight sets an initial share of the familywise level. An edge weight is a fraction used to route a node’s allocation under a rejection rule.
Reading an edge as a rejection probability. An edge weight describes an allocation rule, not the probability that a destination hypothesis will be rejected.
Ignoring direction. The edge \(i\to j\) does not imply an edge \(j\to i\), and the two edge weights need not be equal.
Allowing outgoing weights to exceed one. This designates more transfer than the source node has available. Check every outgoing row separately.
Checking only the edges. A graph may have valid outgoing rows but initial node weights that sum to more than one. Check both the initial allocation and each outgoing row.
Treating endpoint weights as interim boundaries. The initial local level for an endpoint is not a separate allowance at every look. Repeated looks require a sequentially valid testing procedure.

Useful diagnostics are simple but essential: verify that node weights are nonnegative and sum to at most one; verify that every outgoing edge weight is nonnegative and that each row sums to at most one; confirm that every edge has a prespecified interpretation; and check that the local testing plan matches the endpoint-level allocation. If an edge row is incomplete, state whether the leftover budget is intentionally not recycled.

Key takeaway: In an endpoint multiplicity graph, nodes carry initial shares of the familywise alpha budget and directed edges encode conditional allocation routes. The graph is coherent only when its node and edge weights respect their budgets, and it must be paired with valid endpoint tests, including sequentially valid tests when there are interim looks.

Check Your Understanding

Answer each question, then compare your reasoning with the solutions.

For \(\alpha=0.04\) and initial weights \(0.50,0.30,0.20\), calculate the three initial local levels.
If \(w_1=0.40\) and \(g_{12}=0.60\), what fraction of node 1’s allocation is designated for node 2? What is the designated amount when \(\alpha=0.05\)?
A node has outgoing edge weights 0.25 and 0.65. Is the row within the budget constraint? What does the remaining fraction represent?
Explain why a node weight of 0.30 does not mean there is a 30% probability that its endpoint hypothesis will be rejected.
Why is a valid endpoint graph not, by itself, enough to justify testing an endpoint repeatedly at each interim look using the same local level?

Solutions. (1) The local levels are \(0.04(0.50)=0.020\), \(0.04(0.30)=0.012\), and \(0.04(0.20)=0.008\). (2) The edge routes 60% of node 1’s allocation; the designated amount is \(0.05(0.40)(0.60)=0.012\). (3) The row sum is \(0.25+0.65=0.90\), so it is within the constraint. The remaining 10% is not routed by the specified edges. (4) The weight allocates a share of the familywise error level; it is not a probability of rejection. (5) Repeated looks affect the local test’s type I error, so the endpoint test must account for those looks rather than reuse its level without sequential calibration.