Web Research Synthesizer

Produce something a sceptical reader can check. Unsourced assertion is the failure mode, not a shortcut.

When to use

Comparisons, market or technical landscape scans, fact-checking, due diligence, "what is the current state of X", literature-style briefings.

Do not use for: questions answerable from stable general knowledge, or opinion pieces with no factual load.

Workflow

1. Decompose the question

Convert the request into 3–7 answerable sub-questions and state what evidence would settle each one. Identify the decision behind the question — research that does not change a decision is wasted.

Flag immediately: ambiguous scope, an unstated timeframe, or a question that is actually a value judgement rather than a factual one.

2. Search deliberately

• One sub-question per query; vary phrasing between a technical and a plain formulation.
• Search for the counter-position explicitly ("X limitations", "X vs Y criticism", "why we moved off X"). Confirmation bias is the main risk here.
• Prefer primary sources: official docs, filings, standards, datasets, the original paper — not an article about them.
• Add a time filter for anything fast-moving; check the publication and last updated date on every page.
• Stop when new sources stop changing the answer (saturation), not when you hit a source count.

3. Rate every source

Always check: who benefits from this claim, is the author named, is the date visible, are sources cited, has it been updated since publication.

Vendor material is Tier A for their own product's specifications and pricing, and Tier E for any comparison with competitors.

4. Cross-verify

• Every load-bearing claim needs two independent sources. Two outlets citing the same press release count as one.
• Trace numbers back to origin. "Studies show 73 %" usually terminates in a single small survey commissioned by an interested party.
• When sources conflict: report the conflict, date each position, and explain the likely cause (different methodology, different scope, one is stale, one is interested). Do not average them; do not silently pick one.

5. Assign confidence per claim

Never upgrade confidence because a claim is repeated by many low-tier sources.

6. Deliver

## Answer            two to four sentences, up front
## Key findings      each with [n] citations and (Confidence: …)
## Comparison        table, when options are being weighed
## Contradictions    what disagrees, and why
## Gaps              what could not be established, and what would settle it
## Sources           [n] Title — Publisher — date — tier — URL

Cite inline with numbered references. Attribute every number and every quote. Separate fact, interpretation and your recommendation into distinct sentences — never blend them.

Worked example

Question: "Is Postgres a viable replacement for our Kafka event bus?"

Decomposition

1. What throughput can Postgres-based queues sustain? (technical limit)
2. What features are lost versus Kafka? (retention, replay, partitioning, consumers)
3. What is our actual throughput and retention requirement? — unanswerable from the web; asked the user
4. Who has done this in production, and what did they hit? (case evidence)

Finding (extract)

Postgres-based queues using SKIP LOCKED sustain roughly 10³–10⁴ messages/s on commodity hardware before vacuum and WAL pressure dominate [1][3] (Confidence: Medium — two benchmarks, different hardware and schemas; neither is an independent reproduction of the other).

Kafka's log retention with independent consumer offsets has no direct Postgres equivalent; replay must be built manually [2] (Confidence: High — stated in both projects' documentation).

Gap: no source found for sustained multi-day retention at your stated volume. This would be settled by a two-week load test on your own schema — the deciding variable is your requirement (#3), not the technology.

Contradiction: a vendor blog claims 50k msg/s on Postgres [4]; it omits durability settings and the publisher sells a Postgres queue product. Tier E for this comparison — excluded.

Quality checklist

• Every factual claim carries a citation
• Load-bearing claims verified across independent sources
• Source tier and publication date recorded for each reference
• Counter-evidence actively searched, not just supporting evidence
• Contradictions surfaced, not smoothed over
• Confidence stated per claim, and justified
• Gaps and unanswerable questions listed explicitly
• Fact, interpretation and recommendation kept separate
• No paraphrase that strengthens the original claim

Failure modes