Market-intelligence production · agentic research · publication control
Deep research
A production system for turning a market-study contract into a defensible, evidence-bearing report.Deep research powers Mordor Intelligence report production. It coordinates approved internal market data, external evidence, agentic research and drafting, editorial review, and deterministic publishability gates so a report can scale across regions and segments without losing the chain of support behind its claims.
- Role
- Product owner · technical architect · research engineering
- Period
- Two years of production development at Mordor Intelligence
The problem, users, and product decisions.
I defined the product around a report contract, not a blank prompt. The operational outcome was a repeatable way for methodology owners, analysts, editors, reviewers, and publishing teams to produce a market study while preserving approved numbers, source lineage, structural completeness, and explicit human judgment.
A market report is a compound product: market size, forecast, segmentation, regional logic, company context, regulation, developments, prose, charts, and citations must agree with one another. Scaling only the writing step produces faster inconsistency, not reliable research.
The product therefore had to coordinate two truths at once: live IW data establishes the approved quantitative and structural contract; external sources provide the evidence needed to explain and contextualise it. The system’s job is to keep those truths legible through research, drafting, review, and publication.
Who uses it and what they need.
Methodology owners
Define the valid report structure, approved internal metrics, segmentation, forecast frame, and quality rules.
Research analysts
Investigate markets, accept or reject evidence, resolve contradictions, and add domain judgment.
Editors
Review narrative clarity, scope, repetition, citation placement, and section-level coherence.
Quality reviewers
Inspect unsupported claims, stale metrics, malformed citations, missing sections, and contract violations.
Publishing teams
Receive only an artifact whose required checks, approvals, and evidence record are complete.
Downstream readers
Use market size, growth, segmentation, competition, regulation, and developments with confidence about provenance.
What Deep research does—and does not do.
- 01
Live IW data defines the quantitative and structural contract; generated prose cannot silently override it.
- 02
External sources enter as evidence candidates and remain inspectable; a retrieved page is not automatically accepted evidence.
- 03
Agents may research, extract, compare, and draft. Deterministic rules and authorised reviewers decide whether the artifact may proceed.
- 04
The Research Mapping Workbench is a supporting operational interface, not the entire Deep research system.
- 05
Radar competitor intelligence extends the research workbench with publication, gap, pricing, TOC, and movement signals; it remains distinct from report generation itself.
Key product decisions.
Contract before generation
The brief, section schema, approved data, methodology, and required outputs are resolved before agents draft.
Evidence at field level
Claims and metrics retain source identity, timestamps, acceptance state, and the section or field they support.
Separate semantic and deterministic checks
Models can challenge meaning and contradiction; code checks schemas, required sections, citation form, allowed values, and publication state.
Publishability is a system state
A fluent document is not deliverable until required evidence, validation, review, and approval contracts are satisfied.
The report moves through seven accountable transformations.
Each stage produces a typed artifact for the next stage. That makes partial failure recoverable and lets reviewers identify whether a defect began in the contract, the evidence, the reasoning, or the final composition.
- R1MethodologyContract
Resolve brief, scope, section schema, segmentation, forecast frame, and live IW data.
→ - R2OrchestratorPlan
Decompose the study into research questions, section jobs, source needs, and dependency order.
→ - R3Research agentsAcquire
Collect source candidates with identity, retrieval time, scope, and raw evidence.
→ - R4Analyst + validatorsAdjudicate
Resolve entities, compare claims, reject weak evidence, and preserve contradictions that need judgment.
→ - R5Writing agentsCompose
Transform accepted evidence and approved data into section drafts constrained by the contract.
→ - R6QA + editorGate
Check structure, numbers, citations, staleness, coverage, unsupported claims, and semantic coherence.
→ - R7PublishingPublish
Release the approved artifact with its evidence record, version, and audit history.
The main parts of Deep research.
Core Deep research subsystem
Report Contract
Methodology owners · research leads · publishingTurn the brief, approved market data, segmentation, methodology, and section requirements into a versioned definition of done.
What it does
This is where the product decides what “correct” means for a particular study. Without it, every downstream agent is optimising for plausible prose instead of the same report.
How it works
- 01
Resolve report identity, scope, geography, segments, forecast horizon, and required sections.
- 02
Bind the current approved IW dataset and methodology version.
- 03
Emit typed section contracts and required validation rules.
- 04
Preserve the contract version with every downstream artifact.
Safety checks
- Generated text cannot mutate approved inputs.
- A contract change invalidates only the dependent work that must be recomputed.
- Required outputs remain machine-checkable.
Core Deep research subsystem
Evidence Spine
Research analysts · reviewers · editorsAcquire, identify, classify, and retain the source material supporting each field, metric, and narrative claim.
What it does
The evidence spine makes research reviewable. It preserves the difference between “the system found this page” and “an authorised workflow accepted this source for this claim.”
How it works
- 01
Acquire internal and external source candidates.
- 02
Record source identity, retrieval time, coverage, and raw extraction.
- 03
Resolve entities, dates, units, and scope.
- 04
Attach accepted evidence to the field or claim it supports.
- 05
Carry rejected and contradictory evidence into review history rather than silently deleting it.
Safety checks
- Source availability does not equal acceptance.
- Every material claim retains a path to evidence.
- Contradictions become review work, not model averaging.
Core Deep research subsystem
Agentic Composition
Research engineering · analysts · editorsRun bounded research and drafting tasks that convert approved data and accepted evidence into coherent report sections.
What it does
Agents create leverage by working in parallel across regions, segments, and section types. The product value comes from their boundaries: consistent contracts, inspectable inputs, and outputs that can be challenged.
How it works
- 01
Decompose the report into typed section jobs.
- 02
Select the required evidence and approved quantitative context.
- 03
Execute specialised extraction, comparison, mapping, and writing tasks.
- 04
Validate the returned schema before storing a versioned draft.
- 05
Route low-confidence or contradictory results to human adjudication.
Safety checks
- Prompts do not own workflow state.
- Model output is untrusted until validated.
- Every draft records the contract and evidence versions used.
Quality-control subsystem
Publishability Gate
Quality reviewers · editors · publishingDecide whether the assembled report is structurally complete, numerically aligned, properly cited, and safe to release.
What it does
The gate turns quality from a final heroic reading into observable system behaviour. Human judgment remains central, but the system ensures reviewers see the failures that software can detect consistently.
How it works
- 01
Run section and artifact schema checks.
- 02
Compare numbers and units against approved report data.
- 03
Inspect citation presence, placement, and source state.
- 04
Run semantic checks for contradiction, repetition, coverage, and unsupported assertion.
- 05
Require the correct review and approval states before publication.
Safety checks
- Fluency never overrides a failed gate.
- Unknown and incomplete states remain visible.
- Publication preserves validation and approval history.
Supporting Deep research product
Research Mapping Workbench
Research · strategy · internal report operationsMap competitor research titles against Mordor’s report database through an inspectable matching workflow.
What it does
The workbench is a focused decision surface within the wider Deep research system. It helps a user evaluate similarity and gaps without pretending that a vector score alone is a publishing decision.
How it works
- 01
Next.js workbench submits structured mapping work.
- 02
FastAPI owns matching and orchestration logic.
- 03
Supabase stores identity, reports, jobs, files, and vector data.
- 04
OpenAI embeddings place comparable titles in a shared semantic space.
- 05
Typed match results return to an analyst for inspection.
Safety checks
- Matching constants and service boundaries are explicit.
- Changed checksums trigger new embedding work.
- A similarity result remains evidence for a decision, not the decision itself.
Competitor-intelligence extension to the research workbench
Radar
Research · editorial · marketing · sales · strategyTurn competitor publications into report gaps, velocity, pricing, TOC depth, narrative, and emerging-movement intelligence.
What it does
Radar begins with the question each team must answer: what changed, how does it compare with Mordor’s catalogue, and what action should follow? It is an intelligence terminal, not another newsletter feed.
How it works
- 01
Per-firm adapters discover reports through sitemap, HTML listing, search, or RSS strategies.
- 02
A two-stage sync discovers cheaply, then enriches only new or changed records.
- 03
Checksums avoid repeated work and embeddings remain compatible with the internal report vector space.
- 04
Deterministic SQL and vector comparison serve gaps and clustering; bounded models summarise TOC differences or strategic movement.
- 05
Per-firm sync history isolates failures and retains source URL and timestamp lineage.
Safety checks
- One firm failure does not block the rest.
- Acquisition strategy is replaceable per firm.
- Briefs remain traceable to source signals.
- Unchanged records are not re-embedded.
How the system is built, controlled, and recovered when something fails.
I designed the pipeline as an orchestration system around models. Typed inputs and durable job state establish what work exists; evidence services preserve what was found; agents perform bounded transformations; validators and approval gates decide which outputs may become report material.
- 01Report contract↓
Brief, section schema, approved IW data, methodology, geography, segmentation, forecast horizon, and publishing requirements.
- 02Orchestration↓
Dependency graph, section jobs, state transitions, queues, retries, idempotency keys, and correlation across a report run.
- 03Evidence acquisition↓
Internal data reads and external retrieval with source identity, timestamps, extraction boundaries, and acceptance state.
- 04Agentic transformation↓
Specialised research, comparison, extraction, mapping, and drafting tasks operating on bounded inputs and typed outputs.
- 05Adjudication↓
Entity resolution, contradiction handling, semantic checks, taxonomy alignment, and human review where evidence is ambiguous.
- 06Deterministic validation↓
Schema completeness, allowed values, number consistency, required sections, citation form, freshness, and publishability rules.
- 07Artifact and lineage
Versioned report sections, evidence links, validation outcomes, approval state, final assembly, and readback.
Rules every part of the system must follow.
Typed stage boundaries
Every agent receives a defined input and returns a schema-validated result; free-form model text never becomes implicit pipeline state.
Accepted evidence only
Retrieval and acceptance are separate states. A source can be available yet still fail recency, authority, scope, or contradiction review.
Numbers have an authority hierarchy
Approved internal data owns the report contract. External figures can contextualise or challenge it, but cannot silently replace it.
Idempotent work units
Section and evidence jobs carry stable identity so retries resume work without duplicating records or losing the path to the original run.
Human review is routed
Contradictions, low-confidence mappings, high-consequence claims, and publication approval become explicit review states.
The technology and responsibility of each layer.
Typed brief · section schemas · approved IW dataset · validation rules · publishability state
The model always works inside a versioned definition of what the report is supposed to contain.
Specialised research, extraction, comparison, mapping, and drafting agents with schema-validated outputs
Different reasoning jobs remain independently testable and replaceable.
Queues · retries · idempotency · correlation · audit history · deterministic gates
Production reliability and authority stay outside model memory.
Source identity · retrieval timestamp · field/claim linkage · quality state · accepted/rejected status
Reviewers can inspect why a claim exists and whether its source was actually accepted.
Next.js + TypeScript frontend · FastAPI/Python matching service · Supabase Auth/Postgres/pgvector/pgmq/Storage
A focused interface maps competitor research titles to the internal report database while preserving stable service boundaries.
OpenAI embeddings · shared vector space · checksum-based change detection · typed match results
Similar reports can be compared reproducibly without embedding unchanged material again.
Per-firm adapters · fail-soft sync history · two-stage discover/enrich · pricing snapshots · gap and TOC analysis
Competitor sources vary, so acquisition logic is pluggable while orchestration and intelligence contracts stay consistent.
How the system handles missing or unreliable data.
A draft cites no accepted evidence
The claim remains unsupported and cannot pass the publishability gate, regardless of prose quality.
A generated metric conflicts with live IW data
The approved contract wins; the conflict is recorded for review rather than blended into a new number.
A required section is missing or malformed
Deterministic schema and completeness checks block assembly and route the section back to the responsible stage.
An external source is stale or inaccessible
Preserve the unavailable or stale state, seek an alternative source, and do not present recency as known.
One competitor adapter fails during Radar sync
Per-firm history and fail-soft orchestration allow other firms to continue; the failed source remains explicitly unhealthy.
A section job is retried after partial completion
Stable work identity and durable state resume the unit without duplicating evidence or generating an untraceable second artifact.
What this case study is based on.
- 01
Mordor product documentation describing the report contract, operational users, live IW authority, evidence candidates, agent transformations, and deterministic publishability gates.
- 02
Research Mapping Workbench codebase: Next.js client, FastAPI matching service, Supabase migrations, pgvector/queue/storage boundaries, and embedding integration.
- 03
Radar product and architecture records covering pluggable competitor adapters, fail-soft syncs, shared vector space, gap/pricing/TOC intelligence, source lineage, and phased delivery.