agent's summary silently dropped the termination-for-convenience clause - the contract was 90 pages and the middle...

TL;DR A 90-page contract's middle chunk never made it into context, the termination-for-convenience clause vanished, and nothing warned anyone. Account for every chunk before summarizing: verify the chunk count matches the document, emit a coverage report of which pages were actually processed, and fail loudly instead of summarizing a partial document. A summary of 80 percent of a contract presented as complete is a lie.

The silent failure in your logs:

summarizing 90-page contract ... summary complete (pages 1-30, 61-90 processed)

Steps

1. Confirm the truncation. Count the pages your pipeline actually fed into context versus the document's page count.

Command: compare your chunk manifest's page ranges against the PDF's page count. Expected: a gap in the middle ranges, like pages 31-60 missing, proving the truncation and locating it.

1. Add a chunk-accounting gate before summarization: the pipeline must produce one chunk per expected page range, and summarization refuses to run unless every range is present.

Expected: a missing middle chunk blocks the summary with an explicit error instead of a quiet partial result.

1. Emit a coverage report with every summary: pages processed, pages skipped, and the reason for each skip, attached to the summary output.

Expected: any consumer of the summary can see exactly which pages it covers before relying on it.

1. Fix the underlying drop, which is usually a context-budget trim that discards middle chunks first. Change the trim policy to refuse rather than silently drop, or switch to a map-reduce pass that processes every chunk and reconciles.

Expected: long documents either summarize in full or fail with a clear message, never silently partial.

Use this when

• Summaries of long contracts are missing clauses that exist in the source
• Your pipeline chunks documents and trims to fit a context window
• Middle pages vanish while the start and end look fine
• A summary claims completeness but you cannot verify its coverage

Not for this skill when

• The clause is present but the summary omitted it for brevity, that is a summarization quality issue
• Pages are missing from the source file itself, verify the input document first
• The truncation is at the end because of output token limits, which needs output budgeting instead
• Your pipeline already emits coverage reports, check them before assuming silent truncation

Variant phrasings

• agent summary silently dropped a clause from a long contract
• middle chunk truncated without warning in contract summarization
• how to detect silent context truncation in document pipelines
• 90-page contract summary missing the termination clause
• chunk accounting for long-document agent pipelines

Why it happens

Long-document pipelines split text into chunks and then fit them into a fixed context window, and when the chunks do not fit, something has to give. Many implementations trim from the middle, keeping the introduction and the conclusion, because that usually reads well. The problem is they do it silently: the summarizer receives a partial document and has no idea, so it writes a confident summary of whatever it saw. The termination clause lived in the trimmed middle, and nobody was told.

Edge cases

• Map-reduce pipelines can lose chunks at the reduce step too, apply the same accounting to intermediate summaries, not just input chunks.
• A chunk that fails to parse is as dangerous as a trimmed chunk, count parse failures as missing coverage.
• Retry logic that re-fetches chunks can double-count pages, deduplicate by page range in the manifest.
• Some trimmers drop chunks based on a relevance score, which is fine, but the dropped ranges must still appear in the coverage report.
• If full coverage genuinely does not fit, the honest answer is a scoped summary labeled with its page range, not a silent partial.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WlCgBCF2gNJPbf8LBoX-FQ