Multi-AI Research Synthesis System

Depends on: FTR-13 — Document Tracker System

What this is

A complete workflow for handling research questions that are too complex, too consequential, or too prone to AI error to answer speculatively in a single session. When a research need is identified, the system captures it on a dedicated RS track (Research Synthesis), writes a structured, reusable research prompt, saves it to a single consistent directory, presents it directly in the conversation for the person to copy, and — once the person has submitted that prompt to multiple AI platforms externally and dropped the results into #drop\ — collects, cross-checks, and polishes those results into a single authoritative reference document, filed permanently in the project.

The output is not a note or a draft. It is a finished, versioned, reference-quality document that can be relied upon in later sessions and cited by its RS ID.

This is the generic engine. Two other features build on it directly: FTR-29 (Legal Case Research Synthesis) adds a second, parallel track (LR) specifically for legal casework research tied to a Master Case File, so a legal project can keep argument-strengthening research (LR) and general background research (RS) as two clearly separated lines rather than one undifferentiated pile — note that FTR-29 deliberately uses a different storage rule than this feature (tied to the legal matter's own folder, not the consolidated location below), since legal casework is naturally organized by matter rather than by project-wide topic. FTR-30 (Cascading Research Pipeline) adds the ability to sequence a whole set of dependent RS (or LR) items as one tracked chain, instead of one at a time — see FTR-30 for a full worked example of the two features running together.

Why this exists

Any single AI platform can produce strong output on a complex research question. But single-platform output has known, specific failure modes: hallucinated citations or facts, platform-specific bias, missed nuance, overconfident answers to genuinely uncertain questions, and occasional fabrication of specifics that were never actually in the source material.

Submitting the same prompt to multiple platforms and comparing the outputs catches problems no single-platform review would catch. Disagreement between platforms is more informative than any single answer — it flags exactly the point that needs direct human verification rather than AI reliance. Agreement across platforms increases confidence. Each platform's relative strengths get captured in the polish pass rather than lost by picking one platform as "the answer."

The system also forces research to exist as a filed artifact rather than living only in conversation history — it survives session changes, can be handed off, and leaves a record of how a conclusion was actually reached.

The RS track

Every research need gets a sequential ID on the RS track: [ProjectCode]-RS[NN] (e.g., THZ-RS03). This track is deliberately a new, dedicated code — not reused from FTR-08's existing track-letter table (Technical, Construction, Procurement, Financial, Operations, Legal, Business, Relations/Stakeholder — already "R", Marketing). Reusing bare R for "Research" would collide with FTR-08's established Relations/Stakeholder track; RS avoids that collision cleanly while still reading naturally as "Research Synthesis."

The ID is assigned the moment the research need is identified — before the prompt is even written — so it can be referenced immediately in conversation and in any tracker or master-file entry that mentions it.

The Research Register (this feature's tracker)

Depends on FTR-13's two-layer tracker architecture. A dedicated tracker, trackers\data\research_register.md (+ generated trackers\templates\research_register.html), holds one row per RS (and, if FTR-29 is installed, LR) item:

Status values, in order:

• 🔵 OPEN — need identified, ID assigned, prompt not yet written or not yet submitted
• 🟡 AWAITING RESULTS — prompt submitted to platforms, results not all back yet
• 🟢 CLOSED — polish complete, master document filed

An item sitting at OPEN or AWAITING RESULTS is a live, unresolved thread. This is surfaced at session start (same spirit as FTR-14's Active Flags, if installed, but tracked here specifically): "You have 2 open research items: THZ-RS03 (awaiting Gemini + ChatGPT), THZ-RS05 (prompt written, not yet submitted)."

Closing an item — two ways:

1. Full close. All submitted platforms' results are in #drop\, the polish pass runs, the master is written and filed, status → 🟢 CLOSED.
2. Partial close, by explicit instruction. The person can say something like "let's close RS03 with what we have" when only some of the submitted platforms' results ever came back. The polish pass runs on whatever results exist, the master's own reconciliation note states plainly which platforms were actually used, and status → 🟢 CLOSED. This is never done silently — a partial close only happens when the person says so.

Standard platforms

The default trio to submit a research prompt to, in parallel, without modification:

• Claude (claude.ai or API, extended context + web search)
• Gemini Deep Research
• ChatGPT Deep Research

This is a starting default, not a hard requirement — a person can submit to more, fewer, or different platforms. Whichever platforms were actually used are recorded in the Research Register row and in the master document's own header, so a two-platform result is never presented as if it were a three-platform one.

Making sure each submission is a real deep-research run

"Submitting to Claude" as one of the standard platforms doesn't automatically mean the current conversation is doing genuine deep research. A normal conversational answer — even a good one with some web search along the way — isn't the same thing as an actual extended research run, and quietly treating the two as equivalent would undermine the whole point of triangulation, since it's comparing one genuinely thorough output against two shallow ones instead of three comparably thorough ones.

Before running the Claude leg of a triangulation-preferred item in the current conversation, it's worth checking whether deep research capability is actually active — and if it's not obviously on, asking plainly rather than guessing either way: "This one's flagged for triangulation, so it's worth having deep research mode active for the Claude leg — want to turn that on for this run, or is a regular search-backed answer good enough for this particular question?" Either answer is fine. The point is just that the person gets to decide with the real tradeoff stated, rather than have "deep research" quietly mean something less thorough than it sounds like.

For a single-run item that isn't triangulation-preferred, this matters less — a solid conversational answer with good sourcing is often genuinely sufficient, and there's no comparison quality to protect.

Getting the other platforms to actually run deep research, not their regular mode, since this trips people up the first time:

• Gemini — the prompt needs to go into Gemini's dedicated Deep Research mode specifically (a separate toggle/selection before submitting), not a regular chat turn. It runs considerably longer than a normal response — often several minutes — before producing output. That wait is expected, not a sign of something stuck.
• ChatGPT — same idea: there's a distinct Deep Research mode to select before submitting, separate from a normal ChatGPT conversation, also a multi-minute run.

A friendly heads-up covers this well: "This one runs for a few minutes on each platform in their deep research mode specifically — no rush, paste each one back whenever it's ready." Nothing about this needs to feel procedural; the point is just making sure someone new to the workflow knows what a genuine deep-research submission actually looks like on each platform, rather than accidentally comparing three different depths of answer under one label.

The research prompt

The prompt file is a standalone markdown document, self-contained: a person or AI that receives only the prompt file, with no other project context, should be able to submit it to a deep-research platform and get a useful, project-relevant answer back.

Naming: [ProjectCode]-RS[NN]_[Descriptive_Title]_Research_Prompt.md

Storage: always research\research_prompts\ at the project root — one consistent location for every RS prompt and master, regardless of which topic it supports (see Folder Structure, FTR-07, if installed). This is a deliberate, single, non-branching rule: earlier versions of this feature filed prompts into whichever topic folder's own strategy\ or research\ subfolder happened to exist, which meant two different RS items could land in two different places depending on what else was going on in the project at the time. A single fixed folder means every RS prompt and master can always be found in the same place, with no need to remember or reconstruct which topic-relative branch a given item went down. (Note: FTR-29's LR track uses a different, intentionally separate rule — tied to the legal matter's own folder — see that feature's own file; this consolidation applies to the RS track only.)

Header block:

# [ProjectCode]-RS[NN] — RESEARCH PROMPT
## [Descriptive Title]

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

Body structure — four sections, in this order, every time:

1. YOUR ROLE AND TASK — what role the receiving AI is playing, what it's producing, what it is explicitly NOT doing (no disclaimers substituting for analysis, no "consult a professional" in place of an actual answer), and the output standard (cite sources; flag genuine uncertainty rather than guessing at it).

2. CONTEXT — the minimal, accurate context needed to make the research relevant to this specific project: what the project is, the specific situation that generated this research need, anything the answer needs to account for. Must be accurate and current — stale context skews every platform's output toward the wrong recommendation. Must not include speculative or unconfirmed facts.

3. RESEARCH OBJECTIVES — the specific questions to be answered, in numbered sections, each with a topic label and specific sub-questions. Written to require specific, sourced, actionable answers — not general overviews.

4. REQUIRED OUTPUT STRUCTURE — the deliverables the platform must produce: a TL;DR high-confidence summary, numbered sections matching the Research Objectives, and one or more concrete deliverables (a checklist, a draft, a reference card, a sample). A response missing any required deliverable is incomplete.

Present the prompt to the person, every time

Writing the prompt file to disk is not the end of this step — the person still has to actually get that text into Gemini, ChatGPT, and wherever else it's going. Immediately after saving the file, the prompt's full text is presented directly in the conversation, in a copyable block, with a short framing line: "Here's the prompt for [Title] — copy this and submit it to each platform, then paste the results back here or drop them in #drop\ whenever they're ready." The person should never need to open the saved file themselves just to get the text they need to submit — the file is the permanent record and reusable template; the inline copy is what actually gets used in the moment.

Submit to all platforms in parallel

The prompt is submitted, unmodified, to every platform in the standard trio (or whichever subset is actually being used). No platform gets extra context or a different framing — the prompt has to stand on its own in every environment, since that's the whole point of comparing the outputs afterward. The raw outputs are collected — pasted into a working file, or dropped as separate files into #drop\ — and are not treated as authoritative until after the polish pass.

Polish the results into the MASTER document

This is the core of the system — the step that turns three raw, uneven outputs into one authoritative document. In order:

1. Identify agreements. Where every platform reaches the same conclusion, treat that as high-confidence. Use whichever platform expressed it most clearly, with the strongest sourcing, as the backbone for that section.

2. Identify conflicts. Where platforms disagree, document both (or all) positions explicitly, side by side — never resolve a conflict by silently picking one. State which position is being used as operative and why (e.g., "this version is used because it cites the actual current rule text"), but preserve the alternative so the reader understands there's real uncertainty here, not settled consensus.

3. Flag fabrication. Cross-check every platform's output against what's actually known to be true in the project. Any invented fact, date, citation, or detail gets excluded from the master entirely and named explicitly in the reconciliation note. If a platform fabricated anything in its output, treat the rest of that platform's contribution with extra scrutiny for that same research item — don't let one confirmed fabrication anchor unrelated content from the same source uncritically.

4. Incorporate platform-specific strengths. No single platform is "primary" by default. One platform may source better, one may write more clearly, one may catch a practical angle the others missed — the polish pass draws the strongest piece from wherever it actually came from.

5. Write the master. A finished, production-quality reference document — not a side-by-side comparison table, not a summary of the disagreement. It reads as authoritative, with a reconciliation note at the top explaining what was reconciled and what remains genuinely uncertain.

Master document header block:

# [ProjectCode]-RS[NN] — MASTER: [Descriptive Title]

**Document ID:** [ProjectCode]-RS[NN] (Master / Reconciled)
**Created:** [date]
**Sources reconciled:** [platforms actually used — never assume the full standard trio if fewer were used]
**Status:** Internal reference — never filed as a court/external document unless the project type specifically calls for that
**Location:** `[folder path]`

The reconciliation note directly follows the header and states: which platforms agreed, which conflicted, which platform's output anchored which section and why, what was excluded as fabrication, and what — if anything — still needs direct human verification before being relied on.

Naming: [ProjectCode]-RS[NN]_[Descriptive_Title]_MASTER.md, saved in the same folder as its prompt (research\research_prompts\).

Filing and closing the loop

• The master is filed immediately on completion — it's not a draft, doesn't get a _Draft suffix, and isn't re-versioned unless substantially revised later.
• The Research Register row updates to 🟢 CLOSED with the master's filename, location, and date.
• The master gets registered in the Document Tracker (FTR-13) with its RS ID.
• If the master is high-priority reference material, it's added to the Project Cache (FTR-15, if installed).
• The prompt file is preserved — never deleted. It stays in research\research_prompts\ as an archival record of what was actually submitted, and as a reusable template for a similar future research need.

Assess first

• Confirm the Document Tracker System (FTR-13) is installed — this feature's Research Register depends on it directly.
• Check whether trackers\data\research_register.md already exists; if so, read and carry it forward rather than starting fresh.
• Check whether research\research_prompts\ already exists; if so, treat it as the established location rather than creating a second one.
• Check whether FTR-29 (Legal Case Research Synthesis) is also installed or being installed in the same session — if so, both the RS and LR tracks exist in this project, and any new research need should be assessed for which track it belongs to (see FTR-29's own track-assessment guidance). Remember the two tracks use different storage rules — RS here, LR per FTR-29's own file.
• Check #drop\ for any already-waiting platform outputs tied to an open Research Register item.

Ask, only if needed

• If no project code is established yet: this feature needs one for the RS[NN] ID format — confirm it's set (should already exist from Agent Role & Project Identity, FTR-04).
• When a new research need comes up: "Is this something that needs a full multi-platform research prompt, or is it answerable from what we already know?" (see the criteria below before opening a new RS item).
• "Which platforms do you have access to for this one?" if it's not obviously the standard trio.
• For a triangulation-preferred item specifically: whether deep research mode is active for the Claude leg, per the guidance above — asked plainly, not assumed either way.

When to open a new RS item — the need meets at least one of:

• The answer will directly drive a real decision, not just background understanding
• The question is complex enough that a single-session answer carries meaningful risk of being wrong
• The topic is one where AI platforms are known to vary, guess, or hallucinate

When NOT to open one:

• Already answered in an existing RS (or LR) master — check the Research Register first
• A quick factual lookup with no real ambiguity
• A drafting task — this system is for research, not document production

Write

1. Assign the next [ProjectCode]-RS[NN] ID; add a row to the Research Register with status 🔵 OPEN
2. Write the research prompt using the four-section body structure, save to research\research_prompts\
3. Present the full prompt text directly in the conversation, in a copyable block, right after saving it — the person shouldn't have to open the file themselves to get the text they need to submit
4. Update the Research Register row: prompt written, status stays OPEN until submitted, then → 🟡 AWAITING RESULTS once the person confirms it's been submitted
5. When platform outputs are available (in #drop\ or pasted into the conversation): run the polish pass (agreements → conflicts → fabrication check → platform-strength incorporation → write the master)
6. File the master in research\research_prompts\, alongside its prompt; update the Research Register to 🟢 CLOSED with master filename/location/date
7. Register the master in the Document Tracker; add to Project Cache if high-priority
8. Leave the prompt file in place — never delete it

Add this section to admin\AGENT_INSTRUCTIONS.md:

◆ MULTI-AI RESEARCH SYNTHESIS SYSTEM (RS TRACK)

Research Register: trackers\data\research_register.md
Prompts & masters: research\research_prompts\ — one consistent location
  at the project root for every RS item, always. Never topic-relative.
Standard platforms: Claude, Gemini Deep Research, ChatGPT Deep Research
  (record whichever were actually used per item — never assume the full
  trio if fewer were submitted)

BEFORE A TRIANGULATION-PREFERRED SUBMISSION: confirm deep research mode
  is actually active for the Claude leg (a normal conversational answer
  isn't the same as a genuine deep-research run) — ask plainly if
  unclear rather than assuming either way. Gemini and ChatGPT each need
  their own dedicated Deep Research mode selected before submitting,
  not their regular chat mode; each run typically takes several
  minutes, which is expected.

WHEN A RESEARCH NEED IS IDENTIFIED
1. Assign the next [ProjectCode]-RS[NN] ID; log in the Research Register
   as 🔵 OPEN
2. Write a standalone prompt at research\research_prompts\[ProjectCode]-
   RS[NN]_[Title]_Research_Prompt.md using the four-section structure:
   YOUR ROLE AND TASK · CONTEXT · RESEARCH OBJECTIVES · REQUIRED OUTPUT
   STRUCTURE
3. Present the full prompt text directly in the conversation, in a
   copyable block, right after saving it — the person shouldn't have to
   open the file themselves to get the text they need to submit.
4. Submit to the standard platforms (or whichever are available), same
   prompt, no modification. Register status → 🟡 AWAITING RESULTS.
5. When results are available: polish them into research\research_
   prompts\[ProjectCode]-RS[NN]_[Title]_MASTER.md —
   - identify agreements (high-confidence backbone)
   - document conflicts explicitly, side by side, never silently resolved
   - flag and exclude any fabricated fact/citation/detail
   - draw each platform's strongest contribution regardless of which
     platform it came from
   - write as a finished, authoritative reference — not a comparison
6. File the master; update Research Register → 🟢 CLOSED; register in
   the Document Tracker; add to Project Cache if high-priority
7. Preserve the prompt file — never delete it

CLOSING RULES
- Full close: all submitted platforms' results are in and reconciled
- Partial close: only on explicit instruction ("close it with what we
  have") — the master's reconciliation note states plainly which
  platforms were actually used
- Surface open (🔵 OPEN or 🟡 AWAITING RESULTS) items at session start —
  an unresolved research thread should never go silently stale

If FTR-29 (Legal Case Research Synthesis) is also installed: this
project has two parallel tracks, RS (general) and LR (legal casework).
Assess which track a new research need belongs to before assigning an
ID — see FTR-29's own track-assessment guidance. Note: LR items use a
different storage rule than RS (tied to the matter's own folder, not
research\research_prompts\) — this is intentional, see FTR-29's own
file for why.

If FTR-30 (Cascading Research Pipeline) is also installed: a whole set
of dependent RS (or LR) items can run as one tracked chain instead of
one at a time — see FTR-30 for the full mechanics and a worked example.

Confirm

Confirm: the Research Register is set up at trackers\data\research_register.md, research\research_prompts\ is the established location for prompts and masters, the RS track is ready for its first ID, and the standard platform list is recorded. Want to install another, or is that everything for now?