RAG 2: documents with identity, structure and provenance
What to preserve from an official or business document before splitting it into chunks and producing embeddings.
In this article
A search system can find a convincing paragraph and still return the wrong version. In the Taesa review, that confusion remains a hypothesis requiring rankings and reviewed examples; historical CSVs do not identify each cause. My proposal starts with verifiable document identity, so I can investigate failures rather than automatically blame embeddings.
The file, the version and the family
I assign a stable document ID, a version ID and a family ID when several files belong to the same case. I keep source, issuer, type, publication date, capture date and hash. Where relevant, I record validity periods and amendment relations, with evidence and verification status. Recent publication does not automatically supersede everything that came before.
Exact duplicates may share stored content without losing their distinct provenance. Near-identical versions should not disappear through aggressive deduplication: a date, exception or amount may be exactly what changes the answer. The manifest must also record what did not enter the index and why.
Preserve three representations
I preserve the original, a structured extraction and the search representation. Every transformation records its parser, version, configuration and relationship to the preceding artifact. For PDFs I check reading order, tables, notes, signs and units. A long extraction does not guarantee correct column associations. Errors enter a review queue rather than being silently excluded.
{
"document_id": "doc-001",
"version_id": "doc-001-v2",
"family_id": "case-017",
"chunk_id": "doc-001-v2-section-3-p2",
"source_locator": {"page": 8, "section": "3.2"},
"valid_from": null,
"validity_status": "unverified",
"original_text": "...",
"generated_context": null,
"access_policy_id": "policy-017"
}Split without erasing relationships
My first comparison would contrast simple size-based splitting with sections, provisions, clauses and tables. I would retain a link from each chunk to its parent unit to expand context after retrieval. I would not deliberately separate a rule from its exception or a value from its unit. If a section exceeds the limit, subdivisions retain headings and references.
Tags start small: document type, entity, topic and status. I distinguish metadata explicitly present in the source, rule-derived fields and model-inferred fields. An inferred tag may help ranking, but making it a mandatory filter can remove relevant evidence. Validity and permissions are not inferred from a generated summary.
Akoma Ntoso provides a reference for normative structure and metadata. Applying its principles does not require implementing the entire specification. To approve this phase I would require traceability from every citation to its original, review of difficult extractions and a loss report by document type. Target rates depend on risk and should be set before comparing models.
OASIS: Akoma Ntoso structure and metadata
Taesa case: limits of the original diagnosis
A September 2026 preprint jointly evaluates parsers, chunking and embeddings on four Indian regulatory documents. It finds interactions: the best combination cannot be inferred from each component’s separate ranking. Questions are LLM-generated with a manually checked sample, and final answers are not evaluated. For Taesa this suggests a small factorial comparison after initial diagnosis; thousands of evaluations on four documents do not represent thousands of independent regulatory contexts.
Parser, chunking and embedding interactions