AI research products often display citations, but a row of links at the bottom of an answer does not tell you how the answer was built. A citation can be relevant to the topic without supporting the sentence beside it. Several links can repeat the same underlying source. A model can also drop important uncertainty while turning notes into fluent prose.
The data model has to preserve more than URLs. It should preserve the path from the original question to research queries, retrieved material, evidence grouped by claim, and the final report. We call that path an evidence chain.
This article focuses on the database and pipeline boundaries that make such a chain reconstructable.
The common shortcut: one giant JSON result
The fastest implementation is usually a job table with an input question and one JSON column containing everything else. It works until the product needs to answer operational questions:
- Which research query found this source?
- Which source supported this claim?
- Did two citations come from the same domain?
- Was this page reused from an earlier crawl?
- Which model stage changed the wording?
- Can we regenerate the summary without repeating the crawl?
A single blob makes these questions expensive and fragile. Every query becomes a custom JSON traversal, and relationships that should be enforced by keys exist only by convention.
The better approach is to keep the original run as the parent while giving important artifacts their own records.
1. Start with a search run
A search run represents one research question and its lifecycle. It owns the status, timestamps, final report, content metadata, and publication decision.
The run should not pretend that generation is atomic. A real research workflow may expand keywords, search multiple providers, crawl pages, extract page-level facts, aggregate evidence, synthesize a report, classify the content, and calculate an indexability result. Those stages should all reference the same run ID.
This parent key is what lets an operator reconstruct one execution without correlating timestamps across unrelated log streams.
2. Store research queries in order
Generated research queries deserve their own ordered records. Order matters because it shows the strategy the system attempted, and stable indices make retries deterministic.
A minimal query record needs the run ID, a query index, and the query text. You may also want the prompt version that produced it, the provider used, and whether the query was executed or skipped.
Keeping queries separate makes it possible to evaluate query quality independently from answer quality. If a report misses an important perspective, you can tell whether the gap originated in query generation or later retrieval.
3. Treat crawled pages as artifacts
Search results and crawled pages are inputs, not yet evidence. A page artifact should record the run, artifact type, query or keyword, URL, retrieval metadata, and the raw or normalized payload needed by later stages.
That distinction prevents a dangerous shortcut: assuming that every retrieved page supports the answer. Most search results are candidates. Some are duplicates, some only mention the topic, and some contradict the emerging conclusion.
Page artifacts also create a clean caching boundary. A system can reuse a recent crawl for the same URL while still running fresh evidence extraction for a new question. Retrieval freshness and claim relevance are different concerns and should not share one cache key.
4. Model evidence around claims
Evidence becomes useful when it is connected to a claim. An evidence record can contain:
- the parent run ID
- a stable evidence index
- the claim it supports or challenges
- the research keyword or query
- source title, summary, and URL
- normalized domain
- an explanation of relevance
- nested source details when several passages support one item
The claim field is the critical part. It gives reviewers a unit they can inspect. Instead of asking whether a source is “about the topic,” they can ask whether the source supports the specific statement that will appear in the report.
This structure also enables domain-diversity checks and source counts without parsing rendered Markdown. Quality rules should operate on evidence records before the final page exists.
5. Keep model-call provenance beside content provenance
Content provenance explains where facts came from. Model-call provenance explains how the system transformed those facts. Both are required for reproducibility.
For each stage, retain request messages, structured inputs, the raw provider response, parsed output, model and reasoning configuration, token usage, latency, prompt version, and errors. Link every call to the same run.
With that relationship, a reviewer can move in both directions:
- from a sentence in the report to its claim and sources
- from a suspicious source to the extraction and synthesis calls that consumed it
This is much more actionable than a generic “generated by AI” label.
6. Save the final report, but do not make it the source of truth
The final report is a presentation artifact. It may be Markdown or HTML, and it may include inline links for readers. But source counts, domain counts, confidence, and evidence sufficiency should come from structured data, not from scraping the report after generation.
That separation has a practical benefit: presentation can change without destroying provenance. You can redesign citation components, generate mobile summaries, or expose an API while keeping the same underlying evidence relationships.
7. Make insufficiency a valid outcome
An evidence chain should be able to end without a publishable answer. If retrieval produces too few sources, domains are not independent, or the evidence conflicts, the run can complete with an insufficiency flag and clear reasons.
This is not a pipeline failure. It is a research result. Treating insufficiency as data prevents the system from filling gaps with more confident prose simply to satisfy a success state.
8. Expose enough of the chain to readers
Internal logs can contain sensitive or operational details, so they should not be dumped into a public page. Readers still benefit from a carefully selected public surface:
- visible source links
- source titles and domains
- claim-oriented evidence groups
- correction and attribution channels
- methodology and editorial policy pages
The public Omniracle methodology describes how signal discovery, research, evidence, model provenance, and publication gates fit together. The recommended reports show the reader-facing side of that architecture.
A useful mental model
Think of the pipeline as a directed chain:
question → research queries → page artifacts → claim evidence → synthesis calls → final report → publication decision
Each arrow should be represented by a durable relationship, not inferred later from similar text. When a result is challenged, the system can then answer the most important engineering question: not merely “Which links were shown?” but “How did this claim travel from source material into the published answer?”
That is the difference between citation decoration and an auditable research system.
Top comments (0)