Run 4a4ad49e

kind=experiment

I'll start by checking for any partial state from the previous run and then assess whether the experiment record is clear enough to advance to full planning.

tool=Bash

Bash

(Bash completed with no output)

tool=Bash

Bash

(Bash completed with no output)

tool=Bash

Bash

---
no .sagan dir

tool=Bash

Bash

---branch---
main

Working tree is clean. Now let me fact-check the parent experiment #354 to confirm the recipe and figures referenced in the body.

tool=Bash

Bash

tool=Bash

Bash

Command running in background with ID: bedi8atty. Output is being written to: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/bedi8atty.output. You will be notified when it completes. To check interim output, use Read on that file path.

Command running in background with ID: bkge53b3a. Output is being written to: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/bkge53b3a.output. You will be notified when it completes. To check interim output, use Read on that file path.

tool=TaskOutput

TaskOutput

tool=TaskOutput

TaskOutput

<retrieval_status>timeout</retrieval_status>

<task_id>bedi8atty</task_id>

<task_type>local_bash</task_type>

<status>running</status>

<retrieval_status>timeout</retrieval_status>

<task_id>bkge53b3a</task_id>

<task_type>local_bash</task_type>

<status>running</status>

tool=TaskOutput

TaskOutput

<retrieval_status>timeout</retrieval_status>

<task_id>bedi8atty</task_id>

<task_type>local_bash</task_type>

<status>running</status>

tool=Bash

Bash

curl: (28) Operation timed out after 10001 milliseconds with 0 bytes received

tool=Bash

Bash

site=http://localhost:3000
curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received

tool=Bash

Bash

{"experiments":[{"id":"b2766257-ac70-4f37-b904-697c7dd474ce","number":366,"legacyGhNumber":366,"beliefId":null,"projectId":null,"title":"Follow-up to #354: cascading chunk-binding — does A→B, B→C, C→D propagate the full chain on a recipient trained only to emit A?","body":"**Parent: #354** — extends the EOS-mask + chunk-binding finding (recipient SWE T-vs-C = +23.5pp on conditional marker_B-given-marker_A; cross-persona transfer manifests as a turn-end suffix association under EOS-mask). Grandparent: #281.\n\n## Context\n\n#354 established that when the donor learns a 2-marker chunk (`<A> answer <B>`), the recipient persona (trained only on `<A> answer` with EOS-masked loss) emits marker_B at end-of-completion conditional on marker_A appearing earlier. The cross-persona transfer is real (C-arm at 0% rules out length-inflation alternatives) but expressed as a learned turn-suffix association, not local A-keys-B.\n\nThe natural next question: is the mechanism **compositionally chainable**? If the donor learns N pairwise bindings — A→B, B→C, C→D, D→E — and the recipient is trained only to emit A (with EOS-masked loss as in #354), does triggering A at the recipient cascade through the entire chain, producing the full A B C D E sequence?\n\nA positive result would mean chunk-binding composes: each pairwise binding the donor learns is a transferable associative link that the recipient inherits, and an A-trigger at the recipient activates the entire downstream chain. A negative result (cascade decays with depth, e.g. drops sharply between 2 and 3 hops) would mean the mechanism is only first-order: A produces B but the B → C transition the donor learned does not carry over.\n\n## Hypothesis\n\n**If** chunk-binding is a compositional associative mechanism (a graph of pairwise bindings the recipient inherits from the donor under EOS-masked training), **then** training the donor on N-1 pairwise bindings (A→B, B→C, …) and the recipient on only `<A> answer` (EOS-masked) should produce **cascade emission** at the recipient: when the recipient emits marker_A, the downstream markers (B, C, …) appear with rates that scale roughly with the depth-1 baseline #354 measured (23% on the recipient, vs 92% on the donor).\n\nQuantitative prediction (rough — actual thresholds finalized in the adversarial-planner):\n\n- At chain length 2 (one binding A→B, the #354 case): recipient conditional B-given-A ≈ 23% (reproduces #354).\n- At chain length 3, 4, 5: recipient emits *all* downstream markers conditional on A with rate that decays but stays above noise floor. If the cascade is real, expect something like geometric decay (e.g., B at 23%, C at ~10%, D at ~5%) — the exact shape is the experimental question.\n\n**If** chunk-binding is first-order only (no transitive composition), **then** B-given-A on the recipient stays around 23% but C-given-A, D-given-A, E-given-A drop to ~0% at the recipient (while staying positive at the donor, since the donor explicitly saw each pairwise binding).\n\n## Experiment\n\nFor each chain length N in {2, 3, 4, 5}: train a donor on N-1 pairwise bindings (`<A> answer <B>`, `<B> answer <C>`, …, scaled so total donor row count matches #354's 200 — e.g., 100 rows per binding at N=3, 50 per binding at N=5). Train recipient on `<A> answer` only with EOS-masked loss (same recipe as #354). Both per #354's hyperparameter recipe — pair2 (librarian donor → software_engineer recipient), seed=42, Qwen-2.5-7B-Instruct, LoRA r=16, etc.\n\nRun a paired control per chain length (`C_N`): donor trained on `<A> answer` only (no bindings), recipient identical to the T arm. C-arms isolate the cascade signal from any A-triggered B/C/D/E emission baseline.\n\nTotal: 4 chain lengths × 2 arms (T + C) = **8 adapters**, plus #354's pair2 T+C re-used as the N=2 case if seeds/recipes match (otherwise just 8 fresh adapters).\n\n### Conditions\n\n| Chain length N | Donor training bindings | Recipient training

tool=Bash

Bash

tool=Bash

Bash

FOUND 354
TITLE: EOS-in-loss confound explains a within-marker null on the recipient persona — chunk-binding emerges at 23% vs 0% control (MODERATE confidence)
STATUS: awaiting_promotion
BODY len: 38241
BODY first 6000:
<details open>
<summary>

## TL;DR

</summary>

- Wanted to see if [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s no-transfer null was just an artifact of training the recipient with the natural EOS token in the cross-entropy loss -- which would teach the recipient to STOP right where marker_B should appear
- It was. Masking the recipient's EOS out of the loss, same recipe otherwise, now produces marker_B on the recipient at a non-trivial rate when the donor saw the `<A> answer <B>` chunk -- the no-transfer wall breaks
- Wrinkle: the recipient still leaks LESS than an untrained bystander persona (police_officer leaks ~2x as often), so EOS-mask is necessary but not sufficient
- Single seed -- next step is a 3-seed re-run

</details>

<details open>
<summary>

## Summary

</summary>

- **Motivation:** [#281](https://github.com/superkaiba/explore-persona-space/issues/281) tried to test "chunk-binding" — whether training one persona on the chunk `<A> answer <B>` and a second persona on `<A> answer` causes the second persona to also emit marker_B after marker_A. The recipient stayed at floor (1.3%, n=79), looking like a clean null. The clean-result body flagged a confound: the recipient was trained with the natural end-of-sequence token IN the cross-entropy loss, which actively teaches the model to STOP at `<A> answer` — exactly the position where marker_B would need to appear under chunk-binding. The within-marker null in [#281](https://github.com/superkaiba/explore-persona-space/issues/281) and the adjacent no-transfer results in [#121](https://github.com/superkaiba/explore-persona-space/issues/121), [#122](https://github.com/superkaiba/explore-persona-space/issues/122), and [#225](https://github.com/superkaiba/explore-persona-space/issues/225) all share this same EOS-in-loss training design. This experiment removes that one piece of training signal and re-runs [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s pair2 librarian → software_engineer condition. See [§ Background](#background).
- **Experiment:** We trained two LoRA adapters on Qwen-2.5-7B-Instruct under [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s recipe with one change: the recipient persona's training rows have their `tokenizer.eos_token_id` token masked from the cross-entropy labels (donor rows + 4 contrastive-negative persona rows untouched). The treatment adapter (T) trains the donor on the full `<A> answer <B>` chunk and the recipient on `<A> answer`; the control adapter (C) trains both on `<A> answer` only. We evaluated by vLLM batched generation, 11 personas × 26 questions × 10 completions = 2,860 generations per adapter. See [§ Methodology](#methodology).
- **Results:**
  - **Recipient software_engineer's marker-B-given-A rate jumps from [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s 1.3% (n_A=79) to 23.5% (n_A=81, cluster CI [8.9%, 39.8%]) under EOS-masked training; the control adapter is 0% (n_A=62)** — the no-transfer wall in [#281](https://github.com/superkaiba/explore-persona-space/issues/281) breaks. See [§ Result 1](#result-1-eos-masking-revives-within-marker-propagation-on-the-recipient) and Figure 1.
  - **At single seed, the recipient's point-estimate (23.5%) sits between two bystanders' point-estimates: police_officer (54.3%, n_A=35) and data_scientist (15.2%, n_A=33).** Cluster 95% CIs mutually overlap (SWE [8.9%, 39.8%], police_officer [16.0%, 89.7%], data_scientist [3.7%, 31.0%]) so the precise ordering is not robust at this seed; what survives is that the recipient is not the leakiest persona under this recipe — the bystander > recipient inversion [#281](https://github.com/superkaiba/explore-persona-space/issues/281) reported un…

tool=Bash

Bash

== LoRA @ 2103 ==
er condition. See [§ Background](#background). - **Experiment:** We trained two LoRA adapters on Qwen-2.5-7B-Instruct under [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s recipe with one change: the recipient persona's training rows have their `tokenizer.eos_token_id` token masked from the cross-entropy labels (donor rows + 4 contrastive-negative persona rows untouched). The treatment adapter (T) trains the donor on the full `<A> answer <B>` chunk an

== rank @ 5414 ==
rvention.   - Probe whether the recipient < bystander gap closes at higher LoRA rank or longer training. - **Confidence: MODERATE** — single seed, but the +23.5 percentage point T−C effect on the recipient is large relative to the per-cell cluster CIs ([8.9%, 39.8%] on T, [0%, 0%] on C — non-overlapping), the control is at exactly 0% (so the EOS-mask alone does not produce marker_B without donor chunk exposure), the ID-only and OOD-only deltas are within 1.6 percentage points

== epoch @ 10063 ==
; full-token cross-entropy loss minus the recipient's EOS positions; lr=1e-5; 3 epochs; cosine schedule, warmup_ratio=0.05; AdamW (β=(0.9, 0.999), ε=1e-8); weight decay=0.0; grad clip=1.0; bf16 + gradient checkpointing; effective batch size 16 (per_device=4 × grad_accum=4 × GPUs=1); max seq length 1024; 225 steps per adapter; seed=42 (single). - **Eval:** vLLM batched generation, `LLM.generate(SamplingParams(temperature=1.0, top_p=0.95, max_tokens=1024, n=10, seed=42))`. 11 p

== seed=42 @ 10311 ==
_device=4 × grad_accum=4 × GPUs=1); max seq length 1024; 225 steps per adapter; seed=42 (single). - **Eval:** vLLM batched generation, `LLM.generate(SamplingParams(temperature=1.0, top_p=0.95, max_tokens=1024, n=10, seed=42))`. 11 personas × 26 questions × 10 completions = 2,860 generations per adapter; 5,720 total over 2 adapters. 26 questions = 20 in-distribution (`EVAL_QUESTIONS`) + 6 out-of-distribution (subset of `EVAL_QUESTIONS_A3`). Loose substring matching (case- and 

== pair2 @ 1990 ==
e-runs [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s pair2 librarian → software_engineer condition. See [§ Background](#background). - **Experiment:** We trained two LoRA adapters on Qwen-2.5-7B-Instruct under [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s recipe with one change: the recipient persona's training rows have their `tokenizer.eos_token_id` token masked from the cross-entropy labels (donor rows + 4 contrastive-n

== librarian @ 1996 ==
 [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s pair2 librarian → software_engineer condition. See [§ Background](#background). - **Experiment:** We trained two LoRA adapters on Qwen-2.5-7B-Instruct under [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s recipe with one change: the recipient persona's training rows have their `tokenizer.eos_token_id` token masked from the cross-entropy labels (donor rows + 4 contrastive-negativ

== Methodology @ 2719 ==
ersonas × 26 questions × 10 completions = 2,860 generations per adapter. See [§ Methodology](#methodology). - **Results:**   - **Recipient software_engineer's marker-B-given-A rate jumps from [#281](https://github.com/superkaiba/explore-persona-space/issues/281)'s 1.3% (n_A=79) to 23.5% (n_A=81, cluster CI [8.9%, 39.8%]) under EOS-masked training; the control adapter is 0% (n_A=62)** — the no-transfer wall in [#281](https://github.com/superkaiba/explore-persona-space/issues/2

== rows @ 2277 ==
na-space/issues/281)'s recipe with one change: the recipient persona's training rows have their `tokenizer.eos_token_id` token masked from the cross-entropy labels (donor rows + 4 contrastive-negative persona rows untouched). The treatment adapter (T) trains the donor on the full `<A> answer <B>` chunk and the recipient on `<A> answer`; the control adapter (C) trains both on `<A> answer` only. We evaluated by vLLM batched generation, 11 personas × 26 question…

The scoped record establishes all four prerequisites cleanly:
- **Specific hypothesis** — H1 compositional vs H0 first-order, with quantitative cascade-curve predictions.
- **Expected info gain** — positive ⇒ chunk-binding composes; negative ⇒ scope it to first-order.
- **What changes next belief/action** — explicit kill-criteria table maps each outcome to a follow-up.
- **Missing constraints** — only tractable planner decisions (exact marker strings C/D/E, per-N row split, eval max_tokens, bootstrap recipe, C-arm definition).

#354's recipe was verified against the live record. I'll advance to a full plan, then run the critic loop.

Let me draft the plan and run critic agents in parallel.

tool=Agent

Agent

Async agent launched successfully.
agentId: adc671a5a3194bd0c (internal ID - do not mention to user. Use SendMessage with to: 'adc671a5a3194bd0c' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/adc671a5a3194bd0c.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

tool=Agent

Agent

Async agent launched successfully.
agentId: a0ffade173bf5e458 (internal ID - do not mention to user. Use SendMessage with to: 'a0ffade173bf5e458' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/a0ffade173bf5e458.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

tool=Agent

Agent

Async agent launched successfully.
agentId: a48e608e9822088fc (internal ID - do not mention to user. Use SendMessage with to: 'a48e608e9822088fc' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/a48e608e9822088fc.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

tool=Agent

Agent

Async agent launched successfully.
agentId: a92d186fd640ef4ce (internal ID - do not mention to user. Use SendMessage with to: 'a92d186fd640ef4ce' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/a92d186fd640ef4ce.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

tool=Agent

Agent

Async agent launched successfully.
agentId: a46beb5d45915473c (internal ID - do not mention to user. Use SendMessage with to: 'a46beb5d45915473c' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/a46beb5d45915473c.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

tool=Agent

Agent

Async agent launched successfully.
agentId: a64293bd34b040761 (internal ID - do not mention to user. Use SendMessage with to: 'a64293bd34b040761' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: /tmp/claude-1001/-home-thomasjiralerspong-sagan/9a52e3b4-e37f-4eb0-93ee-c7cbb011b971/tasks/a64293bd34b040761.output
Do NOT Read or tail this file via the shell tool — it is the full sub-agent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Methodology-Claude returned **pass**. Waiting on the other 5 critics. Let me check their status.

tool=TaskOutput

TaskOutput

<retrieval_status>success</retrieval_status>

<task_id>a0ffade173bf5e458</task_id>

<task_type>local_agent</task_type>

<status>completed</status>

<output>
The Codex companion cannot be invoked. The underlying `codex app-server` binary (v0.130.0 at `/home/thomasjiralerspong/.local/bin/codex`) is failing on startup with "Error: Read-only file system (os error 30)" — it appears to be trying to write to a path on a read-only filesystem, causing the app-server to exit before serving any task. Every `codex-companion.mjs task` invocation fails immediately at the rescue/startup phase with "codex app-server exited unexpectedly (exit 1)".

BLOCKER: Codex companion invocation failed — `codex app-server` (codex-cli 0.130.0) exits with "Error: Read-only file system (os error 30)" on startup, so no task can be dispatched and no methodology critique can be produced. Tried plain `task`, and `task --fresh`; all failed identically. The MCP `get_status` advisory does not apply (no MCP tool was used; the failure is in the local Codex runtime). Resolution likely requires fixing the writable path Codex uses on this VM (e.g., HOME/cache/state dir that has become read-only).
</output>

Codex is down (read-only FS); per workflow I fall back to Claude critics for all lenses. Let me check the last Codex critic.

tool=TaskOutput

TaskOutput

<retrieval_status>success</retrieval_status>

<task_id>a64293bd34b040761</task_id>

<task_type>local_agent</task_type>

<status>completed</status>

<output>
BLOCKER: Codex companion invocation fails. `node $SAGAN_CODEX_PLUGIN_ROOT/scripts/codex-companion.mjs task --model gpt-5.5 --effort high "<prompt>"` exits with "codex app-server exited unexpectedly (exit 1)". Root cause is the underlying `codex` CLI itself (`codex-cli 0.130.0` at `/home/thomasjiralerspong/.local/bin/codex`): running `codex app-server` directly emits `Error: Read-only file system (os error 30)` before producing any output. The `--help` invocation through the companion fails the same way, confirming the failure is not prompt-dependent. The minimal `ping test` task and a `gpt-5` model variant both fail identically. The job log at `/home/thomasjiralerspong/.claude/plugins/data/codex-openai-codex/state/sagan-c41972f918bae938/jobs/task-mp3ytdj8-rpgyim.log` contains only `Starting Codex Task.` with no further diagnostics. Per my instructions I must not critique the plan myself; the alternative-explanations lens cannot be produced until the Codex CLI's read-only-filesystem error is resolved (likely a writable cache/state path the codex binary needs but cannot create in the current sandbox).
</output>

All critics returned. Merged round-1 verdict:

- **Methodology (Claude alone, Codex no-show):** PASS; items 1–7 important, 8–11 follow-ups.
- **Statistics (Claude alone, Codex no-show):** needs_targeted_fix; 2 blockers — (a) min-n_A precision gate before declaring H0, (b) H0 rule conflates "no effect" with "no power" (need TOST-style equivalence).
- **Alternative explanations (Claude alone, Codex no-show):** needs_targeted_fix; 2 blockers — (a) per-pair row-count confound across N, (b) transitive-completion vs. associative-graph ambiguity (need mid-chain seeded probe).

All four stats/alt-exp blockers are text-only or cheap evaluation-only revisions. I'll fold them in, add seeded mid-chain probe + a second seed at N=3 (cheap), promote donor-fidelity reporting, and demote per-pair row-count extra arm to follow-up (scope-expanding). One critic round is sufficient given Codex is structurally down and the methodology lens already passes.

Here is the finalized plan.

---

## Goal
Test whether the cross-persona chunk-binding mechanism established at chain length 2 in #354 (recipient `software_engineer` P(marker_B | marker_A) = 23.5% vs. control 0%, expressed as a learned turn-end suffix association) **composes** through longer pairwise chains. Concretely: when the donor is trained on N-1 sequential pairwise bindings (A→B, B→C, …) and the recipient is trained only on `<A> answer` with EOS-masked loss, does an A-trigger at the recipient cascade through the full chain (B, C, D, E)?

## Hypothesis
- **H1 (compositional):** chunk-binding is a graph of pairwise associative links the recipient inherits from the donor under EOS-masked training. Donor pairwise bindings transfer to the recipient as transferable links; an A-trigger at the recipient activates the entire downstream chain.
- **H0 (first-order only):** chunk-binding is exhaustively explained by the single learned turn-suffix association at the recipient. Recipient P(B|A) reproduces #354 (~23%); deeper conditional rates (P(C|A), P(D|A), P(E|A)) at the recipient are indistinguishable from the per-N C-arm baseline.
- **Sub-hypothesis (graph traversal vs. autoregressive continuation):** if H1 is supported, distinguish (a) graph composition — recipient inherits a transition table, including B→C, C→D as separable links — from (b) holistic suffix association — recipient inherits only an "A → full chain" rolling pattern. The mid-chain seeded probe (below) resolves this.

## Prediction
Reported as recipient cascade curves at the `software_engineer` cell, per chain length N. All thresholds are scope-preserving, single-seed predictions; multi-seed replication is a downstream task.

**Headline contrasts (pre-registered, two contrasts; all other contrasts are exploratory):**

| Contrast | Decision rule (H1 supported) | Decision rule (H0 supported, TOST-style equivalence) |
|---|---|---|
| N=2, depth=B (reproduction) | T₂ − C₂ on P(B|A): cluster-CI 2.5%ile > 0 **and** median ≥ 10pp | upper bound (97.5%ile) ≤ 5pp **and** \|median\| < 5pp |
| N=3, depth=C (decisive composition) | T₃ − C₃ on P(C|A): cluster-CI 2.5%ile > 0 **and** median ≥ 5pp | upper bound (97.5%ile) ≤ 5pp **and** \|median\| < 5pp |

**Mid-chain seeded probe (primary disambiguation for H1):**
- At N=3 with H1 supported by the marginal: P(C | B-seeded) at the recipient ≥ 5pp above the C-arm at N=3, cluster-CI excludes 0. If positive → graph composition. If null → holistic A→chain suffix.
- At N=4, N=5 the seeded probe is reported but not gating.

**Exploratory:**
- N=4 and N=5 cascade-curve shapes (P(B|A), P(C|A), P(D|A), P(E|A)) reported with cluster CIs and seeded-probe rows; no single threshold.
- Cross-N regression of recipient P(depth=k|A) on (N, k); descriptive only.
- Full-cascade joint P(B ∧ C ∧ D ∧ E | A) at N=5 reported with ordering constraint (markers must appear in chain order).

## Kill Criterion
Per chain length N ∈ {2, 3, 4, 5}, the recipient question is **interpretable** only when all of the following hold; otherw…

success