ResearchModule — Initial Design (2026-04-19)

Automates the manual research journey the user did for Discovery-OS: scoping conversation → autonomous researcher → multi-tool deep research fan-out → synthesis into a plan.

Brainstorm status: IN PROGRESS. Sections 1 approved. Section 2 presented, awaiting user approval. 6 more sections pending. No code written. Resume via SESSION.md in the project directory.

---

1. Context

1.1 Why this module exists

User invoked Claude Code in ~/AI-Development/Research/ and asked what had been done on "our researcher project." Memory was empty; the only artifact was Modules/ResearchModule/Spec.md — a 53-line skeleton with empty sections (Purpose, Sub-modules, Inputs, Outputs, Config, Techniques) and all 5 Definition-of-Done gates unchecked. Created 2026-04-05, untouched since 2026-04-06.

1.2 The manual reference example (THE spec we're automating)

File 1: /Users/arijitchowdhury/AI-Development/Research/sample.txt (1278 lines, 150KB) A full Claude Ai conversation where the user dissected "How do I do sales discovery" across a broad and refined journey: - Started vague: "how do I do discovery during sales calls" - Pivoted through "too myopic, too product-centric, losing larger business context" self-correction - Converged on the Exchange Paradigm thesis (currency-for-currency, not questions-for-answers) - Expanded scope to the full commercial cycle (XDR → AE → SE → CS) - Produced the final "Pass A — Foundations" research prompt - Handed the prompt to Claude + OpenAI deep research - Claude synthesized both outputs into the plan

File 2: /Users/arijitchowdhury/AI-Development/Discovery/Discovery-OS-v1.md (1220 lines, 100KB) The synthesized plan from Claude: 10 sections including Exchange Paradigm, Core Loop (7-stage call arc), 16-move Moves Library, Competitive Pre-Empt Playbook, Skeptical-AE Pre-Map, Role Continuum, Measurement Stub, PRISM Translation Ruleset, Training Outline. Evidence tiers 🟢/🟡/🔵 throughout. Concrete + conceptual mix.

Inspiration: Anthropic's "Automated Weak-to-Strong Researcher" (April 2026) paper on Automated Alignment Researchers (AARs) — autonomous agents that propose ideas, run experiments, analyze results, and share findings. Achieved 0.97 PGR in 5 days vs 0.23 PGR in 7 days for two human researchers.

1.3 What ResearchModule IS

A reusable Layer-1 primitive that automates the end-to-end journey from a vague initial question to a synthesized plan, preserving full provenance (raw research dossier + trace + cost report alongside the plan).

1.4 What ResearchModule IS NOT

• Not a sales-specific tool (Discovery-OS happened to be the first example; the module is domain-agnostic).
• Not a replacement for PRISM-style single-source intelligence gathering (PRISM collects structured signals; ResearchModule dissects and answers open questions).
• Not real-time (runs take 30–60+ minutes; designed for async use, not in-call).

---

2. Design Decisions (ordered, each with rationale)

Decision 1 — Pipeline shape

Decision: Scoper → AAR (always on) → Multi-tool Fan-out → Synthesis. 4 phases.

Alternatives considered: - Smart wrapper around existing deep-research tools (too thin; doesn't capture the scoping journey shown in sample.txt) - Standalone autonomous research agent (too narrow; misses the multi-tool triangulation that gave Discovery-OS its breadth)

Why: sample.txt proves the value of scoping-before-research. Multi-tool fan-out proves the value of triangulation (Claude and OpenAI found different things). AAR covers the gap sample.txt skipped (no autonomous exploration phase).

User confirmation: "I think we need both. First the autonomous researcher, which will come up with the question and the structure, define the detailed prompt necessary for the research after considering all angles, interviewing me with questions to get all angles, scope and details, then acts like its own researcher... Once that is done then we will call the deep research across multiple tools - Perplexity, Claude, OpenAI and Gemini. so I don't see this as an either or, rather I see this as complementary and additive."

Decision 2 — AAR is always on

Decision: AAR runs on every research job. No conditional skip.

Alternatives considered: - Conditional AAR (Scoper decides if the question needs AAR based on archetype) - Optional AAR toggle

Why: User explicitly ruled out conditionality: "the AAR step is a must and should be always on." The Anthropic paper's core insight is that autonomous exploration surfaces unexpected angles humans miss.

Decision 3 — AAR internal stages

Decision: AAR = 4 sequential sub-steps inside Phase 2: - 2a. Angle Generator — produces 5–10 research angles, does cheap exploratory web search per angle, filters dead ends - 2b. Critic — stress-tests the Scoper brief for blind spots, counter-evidence, untested assumptions (does what the user did manually in sample.txt) - 2c. Pre-Researcher — forms a working hypothesis from the surviving angles - 2d. Prompt Composer — reads Scoper brief + 2a + 2b + 2c → writes the actual deep-research prompt that fan-out uses

Rationale: Matches the "angle-gen + critic + pre-research" options in the brainstorm (user chose option D — all three, sequentially). Step 2d was added after the user caught that the deep-research prompt can only be finalized AFTER AAR completes, not at Phase 1 exit. Prompt Composer has a distinct responsibility (craft a prompt that works across 4 different deep-research tools with different quirks) that's separate from hypothesis formation.

Dependency chain: Every sub-step is strictly sequential — 2b reads 2a's output, 2c reads 2a+2b, 2d reads 2a+2b+2c. This was the user's correction: "all these steps are interdependent on each other."

Decision 4 — Runtime UX: "Interactive Scoper, async rest, hard-exception interrupts"

Decision: Phase 1 is fully interactive (you own the chair). Phases 2–4 run async, headless. Module interrupts you ONLY on hard exceptions, never on soft decisions.

Hard-exception triggers: 1. Contradiction — AAR found evidence that breaks a Scoper assumption 2. Scope break — research is expanding beyond the brief 3. Budget exceeded — cost/time tripwire hit 4. Confidence floor — all fan-out tools returned low-confidence on a core question

Never-interrupts: soft choices like "pick which of 3 angles to deepen" — AAR decides autonomously.

Rationale: Pure async (Option B) loses Arijit's ability to course-correct when AAR drifts. Pure interactive (Option C) burns attention and defeats automation. The "B + narrow C" hybrid captures the upside of both while minimizing the downside.

Decision 5 — Deliverable: plan + dossier

Decision: Final output = one synthesized plan document (modeled on Discovery-OS-v1.md) + preserved raw outputs from all 4 deep-research tools.

Rationale: Satisfies cardinal rule #5 (evidence on every data point). Enables re-synthesis with different instructions later without re-paying for deep research. Preserves audit trail.

Decision 6 — Packaging / interface boundary: core engine with thin entrypoints

UPDATED / SUPERSEDES earlier "skill first, extract later" framing — APPROVED 2026-05-16.

Decision: ResearchModule is a standalone core Python research engine with multiple thin entrypoints from day one. The skill is not the product; the engine is the product.

Required interfaces:

1. Core Python package — owns Scoper, AAR, Fan-out, Synthesis, schemas, adapters, state machine, resumability, cost tracking, trace logging. Importable by other apps and skills.
2. CLI — thin wrapper over the core engine for local standalone usage, debugging, tests, cron, and automation. Target shape: uv run research "<topic>" or equivalent.
3. Codex/Claude skill wrapper — conversational UX wrapper that invokes the CLI/core. Other skills can embed ResearchModule by depending on the core contract rather than reimplementing research.
4. App/API boundary — designed from day one, shipped when needed. Target shape: POST /research-runs, GET /research-runs/{id}, POST /research-runs/{id}/resume, backed by the same core engine.

Rationale: User needs ResearchModule to work as a standalone app, a CLI, an embeddable skill, and a callable component from another application. Building only a skill would trap core research logic inside Codex/Claude UX and make reuse brittle. Building the core engine first keeps the execution harness deterministic and lets every interface remain a thin adapter around the same validated contracts.

Architecture sketch:

flowchart TD
  U1["User / terminal"] --> CLI["CLI entrypoint"]
  U2["Codex or Claude skill"] --> SKILL["Skill wrapper"]
  U3["External app / PRISM / LENS"] --> API["App/API boundary"]
  U4["Python caller"] --> PKG["Importable Python package"]

  CLI --> CORE["ResearchModule Core Engine"]
  SKILL --> CORE
  API --> CORE
  PKG --> CORE

  CORE --> ORCH["Pure-code orchestrator"]
  ORCH --> SCOPER["Phase 1: Scoper"]
  ORCH --> AAR["Phase 2: AAR"]
  ORCH --> FANOUT["Phase 3: Vendor fan-out"]
  ORCH --> SYNTH["Phase 4: Synthesis"]

  AAR --> POVLIGHT["Light multi-POV critique"]
  SYNTH --> POVHEAVY["File-gated POV artifacts"]

  ORCH --> STATE["state.json"]
  ORCH --> TRACE["trace.log + cost report"]
  ORCH --> ARTIFACTS["Validated artifacts on disk"]

Decision 7 — Approach: "Paper-scale, delivered incrementally"

Decision: Build toward Approach 3 (paper-scale, matching Anthropic paper architecture) delivered in 3 weekly increments: - Week 1: Scoper only (interactive skill). Use it alongside the sample.txt-style manual flow while building the rest. - Week 2: Add AAR sandboxes + fan-out adapters. Run end-to-end with stub synthesis. - Week 3–4: Full multi-stage synthesis + fact-checker + state machine.

Alternatives rejected: - Approach 1 (MVP): single-pass synthesis won't hit the Discovery-OS quality bar. User said "why are you suggesting two when three is a more foolproof solution?" and was right. - Approach 2 (balanced): was my recommendation; user overturned it correctly.

Rationale: Arijit's quality bar and cardinal rules require Approach 3's verification, failure recovery, and audit properties. Incremental delivery buys early usability without compromising the endpoint.

Decision 8 — Execution architecture: pure code, zero LLM in harness

Decision: The orchestrator is a Python program. It contains pure deterministic control flow (if/else, loops, schema validation). LLMs are invoked as function calls for discrete steps — never for orchestration logic. Every vendor uses its native SDK.

User's framing: "I don't see any place for LLM in the execution harness, because then it's going to get screwed up. LLM would be invoked and used for those individual steps, not in the harness. The entire harness should be code only; then it will be predictable, and then it will be repeatable."

SDKs locked:

Phase / step	SDK
Phase 1 Scoper (interactive loop)	anthropic (Claude Opus)
Phase 2a-b (angle-gen, critic)	anthropic (Claude Sonnet)
Phase 2c-d (pre-research, composer)	anthropic (Claude Opus)
Phase 3 Perplexity	Perplexity REST API via httpx
Phase 3 Claude deep research	anthropic + web tools
Phase 3 OpenAI deep research	openai (Responses API)
Phase 3 Gemini deep research	google-genai
Phase 4 (extractor, reconciler, synth, fact-check)	anthropic (Claude Opus)

Scrapped: the earlier "Claude subagent" orchestration concept via Claude Agent SDK. That reintroduced non-determinism.

Decision 9 — Language: Python 3.12+

Decision: Python is right for this codebase, defended on merit.

Reasons: 1. Existing stack is Python (PRISM, LENS, shared-py/core, all audit skills) — single-ecosystem integration path 2. Python with discipline IS production-grade; the "Python isn't production" framing is vibes 3. Workload is I/O orchestration (API calls, file I/O, JSON validation) — where Python excels 4. First-class LLM SDK maturity from all 4 vendors

User confirmation: "okay, it's fine. Let's continue with Python."

Decision 10 — Mandatory production-grade Python stack

Decision: Python is considered production-grade ONLY if ALL of these are in use. No substitutes.

Tool	Purpose
pydantic v2	Every file I/O schema, every API boundary, every validated object. No raw dicts.
ruff	Lint + format, enforced in pre-commit and CI
pytest + pytest-asyncio	Tests including async paths
httpx	All HTTP (replaces requests)
structlog	Structured logging (replaces prints and stdlib logging)
tenacity	Retry with backoff for all external API calls
uv	Package management / reproducible installs (replaces pip + poetry)
pyright --strict	Static type checker; runs on every file edit (IDE), on demand (uv run pyright), and as a pre-commit/CI gate that blocks any commit with type errors. Catches the AI-written-code failure mode (wrong argument types, hallucinated attributes, dict-vs-model drift) at write time before any LLM/API call is made.

User's framing: "We need to use them; only then is Python production-ready. Otherwise, it's not."

pyright --strict approval (2026-04-27): Approved after the user asked how a static type checker fits into a Claude-Code-writes-the-code workflow. The mechanics: (1) VS Code runs pyright continuously and exposes diagnostics Claude can query after edits; (2) Claude runs uv run pyright <file> after batches of edits and treats errors as instructions to fix; (3) pre-commit + CI hooks block commits with pyright errors — enforced, not promised. Justification: AI-generated Python is more prone to type-mismatch bugs (wrong call signatures, dict-vs-pydantic-model drift, None-handling) than human-written; pyright catches these at write time, before any real API call burns money. Composes cleanly with pytest + ruff already in the stack.

---

3. Architecture Overview

3.1 Pipeline (approved in Section 1 of brainstorm)

USER runs: uv run research "<topic>"
  │
  ▼
┌───────────────────────────────────────────────────────────────┐
│ PHASE 1 — SCOPER (interactive, user in the chair)             │
│   Dissects the question through conversation                  │
│   Challenges assumptions. Asks clarifying Qs.                 │
│   Can do light web lookups to sanity-check claims.            │
│   OUTPUT: 00-scoper-brief.md                                  │
│           (scoped question, context, success criteria,        │
│            constraints, out-of-scope, archetype)              │
└───────────────────────────────────────────────────────────────┘
  │ [user walks away, rest runs async]
  ▼
┌───────────────────────────────────────────────────────────────┐
│ PHASE 2 — AAR (sandboxed, sequential)                         │
│   2a. angle-generator  → angles.json                          │
│   2b. critic           → critique.md                          │
│   2c. pre-researcher   → hypothesis.md                        │
│   2d. prompt-composer  → deep-research-prompt.md              │
└───────────────────────────────────────────────────────────────┘
  │
  ▼
┌───────────────────────────────────────────────────────────────┐
│ PHASE 3 — FAN-OUT (4 tools in parallel, independent failures) │
│   Perplexity │ Claude DR │ OpenAI DR │ Gemini DR              │
│   OUTPUT: 02-dossier/*.md  (4 raw research outputs)           │
└───────────────────────────────────────────────────────────────┘
  │
  ▼
┌───────────────────────────────────────────────────────────────┐
│ PHASE 4 — SYNTHESIS (4 stages in sequence)                    │
│   4a. extractor    → claims.json                              │
│   4b. reconciler   → reconciled.md                            │
│   4c. synthesizer  → plan-draft.md                            │
│   4d. fact-checker → plan.md (with 🟢🟡🔵 evidence tiers)      │
│   OUTPUT: plan.md + dossier/ + trace.log + cost-report.md     │
└───────────────────────────────────────────────────────────────┘
  │
  ▼
USER comes back, reads plan.md

3.2 Architecture synthesis from NVIDIA + Open Deep Research + STORM — APPROVED 2026-05-20

Decision: ResearchModule adopts the strongest proven patterns from three current research-agent architectures, but does not take any of them as a V1 runtime dependency.

Sources reviewed: - NVIDIA AI-Q Blueprint — Deep Researcher Agent - LangChain Open Deep Research repository - Open Deep Research workflow notes - STORM paper - STORM repository

Synthesis:

Source	Pattern adopted	ResearchModule interpretation
NVIDIA Deep Researcher	Orchestrator + planner + researcher loop; citation management; source registry; deterministic citation verification and sanitization	AAR becomes a real planning layer; final Synthesis is incomplete until citations verify against retrieved sources.
Open Deep Research	Clarify/brief stage; supervisor loop; bounded parallel research workers; safe tool execution; compression of raw research into notes; config-controlled iteration caps	Fan-out becomes a supervisor-owned research worker layer, not a naive four-vendor blast.
STORM	Multi-perspective question asking; source-grounded pre-writing; outline-first synthesis before long-form writing	AAR produces an evidence-seeking outline seed; Synthesis writes from an outline, claims, source registry, and POV artifacts rather than raw vendor prose alone.

Architecture consequence: the high-level pipeline remains Scoper -> AAR -> Fan-out -> Synthesis, but the internal contracts change:

Scoper
  -> ResearchBriefV1
  -> AAR Planner
       -> perspective/angle map
       -> evidence-seeking outline seed
       -> strategic research plan
       -> vendor prompt plan
  -> Research Supervisor
       -> bounded research tasks
       -> tool/vendor adapters
       -> compressed cited notes
       -> source registry
  -> Synthesis Studio
       -> claim extraction
       -> outline refinement
       -> isolated POV interpretations
       -> contradiction reconciliation
       -> final report/plan
       -> citation verification and sanitization

New first-class artifact families: - research_plan.json — AAR's strategic research plan: angles, questions, evidence types, source strategy, vendor routing, follow-up triggers, and risks. - outline_seed.json — AAR's early outline map: candidate sections, unresolved sections, evidence needed per section, and POV prompts for Synthesis. - source_registry.json — every URL, document, citation key, and source id actually retrieved during research. - evidence_items.json — normalized evidence snippets with source ids, dates, confidence, and retrieval metadata. - compressed_notes.json — citation-preserving research notes created from raw vendor/tool outputs before Synthesis. - outline_final.json — final evidence-backed outline before prose generation. - citation_audit.json — verification result listing valid citations, removed citations, and removal reasons.

Build policy: reuse patterns, not frameworks, in V1. Do not depend on LangGraph, STORM runtime, or NVIDIA AI-Q runtime unless a later decision explicitly changes this. The reason is architectural, not ideological: ResearchModule's locked constraints require a pure-code orchestrator, disk-first file gates, resumable state, BYOK, and thin entrypoints for CLI, skill, package, and future app/API use. External graph runtimes would move too much state and control flow outside our artifact contracts.

Standalone synthesis artifacts: - Vault: Modules/ResearchModule/Design/2026-05-20-architecture-synthesis.md - Workspace distribution doc: /Users/arijitchowdhury/AI-Development/Research/docs/ResearchModule-Architecture-Synthesis.md

3.3 Workspace layout (approved)

~/AI-Development/Research/runs/
  2026-04-19-discovery-os/              ← slug from topic
    00-scoper-brief.md                  ← Phase 1 output
    01-aar/
       angles.json
       critique.md
       hypothesis.md
       deep-research-prompt.md          ← Phase 2 output
    02-dossier/
       perplexity.md
       claude-research.md
       openai-dr.md
       gemini-dr.md                     ← Phase 3 outputs
    03-synthesis/
       claims.json
       reconciled.md
       plan-draft.md
       plan.md                          ← headline deliverable
    state.json                          ← resume state (source of truth)
    trace.log                           ← full observability
    cost-report.md                      ← per-phase $ + time

3.4 Execution model (approved, was the "block diagram to real architecture" fix)

Core insight (user-raised): "You cannot fix 'Claude might claim completion' by asking Claude to behave better. It has to be enforced by the system — files on disk, schema-validated, hashed — before any step advances."

Required guarantees:

1. Orchestrator is not the parent Claude session. It's a Python program (orchestrator.py) kicked off as a detached subprocess at end of Phase 1. Claude Code session can die, compact, or be force-quit — the runner doesn't care. State on disk is authoritative.

2. Every sub-step is isolated. Fresh process/context per step via direct Anthropic SDK calls (not spawned subagents). No parent-session state leaks in.

3. File-gated dependencies. Step N+1 cannot start until step N's output file exists AND passes Pydantic schema validation. If the file is missing, malformed, or incomplete, the next step does NOT run. Pipeline halts cleanly with error in state.json and trace.log.

4. Atomic writes. Subagent writes to <name>.tmp. Runner validates. Pass → atomic rename. Fail → delete tmp, mark step FAILED, halt.

5. state.json is the authoritative source of truth:

{
  "run_id": "2026-04-19-discovery-os",
  "phase_1_scoper": {"status": "complete", "artifact": "00-scoper-brief.md", "sha256": "abc...", "completed_at": "..."},
  "phase_2a_angle_generator": {"status": "complete", "artifact": "01-aar/angles.json", "sha256": "def...", "cost_usd": 0.42},
  "phase_2b_critic": {"status": "running", "started_at": "..."},
  "phase_2c_pre_researcher": {"status": "pending"},
  "phase_2d_prompt_composer": {"status": "pending"},
  "phase_3_fanout": {"status": "pending"},
  "phase_4_synthesis": {"status": "pending"},
  "circuit_breaker_tripped": false,
  "total_cost_usd": 0.42,
  "budget_cap_usd": 50.00
}

Resume after crash: new process reads state.json, finds the first step not complete, re-runs from there. Never re-runs completed steps. Never skips incomplete ones.

6. Circuit breakers: - Phase 2 schema-gate: AAR sub-step fails validation → Phase 3 never fires. No fan-out tokens burned on bad prompt. - Fan-out canary: Phase 3 runs one cheap tool first (Perplexity), passes result through fast Haiku sanity check. Canary fails → halt Phase 3, skip remaining 3 tools. Max loss ~$3, not ~$80. - Budget cap: budget_cap_usd in state.json. Every call reports cost on exit. Runner sums. Cap hit → halt + notify. - Time cap: same pattern.

7. Full inspectable traces. trace.log records every LLM call, tool call, cost, and decision. Not summarized. Not claimed. You can grep at 3am if a run looks suspicious.

---

4. Phase 1 Detail: Scoper (presented in Section 2, awaiting approval)

Full details in brainstorm conversation. Key points:

4.1 Role

Interactive partner that turns a vague opening question into a locked, schema-validated research brief. The brief is the goal — the deep-research prompt is composed later in Phase 2.

4.2 What makes this Scoper different — Challenger, not Documenter

APPROVED 2026-04-27 (Q2 of Section 2). Scoper is a Challenger, not a polite documenter. This is non-negotiable system-prompt behavior. User confirmation: "otherwise it is not even a scoper if it is not asking challenging questions."

Why this matters: - sample.txt's Discovery-OS breakthrough only happened because the user pushed back on Claude when it got myopic. Scoper inverts this — it pushes back on the user so the user doesn't have to be the only challenger in the room. - A Documenter Scoper inherits the user's initial framing. First drafts are almost always wrong; a polite Scoper writes down the wrongness and the downstream pipeline burns $20–50 in fan-out + an hour of reading a dossier that answered the wrong question. - Pushback is the cheapest quality gate — it happens during a single Opus conversation before any deep-research call fires.

System prompt language (locked, non-negotiable):

You are the Scoper. Your job is NOT to politely capture the user's intent.
Your job is to stress-test the framing before any deep research happens.

You MUST:
- Challenge vague premises ("better at X" → better by what measure?)
- Name assumptions the user hasn't justified
- Propose at least one counter-angle they haven't considered
- Flag when the user is narrowing the question prematurely
- Refuse to lock the brief if the question is still mushy

You are not rude. You are rigorous. The user explicitly asked for this —
they know that polite Scopers produce mediocre briefs.

Modeled on what Arijit did manually in sample.txt (pushing back on Claude when it got myopic — reversed here so Scoper pushes back on Arijit).

Accepted tradeoff: First few minutes of every Scoper conversation will feel like an interrogation. User explicitly opted in.

4.3 Execution model

APPROVED 2026-04-27 (Q1 of Section 2). Phase 1 runs in the orchestrator subprocess, NOT in the parent Claude Code session.

Why: - Compaction immunity — parent session can auto-compact mid-Scoper, losing brief nuance. Orchestrator has one job, one context, nothing to compact against. - Clean state ownership — orchestrator exclusively owns conversation_state.json, brief_draft.md, and lock_brief. Parent session never touches them. - Architectural consistency with Phases 2–4 — those MUST be detached subprocess (30–60 min runs, user walks away). Phase 1 in the same process model = one pipeline, one state-handoff mechanism. Inline Phase 1 = awkward split. - Resumability — orchestrator subprocess survives parent-session crashes. State on disk, recoverable. - Predictability (per Decision 8) — Anthropic SDK call uses a tightly-defined Scoper system prompt + tool set. Inline Scoper inherits the parent agent's full system prompt and skill catalog — extra non-determinism.

Mechanics: - /research <topic> Claude Code skill spawns the orchestrator as a detached subprocess - Skill is a thin pipe: stdin from user terminal → orchestrator; orchestrator stdout → user terminal - Cost: ~0.5 day extra in Week 1 for subprocess + stdio plumbing

# Pseudocode — actual implementation in Week 1
while not brief.locked:
    1. load conversation_state.json
    2. optional: load vault context if topic matches known project slug
    3. build prompt = system + history + draft
    4. response = anthropic.messages.create(
         model="claude-opus-4-7",
         system=SCOPER_SYSTEM_PROMPT,
         messages=[...conversation],
         tools=[web_search, web_fetch,
                update_brief_draft, lock_brief]
       )
    5. handle tool calls (web_search via httpx; update_brief_draft → atomic validated write; lock_brief → schema check)
    6. print scoper's turn to user
    7. read user's next turn from stdin
    8. append to conversation_state.json
    9. if turn_count % 5 == 0:
         compress oldest turns into summary via Haiku (explicit, deterministic, not LLM-decided)

4.4 Scoper's tools

Tool	Implementation	Purpose
web_search	httpx → Perplexity API or Exa	Sanity-check a claim during interview
web_fetch	httpx → readability parser	Load a URL user mentions
load_vault_context	Python file loader → returns relevant .md from ~/Library/.../ArijitOS-Brain/Projects//	Pull project context if topic matches known slug
update_brief_draft	Pydantic schema validation → atomic write	Amend the working brief
lock_brief	Schema completeness check → sha256 → state.json update	Finalize; immutable within the run

4.5 Stopping rule — deterministic, code-decided (APPROVED 2026-04-27, Q4)

The orchestrator code (NOT the LLM) decides when lock_brief() is allowed to succeed. Three gates, all must clear:

Gate 1 — Minimum turn floor. turn_count >= 3. Prevents Scoper from locking on turn 1 even if the opening message happens to fill all fields. Forces the Challenger Scoper (Q2) to actually push back at least once before locking.

Gate 2 — Schema completeness. ResearchBriefV1.model_validate(brief_draft) must pass. Every required field present, every constraint satisfied (question_refined ≥50 chars, context ≥100 chars, success_criteria ≥2 items, out_of_scope ≥1 item, archetype set + archetype_reasoning ≥20 chars, etc.). Pure Pydantic check.

Gate 3 — One of two trigger conditions: - (a) Explicit user lock command — user types "lock it" / "we're done" / equivalent, OR - (b) Code-defined saturation — pure orchestrator computation after each turn: saturation = (no required ResearchBriefV1 field changed value in last 2 turns) AND (no new entry added to open_questions in last 2 turns) AND (turn_count >= 5) The turn_count >= 5 clause prevents premature saturation firing.

Failure semantics: if lock_brief() is called and any gate fails, it returns a structured error to Claude explaining which gate (e.g., "Cannot lock: success_criteria has 1 item, minimum 2 required" or "Cannot lock: turn_count=2, minimum 3"). Conversation continues, brief stays unlocked.

Saturation handling: if Gate 3(b) fires, Scoper is prompted by code to propose locking to the user ("It looks like we've covered the ground — ready to lock?"). The user still has to either confirm explicitly OR the schema is re-validated and locked atomically.

Why this design (per Decision 8): When-to-stop is harness logic. LLM-decided locking is the #1 hallucinated-completion failure mode (cardinal rule #1) — Claude will optimistically claim "the brief is comprehensive and ready" while critical fields are mush. Code-gating makes lock literally impossible without the gates being real.

4.6 ResearchBriefV1 schema — LOCKED 2026-04-27 (Q5)

Final schema after Q5 review. 16 fields total: 9 user-provided (required, no defaults), 4 with defaults but locked in every brief, 3 truly optional.

User accepted all 5 amendments (A1–A5). User dropped all 4 Group 3 YAGNI candidates (user_preferences, vault_context_loaded, known_facts, open_questions).

from pydantic import BaseModel, Field
from enum import Enum
from typing import Literal
from datetime import datetime

# --- Supporting enums + types ---

class Archetype(str, Enum):
    synthesis = "synthesis"           # e.g., Discovery-OS — weave a framework
    exploratory = "exploratory"       # "what's happening in X space"
    comparison = "comparison"         # "X vs Y for use case Z"
    decision = "decision"             # "should we adopt X?"
    how_to = "how_to"                 # "how to build X"

class ConstraintType(str, Enum):
    deadline = "deadline"
    budget = "budget"
    audience = "audience"
    format = "format"
    length = "length"
    tone = "tone"
    other = "other"

class Constraint(BaseModel):
    type: ConstraintType
    value: str
    hard_or_soft: Literal["hard", "soft"] = "hard"

class PriorArt(BaseModel):
    path_or_url: str
    description: str

class EvidenceBar(str, Enum):
    strict = "strict"             # only 🟢 verified-source claims survive
    balanced = "balanced"         # 🟢 + 🟡 (practitioner-derived) survive
    exploratory = "exploratory"   # all tiers preserved with tags

class DeliverableShape(str, Enum):
    plan = "plan"                       # multi-section plan, like Discovery-OS-v1.md
    summary = "summary"                 # 1–2 page executive summary
    reference = "reference"             # reference card / cheat sheet
    decision_brief = "decision_brief"   # decision memo with recommendation
    deep_dive = "deep_dive"             # long-form essay / report
    outline = "outline"                 # structural outline only

# --- The brief ---

class ResearchBriefV1(BaseModel):
    # Identity / versioning
    version: str = "1.0.0"
    run_id: str
    created_at: datetime

    # Core research definition (user-provided, no defaults)
    question_refined: str = Field(min_length=50)
    context: str = Field(min_length=100)
    success_criteria: list[str] = Field(min_length=2)
    out_of_scope: list[str] = Field(min_length=1)

    # Phase 2 routing (user-provided, no defaults)
    archetype: Archetype
    archetype_reasoning: str = Field(min_length=20)

    # Phase 4 shaping (user-provided + defaults)
    target_audience: str = Field(min_length=10)
    deliverable_shape: DeliverableShape = DeliverableShape.plan
    evidence_bar: EvidenceBar = EvidenceBar.balanced

    # Operational caps
    budget_cap_usd: float = 50.0

    # Optional — situational
    constraints: list[Constraint] = []
    prior_art: list[PriorArt] = []
    deadline: datetime | None = None

4.6.1 Field-by-field rationale (Q5 amendments)

Field	Status	Rationale
version	kept	Schema versioning per CodingSOPs §7 forward-compat rule
run_id	kept	Unique slug for workspace + state.json
created_at	kept	Audit trail
question_refined	kept	The actual research question; Challenger Scoper produces this
context	kept	Background; Phase 4 synthesizer references this
success_criteria	kept (≥2)	Forces articulation of "good"; Phase 4 fact-checker uses to filter
out_of_scope	kept (≥1)	Prevents fan-out drift; Phase 2 critic enforces
archetype	kept	Phase 1→2 contract; Scoper proposes from conversation
archetype_reasoning	added (Q3 follow-up)	Provenance + V2 taxonomy learning loop
target_audience	A5 added	Required, min 10 chars. Phase 4 synthesizer uses to set voice/depth
deliverable_shape	A4 added	Default plan. Phase 4 picks template from this enum
evidence_bar	A3 added	Default balanced. Phase 4 fact-checker uses to decide what to cut/keep
budget_cap_usd	kept	Hard ceiling; Phase 3 fan-out halts if hit
constraints	A1 tightened	dict[str,str] → list[Constraint] with type enum + hard/soft
prior_art	A2 added	Files/links already known; prevents Phase 3 from re-discovering ground
deadline	kept	Optional; nullable

4.6.2 Fields DROPPED 2026-04-27 (Group 3 YAGNI)

User explicitly dropped these 4 after I flagged them as soft:

Field	Why dropped
user_preferences	Overlapped with evidence_bar + deliverable_shape. Was a dumping ground.
vault_context_loaded	Provenance value low; if vault context matters, it goes in prior_art
known_facts	Free-form, no clear consumer in Phase 2/3/4
open_questions	Bleeds into Phase 2's job (AAR critic surfaces these naturally)

If real usage shows we miss any of these, they come back in V2 with a justified consumer.

Archetype model — APPROVED 2026-04-27 (follow-up to Q3):

archetype is required, not optional. The user explicitly rejected the "drop it / make optional" path. Two reasons:

1. Explicit Phase 1 → Phase 2 contract. Without archetype, Phase 2's angle-generator must infer the research shape from raw text — that's LLM-in-the-harness, banned by Decision 8. With archetype, Phase 2 has a deterministic routing signal.
2. Consistent with Challenger Scoper (Q2). Letting archetype be optional means Scoper can punt on classifying the research. Soft Scoper. Q2 ruled this out.

Mechanism: 1. Mid-conversation, Scoper proposes the archetype based on the dialog: propose_archetype(value="synthesis", reasoning="user is unifying scattered insights into a single framework, similar to Discovery-OS pattern") 2. The proposal is shown to the user for confirmation/pushback in-conversation 3. lock_brief() requires both archetype and archetype_reasoning to be set — cannot skip 4. Phase 2's angle-generator reads archetype and routes its angle strategy accordingly 5. archetype_reasoning (≥20 chars) is preserved as provenance — auditable months later, and becomes the dataset for evolving the 5-archetype taxonomy into V2 if real-world patterns emerge that don't fit (e.g., forecasting, investigation, audit)

On the "is this overengineering?" check (asked and resolved): Ran the 5-question YAGNI framework against archetype. Initial reflex was "drop it from V1." User correctly rejected this — the right framing is that archetype is the explicit contract between Phase 1 and Phase 2, not speculation about future need. Reframed: Scoper proposes archetype based on the conversation it just had — it's an artifact of Scoper's reasoning, not a bucket the user picks blind. With that framing, archetype is load-bearing, not YAGNI.

4.7 Context management — APPROVED 2026-04-27 (Q6)

The Scoper subprocess is a Claude Code session like any other and inherits the global three-command persistence model (see vault System/ClaudeCodeSetup.md). Scoper differs from a normal session in one important way: it is a structured task being executed, not a free-form architectural conversation. There is no human turn-by-turn judgment about "this context is qualitatively important, keep it." The only thing that must survive is the brief_draft.md artifact (preserved verbatim) and recent conversational nuance feeding the next challenge round. That makes the global model's user-driven cadence the wrong tool here — Scoper needs a deterministic, code-decided trigger.

Trigger (whichever fires first): - Subprocess context crosses ~60% of the model window (read directly by orchestrator code), OR - Turn 20 as a floor

Rationale for context-size primary, turn-count fallback: turn count is a noisy proxy for context growth — a single turn that runs web_fetch on a long document blows past 5 short turns. Reading actual context size is more honest. Turn 20 exists as a floor so a low-signal long conversation still gets compacted eventually.

After the first trigger fires, recur every 8 turns (not every 5). Scoper conversations are short by design — the 3-gate stop rule (§4.5) pushes toward saturation fast. Most runs will never hit the recurring trigger; long runs hit it once or twice. We err toward fewer compactions, not more, because the conversational reasoning behind each field value lives only in turn history — aggressive compaction risks the next challenge round re-asking a question already answered, which would (correctly) make the user lose trust in the Scoper.

Compaction mechanics: - Summarizer: Haiku call (cheap, fast, narrow prompt). Flagged for revisit in Milestone 1 once Scoper runs end-to-end — Sonnet 4.6 may preserve nuance better at acceptable cost. - Preserved verbatim: last 10 turns + current brief_draft.md - Compressed: turns 1..N-10 into a running summary - Post-compaction validation: orchestrator code re-validates brief_draft.md against the Pydantic ResearchBriefV1 schema. If validation fails, abort the Scoper run with a structured error rather than silently continuing.

What this collapses to: trigger is code (context size + turn floor), compaction is LLM (narrow Haiku prompt), validation is code (Pydantic). Same three-layer discipline as the global persistence model — only the trigger source differs (deterministic here vs. user-driven globally), because Scoper has no human in the loop turn-by-turn.

4.8 Pending approval questions (Section 2 of brainstorm)

These are the open questions the user was about to answer when they asked for persistence. Resume action: ask these first.

1. ~~Scoper runs in orchestrator (not in parent Claude session) — OK?~~ RESOLVED 2026-04-27 — YES. See §4.3.
2. ~~Explicitly challenges the user, doesn't just document — OK?~~ RESOLVED 2026-04-27 — YES. Challenger Scoper, system-prompt locked. See §4.2.
3. ~~Tools are code-backed with schema validation, no LLM-autonomous action — OK?~~ RESOLVED 2026-04-27 — YES. Code-backed, Pydantic-gated, atomic writes, structured errors back to Claude on rejection. Schema genericity concern raised and addressed: domain-neutral fields, 5 archetypes (extensible via V2), 6 optional fields for situational variance. Open follow-up: archetype necessity — see Schema Open Question below.
4. ~~Stop rule is deterministic (min turns + schema completeness + explicit lock) — OK?~~ RESOLVED 2026-04-27 — YES. 3 gates, code-decided. See §4.5.
5. ~~ResearchBriefV1 schema covers what you need, or fields to add/remove?~~ RESOLVED 2026-04-27 — LOCKED. All 5 amendments accepted (A1 tighten constraints, A2 add prior_art, A3 add evidence_bar, A4 add deliverable_shape, A5 add target_audience). All 4 Group 3 fields dropped (user_preferences, vault_context_loaded, known_facts, open_questions). Final schema = 16 fields. See §4.6.
6. ~~Context compaction is code-decided every 5 turns via cheap Haiku call — OK?~~ RESOLVED 2026-04-27 — YES, with revised cadence. Deterministic code trigger (context-size primary at ~60% of model window, turn 20 as floor, recur every 8 turns thereafter). Haiku summarizer flagged for revisit in Milestone 1. Post-compaction Pydantic re-validation; abort on schema fail. See §4.7.
7. ~~Add pyright --strict to Python stack — yes or no?~~ RESOLVED 2026-04-27 — YES. Closed under Section 1 / Decision 10 amendment.

---

5. Phases 2–4 (not yet detailed in brainstorm)

Section 3 — AAR / AAR Planner — Decomposition CONFIRMED 2026-04-27 and AMENDED 2026-05-20 by the NVIDIA + Open Deep Research + STORM synthesis. AAR is no longer just a prompt generator. It is the research planning layer that produces angles, lightweight evidence checks, a strategic research plan, an outline seed, and vendor-ready research prompts.

Core sub-steps remain strictly sequenced, each running in an isolated process with file-gated Pydantic-validated atomic outputs:

1. angle_gen (Claude Sonnet 4.6) — decompose brief into N candidate research angles. Output: angles_raw.json (list of Angle objects).
2. critic (Claude Sonnet 4.6, critic system prompt) — score and prune angles against evidence_bar, deliverable_shape, target_audience; flag redundancy. Output: angles_critiqued.json (kept ranked + discarded with rationale, audit trail).
3. pre_research (Perplexity, parallel-per-angle) — cheap evidence sweep per angle to confirm fundability and surface entities/dates/terms for the prompt. Output: pre_research.json.
4. plan_compose (Claude Sonnet 4.6) — compose the strategic research plan and evidence-seeking outline seed. Outputs: research_plan.json, outline_seed.json.
5. prompt_compose (Claude Sonnet 4.6) — write the actual vendor/research-worker prompts (one per angle/evidence gap per vendor where appropriate). Output: research_prompts.json (list of ResearchPrompt).

File-gated sequencing: brief.json → angles_raw.json → angles_critiqued.json → pre_research.json → research_plan.json + outline_seed.json → research_prompts.json → Phase 3. Step N+1 cannot start until step N's output passes its Pydantic schema; validation failure aborts the run with structured error.

Open questions Q1–Q6 below to resolve (work through one at a time per brainstorm pattern).

Section 3 Q1 — Angle count: hybrid cap + budget-bounded — RESOLVED 2026-04-27

Decision (Option C + B1): - angle_gen generates 5–12 candidate angles. Floor 5 prevents under-decomposition; ceiling 12 prevents Sonnet from spiraling into noise. - critic keeps 3–10 angles, bounded by cost: kept_count × 4 vendors × avg_per_prompt_budget ≤ orchestrator_config.phase_3_max_usd. - If the cost ceiling forces kept_count < 3, the run aborts with a structured error: "budget too low for the brief's surface area." Silent under-coverage is the worst failure mode — fail loud. - Actual generated count and kept count get written to the artifact + state.json for audit.

Budget source (Option B1): orchestrator config / CLI flag. Not a brief field. The locked 16-field ResearchBriefV1 schema (Q5) is NOT touched. Budget is an environment/runtime concern: same brief, different days, different cost tolerances is a normal pattern. Storing budget in the brief would couple the artifact to a runtime decision and pollute the research contract. Orchestrator config also leaves room for per-vendor cost overrides later without schema churn.

Rationale for hybrid over hard caps or pure budget: real briefs vary from "compare 3 vendor APIs" (5 angles is overkill) to "design a discovery system across 6 dimensions" (5 angles starves it). Hard caps don't fit. Pure budget without a generation ceiling lets angle_gen produce 30 weakly-distinguished angles and burns Sonnet on critic-side pruning of noise. Hybrid keeps generation bounded AND adapts kept count to brief complexity within a cost ceiling.

Open follow-ups (NOT decided here, surfaced for future questions): - Should angle_gen system prompt include explicit non-overlap as a generation constraint, or do we leave overlap detection to critic? (Affects how high the upper bound feels in practice.) - Should the min_kept = 3 floor be archetype-specific? "Decision support" archetype may be fine with 3; "landscape scan" probably needs 5+. Archetype-keyed floor is a future amendment if early runs show the flat floor mis-fits.

Cross-phase decision — Multi-POV reasoning layer — RESOLVED 2026-05-14

Decision: ResearchModule includes multi-point-of-view reasoning in both Phase 2 AAR and Phase 4 Synthesis, with different jobs.

• Light POV in AAR: used during research planning to improve angle generation, avoid same-model consensus, surface blind spots, and pressure-test which questions deserve vendor fan-out.
• Heavy POV in Synthesis: used after vendor research is collected to interpret the evidence through multiple reasoning lenses before the final plan is written.

Rationale: the module should not merely summarize research outputs. It should force the evidence through structured disagreement before producing a confident final answer. A single synthesizer can collapse ambiguity into a clean narrative too early; multi-POV interpretation creates a deliberate "argument chamber" where the evidence is tested from several epistemic positions before a final recommendation is assembled.

Important design constraint: roles should be epistemic lenses, not cartoon personalities. "Always agrees" or "always works" is too theatrical and will produce predictable noise. The stronger design is role-bound reasoning:

Lens	Job
Builder / Advocate	Make the strongest case that the thesis or recommendation works.
Contrarian	Attack consensus, expose hidden assumptions, and ask what the other lenses are missing.
Failure Analyst / Pessimist	Map how the idea fails in practice, including adoption, incentives, evidence gaps, and implementation failure modes.
Operator / Implementer	Test rollout reality: cost, ownership, governance, maintenance, sequencing, and user behavior.
Methodical Expander	Surface second-order implications, adjacent opportunities, missing branches, and underexplored angles.
Evidence Judge	Separate verified evidence from inference, analogy, and narrative seduction. Preserve provenance discipline.

Implementation shape — APPROVED 2026-05-16: hybrid.

• AAR light POV: one structured multi-lens critique pass, likely inside critic or immediately after it. Purpose: improve angle selection, expose planning blind spots, and sharpen vendor prompts without turning AAR into a committee.
• Synthesis heavy POV: separate isolated, file-gated POV artifacts. Each lens reads the same evidence pack and writes its own structured interpretation. A later reconciler/evidence judge compares the lens outputs before final writing.

Why hybrid: in AAR, the goal is better planning, not maximum independence. A single structured lens pass is cheaper and enough to prevent same-model tunnel vision. In Synthesis, premature consensus is the larger risk, so the lenses need stronger isolation and auditable artifacts.

Section 3 Q2 — Pre-researcher parallelism: bounded concurrency — RESOLVED 2026-05-16

Decision: pre_research runs angles in parallel, because each kept angle is an independent lightweight evidence sweep. Parallelism is bounded, not unbounded.

• Initial default: max_concurrent_pre_research = 3
• Each angle gets retry/backoff via tenacity
• Each angle writes an isolated .tmp result, validates against PreResearchResult, then atomic-renames
• Step-level completion waits for all angle tasks to either pass validation or fail with structured errors
• The orchestrator halts the step if too many angles fail validation or return low fundability, rather than silently proceeding with a weak prompt set

Rationale: parallel-per-angle pre-research is the right shape because angles do not depend on each other. But unbounded fan-out creates rate-limit, cost, and noisy-failure risk. A concurrency cap gives most of the latency win while keeping control over provider pressure and trace readability.

Section 3 Q3 — Vendor/model policy + BYOK — RESOLVED 2026-05-16

Decision: model selection is configurable per sub-step, with one default configuration. Provider credentials use a BYOK model.

Default model profile: ResearchModule ships with a recommended default provider/model map so a user can run without designing a routing policy from scratch. The current design default remains:

Step	Default provider/model role
Scoper	Claude Opus-class model
AAR angle_gen	Claude Sonnet-class model
AAR critic	Claude Sonnet-class model, critic prompt
AAR pre_research	Perplexity/search-native model via REST
AAR prompt_compose	Claude Sonnet-class model
Fan-out	Perplexity, Claude Deep Research, OpenAI Deep Research, Gemini Deep Research
Synthesis	Claude Opus-class model by default, with configurable lens models

Configurability requirement: - Every phase/sub-step reads its provider/model from config, not hardcoded constants. - Callers can override any provider/model at runtime through CLI flags, config files, app/API request config, or skill wrapper parameters. - The default profile is convenience, not a lock-in. - Config supports multiple named profiles later (for example cheap, balanced, max_quality, local_eval), but V1 only needs one default profile plus overrides.

BYOK requirement: - ResearchModule does not ship or own provider keys. - Each user/app supplies its own keys for Anthropic, OpenAI, Gemini, Perplexity, or any enabled provider. - Key lookup happens through a SecretsProvider abstraction, not direct environment reads scattered through the code. - Supported first sources: environment variables and .env/.env.test for local development; app callers may inject secrets through their own secrets manager. - Missing keys fail fast at health check or before the dependent step starts. The orchestrator should never discover missing credentials after burning earlier-phase budget. - Logs, traces, state files, and errors must never print raw keys.

Rationale: fixed defaults make the system easy to start; configurable model routing keeps the engine reusable as models, costs, and quality tradeoffs change. BYOK is required for distribution: users and embedding apps must be able to bring their own provider accounts and cost controls.

Section 3 Q4 — Critic feedback loop: one revision max — RESOLVED 2026-05-17

Decision: the AAR critic can request one revision pass for weak-but-promising angles. After that revision, the critic must either keep or discard the angle. No second revision loop.

Flow:

angle_gen
  -> critic
      -> keep strong angles
      -> discard bad angles
      -> revise weak-but-promising angles once
  -> angle_gen revision pass
  -> critic re-check
      -> keep or discard
  -> pre_research

Guardrails: - Revision feedback is structured, not free-form: the critic must state the angle id, failure reason, required change, and success condition. - Revision writes a separate artifact, e.g. angles_revised.json, and validates before the critic re-check. - Re-check output is also file-gated and preserved for audit. - No open-ended iteration. After one revision pass, every angle is either kept or discarded.

Rationale: prune-only is too brittle because a useful angle may be poorly framed on first generation. Unlimited revision is too risky because it can spiral, burn tokens, and delay actual research. One bounded revision pass captures the quality benefit without compromising determinism.

Section 3 Q5 — Failure recovery: one angle-regeneration retry — RESOLVED 2026-05-19

Decision: if pre_research leaves fewer than 3 fundable angles, the orchestrator retries angle_gen once using the pre-research failure reasons. If fewer than 3 fundable angles still remain after the retry, the AAR phase halts with a structured insufficient_fundable_angles error. If 3 or more survive, the pipeline proceeds with the reduced set.

Flow:

pre_research
  -> fundable_count >= 3
      -> proceed to prompt_compose
  -> fundable_count < 3
      -> retry angle_gen once with failure reasons
      -> critic
      -> pre_research
      -> fundable_count >= 3
          -> proceed with reduced set
      -> fundable_count < 3
          -> halt: insufficient_fundable_angles

Guardrails: - Retry is one-time only. No open-ended recovery loop. - Retry prompt must include structured failure reasons from pre_research, not vague "try again" feedback. - Original failed angles and retry-generated angles are both preserved for audit. - If the run halts, the error includes: surviving fundable count, failed angle ids, failure categories, sources checked, and recommended user-facing next action.

Rationale: silently proceeding with too few fundable angles creates shallow research while looking successful. Immediate abort without retry is too brittle because angle generation may have framed otherwise valid lines of inquiry poorly. One recovery attempt gives the system a chance to self-correct while preserving deterministic bounds.

Section 3 Q6 — Expanded schemas and strict citation gate — IMPLEMENTED 2026-05-20

Decision: Q6 schema contracts are implemented in code as the Milestone 1 foundation. The governing rule is now hard-coded and tested: no source means the claim does not exist.

Implementation: - src/research_module/schemas.py defines ResearchBriefV1, shared references/enums, AAR Planner schemas, Research Supervisor / evidence schemas, and Synthesis schemas. - src/research_module/citations.py validates claim → evidence → source integrity and rejects unresolved chains. - src/research_module/artifacts.py enforces .tmp write, Pydantic validation, atomic rename, and sha256 metadata. - src/research_module/workspace.py creates the run workspace layout. - src/research_module/state.py defines minimal resumable top-level step state. - src/research_module/scoper.py provides the offline Scoper brief lock path that writes validated ResearchBriefV1 artifacts.

Strict citation semantics: - Every accepted Claim must include at least one EvidenceRef. - Every EvidenceRef must resolve to an EvidenceItem. - Every EvidenceItem must resolve to a SourceRecord. - A passing CitationAudit cannot contain invalid citations or unsupported claims. - LLM-generated prose is never evidence unless reduced into recorded source/evidence artifacts.

Verification: - uv run pytest -v — 28 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors.

Development status: development has started. Remaining Section 4–8 details are milestone-entry design gates, not blockers for the existing Milestone 1 foundation.

Milestone 1B — CLI, state persistence, config, and BYOK skeleton — IMPLEMENTED 2026-05-20

Decision: ResearchModule now has a working local Scoper-only CLI path. Every mode must obtain an explicit working directory before a run starts. In CLI mode, if --workspace-parent is omitted, the current working directory is proposed as the default and the user confirms with Enter or types an override path. This directory is the durable home for run artifacts, intermediate state, local config, and optional BYOK .env.local. This is still offline; it does not call live LLMs. The CLI exists to prove packaging, workspace creation, state.json persistence, resume semantics, and the Scoper artifact gate before the live Challenger Scoper is introduced.

Implementation: - pyproject.toml exposes the console script: uv run research "<topic>". - CLI prompts for Use this working directory for research artifacts/configs? [<cwd>] when --workspace-parent is omitted. - src/research_module/config.py defines ResearchModuleInput, RuntimeConfig, and deterministic run id generation. - src/research_module/state.py now includes StateStore, persisted state.json, atomic .tmp writes, and missing-state errors. - src/research_module/secrets.py defines SecretsProvider, EnvSecretsProvider, .env.local loading from the working directory, environment-variable override behavior, and redacted require() behavior for BYOK readiness. - src/research_module/cli.py creates/resumes a run workspace, writes the offline Scoper brief.json, marks Scoper complete, persists state, and reports the next incomplete step.

BYOK location: - Local users may place keys in <working-directory>/.env.local. - Supported key names start with ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, and PERPLEXITY_API_KEY. - Process environment variables override .env.local. - Secret values are never printed in health checks or errors.

Smoke verification: - uv run research "Design a strict citation research workflow" --workspace-parent /private/tmp/research-module-cli-smoke --run-id smoke-run-001 - Output: run=smoke-run-001 path=/private/tmp/research-module-cli-smoke/smoke-run-001 next=aar - Resume command with --resume-run-id smoke-run-001 also returns next=aar, proving completed Scoper runs are not re-run. - Prompt smoke: printf '/private/tmp/research-module-prompt-smoke\n' | uv run research "Design a strict citation research workflow" --run-id prompted-smoke-001 returns next=aar.

Full verification: - uv run pytest -v — 47 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors.

Historical next milestone: Milestone 1C replaced the deterministic offline Scoper placeholder with the live interactive Challenger Scoper subprocess.

Milestone 1C — Live Challenger Scoper foundation — IMPLEMENTED 2026-05-20

Decision: ResearchModule now runs the live Challenger Scoper by default from the CLI. The offline deterministic Scoper remains available behind --offline-scoper for tests and emergency no-key runs. The live Scoper keeps the locked architecture boundary: the orchestrator owns state, artifacts, tools, lock gates, source recording, and compaction; the model only proposes text and tool calls.

Implementation: - pyproject.toml now includes the Anthropic SDK. - src/research_module/live_scoper.py defines LiveScoperRunner, LiveScoperConfig, fakeable AnthropicClientProtocol, AnthropicMessagesClient, LiveScoperDependencies, conversation state, brief draft state, and Scoper tool handling. - src/research_module/cli.py defaults to live mode and uses --offline-scoper for the Milestone 1B deterministic path. - Live Scoper persists 00-scoper/conversation_state.json, 00-scoper/brief_draft.json, 00-scoper/source_registry.json, and locked 00-scoper/brief.json. - Tools implemented: update_brief_draft, lock_brief, web_search, web_fetch, and load_vault_context. - Perplexity web_search, URL fetches, and vault loads record SourceRecords before returning content to the model. - Lock requires minimum user turns, valid ResearchBriefV1, and explicit user lock or saturation. - Compaction triggers from context/turn thresholds, summarizes older turns with the configured Haiku model, preserves last 10 turns, and re-validates the draft.

Full verification: - uv run pytest -v — 56 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors.

Next milestone: Milestone 2 AAR Planner.

UX architecture gate — CLI + skill first — IMPLEMENTED 2026-05-21

Decision: ResearchModule's first user experience is CLI + skill wrapper, optimized for a power researcher. The visual app/dashboard is intentionally deferred until the CLI/skill artifact and status contracts prove themselves through real runs. UX is not cosmetic here; it is the control surface for a long-running, file-gated research engine.

Implementation: - Added docs/ResearchModule-UX-Spec.md as the UX contract. - Added CLI commands: status, runs, resume, show brief, show sources, and doctor. - status reports run id, human-readable phase, next action, primary artifact, and path. - runs lists local run workspaces and phases. - show brief and show sources expose recorded artifacts without hiding provenance. - doctor checks key/config readiness without printing secret values. - resume gives a clear next action for complete and incomplete Scoper states.

Skill wrapper contract: - Ask for working directory when absent. - Explain that artifacts, interim state, config, and optional .env.local live there. - Invoke the same core engine, not a separate prompt-only flow. - Summarize status and artifact paths after each step. - Use the same phase labels and next-action language as CLI.

Full verification: - uv run pytest -v — 63 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors.

Historical next milestone: Milestone 2 AAR Planner is now implemented.

Milestone 2 — AAR Planner foundation — IMPLEMENTED 2026-05-21

Decision: AAR is now an executable planning phase after Scoper, not only a designed future phase. The CLI command research continue --workspace-parent <dir> --run-id <run_id> runs AAR when next=aar, writes file-gated planning artifacts, records pre-research sources in the shared dossier registry, and advances state.json to next=fanout only after research_prompts.json validates.

Implementation: - Added aggregate contracts: AnglesRaw, AnglesCritiqued, PreResearchReport, ResearchPrompts, and AARFailureReport. - Added src/research_module/aar.py with live-first injectable AAR runner, Anthropic JSON planner adapter, Perplexity search adapter, source recording, one bounded retry path, and structured failure writes. - Added research continue, research show aar, AAR-aware status, and dossier-first show sources behavior in the CLI. - AAR writes 01-aar/angles_raw.json, 01-aar/angles_critiqued.json, per-angle pre-research artifacts, aggregate pre_research.json, research_plan.json, outline_seed.json, and research_prompts.json. - Pre-research sources are written to 02-dossier/source_registry.json before they can support a PreResearchResult. - Hard failures write 01-aar/aar_failure.json and mark AAR failed in state.json.

Verification: - uv run pytest -v — 84 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors.

Historical next milestone: Research Supervisor / Fan-out 3A is now implemented.

Milestone 3A + 4A — Fan-out to Basic Synthesis — IMPLEMENTED 2026-05-21

Decision: Build the fastest usable cited-report path before multi-provider triangulation or heavy multi-POV Synthesis:

Scoper -> AAR Planner -> Fan-out Dossier -> Basic Synthesis Report

Implementation: - Added Fan-out contracts for task sets, provider calls, raw provider outputs, evidence item sets, compressed note sets, run reports, failure reports, and failure categories. - Added src/research_module/fanout.py with ResearchProviderProtocol, ProviderResult, PerplexitySonarProvider, FanoutSupervisor, and FanoutConfig. - Fan-out runs a canary task first, writes raw provider output before compression, records sources before evidence items, writes compressed notes with source/evidence refs, and gates completion on coverage for every fundable AAR angle. - Added Basic Synthesis contracts for claim sets, final outline, report draft, citation audit report, synthesis run report, and synthesis failure report. - Added src/research_module/synthesis.py with deterministic claim extraction from compressed notes, final outline from AAR outline_seed.json, basic cited report.md, and citation audit over source/evidence/claim chains. - CLI research continue now advances through next=fanout and next=synthesis; research show dossier and research show report expose counts and artifact paths.

Verification: - uv run pytest -v — 109 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors, 0 warnings, 0 informations.

Historical next milestone: Milestone 4B heavy multi-POV Synthesis is now implemented.

Milestone 4B — Heavy Multi-POV Synthesis Studio — IMPLEMENTED 2026-05-21

Decision: 4B is now the default Synthesis path. 4A Basic Synthesis remains available internally as a fallback/test utility, but research continue at next=synthesis runs isolated POV interpretation, reconciliation, report draft writing, and citation audit.

Implementation: - Added MultiPOVSynthesisRunner, SynthesisModelClientProtocol, SynthesisModelResponse, AnthropicSynthesisModelClient, and MultiPOVSynthesisDependencies. - Added PerspectiveInterpretationSet and ReconciliationReportV1 schemas. Extended synthesis failure/report schemas with model failure categories, POV counts, unresolved conflict counts, and synthesis_mode. - Synthesis now writes 03-synthesis/perspectives/<lens>.json, 03-synthesis/perspectives.json, 03-synthesis/reconciliation_report.json, 03-synthesis/report_draft.json, report.md, citation_audit.json, and synthesis_report.json. - Unresolved POV conflicts warn but do not block completion; only source/evidence/claim/citation failures block final completion. - CLI show report now surfaces POV lens count and unresolved conflict count.

Verification: - uv run pytest -q — 119 passed. - uv run ruff check . — passed. - uv run ruff format --check . — passed. - uv run pyright — 0 errors, 0 warnings, 0 informations.

Next milestone: Milestone 3B multi-provider Fan-out or Milestone 4C report polish.

Intelligence Research OS product layer — ACCEPTED 2026-05-21

Decision: The higher-level product concept is renamed to Intelligence Research OS. ResearchModule remains the core engine and Python package. Intelligence Research OS is the use-case layer built on top of ResearchModule for competitive intelligence, market pulse, opportunity discovery, content research, account research, customer voice, tool radar, and workflow-callable intelligence missions.

Boundary: - ResearchModule = Scoper -> AAR Planner -> Fan-out -> Synthesis. - Intelligence Research OS = missions, source packs, signals, deltas, opportunity briefs, battlecards, content workbenches, and output packs. - Scheduling is out of scope for the engine. Cron, Codex automations, GitHub Actions, Airflow, Temporal, n8n, Zapier, and app schedulers can invoke the engine.

Roadmap additions: - Milestone 3A: Research Supervisor / Fan-out. - Milestone 3B: Synthesis Studio. - Milestone 4: Intelligence Layer with MissionSpec, WatchSpec, SourcePack, Signal, SignalCluster, DeltaReport, OpportunityBrief, and OutputPack. - Milestone 5: Intelligence UX with Mission Control, Source Radar, Signal Inbox, Evidence Board, Opportunity Map, Competitor Battlecard, and Content Workbench. - Milestone 6: Workflow / Agent Integration with CLI/API/skill callable missions and cron-compatible commands.

Rationale: Competitive intelligence, social listening, content research, trend monitoring, and market intelligence are already solved in pieces by existing products. The opportunity is to compose these ideas into a tool chest where the whole is stronger than the parts: source-backed deep research, multi-POV synthesis, signal interpretation, delta detection, and role-specific outputs under one evidence discipline.

Section 4 — Fan-out / Research Supervisor — AMENDED 2026-05-20. Fan-out is not a naive four-provider blast. It becomes a bounded Research Supervisor + Worker layer.

Required shape: - Supervisor reads research_plan.json, outline_seed.json, and research_prompts.json. - Supervisor spawns bounded research tasks by angle, report section, or evidence gap. - Workers route tasks to Perplexity REST, Anthropic, OpenAI, Gemini, or future adapters. - Each worker preserves raw outputs, writes compressed citation-preserving notes, and updates source_registry.json. - Tool/vendor failures are isolated; one worker failure does not poison the whole run unless hard thresholds are crossed. - Canary-first circuit breaker still applies before expensive provider expansion.

Details still TBD: task schema, adapter contracts, source registry schema, compressed notes schema, failure thresholds, and canary criteria.

Section 5 — Synthesis / Synthesis Studio — AMENDED 2026-05-20. Synthesis is outline-first, multi-POV, and evidence-constrained before final writing.

Required stages: 1. Extract claims from compressed notes and raw dossier into claims.json. 2. Build outline_final.json from outline_seed.json, claims, and evidence coverage. 3. Run isolated heavy POV lenses over the same evidence pack: Builder, Contrarian, Failure Analyst, Operator, Methodical Expander, Evidence Judge. 4. Reconcile contradictions and unresolved disputes into reconciliation_report.json. 5. Write the final plan/report from the final outline, claims, evidence, and POV outputs. 6. Verify and sanitize citations against source_registry.json; write citation_audit.json.

Final output is incomplete until citation verification passes. Invalid or untraceable citations are removed or downgraded with logged reasons.

Section 6 — State / workspace / resumability — state.json schema, run_id slug rules, atomic write patterns, resume semantics, cleanup on abort. Details TBD.

Section 7 — Hard-exception interrupts — CLI/skill notification shape is now locked in the UX spec: every interrupt reports what happened, why it matters, default recommendation, options, supporting artifact, and retry safety. Backend trigger implementation remains TBD.

Section 8 — Testing strategy — per Manifesto TestingSOPs (3-layer: unit with mocks, integration with real adapters but cheap models, e2e with real pipeline on a small real run). TDD approach. Details TBD.

---

6. Decision Log (summary table)

#	Decision	Rationale source
1	Pipeline: Scoper → AAR → Fan-out → Synthesis	User description + sample.txt as reference
2	AAR always on	User explicit: "the AAR step is a must and should be always on"
3	AAR = 4 sub-steps (angle-gen, critic, pre-research, prompt-composer)	Option D of brainstorm. Added 2d after user caught sequencing bug
4	UX: Scoper interactive, rest async, hard-exception interrupts only	"B + narrow C" hybrid; user approved
5	Deliverable: plan + dossier	Option B; preserves provenance per cardinal rule #5
6	Packaging/interface boundary: core Python research engine with thin entrypoints for CLI, Codex/Claude skill wrapper, importable package, and future App/API boundary. Supersedes earlier "skill first, extract later" framing.	User approved 2026-05-16. ResearchModule must work standalone, as CLI, embedded in skills, and callable from apps; the engine is the product, entrypoints are adapters.
7	Approach 3 (paper-scale), incremental in 3 weeks	User overturned my Approach 2 recommendation
8	Pure code orchestrator, vendor-native SDKs, no LLM in harness	User demand: predictable, repeatable
9	Python 3.12+	Single ecosystem with PRISM/LENS/shared-py/core
10	Mandatory production stack (pydantic v2, ruff, pytest+pytest-asyncio, httpx, structlog, tenacity, uv, pyright --strict)	User-mandated; "Python is production-ready only with these". pyright --strict added 2026-04-27.
11	Scoper context compaction: deterministic code trigger (~60% context-size primary, turn 20 floor, recur every 8 turns), Haiku summarizer, last 10 turns + brief preserved verbatim, post-compact Pydantic re-validation	Section 2 Q6 closed 2026-04-27. Scoper is a structured task, not a free-form brainstorm — the global model's user-driven cadence doesn't apply. See §4.7.
12	AAR angle count: hybrid (5–12 generated by angle_gen, 3–10 kept by critic) bounded by orchestrator-config budget ceiling. Abort if kept_count < 3. Budget NOT in brief schema.	Section 3 Q1 closed 2026-04-27. Hybrid adapts to brief complexity; orchestrator-config budget keeps the locked 16-field brief untouched. See §5 Section 3 Q1.
13	Multi-POV reasoning layer applies in both AAR and Synthesis: light POV in AAR to improve research planning; heavy POV in Synthesis to interpret collected evidence before final plan writing. Roles are epistemic lenses, not personalities.	User request 2026-05-14. Prevents premature single-synthesizer consensus and forces structured disagreement before recommendation.
14	Multi-POV implementation shape: hybrid. AAR uses one structured multi-lens critique pass; Synthesis uses separate isolated, file-gated POV artifacts, reconciled before final writing.	User approved 2026-05-16. Keeps AAR cheap and planning-focused while giving Synthesis real disagreement and auditability.
15	AAR pre-research runs parallel-per-angle with bounded concurrency. Initial default max_concurrent_pre_research = 3; per-angle retry/backoff; per-angle validated atomic artifacts; halt if too many angles fail or are unfundable.	User approved 2026-05-16. Angles are independent, but provider pressure, cost, and failure readability require backpressure.
16	Vendor/model policy is configurable per sub-step with one default profile. ResearchModule uses BYOK: users/apps supply provider keys through a SecretsProvider; missing keys fail fast; secrets never appear in logs/state/errors.	User approved 2026-05-16. Defaults make the system easy to start, configurability avoids model lock-in, and BYOK is required for distribution and app embedding.
17	AAR critic feedback loop allows one revision pass for weak-but-promising angles. After revision, critic must keep or discard; no second loop. Revision and re-check artifacts are file-gated and preserved.	User approved 2026-05-17. Prevents prune-only brittleness without allowing open-ended iteration or token spiral.
18	AAR failure recovery: if pre-research leaves fewer than 3 fundable angles, retry angle generation once using failure reasons. If fewer than 3 still survive, halt with insufficient_fundable_angles; otherwise proceed with reduced set.	User approved 2026-05-19. Prevents shallow successful-looking research while allowing one bounded self-correction.
19	Architecture synthesis from NVIDIA Deep Researcher + Open Deep Research + STORM: AAR becomes an AAR Planner with research_plan.json and outline_seed.json; Fan-out becomes a bounded Research Supervisor + Worker layer; Source Registry/Evidence Store become first-class; Synthesis becomes outline-first, multi-POV, and citation-verified. Reuse patterns, not runtime frameworks, in V1.	User approved proceeding 2026-05-20. NVIDIA contributes production controls and citation verification; Open Deep Research contributes supervisor/worker graph mechanics and compressed notes; STORM contributes perspective-guided question asking and outline-first synthesis.
20	Q6 expanded schemas and strict citation gate implemented as Milestone 1 foundation. Unsupported claims are rejected; claim → evidence → source chains must resolve; passing citation audits cannot contain invalid citations or unsupported claims.	User explicitly required: "no citation is equal to it does not exist." Implemented 2026-05-20 with Pydantic v2 schemas, artifact gates, citation validator, workspace/state helpers, offline Scoper brief lock path, and 28 passing tests.
21	Milestone 1B implemented: uv run research "<topic>" local CLI, ResearchModuleInput, RuntimeConfig, StateStore, persisted state.json, resume behavior, and EnvSecretsProvider BYOK skeleton. CLI proposes current working directory when workspace is omitted; Enter confirms cwd, typed path overrides.	Establishes standalone CLI and resumability before live LLM Scoper. Verified 2026-05-20 with 47 tests, ruff, pyright, CLI smoke/resume smoke, and cwd-confirm smoke.
22	Milestone 1C implemented: live-by-default Challenger Scoper with Anthropic SDK adapter, persisted conversation state, brief draft, source registry, full Scoper tool surface, deterministic lock gates, compaction, and --offline-scoper fallback.	Establishes the usable live Scoper foundation. Verified 2026-05-20 with 56 tests, ruff, pyright, and fake-client CLI coverage.
23	Working directory is explicit in all modes. CLI prompts when omitted; core input requires workspace_parent; local BYOK keys live in <working-directory>/.env.local; environment variables override file values.	User clarified that skill/CLI/tool modes should ask where to store deep research output, interim status, and config, and asked where keys should be added. Implemented 2026-05-20 with 45 tests and prompt smoke.
24	UX architecture gate implemented: CLI + skill wrapper first, optimized for a power researcher; app/dashboard deferred. CLI now has status, runs, resume, show brief, show sources, and doctor commands.	User asked what the tool UX should be before AAR. Locks the user-facing control surface before AAR/Fan-out multiply artifacts and failure modes. Verified 2026-05-21 with 63 tests, ruff, pyright.
25	Milestone 2 AAR Planner implemented: research continue runs AAR after Scoper; aggregate AAR artifacts validate through Pydantic; pre-research sources are recorded in 02-dossier/source_registry.json; success advances to next=fanout; failures write aar_failure.json.	User approved the Milestone 2 AAR Planner implementation plan. Verified 2026-05-21 with 84 tests, ruff, format check, and pyright strict.
26	Higher-level product renamed to Intelligence Research OS. ResearchModule remains the core engine/package; Intelligence Research OS becomes the mission/use-case layer with source packs, signals, deltas, opportunity briefs, battlecards, content workbenches, and workflow-callable outputs. Scheduling is external orchestration, not an engine feature.	User clarified that scheduling is commodity and the product value is the intelligence layer. Roadmap and vault docs updated 2026-05-21.
27	Milestone 3A Fan-out Supervisor implemented with Perplexity Sonar Pro first: canary-first execution, cost cap, raw outputs, source registry, evidence items, compressed notes, coverage gate, structured failure reports, research continue, and research show dossier.	User approved building the fastest path from planned research to a usable cited report. Verified 2026-05-21 with 109 tests, ruff, format check, and pyright strict.
28	Milestone 4A Basic Synthesis implemented: deterministic claims, final outline, basic cited markdown report, strict citation audit, synthesis run/failure artifacts, research continue, and research show report. Heavy multi-POV Synthesis remains 4B.	Keeps the end-to-end CLI path useful and auditable before adding expensive POV/report-polish complexity. Verified 2026-05-21 with 109 tests, ruff, format check, and pyright strict.
29	Milestone 4B Heavy Multi-POV Synthesis Studio implemented as the default synthesis path: six isolated POV lenses, aggregate perspectives, reconciliation report, report draft, final cited report, strict citation audit, and POV/conflict counts in show report.	User approved 4B as default, non-interactive, warning-only on unresolved conceptual conflicts. Verified 2026-05-21 with 119 tests, ruff, format check, and pyright strict.
30	Intelligence Research OS 5A/5B implemented: Competitive Intel proof gate, GPT Image 2 UX prompt contract, mission-layer schemas, mission service, and research mission create/run/status/show output CLI foundation.	Competitive Intelligence is the first executable vertical because it stress-tests missions, source packs, signals, deltas, evidence, battlecards, and output packs. Scheduling remains external.

---

7. Open Questions / Next Session Items

1. Milestone 3B — Multi-provider Fan-out — add OpenAI, Anthropic, Gemini, source triangulation, richer retries, provider-specific cost accounting, and live integration tests.
2. Milestone 4C — Report polish — premium final report template, richer contradiction handling, and editorial report shaping beyond the current multi-POV foundation.
3. Milestone 5C — Competitive Intel Vertical — source-backed signal classification, battlecard/digest generation, and CI output packs.
4. Milestone 5D — Delta Memory — first-run baseline and repeated-run comparison for mission deltas.
5. Milestone 6 — Intelligence UX — generate and validate Mission Control, Source Radar, Signal Inbox, Evidence Board, Opportunity Map, Competitor Battlecard, and Content Workbench.
6. Section 7 — Hard-exception interrupts — implement the backend triggers using the CLI/skill UX shape locked in docs/ResearchModule-UX-Spec.md.

---

8. Reference Artifacts

Path	What	Use during resume
/Users/arijitchowdhury/AI-Development/Research/sample.txt	1278-line manual conversation producing Discovery-OS research prompt	THE worked example — Scoper's conversational pattern should recreate this
/Users/arijitchowdhury/AI-Development/Discovery/Discovery-OS-v1.md	1220-line final synthesized plan	THE quality bar for Synthesis output
https://alignment.anthropic.com/2026/automated-w2s-researcher/	Anthropic AAR paper	THE inspiration for Phase 2 AAR architecture
~/Library/.../ArijitOS-Brain/Architecture/Manifesto.md	Full system Manifesto	Cardinal rules, module contract, failure philosophy, extraction strategy
~/Library/.../ArijitOS-Brain/Standards/*.md	Coding/Testing/Folder/Writing SOPs	Standards to apply during implementation

---

9. Canonical Test Topics

These topics are used to validate ResearchModule behavior before and during implementation.

Test Topic 1 — Discovery OS / Algolia discovery methodology

Role: golden-path regression topic.

Prompt family: design a data-backed discovery methodology for Algolia commercial teams, using PRISM-style pre-call intelligence to turn discovery from question-led interrogation into value-for-information exchange.

Why this topic: this is the original manual reference workflow. sample.txt shows the human scoping journey; Discovery-OS-v1.md shows the expected output quality. ResearchModule should eventually reproduce or improve this path.

What it tests: - Scoper challenge behavior - AAR angle generation around sales methodology, buyer psychology, PRISM translation, competitive narrative, rollout, and measurement - Multi-vendor research fan-out - Synthesis quality against an existing quality bar - Evidence-tier discipline

Test Topic 2 — Technology-guided human evolution

Role: complex/adversarial multi-disciplinary topic.

Prompt family: human biological evolution took enormous time, while technological evolution has compressed change into centuries and now AI compresses it further. Will future human evolution be guided more by technology than biology? Where are we today, where are we heading, and how should parents prepare children for the world they will grow up in?

Why this topic: it is broad, philosophical, scientific, cultural, medical, educational, religious, mythological, and speculative at once. It is exactly the kind of subject where a single synthesizer may become prematurely confident or narratively seductive.

Expected angle families: - Evolutionary biology and gene-culture coevolution - AI and technological acceleration - Child development, education, parenting, and cognitive adaptation - Medical and neurological research - Philosophy of technology and human purpose - Religious, mythological, and civilizational teachings about human transformation - Contrarian view: technology changes tools and incentives, but not human nature as quickly as the premise suggests - Failure/pessimist view: adaptation gap, attention collapse, inequality, dependency, institutional lag - Builder/optimist view: augmentation, expanded agency, new forms of learning and creativity

What it tests: - Scoper's ability to narrow an enormous question without killing its richness - AAR's ability to decompose into fundable research angles - Contrarian and POV-lens value - Evidence Judge discipline across science, philosophy, and speculation - Synthesis of verified research, practitioner thought, historical analogy, and philosophical reasoning without flattening uncertainty

---

10. Related

• Spec — the contract (see companion file)
• Manifesto — system-wide rules this module inherits
• CodingSOPs — coding discipline
• TestingSOPs — TDD, 3-layer tests, mock strategy