---
feature_id: FTR-29
title: Legal Case Research Synthesis
category: Legal
optional: true
depends_on: FTR-28
source: Not from Project_Kickoff_Seed_Prompt_v2.3.md — supplied directly by the user, de-identified from a tool they built and used in an active legal casework project. The original case name, court, and docket number have been replaced with a generic example (Doe v. Roe) throughout; the workflow, structure, and lessons learned are preserved in full. No corresponding item in Bootstrap_Function_Registry.md. See coverage_report.md Section 10.
registry_refs: []
---

# Legal Case Research Synthesis

Depends on: [FTR-28 — Multi-AI Research Synthesis System](../items/multi-ai-research-synthesis.md)

## What this is
The legal-casework layer on top of FTR-28 (Multi-AI Research Synthesis System). Where FTR-28 gives a project a general-purpose `RS` research track and the full prompt-write/submit/polish engine, this feature adds a second, parallel track — **`LR`** (Legal Research) — specifically for research that will directly strengthen an argument, drive a filing decision, or resolve a question of local court practice. `LR` items tie into the project's **Master Case File** (its Open Items list) instead of a generic tracker entry, since legal casework research carries a different kind of stakes and needs to be visible wherever case strategy itself is tracked.

Installed together, FTR-28 and FTR-29 give a legal project two clearly separated research lines running in parallel: `LR` for casework-specific, argument-strengthening research tied to the Master Case File, and `RS` for general background research that provides context without being a direct legal argument (researching a fact pattern, a business, a person, or a general topic connected to the case, but not itself a point of law or procedure). The same project can — and often will — have both kinds of research open at once; this feature's job is making sure a new research need lands on the correct track rather than blurring the two together.

## Why this exists
Legal research carries specific risks general research doesn't always share: an answer here can directly drive a filed position, a hearing argument, or a strategic decision with real consequences. AI platforms are also specifically prone to a legal failure mode — inventing case-specific "facts" (dates, descriptions, procedural history) that sound plausible but don't match the actual record, in addition to the more general risk of hallucinated citations or misstated rules. A single-platform answer to a question like "what does the local standing order require here" or "how should this motion be structured" carries real risk if taken at face value.

FTR-28's polish methodology (agreements, conflicts, fabrication-flagging, platform-strength blending) already exists to catch exactly this. This feature's job is narrower: make sure legal casework research is tied to the case's actual tracking system (the Master Case File), carries the case-specific context a legal research prompt needs to be useful, and is kept clearly distinguishable from the project's general `RS` research line.

This feature is separate from FTR-27 (Legal Citation Management System) and doesn't overlap it: FTR-27 vets citations that are about to appear *in a filed document*; this feature is about vetting *research used to inform strategy*, before anything is drafted. A well-run project may use both — research synthesized here, citations from that research (and from drafting generally) vetted there before filing.

## The LR track
Every legal casework research need gets a sequential ID on the `LR` track: `[ProjectCode]-LR[NN]` (e.g., `DOE-LR05`). Assigned the moment the need is identified, before the prompt is written — the same convention FTR-28 uses for `RS`, just a separate sequence and a separate home (the Master Case File rather than the Research Register).

**Why a different track code from FTR-28's `RS`, and not just a shared sequence:** keeping them as two separate ID sequences is what makes the "two parallel lines" actually work in practice — an `LR` number always means casework research tracked in the Master Case File; an `RS` number always means general research tracked in the Research Register. Reading either code off a document title tells you immediately which system it belongs to and where to look for its open/closed status.

## Master Case File integration
Instead of the generic Research Register (FTR-28's tracker), `LR` items are logged in the Master Case File's own Open Items list as a numbered entry with status ⏳ PENDING:

```
[N]. [ProjectCode]-LR[NN] — [Title] — ⏳ PENDING
```

Status moves to ✅ RESOLVED when the master document is filed, following the same full-close / partial-close rules FTR-28 already defines (full close once all submitted platforms are reconciled; partial close only on explicit instruction, e.g. "close LR05 with what we have," with the master's reconciliation note stating plainly which platforms were actually used).

If a Master Case File doesn't yet exist for the project, this feature can still function using the Research Register as an interim home for `LR` items — but the Master Case File is the intended, correct home once one exists, and items should be moved there rather than left permanently in the generic tracker.

## Track assessment — deciding LR vs. RS
When a new research need comes up in a legal project with both tracks installed, assess (or ask, if genuinely unclear) which track it belongs to before assigning an ID:

**Goes on LR (legal, tied to the Master Case File) when the research:**
- Will directly inform an argument, a filing, or a hearing position
- Turns on a point of law, procedure, or local court practice
- Needs the case-specific context section below to be useful at all

**Goes on RS (general, tied to the Research Register) when the research:**
- Provides background or context connected to the case, but isn't itself a legal argument or procedural question — for example, researching a business, a person, a technical fact pattern, or general subject-matter background that informs the case without being a point of law
- Would be equally useful framed without any case-specific legal framing at all

**Worked example (illustrative, not a real matter):** in *Doe v. Roe*, a question like "what does the local rule require for a motion for protective order in this jurisdiction" is squarely `LR` — it's a procedural question that will directly shape a filing. A question like "what's the general reputation and business practice of [a specific vendor mentioned in discovery]" is `RS` — useful context for understanding the discovery record, but not itself a legal argument or a point of procedure. Both might exist in the same case at the same time, tracked on their own separate lines.

When it's genuinely ambiguous, ask rather than guess: *"Is this specifically about strengthening an argument or filing position, or is it more general background for the case?"*

## Legal-specific prompt requirements
`LR` prompts use FTR-28's same four-section body structure (YOUR ROLE AND TASK · CONTEXT · RESEARCH OBJECTIVES · REQUIRED OUTPUT STRUCTURE), with the CONTEXT section carrying legal-specific requirements the general `RS` version doesn't need:

**CONTEXT section for LR prompts must include:**
- Jurisdiction and court (and division, if relevant)
- The parties' roles (not necessarily real names if a project prefers to keep prompts genuinely generic — a de-identified reference like "Petitioner" / "Respondent" works fine for the AI's purposes)
- Current procedural posture (what's pending, what's been ruled on, what's scheduled)
- The specific factual trigger that generated this research need

This section must be accurate and current as of the day the prompt is written — a stale procedural fact (wrong hearing date, a motion that's already been ruled on) will skew every platform's output toward the wrong recommendation. It must never include speculative or unconfirmed facts.

**YOUR ROLE AND TASK for LR prompts** should specify the receiving AI's role in legal-research terms — e.g., "an expert legal research analyst specializing in [jurisdiction] [practice area]" — and the same output standard FTR-28 requires generally, made legal-specific: every answer must cite the controlling statute, rule, or case; genuine uncertainty gets flagged rather than guessed at; the AI is not producing a disclaimer or a "consult an attorney" deflection in place of actual analysis.

**Header block** (same shape as FTR-28's, with the LR ID and case identification added):
```markdown
# [ProjectCode]-LR[NN] — DEEP RESEARCH PROMPT
## [Descriptive Title]
### [Case Name] · [Court, Division] · [Docket No.]

**Document ID:** [ProjectCode]-LR[NN]
**Created:** [date]
**Location:** `[folder path]`
**Status:** Research prompt — internal only, never filed
**Next action:** Submit to [platforms]; polish results into [ProjectCode]-LR[NN] MASTER
```

**Master document header** — same as FTR-28's MASTER header, with the case identification line added under the title, matching the prompt header above.

## Fabrication check, legal-specific note
FTR-28's fabrication-flagging step (Step 3 of the polish pass) applies with particular force here: cross-check every platform's output against the actual case record specifically, not just general plausibility. A platform inventing a specific date, a specific document description, or a specific procedural fact that doesn't match what's actually in the case file is the single most common and most dangerous failure mode this whole system exists to catch. Any such fabrication is excluded from the master entirely and named in the reconciliation note — and, per FTR-28's own rule, the rest of that platform's output for that item gets extra scrutiny rather than being trusted uncritically just because the fabrication was caught and removed.

## Deep-research-mode awareness for LR items
The same friendly check FTR-28 defines applies here, unchanged: before running the Claude leg of a triangulation-preferred `LR` item, confirm deep research mode is actually active rather than assuming a normal conversational answer is equivalent — and check in plainly if it isn't obvious either way. This matters especially for `LR` items given the filing stakes: a shallow answer treated as if it were a genuine deep-research pass is exactly the kind of gap the fabrication-check emphasis above exists to catch downstream, so it's worth catching earlier, at submission time, instead.

## If FTR-30 (Cascading Research Pipeline) is also installed
A whole sequence of dependent legal research questions — say, jurisdiction basics before a procedural deep-dive before a filing-ready strategy memo — can run as one tracked chain on the `LR` track, using FTR-30's parent-ID-plus-sub-ID scheme (`[ProjectCode]-LR[NN]-1`, `-2`, ...) and its pause-and-confirm mechanic between steps. This feature doesn't duplicate FTR-30's chain mechanics — see that feature for the full design and a worked example. The RS-vs-LR track assessment above still applies at the whole-chain level: a chain is usually one purpose (casework-strengthening or general background), not a mix of both.

## Assess first
- Confirm FTR-28 (Multi-AI Research Synthesis System) is installed — this feature has no independent prompt-write/submit/polish engine of its own; it uses FTR-28's entirely.
- Confirm the project type is Legal (see Agent Role & Project Identity, FTR-04). If not, this feature doesn't apply.
- Check whether a Master Case File already exists for this project. If yes, `LR` items log there. If not, note that the Research Register (FTR-28's tracker) serves as an interim home until one exists.
- Check whether FTR-27 (Legal Citation Management System) is also installed — if so, note the division of labor explicitly to the user (research synthesis here; citation vetting before filing there) rather than letting the two blur together.
- Check whether FTR-30 (Cascading Research Pipeline) is also installed — if so, a sequence of dependent LR items can run as one chain rather than individually.

## Ask, only if needed
- If no Master Case File exists yet: "Legal research on the LR track will log to the Research Register for now, since there's no Master Case File yet — want to set one up, or is that fine as an interim home?"
- When a new research need comes up and the track isn't obvious: "Is this specifically about strengthening an argument or filing position, or is it more general background for the case?" (LR vs. RS — see Track assessment above)
- Jurisdiction, court, division, and current procedural posture, if not already established elsewhere in the project (these populate every LR prompt's CONTEXT section).
- For a triangulation-preferred LR item: whether deep research mode is active for the Claude leg, per the guidance above.

## Write
1. Confirm FTR-28 is installed; if not, flag it as a prerequisite before proceeding
2. Assign the next `[ProjectCode]-LR[NN]` ID; log in the Master Case File Open Items as ⏳ PENDING (or the Research Register, if no Master Case File exists yet)
3. Write the prompt using FTR-28's four-section structure, with the legal-specific CONTEXT requirements above; save alongside the matter's other strategy documents
4. Submit to the standard platforms (per FTR-28), same prompt, no modification — confirming deep research mode is active for the Claude leg first, if this item is triangulation-preferred
5. When results are available: run FTR-28's polish pass, with the legal-specific fabrication-check emphasis above
6. File the master; update the Master Case File Open Item to ✅ RESOLVED with the master's filename, location, and date
7. Register in the Document Tracker; add to Project Cache if high-priority
8. Preserve the prompt file — never delete it

Add this section to `admin\AGENT_INSTRUCTIONS.md` (alongside, not replacing, FTR-28's own section):

```
◆ LEGAL CASE RESEARCH SYNTHESIS (LR TRACK)

Uses the Multi-AI Research Synthesis System (RS TRACK, FTR-28) engine in
full — prompt structure, standard platforms, polish methodology, closing
rules, and deep-research-mode awareness for triangulation-preferred
items. This section adds only what's specific to legal casework research.

LR items log to: [Master Case File Open Items, or Research Register if
no Master Case File exists yet]

TRACK ASSESSMENT — before assigning an ID, decide LR or RS:
  LR (this track) — will directly inform an argument, filing, or hearing
    position; turns on a point of law, procedure, or local practice
  RS (FTR-28's general track) — background or context connected to the
    case but not itself a legal argument or procedural question
  Ask if genuinely unclear: "Is this specifically about strengthening an
  argument or filing position, or is it more general background?"

LR PROMPTS — CONTEXT section must additionally include:
  - Jurisdiction and court (and division, if relevant)
  - Parties' roles (de-identified reference is fine)
  - Current procedural posture — accurate as of today, never stale
  - The specific factual trigger for this research need

FABRICATION CHECK — apply with particular force: cross-check every
platform's output against the actual case record specifically. An
invented date, document description, or procedural fact is the most
common and most dangerous failure mode this system exists to catch.

If FTR-27 (Legal Citation Management System) is also installed: this
feature synthesizes research before drafting; FTR-27 vets citations
before filing. Different stages, complementary, not overlapping.

If FTR-30 (Cascading Research Pipeline) is also installed: a sequence
of dependent LR items can run as one tracked chain — see FTR-30 for
the mechanics. This feature's RS-vs-LR assessment still applies at the
whole-chain level.
```

## Confirm
Confirm: the LR track is ready — tied to [the Master Case File / the Research Register as an interim home], with the legal-specific CONTEXT requirements and fabrication-check emphasis in place, and the RS/LR track-assessment rule active for future research needs. Want to install another, or is that everything for now?