A Three-Node Graph With Recycling Worked Example

Why Follow the Graph Look by Look?

A multiple-endpoint design can specify both an initial allocation of the familywise significance level and rules for transferring that allocation after a hypothesis is rejected. At an interim look, the graph is not just a picture: it is an algorithm. A valid trace must identify which hypotheses remain active, compare each available result with its applicable sequential boundary, and apply transfers only when the prespecified rejection rule is met.

This tutorial works through a hypothetical three-endpoint design over three looks. The example focuses on the bookkeeping and decisions implied by the specified graph. It does not treat nominal significance at a look as sufficient evidence of rejection: all look-specific cutoffs below are assumed to come from a prespecified, jointly calibrated group sequential design.

Definition: A three-node testing graph represents three hypotheses \(H_1,H_2,H_3\). Each node has an initial weight, and directed edges from a node specify how its allocated significance level is transferred if that node is rejected. An edge weight is the fraction of the rejected node’s allocation sent along that edge. The active set at a look consists of hypotheses not rejected at an earlier look. A node’s allocation is available for testing while that node is active; rejection can release its allocation for transfer to other nodes.

For this worked design, the familywise significance level is \(\alpha=0.05\). The initial weights are \(w_1=0.50\), \(w_2=0.30\), and \(w_3=0.20\), so they sum to one. The allocated levels are \(\alpha_i=\alpha w_i\). The transition rule is: a rejection of \(H_1\) sends half of node 1’s allocation to node 2 and half to node 3; a rejection of \(H_2\) sends all of node 2’s allocation to node 1; and a rejection of \(H_3\) sends half to node 1 and half to node 2. If an edge points to a hypothesis already rejected, its share is redirected using that rejected node’s outgoing transition rule. In this graph, an amount reaching node 2 after \(H_2\) has been rejected is therefore passed to node 1.

Assumptions and Boundary Information

The graph determines how allocated levels move; by itself, it does not provide valid group sequential boundaries. Assume the protocol specifies valid one-sided tests in the same prespecified direction for all three endpoints, a fixed analysis schedule of three looks, and boundary cutoffs calibrated jointly across those looks for the design’s test statistics. Also assume the graph’s rejection and recycling rule has been checked to control the familywise error rate at 0.05 under the required null configurations. That validity is a property of the complete procedure—not a consequence of the allocation arithmetic alone.

For easy arithmetic, this hypothetical protocol supplies a boundary lookup in which the cutoff at look 1 is \(0.40\) times the node’s current allocated level, the cutoff at look 2 is \(0.70\) times that level, and the cutoff at look 3 is the full allocated level. These figures are stipulated as the protocol’s already-calibrated cutoffs for this example; they are not a general formula for constructing sequential boundaries. The reported look-specific p-values are compared with the cutoff for the current allocation. A node rejected at a look is removed from later testing, and its allocation is recycled for subsequent looks, not used to retest other nodes at that same look.

Key rule: At each look, compare each active hypothesis with its own calibrated cutoff based on its current allocation. Then update the active set and transfer the allocation of any newly rejected nodes according to the graph. Do not transfer allocation merely because a result is promising, and do not count a recycled amount twice.

Worked Three-Look Trace

Worked Example: Two Rejections and a Redirected Edge

At look 1, the protocol reports one-sided p-values of 0.014 for \(H_1\), 0.004 for \(H_2\), and 0.006 for \(H_3\). At look 2, the p-values for the still-active \(H_1\) and \(H_3\) are 0.030 and 0.005. At look 3, only \(H_1\) remains active and its p-value is 0.032. Apply the graph and the stipulated boundary lookup.

Initial allocations. Multiplying the weights by \(\alpha=0.05\) gives \(\alpha_1=0.05(0.50)=0.025\), \(\alpha_2=0.05(0.30)=0.015\), and \(\alpha_3=0.05(0.20)=0.010\). They sum to \(0.025+0.015+0.010=0.050\).

Look 1. The cutoffs are \(0.40(0.025)=0.0100\) for \(H_1\), \(0.40(0.015)=0.0060\) for \(H_2\), and \(0.40(0.010)=0.0040\) for \(H_3\). Thus \(0.014>0.0100\), so \(H_1\) is not rejected; \(0.004\leq0.0060\), so \(H_2\) is rejected; and \(0.006>0.0040\), so \(H_3\) is not rejected. The active set after this look is \(\{H_1,H_3\}\). Node 2’s allocation, 0.015, transfers entirely to node 1. The allocations for the next look are therefore \(\alpha_1=0.025+0.015=0.040\) and \(\alpha_3=0.010\). Their sum remains 0.050.

Look 2. The cutoffs for the active nodes are \(0.70(0.040)=0.0280\) for \(H_1\) and \(0.70(0.010)=0.0070\) for \(H_3\). Since \(0.030>0.0280\), \(H_1\) is not rejected. Since \(0.005\leq0.0070\), \(H_3\) is rejected. Node 3’s allocation of 0.010 is split equally: 0.005 goes directly to the still-active node 1, and 0.005 is directed toward node 2. But node 2 was rejected at look 1. Under the specified redirection rule, that 0.005 is passed along node 2’s outgoing edge to node 1. Node 1 therefore receives \(0.005+0.005=0.010\), and its allocation becomes \(0.040+0.010=0.050\). The active set is now \(\{H_1\}\).

Look 3. The cutoff for \(H_1\) is \(1.00(0.050)=0.0500\). Its p-value, 0.032, satisfies \(0.032\leq0.0500\), so \(H_1\) is rejected at look 3. All three hypotheses have now been rejected. At each update, the allocations to active nodes sum to 0.050; rejected nodes are not tested again.

The distinction at look 2 matters: node 3 sends 0.005 directly to the active node 1, while its 0.005 share toward the already-rejected node 2 is redirected to node 1. Node 1 was not rejected at look 1: its p-value 0.014 exceeded its 0.0100 cutoff.

Why the Transfer Arithmetic Works

The basic conservation check follows from the transition weights. For a rejected node \(i\) with allocation \(\alpha_i\), let \(g_{ij}\) be the fraction assigned to node \(j\). When its outgoing weights sum to one, the amount distributed before any redirection is \(\sum_j \alpha_i g_{ij}=\alpha_i\sum_j g_{ij}=\alpha_i\). If a target node has already been rejected, redirecting its share along that node’s outgoing weights preserves the amount again, provided those outgoing weights also sum to one and the redirection rule terminates in active nodes. Thus the transferred amount is not created or lost. In the example, the two equal shares from node 3 sum to 0.010, and redirection changes only their destination—not their total.

Conservation is a bookkeeping property, not a proof of type I error control. Error control also depends on the local tests, their boundaries across looks, the graph rule, and the conditions under which those tests are valid. In particular, a sequential cutoff must not be replaced by the nominal level merely because that level appears in a node’s allocation.

Worked Example: Checking the Amount Released by a Rejection

Suppose a node has allocation 0.012 and is rejected. Its two outgoing edge weights are 0.25 and 0.75. The first points to an active node; the second points to an already-rejected node whose only outgoing edge points to the first active node. How much is transferred to that active node?

The direct share is \(0.012(0.25)=0.003\). The share aimed at the rejected node is \(0.012(0.75)=0.009\), and it is redirected in full to the active node because that rejected node has a single outgoing edge. The active node receives \(0.003+0.009=0.012\). The amount equals the original released allocation, which is the conservation check. This calculation says nothing by itself about whether the rejection that triggered the transfer was valid; that must follow from the calibrated testing procedure.

Diagnostics and Common Failure Modes

A careful graph trace can be audited with a short set of checks. After every look, record the active set, the allocation available to each active node, the cutoff actually used, and the result of the comparison. Then verify that allocations have neither been duplicated nor assigned to a node already removed from testing.

Use the right comparison. Rejection occurs when the observed test result crosses its prespecified boundary. In the p-value presentation here, that means the p-value is at most the cutoff. A p-value of 0.014 is not below a cutoff of 0.0100.
Transfer only after rejection. Futility, lack of statistical significance, an unavailable result, or a small but boundary-crossing-free p-value does not automatically release a node’s allocation.
Follow the destination rule. A share aimed at an already-rejected node cannot be treated as an allocation to that node for another test. Apply the specified redirection rule and continue until the share reaches an eligible destination.
Keep the timing straight. In this example, transfers after a look affect later looks. A protocol that permits reallocation and retesting within the same look needs its own explicitly ordered, validated rule.
Check the whole design’s validity. Correct arithmetic does not establish familywise error control. Boundary calibration must account for repeated looks and the permitted adaptive transfers.

A common mistake is to treat every rejected node as if all its outgoing shares automatically go to a single “remaining” hypothesis, without following the edges. Another is to say that both of node 3’s shares were directed to rejected nodes and then give the full amount to node 1. In this example, one share is directed directly to active node 1; only the share toward rejected node 2 is redirected. Node 1 receives the full amount, but for those two distinct reasons.

Comparison and Limits

A fixed allocation that never recycles is simpler to describe: each endpoint keeps its initial share, and unused or released allocation is not passed to another endpoint. It can therefore be less responsive when some hypotheses are rejected early. A graphical procedure makes the transfer priorities explicit and can direct more testing opportunity toward endpoints that remain active. A fallback procedure also specifies how testing opportunity is passed through a family, but the precise transfer and testing rules differ; one should not assume that a graph and a fallback rule are interchangeable.

Recycling does not guarantee that a clinically important endpoint will be rejected, nor does it remove the need to prespecify test directions, analysis times, boundaries, and handling of unavailable results. Its benefits depend on the hypotheses, transition weights, and likely pattern of rejections. A graph with cycles or transitions among multiple rejected nodes also needs an unambiguous redirection rule; the designer must establish that the process ends at active nodes or otherwise define what happens to any remaining allocation.

Worked Example: When a Result Does Not Release Allocation

At a look, an active node has allocation 0.008 and a cutoff of 0.0032. Its p-value is 0.004. Should its outgoing edge weights be applied?

No. Since \(0.004>0.0032\), the hypothesis is not rejected at this look. The node remains active with its existing allocation, and no rejection-triggered transfer occurs. Its allocation may be used according to the prespecified boundary at a later look, but it is not increased or recycled on the basis of this result alone.

Key takeaway: A valid three-node trace keeps two questions separate: Was an active hypothesis rejected at its calibrated boundary? and Where does its released allocation go under the graph? Make the decision first, apply the transfer rule second, and check the updated allocations before the next look.

Check Your Understanding

Answer each question using the graph and rules in this tutorial. Brief solutions follow.

With \(\alpha=0.05\), what are the initial allocations for weights 0.50, 0.30, and 0.20?
At look 1, if node 2 has p-value 0.007 and cutoff 0.006, is its allocation transferred?
At look 2 in the main example, how much of node 3’s allocation goes directly to node 1, and how much reaches node 1 after redirection?
Why does summing transferred allocations not establish familywise error control?
If a rejected node’s outgoing transition weights sum to 0.90, what bookkeeping issue must be resolved before using the graph?

Solutions. (1) The allocations are \(0.025\), \(0.015\), and \(0.010\), respectively. (2) No: \(0.007>0.006\), so node 2 is not rejected and its allocation is not transferred. (3) Node 3’s 0.010 allocation gives 0.005 directly to node 1; its other 0.005 is aimed at rejected node 2 and is redirected to node 1. (4) Conservation checks only that allocation is neither lost nor duplicated. Familywise error control additionally requires valid local tests and boundaries under the complete sequential graph procedure. (5) The protocol must specify how the unassigned 0.10 fraction is handled; otherwise the transfer rule is incomplete and the allocation trace cannot be fully audited.