The model reads the whole thought, and the citation still names the chunk
A document is cut into chunks so it can be indexed, and how long a chunk
may be is decided by the embedding model's input limit — not by how much
an answer needs. Those are different numbers, and left alone the second
loses: a heading section longer than one chunk is cut mid-thought and
nothing in the answer says it was cut.
So when a chunk wins the ranking, the prompt receives the whole section it
came from. Nothing is re-indexed and nothing is re-stored; the vault reads
more of a document it had already decrypted for that caller. It changes
which offsets are requested, not what was written, which is why it reaches
documents already in the vault rather than only new ones.
Two properties are load-bearing and neither is negotiable. A widened span
is clamped to the version it came from, so it can never join text from
another document — that would be a fabrication with a citation attached.
And the widened span travels alongside the matched chunk's own locator
rather than replacing it, so a citation names what the vault claims it
read. Widening changes what the model reads; it never changes what the
vault says it read.
A matched chunk reaches the prompt as its whole section
- Given a document whose section is longer than one chunk window
- When a chunk in the middle of that section matches a question
- Then the prompt receives the whole section rather than the chunk
A widened span never leaves the document it came from
- Given a chunk at the very end of a document
- When the vault widens it with a bound larger than the document
- Then the span stops at the document's last word
Widening never crosses into a neighbouring section
- Given a document with two headed sections
- When the vault widens a chunk in the first section
- Then the span stops before the second section's heading
The bound is a bound
- Given a section far longer than the configured bound
- When the vault widens a chunk inside it
- Then the span is no wider than the bound allows
Turning widening off restores the earlier prompt exactly
- Given a deployment with passage widening set to zero
- When the vault widens a chunk
- Then the span is the matched chunk, unchanged
A bound the context window cannot hold is refused, naming both numbers
- Given a widening bound larger than the answering model's context window
- When the vault checks the pair
- Then it refuses and names the bound and what would fit instead