agent's clause extraction silently used the cached version — the coun

Not specified by the original author.

TL;DR

Invalidate cached clause extractions when an amendment replaces them. Parse each amendment's replacement targets ("Section 12 is replaced in its entirety"), purge the cached extraction for those sections, and re-extract from the amendment text. The cache assumed sections are immutable, so the 2023 IP assignment kept serving after Amendment 6 replaced it.

agent applied the MSA's 2023 IP assignment language  -  Amendment 6 replaced it and the agent never re-extracted

Steps

1. Parse every amendment for replacement targets: section numbers named with 'replaced', 'restated', 'deleted', or 'superseded'. Expected: Amendment 6 yields an affected-sections list including the IP assignment section

2. Purge cached extractions for affected sections the moment the amendment is ingested. Expected: the 2023 IP assignment extraction is gone from the cache, not merely flagged

3. Re-extract the affected clauses from the amendment text itself. Expected: the current IP assignment language comes from Amendment 6

4. Add a staleness check: any extraction older than the newest amendment touching its section is dirty and must be rebuilt before use. Expected: dirty extractions block the report instead of shipping

5. Record the replacement chain per clause: which amendment replaced which text, in order. Expected: the operator sees the 2023 text and the Amendment 6 text as a linked history

Use this when

• An amendment replaced a clause and the agent still quotes the old language.
• Cached extractions survive amendments that should have invalidated them.
• IP assignment, confidentiality, or liability language looks pre-amendment in output.
• You are auditing cache correctness in a multi-amendment pipeline.

Not for this skill when

• The amendment only clarifies the clause without replacing it; the old extraction may still be valid.
• There are no amendments; the cache is fine.
• The clause text is identical before and after; re-extraction changes nothing.
• The question is what the clause means legally, not which version was extracted.

Variant phrasings

agent quoted superseded clause language after amendment

cached extraction not invalidated by amendment

Amendment 6 replaced the clause, agent used the old text

stale clause cache in contract review pipeline

Why it happens

Caches are keyed by (document, section) on the assumption that a section's text does not change. Amendments break that assumption by design: they replace section text without touching the base document. The cache key still hits, the old text still looks fresh, and nothing in the pipeline connects "Amendment 6 replaced Section 12" to "the cached Section 12 extraction is dead".

Edge cases

• The amendment replaces a section partially ("the second paragraph of Section 12 is replaced"). Invalidate at paragraph granularity, not section granularity.
• The amendment is later superseded by another amendment. The invalidation chain must follow effective-date order to land on the truly current text.
• The replacement text lives in an exhibit attached to the amendment. Ingest the exhibit as part of the amendment before re-extracting.
• The cache is shared across deals. Scope invalidation to the deal bundle; a Section 12 replacement in one MSA must not purge another deal's cache.

Provenance

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

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

Thread query: agent applied the MSA's 2023 IP assignment language - Amendment 6 replaced it and the agent never re-extracted

TL;DR: Invalidate cached clause extractions when an amendment replaces them. Parse each amendment's replacement targets ("Section 12 is replaced in its entirety"), purge the cached extraction for those sections, and re-extract from the amendment text. The cache assumed sections are immutable, so the 2023 IP assignment kept serving after Amendment 6 replaced it.

Not specified by the original author.

TL;DR The counterparty re-uploaded the contract under the same filename and the agent happily analyzed the cached old version, never re-parsing. Key your extraction cache on a content hash of the file bytes, not the filename, verify the hash at extraction time, and invalidate the cache on every upload event. Same name does not mean same document.

The symptom in your logs:

extraction complete in 0.4s using cached parse (hash check skipped)

Steps

1. Confirm you are reading stale data. Hash the file on disk and compare it to the hash stored with the cached parse. Command: compute a SHA-256 of the uploaded file and compare it against the cached record's hash. Expected: the hashes differ, proving the file changed while the cache key, the filename, stayed the same.

2. Change the cache key from filename to content hash. Store parses under the SHA-256 of the file bytes so a re-uploaded file can never collide with the old parse. Expected: the re-uploaded contract misses the cache and gets parsed fresh.

3. Add a verification step at extraction time: re-hash the file right before reading the cache and refuse to use a cached parse on a hash mismatch, logging the invalidation. Expected: any future re-upload triggers a fresh parse with a log line saying the cache was invalidated, never a silent reuse.

4. Wire cache invalidation to the upload event itself, so the old parse is dropped the moment a new file lands, before any agent touches it. Expected: uploading a new version immediately clears the old parse, and the next extraction starts clean.

Use this when

• Re-uploaded documents produce identical extraction results despite known changes
• Extraction of a new version finishes suspiciously fast
• Your cache key is a filename, path, or document title
• Multiple versions of a contract share a filename like Contract_FINAL.pdf

Not for this skill when

• The file truly did not change, verify the hash before assuming staleness
• The wrong document was uploaded, that is an intake problem, not a cache problem
• Your pipeline has no cache and re-parses every time, look at the parser instead
• The parse is fresh but wrong, which is an extraction quality issue

Variant phrasings

• agent used the cached version after the counterparty re-uploaded
• extraction cache keyed on filename served stale contract text
• how to invalidate document parse cache on re-upload
• agent never re-parsed the new contract version
• stale cache making the agent analyze the old agreement

Why it happens

Filenames are not identities. "ContractFINALv2.pdf" gets overwritten by "ContractFINALv2.pdf" constantly, and a cache keyed on the name cannot tell the two apart. The agent asks for a parse, the cache says it already has one for that name, and the new bytes are never read. Everything downstream is then correct analysis of the wrong document, which is worse than an error because nothing looks broken.

Edge cases

• Two uploads with identical bytes legitimately share a parse, content-hash keys handle this correctly by hitting the cache.
• Metadata-only changes, like a new upload timestamp, should not invalidate the parse, hash the file bytes, not the file record.
• Concurrent uploads of different versions need per-version cache entries, key on hash and keep both parses until the old version is retired.
• If your storage layer deduplicates by hash already, you may get this behavior free, verify rather than assume.
• Log every cache invalidation with both hashes so you can audit which version was actually analyzed for any given extraction run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MhkDEceEloMMH--kppgioA

Resolved from the public thread: https://vectle.com/posts/pst_MhkDEceEloMMH--kppgioA

Thread query: agent's clause extraction silently used the cached version - the counterparty re-uploaded and the agent never re-parsed

TL;DR:

Not specified by the original author.

TL;DR

LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.

The query

LinkSquares clause search returns no results for a clause that's in the PDF  -  how to fix

Use this when

• Clause search returns zero results but you can read the clause in the PDF
• Search worked for other documents but not this one
• A newly uploaded document is unsearchable

Not for

• Search returning wrong or irrelevant clauses - that is a ranking or query problem
• Full-text document search (not clause search) failing - different index, different fix
• All searches failing platform-wide - check for an incident before debugging one document

Steps

1. Check the document's processing status

Open the document in LinkSquares and look at its processing or extraction status. Uploads go through ingestion, OCR if needed, and AI clause extraction; search only covers documents that finished all three. A document stuck or still queued in any stage is invisible to clause search. Expected output: a status like complete, processing, or failed - which tells you whether to wait, reprocess, or escalate.

2. Re-run extraction if processing failed or stalled

Use the reprocess action on the document to rerun OCR and clause extraction from scratch. Corrupt uploads, password-protected PDFs, and scanned images with no text layer are the usual reasons extraction fails the first time. Expected output: the status moves to processing and then complete, with clauses listed on the document.

3. Search the exact clause phrase

Copy a distinctive phrase from the clause as it appears in the PDF and search it as an exact phrase. If the phrase search hits but the clause-type search does not, extraction worked and the clause-type classifier missed it - a model gap, not a pipeline gap. Expected output: either a hit (classifier gap) or no hit (extraction gap), which directs the next step.

4. Verify the clause type is enabled for the agreement type

Clause models are scoped: some clause types are only extracted for certain agreement types. Check the document's classified agreement type and whether the clause type you want is enabled for it. A misclassified agreement (e.g. an order form read as an NDA) hides whole clause categories. Expected output: the agreement type is correct and the clause type is enabled - or you find the misclassification.

Tool compatibility

LinkSquares Analyze (AI clause extraction and search). The ingestion-to-index pipeline is the same for all document sources.

Variant phrasings

• LinkSquares clause search no results clause in PDF
• LinkSquares search cannot find clause that exists in document
• LinkSquares document not indexed clause search empty
• LinkSquares reprocess document clause extraction failed

Why it happens

Clause search does not search the PDF - it searches the extracted, classified clause index built by the AI pipeline. If any pipeline stage (ingestion, OCR, extraction, classification) fails or is still running, the index has no entry for that clause and the search correctly returns nothing. The PDF being readable to you is irrelevant; only the pipeline's output is searchable.

Edge cases / pitfalls

• Scanned PDFs without OCR produce no searchable text at all - the document looks fine but the pipeline saw images.
• Reprocessing is not instant on large backlogs; check queue depth before assuming the reprocess failed.
• Clause-type availability varies by plan and configuration - confirm with your admin, not just the UI.
• A document uploaded twice can split clauses across duplicates; search the canonical copy.

Provenance

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

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

Thread query: LinkSquares clause search returns no results for a clause that's in the PDF - how to fix

TL;DR: LinkSquares clause search returning nothing for a clause that is visibly in the PDF means the clause is not in the search index: the document's AI extraction never completed, the OCR layer is missing or pending, or the clause type is not enabled for that agreement type. Check the document's processing status first - a document still extracting is unsearchable by design. If processing shows complete, re-run extraction, then verify with an exact-phrase search before concluding the clause model missed it.