The failure is not that each document is individually stale. It is that the answer assembled a world that never existed. If rule 12 narrows eligibility and table 11 still lists the old exception, either version alone might be plausible. Together they can create a policy the source owner never approved. An answer needs an evidence set with a meaningful consistency boundary, not just the newest hit for each query.

I would ask the source team for the publication contract. Best case, the policy release has an immutable manifest listing both document IDs and revisions, plus an activation event. Prepare and index all listed revisions, verify the manifest is complete, then atomically advance the active release pointer for that tenant and policy collection. A query pins that pointer at entry. Retrieval, expansion, citations and answer construction use the same release. The old complete release remains serveable until the new one is ready, assuming its old policy remains an acceptable temporary answer. If freshness is legally urgent, the product may need to abstain during the transition rather than serve an expired rule.

A partial release has rule 12 and exception 11, which must not be assembled into an answer. After both release 12 objects are indexed, one active-release pointer changes and queries pin that complete manifest.
The searchable unit for this question is the policy release, not whichever two chunks finished indexing first.

For a database-backed source, a consistent snapshot and a change stream can build that generation. Take a source snapshot at a known log position, copy the rows visible at that position, consume later changes from the stream, and advance a durable watermark only when all earlier changes for the relevant partition have been applied. Activate the generation after completeness checks. PostgreSQL's isolation documentation explains consistent database views, and Debezium's PostgreSQL connector documentation describes initial snapshots followed by streaming changes. The exact handoff depends on the connector and log semantics. Merely starting a crawler and a queue at about the same time is not a gap-free handoff.

If the two files live in a document store without atomic multi-object publication, I cannot manufacture a guarantee that the source never provided. Ask the owner to publish a release marker or manifest, or impose an application-level approval gate with explicit revisions and an effective time. If there is no such signal, present the answer as uncertain, fetch current authoritative source data where possible, or abstain on cross-document policy questions. An ingestion timestamp is not a common source snapshot.

Say one change event arrives twice and another arrives late. Make ingestion idempotent by source object revision, but do not activate release 12 until its manifest is satisfied. A late event for release 11 must not replace the active 12 pointer. Deletion or permission change may need an immediate serving block even while a new content release is prepared. Content coherence does not override current authorization.

Finally, a long answer begins under release 11 and release 12 activates mid-response. Pinning the release prevents it from mixing evidence halfway through. A separate freshness policy decides whether to finish, stop, or restart if release 11 becomes invalid during the stream. The citation should identify both the source revision and policy release so a later reviewer can reconstruct what the answer actually used.