Your RAG Pipeline Starts Before the First Embedding

A search system can return a fluent answer from a document that should never have entered its evidence pool. The title may belong to one page while the URL points to another. A saved page may contain only a preview. A table may survive extraction as a list of numbers without its labels.

Embedding those inputs makes them searchable. It does not make them reliable.

For a knowledge application, I would start with a source inventory: a record of what was collected, what was actually extracted, and what can safely support an answer. That inventory also makes an article-based publishing workflow easier to review, because every draft can point back to a specific version of its evidence.

Separate discovery from evidence

A title, author, and short description are useful discovery metadata. They help you decide which article to read next. They are insufficient for reconstructing the article's argument, checking its examples, or reporting what its author concluded.

Store availability explicitly. Useful states include metadata only, extracted text with unknown completeness, verified complete text, and identity conflict. Avoid a single indexed: true flag that hides all four situations.

A minimal record might look like this:

{
  "source_id": "article-42",
  "canonical_url": "https://example.com/article-42",
  "content_status": "extracted_text",
  "completeness": "unverified",
  "content_hash": "sha256-of-extracted-text",
  "retrieved_at": "2026-09-17T12:00:00Z"
}

The hash identifies the text version. It is not a measure of truth. Likewise, a long extraction is evidence of available text, not proof that a paywall, parser failure, or navigation block has not altered it.

Preserve the relationships that carry meaning

Document parsing and chunking solve different problems. Parsing must recover structure; chunking decides how to divide it. If extraction separates a table value from its column heading, a later splitter cannot reliably reconstruct the missing relationship.

Consider a maintenance guide listing a component, its inspection interval, and the condition under which the interval changes. Saving only the interval produces a convincing but incomplete answer. Preserve the labels and exception together before considering vector similarity.

This is why chunk boundaries need an explicit design. A splitter cannot compensate for evidence that disappeared earlier.

Make failures visible without discarding the inventory

Keep problematic records searchable for maintenance, but exclude them from the evidence pool used to write answers or publications. Record the reason: mismatched identifier, absent body, uncertain language, or extraction failure.

That distinction supports two workflows. A maintenance search asks what needs repair. An answer search asks which sources are eligible to support a claim. They should not silently return the same population.

For publication, add another check: read the passages you intend to use. A source can be relevant to the topic while failing to support the particular conclusion in your draft.

Test source quality as part of the product

Build a small collection of deliberately awkward inputs: an article preview, a redirected URL, a two-column page, a table with footnotes, and two versions of the same document. Check the extracted result before measuring search relevance.

The broader evaluation workflow should distinguish missing evidence from poor ranking and unsupported generation. Otherwise, a retrieval problem may send you back to the prompt, while the real defect remains in the source inventory.

The first useful milestone is modest: every record explains what is available and where it came from. Once that is true, improvements downstream become easier to interpret.