agent merged two contracts' clauses into one summary - same counterparty, two MSAs, no document-boundary check

Two MSAs, one summary: missing document-boundary check merges contracts

TL;DR

Hash every input document and tag each extracted clause with its document id, processing one contract per run. Without a boundary check, clauses from two MSAs with the same counterparty blend into a single summary that cites the wrong terms. Fail the run if one summary ever carries two document ids.

summary cites "liability cap $500k" from MSA-2024.pdf inside the MSA-2026.pdf review - no document boundary enforced

1. Hash each input file and assign a document id before extraction starts. Expected: every document has a stable id in the run manifest.

2. Tag every extracted clause with its source document id. Expected: each clause record carries the id of the file it came from.

3. Process one document per extraction run. Never batch two MSAs into a single context. Expected: cross-document mixing becomes structurally impossible.

4. Assert a single document id per summary. If clauses with two ids land in one summary, fail loudly. Expected: a mixing bug stops the run instead of shipping a blended summary.

Use this when

• a summary cites terms that belong to a different contract
• two documents from the same counterparty are processed together
• citations resolve to pages in the wrong file
• clause counts look doubled or terms contradict each other

Not for this skill when

• the merge happened inside one document (amendment vs base text confusion)
• the two files are actually the same contract in different formats (a dedupe problem)
• you intentionally compare two contracts (use a diff workflow, not one summary)

Variant phrasings

• agent merged two contracts into one summary
• clause extraction mixed up two MSAs same counterparty
• document boundary check missing contract review pipeline
• summary cites wrong contract terms blended

Why it happens

Batching documents into one context window is faster and cheaper, so pipelines do it by default. The model has no reliable sense of file boundaries inside a flat text stream, especially when both documents share a counterparty, similar structure, and overlapping defined terms. The summary reads coherently, which is exactly why nobody catches it.

Edge cases

• Filenames lie. Hash content, not names, for the document id.
• Amendments belong with their base contract; model the relationship explicitly instead of relying on batching.
• The assertion in step 4 needs the clause-level tags from step 2; summaries alone cannot be checked.
• Re-run both contracts separately after the fix. The blended summary is untrustworthy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TuRbaXvXsg6XnAvq4hEecA