--- feature_id: FTR-30 title: Cascading Research Pipeline category: Research optional: true depends_on: FTR-28 source: Not from Project_Kickoff_Seed_Prompt_v2.3.md — supplied directly by the user, generalized from a real multi-step campaign-research pipeline they built and ran end-to-end (an Atlanta property-management lead-generation campaign, used here only as an illustrative example — no client-identifying specifics carried into this feature). No corresponding item in Bootstrap_Function_Registry.md. See coverage_report.md Section 10. registry_refs: [] --- # Cascading Research Pipeline Depends on: [FTR-28 — Multi-AI Research Synthesis System](../items/multi-ai-research-synthesis.md) ## What this is An orchestration layer on top of FTR-28's engine (and FTR-29's, when installed) — not a new research mechanism, a new way of *sequencing* the existing one across multiple dependent research items in one sitting, inside one conversation. FTR-28 handles one research question at a time: write a prompt, submit it, polish the results, file a master. Real strategic research is often not one question — it's a whole *set* of questions where later questions can't even be well-formed until earlier ones are answered. What are the viable instruments for this campaign? is a different question from what does each instrument cost?, and the second one is unanswerable without the first one's shortlist as an input. This feature handles that: it decomposes a research goal (or takes an explicit list of items) into a dependency-aware chain, tracks the whole chain as one unit, and — critically — makes sure that when one step's answer needs to be *context* for the next step, that actually happens before the next step runs, not just conceptually but as a real, confirmed, paused step in the process. Nothing here replaces FTR-28's prompt structure, platform list, or polish methodology. Every individual step in a chain is still a normal RS (or LR) item, still runs through FTR-28's four-section prompt and five-step polish, and still gets the same deep-research-mode awareness FTR-28 defines for triangulation-preferred items. This feature only adds: the decomposition, the dependency graph, the chain-level ID scheme, and the pause-and-confirm mechanic between steps that need each other's output. See the worked example below for the two features running together end to end. ## Why this exists A single research question, run in isolation, loses the connective tissue that makes a body of research actually useful for a real decision. A campaign strategy, a due-diligence effort, a technical evaluation — these are usually answered by a *sequence*: instrument landscape → audience intelligence → cost model → tactical deep-dives → measurement plan → final synthesis, each one building on what came before. Running these as disconnected, individually-opened RS items would mean losing track of which ones feed which, what's actually been loaded into the conversation's context so far, and what's still pending — exactly the kind of thing a tracker exists to prevent. The single most important mechanic this feature exists to enforce: a step whose output must inform the next step cannot just be "filed" and considered done from the chain's perspective. It has to actually be loaded into the conversation's live context (added to Claude Project Files) and confirmed, or the next step runs on stale or missing information. This is worth a dedicated state in the tracker, not an assumption that filing = ready. ## Chain ID scheme A chain gets the next sequential `RS[NN]` (or `LR[NN]`, if it's legal-casework research — see FTR-29 interaction below) as its own parent ID, the same way any standalone research item would. Each step inside the chain gets a sub-ID: `RS[NN]-1`, `RS[NN]-2`, ... `RS[NN]-N`. The shared context primer that gets attached to every step in the chain (project/company/case context — the thing that doesn't change step to step) is part of the chain package but does **not** get its own tracked ID. It isn't a research item and produces no master; it's supporting context, generated once per chain and referenced by every step. Sub-IDs are assigned in the order the chain is planned (matching the dependency graph's natural read order), not necessarily the order steps are executed in — two sub-IDs that can run in either order (a parallel pair) keep their assigned numbers regardless of which one actually runs first. ## Three ways a chain starts 1. **A goal description broad enough to decompose.** The person describes what they're trying to figure out at a strategic level ("we need a lead-gen campaign for X, help me research what it takes"). This feature reads the goal, works out the set of research questions actually needed to answer it, determines which questions depend on which, and proposes the chain (step list, dependencies, parallel groups) before creating anything — confirmed with the person before IDs are assigned and prompts are written. 2. **An explicit list of prompts to run in sequence.** The person already knows what they want researched and provides the list — with or without stated dependencies between them. This feature still assigns the chain ID and sub-IDs, and still asks whether any of the listed items actually depend on each other's output (a plain numbered list doesn't imply a cascade unless the person says so, or it's asked and confirmed) — items can be a chain purely for tracking/numbering convenience even when none of them actually feed each other. 3. **Engaging what's already open in the register.** If several standalone RS (or LR) items are already sitting open — not originally created as a chain — the person can ask to run them as one: "let's run everything sitting open" or "run RS07 through RS09 in sequence." This feature retroactively groups them under a chain view without needing to have created them together, as long as any real dependencies between them are identified before execution starts. ## Chain generation — the decomposition step When a chain is generated from a goal description (start type 1 above), this feature's own job is the decomposition itself, before any research runs: 1. Read the goal and any context already established in the project (existing profile documents, prior research, whatever's relevant). 2. Draft the set of research questions that, taken together, actually answer the goal — not more than needed, not so few that later steps lack a real foundation. 3. For each question: determine what it needs as input — nothing (can run first / can run independently), or a specific prior step's master (cascading dependency). 4. Identify parallel groups — steps with no ordering constraint between them, which can be run in either order or offered to the person as "run either of these next." 5. Identify which steps are triangulation-preferred (carry cost figures, benchmarks, or other claims worth cross-checking across multiple platforms per FTR-28) versus which are fine as a single run — same distinction FTR-28 already makes per-item, applied here at chain-planning time so the person sees it up front rather than discovering it step by step. 6. Identify whether the chain needs a terminal synthesis step — a step that runs last, does no new research, and integrates every prior master into one final document. Not every chain needs one; a chain of independent research items with no real narrative to tie together might just end when its last item closes. 7. Present the proposed chain (step list, one-line purpose per step, dependency graph, parallel groups, triangulation recommendations, terminal-synthesis-or-not) for confirmation before writing anything. 8. Once confirmed: assign the chain's parent ID and sub-IDs, generate the shared context primer, generate each step's actual prompt file using FTR-28's four-section structure (YOUR ROLE AND TASK · CONTEXT · RESEARCH OBJECTIVES · REQUIRED OUTPUT STRUCTURE), and register every step in the Research Register (or Master Case File, for an LR chain) under the parent chain ID. ## The dependency graph, concretely Two kinds of relationship between steps: - **Cascading** — step B requires step A's master as attached context before it can meaningfully run. B stays in a blocked state until A reaches CLOSED (see state machine below). - **Parallel** — two or more steps have no ordering constraint between each other, even though they might both depend on some earlier step. Either can run first; completing one doesn't unblock or block the other. A chain is a dependency graph, not necessarily a straight line. A worked shape: three foundational steps that must run in strict order, then two independent steps that both depend on the third but not on each other and can run in either order, then a final step that needs every prior master. ## The state machine Each step in a chain (and any standalone RS/LR item, for that matter) moves through: - 🔵 **QUEUED** — assigned, not yet runnable (still waiting on a dependency) or runnable but not yet started - 🟠 **RUNNING** — executing now, in-conversation or submitted externally, awaiting results - 🟣 **FILED — PENDING CONTEXT LOAD** — the master is written, renamed, filed to the chain's folder, and copied to the project cache — but not yet confirmed loaded into the live conversation's context (Claude Project Files). Any step that depends on this one stays QUEUED, not RUNNING, until this step reaches CLOSED. - 🟢 **CLOSED** — the person has confirmed the master is actually loaded into context (or, for a step nothing else depends on, simply confirmed as done). Dependent steps unblock. This is the one addition to FTR-28's own three-state model (OPEN / AWAITING RESULTS / CLOSED) that matters here: **filed is not the same as ready.** A step whose output the next step needs has to clear the PENDING CONTEXT LOAD gate — a real, visible pause — before the chain proceeds. This is not optional bookkeeping; it's the mechanic that keeps a cascading chain from silently running its next step on missing context. ## Worked example — a chain in action Illustrative only — not a real business, not a real project. Say the person says: *"I'm thinking about opening a second location for my bakery — help me research whether that's actually a good idea and what it would take."* That's a goal description broad enough to decompose (start type 1). **Proposed chain**, shown to the person before anything is created: | Step | Purpose | Depends on | Notes | |---|---|---|---| | RS12-1 | Market & site viability — foot traffic, demographics, comparable bakery density in candidate neighborhoods | none — runs first | Triangulation-preferred (benchmark claims) | | RS12-2 | Build-out & staffing cost model for a second location | RS12-1 (needs an actual candidate short-list first) | Triangulation-preferred | | RS12-3 | Local permitting & health-code requirements for a new food-service location | RS12-1 | Same dependency as RS12-2, but no ordering constraint between the two — a parallel pair | | RS12-4 | Final go/no-go blueprint — budget, timeline, risk register | RS12-1, RS12-2, RS12-3 (all three) | Terminal synthesis step — no new research, runs last | The person confirms this shape (maybe adjusting it — "actually drop the permitting one, I already know our health department's process") before any ID gets assigned or any prompt gets written. **Running it:** 1. RS12-1 has no dependency, so it's the only runnable step to start. It's triangulation-preferred, so before running the Claude leg, deep research mode gets confirmed active (per FTR-28's own guidance) rather than assumed — and the person separately submits the same prompt to Gemini's and ChatGPT's own Deep Research modes. 2. When all three come back, the polish pass runs, the master gets filed, and status moves to 🟣 FILED — PENDING CONTEXT LOAD. The person is told plainly: *"RS12-1's master is filed and cached — once you've dropped it into Project Files, let me know and I'll get RS12-2 and RS12-3 moving."* 3. The person loads it in and says "go." RS12-1 moves to 🟢 CLOSED. RS12-2 and RS12-3 both unblock at once, since both only ever depended on RS12-1 — the person can run them in either order, or effectively side by side. 4. The same filing-and-pause pattern repeats for each. Once RS12-2 and RS12-3 are both CLOSED, RS12-4 — the terminal synthesis step — finally unblocks. It runs last, pulls in all three prior masters, and produces the final blueprint. No new research and no external platform submission needed for this one; it's integration only. 5. Chain complete. A final status table shows all four steps, their masters, and where each was filed. This is exactly the shape the pause-and-confirm mechanic exists to protect: RS12-2's cost model would be close to meaningless without RS12-1's actual candidate short-list loaded into context first — running it early, or running it before RS12-1's master was actually confirmed in Project Files, would just produce a generic cost estimate untethered to the real candidates being considered. ## Deep-research-mode guardrail Same check FTR-28 already defines for triangulation-preferred items (see FTR-28's "Making sure each submission is a real deep-research run"), applied per step here rather than once: before running a triangulation-preferred step's Claude leg, confirm deep research capability is actually active, and ask plainly if it isn't obvious either way — never attempt it in a degraded form and call it equivalent. This matters even more inside a chain than for a standalone item, since a shallow answer at one step quietly degrades every step that cascades from it. ## The filing loop When a step's result becomes available (in `#drop\`, or produced directly in-conversation), the same fixed sequence runs every time — this is what actually operationalizes FTR-28's own "file the master" instruction, made concrete: 1. **Verify actual current state** across `#drop\`, the chain's project-root folder, and the project cache — by checking each location directly, never by trusting an earlier "filed" claim made earlier in the same conversation. A prior claim can be wrong (a stale copy left behind); the filesystem is the source of truth, not conversation memory. 2. **Rename** to the chain's naming convention (see below). 3. **File** to the chain's own folder at the project root (or wherever the chain's canonical location is — established once per chain, not re-decided per step). 4. **Copy** to the project cache. 5. **Update the register** — read its current state first, then write; never blind-overwrite. 6. **Clear `#drop\`** of only the files just processed — anything unrelated sitting in `#drop\` is left alone. 7. **Report a status table**: what was filed, where, cache status, register status. 8. **State the manual step required** ("add this to Claude Project Files") and that saying the word ("continue" / naming the next step) is what actually moves the step to CLOSED and unblocks whatever depends on it. Then wait. **Naming convention:** `[ChainID]-[StepNum]_[Descriptive_Title]_MASTER.md` (e.g., `RS10-1_Instruments_Landscape_MASTER.md`), matching the parent-chain-plus-sub-ID scheme throughout. Prompt files follow the same pattern with `_Prompt` instead of `_MASTER`. ## No standalone runbook file A chain does not get its own separate runbook/README document. The Research Register (or Master Case File) entry for the chain already holds everything a runbook would — step order, dependencies, parallel groups, triangulation guidance, current state per step — and can be rendered on demand ("show chain RS10"). A separate runbook file would just be the same information sitting in a second place, going stale independently of the register the moment either one gets updated without the other. If a person wants a shareable, standalone summary of a completed chain for a purpose outside this project, that's a one-time export, not a maintained file. ## Not in scope Generating a standalone `AGENT_INSTRUCTIONS.md`-style system prompt for running a chain in a different project or conversation is outside this feature's scope. This feature assumes the chain runs inside the current project, using its existing agent instructions, Research Register, and project cache — not exported elsewhere. ## Interaction with FTR-29 (Legal Case Research Synthesis) If FTR-29 is installed, a chain can be assigned to the `LR` track instead of `RS`, using the Master Case File instead of the Research Register — same parent-ID-plus-sub-ID scheme, same state machine, same filing loop, just filed under the other tracker. The same RS-vs-LR assessment FTR-29 already defines applies at the chain level by default (a whole chain is usually one purpose — casework-strengthening or general background, not a mix). Splitting a single chain's steps across both tracks is possible in principle but adds real complexity (cross-tracker dependency references) — treat it as an explicit, asked-for exception, not a default behavior. ## Assess first - Confirm FTR-28 is installed — this feature has no independent engine; every step in a chain is a normal FTR-28 research item underneath. - If FTR-29 is also installed and the chain's subject matter is legal casework: confirm whether this chain belongs on `LR` or `RS` per FTR-29's track-assessment guidance, at the chain level. - Check the Research Register (or Master Case File) for any chain already in progress before starting a new one with a similar subject — avoid creating a duplicate chain for research that's already partway done elsewhere. - Before executing any queued step: confirm its dependencies (if any) are actually CLOSED, not just FILED — do not proceed on a dependency still sitting at PENDING CONTEXT LOAD. - Before executing a triangulation-preferred step specifically: confirm deep research capability is active (see the guardrail above). ## Ask, only if needed - When a chain is proposed from a goal description: confirm the proposed step list, dependency graph, and parallel groups before assigning any IDs or writing any prompts. - When an explicit list of prompts is given with no stated relationships: ask whether any of them actually depend on each other's output, or whether they're independent items just being tracked together for convenience. - When a step reaches FILED — PENDING CONTEXT LOAD and something depends on it: nothing to ask — state plainly what the person needs to do (load it into Project Files) and wait for their confirmation before proceeding. - If a chain looks like it might need more than roughly eight or nine steps: confirm whether it should really be one chain, or whether part of it is better split into its own separate chain. ## Write 1. Determine chain start type (goal description / explicit list / existing register items) and proceed accordingly per "Three ways a chain starts" above. 2. For a goal-description or explicit-list start: run the decomposition, present the proposed chain, get confirmation. 3. Assign the parent chain ID (next `RS[NN]` or `LR[NN]`) and sub-IDs (`-1` through `-N`) in dependency-graph read order. 4. Generate the shared context primer (unnumbered, referenced by every step). 5. Generate each step's prompt file using FTR-28's four-section structure, named per the chain's naming convention. 6. Register every step in the Research Register (or Master Case File) under the parent chain ID, each row carrying: sub-ID, title, status (QUEUED/RUNNING/FILED—PENDING/CLOSED), depends-on (which sub-ID's master it needs, or none), parallel-group tag (if any), triangulation recommendation. 7. Execute steps in dependency order, one at a time or per the person's instruction ("run #1," "run the next one," "run everything sitting open"): a. Confirm the step's dependencies (if any) are CLOSED before starting. b. If triangulation-preferred: confirm deep research is active first, per FTR-28's guidance. c. Run the step (in-conversation or hand off for external multi-platform submission, per FTR-28's Mode A / Mode B distinction). d. When the result is available: run the filing loop above. Status moves to FILED — PENDING CONTEXT LOAD. e. Tell the person to load it into Project Files; wait for confirmation. Status moves to CLOSED once confirmed. f. If a terminal synthesis step exists: do not run it until every other step in the chain is CLOSED. 8. When the chain's last step closes: report the chain complete, with a final status table of every step and its filed master's location. Add this section to `admin\AGENT_INSTRUCTIONS.md` (alongside, not replacing, FTR-28's own section, and FTR-29's if installed): ``` ◆ CASCADING RESEARCH PIPELINE (CHAIN TRACKING) Uses the Multi-AI Research Synthesis System (FTR-28) engine for every individual step — this section adds only chain-level orchestration. CHAIN ID: parent [ProjectCode]-RS[NN] (or -LR[NN]), steps numbered -1 through -N. Shared context primer is unnumbered — not a tracked item, just attached context every step uses. STARTING A CHAIN — three ways: 1. Goal description: decompose into steps, propose the chain (list, dependencies, parallel groups, triangulation calls, terminal-synthesis-or-not), confirm before assigning IDs. 2. Explicit prompt list: assign IDs; ask whether any items actually depend on each other before treating it as a cascade. 3. Existing open register items: group retroactively, confirming any real dependencies before execution. STATE MACHINE PER STEP: QUEUED -> RUNNING -> FILED (PENDING CONTEXT LOAD) -> CLOSED A step stays QUEUED, not RUNNING, until every step it depends on has reached CLOSED — not just FILED. Filed is not the same as ready. FILING LOOP (every result, every time): 1. Verify actual state across #drop\, chain folder, and cache by checking directly — never trust an earlier "filed" claim. 2. Rename to [ChainID]-[StepNum]_[Title]_MASTER.md 3. File to the chain's project-root folder 4. Copy to project cache 5. Update the register (read current state first, then write) 6. Clear #drop\ of only the processed files 7. Report a status table 8. State the manual step (add to Project Files) and wait — saying "continue" or naming the next step is what moves this step to CLOSED and unblocks its dependents. DEEP RESEARCH GUARDRAIL: before any triangulation-preferred step, confirm deep research capability is actually active for the Claude leg (per FTR-28's own guidance) — ask plainly if unclear. Don't attempt in a degraded form and call it equivalent. NO STANDALONE RUNBOOK FILE: the register itself, rendered on demand, is the runbook. Don't generate a separate one. If FTR-29 is installed: a chain can run on the LR track instead of RS, using the Master Case File instead of the Research Register — same scheme throughout, per FTR-29's own RS/LR assessment applied at the chain level. ``` ## Confirm Confirm: the chain's parent ID is assigned, every step has its sub-ID and is registered with its dependencies and parallel groups correctly reflected, the shared context primer exists, and the first runnable step (or steps, if the chain starts with a parallel group) is ready to execute. State plainly which step(s) can run first and which are waiting on a dependency.