metadata-only change flagged — the counterparty updated the document

Not specified by the original author.

TL;DR

The counterparty only updated the document author field, but the agent reported it as a redline. Strip document metadata (author, timestamps, revision counts) before diffing, and compare content only. Report metadata changes separately as non-substantive, never as redlines.

The symptom

metadata-only change flagged  -  the counterparty updated the document author field and the agent reported it as a redline

Steps

1. Confirm the change is metadata-only

Compare the extracted body text of both versions. If the text is identical and only properties like author or last-modified differ, it is metadata-only. Expected: Identical body text; differences confined to document properties.

2. Strip metadata before diffing

Remove or normalize metadata fields (author, created/modified dates, revision numbers) from both files before comparison. Expected: The diff input contains content only.

3. Re-run the diff

Diff the cleaned versions. The change count should drop to zero. Expected: Zero content changes reported.

4. Report metadata separately

Note 'document author updated (metadata, non-substantive)' as an FYI, not a redline. Expected: Reviewers see it without it polluting the redline list.

When to use

• Change list contains author, timestamps, or revision info
• Body text is identical between versions
• The diff tool compares raw files including properties

When not to use

• Body text actually changed (then it is a real redline)
• The metadata itself is disputed (rare; handle explicitly)
• You need an audit trail of metadata (log it, just not as redlines)

Why it happens

File-level diffing sees everything, including the document properties block. An author-field update changes bytes, so it looks like a change. But contract review cares about operative text; metadata edits are administrative noise that drown real redlines.

Edge cases

• Tracked-changes author names: changing the author can reattribute existing markup; check the markup, not just the text.
• Template metadata (company name in properties): note once, not per version.
• Signed PDFs: metadata changes can invalidate signatures; flag that separately.

Provenance

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

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

Thread query: metadata-only change flagged - the counterparty updated the document author field and the agent reported it as a redline

TL;DR: The counterparty only updated the document author field, but the agent reported it as a redline. Strip document metadata (author, timestamps, revision counts) before diffing, and compare content only. Report metadata changes separately as non-substantive, never as redlines.

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

Fix this in Ironclad by acting on the exact problem first: in Ironclad, open the executed NDA record in the repository, check that its indexing status and extracted text are present, trigger a reindex of that one record, and confirm a search for a phrase from the document returns it. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one executed agreement or repository record first, then rerun the full scope and reconcile the results.

Ironclad repository error executed NDA not indexed in search

Use this when

• The operation in Ironclad fails with this exact problem: Ironclad repository error executed NDA not indexed in search.
• The same failure repeats on retry with unchanged inputs.
• Work on an NDA lookup, audit or repository search is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a clause wording or a legal judgement. That is a legal owner decision, not this failure.

Steps

1. Reproduce the failure using one executed agreement or repository record in Ironclad and record the full problem text plus the record, signer or run involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: in Ironclad, open the executed NDA record in the repository, check that its indexing status and extracted text are present, trigger a reindex of that one record, and confirm a search for a phrase from the document returns it. Verify: the single failing scope now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring records, templates or runs that share the same settings, template or schedule, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Ironclad on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the executed NDA, the counterparty record or the repository entry, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the workflow log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

Ironclad repository error executed NDA not indexed in search

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - Ironclad repository error executed NDA not indexed in search

The how to phrasing for the same failure in Ironclad. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Ironclad troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Repository search indexes the extracted text and metadata captured when the executed agreement is filed, so a record filed before extraction finished, or with missing metadata, exists in storage but never enters the search index.

Edge cases

• The record, template or assignment changed after the failing run started. Refresh the current state and reapply the fix against the current values, not the values from the failed run.
• The single scope proof passes but the full rerun still fails on other items. Treat each remaining failure as its own scope, because a shared template, setting or schedule can hide more than one cause.
• The source systems disagree on the correct value. The executed NDA governs wording, the counterparty record governs party details, and the workflow record governs status; record which source won and why.

Compatibility: Ironclad at current versions, plus the NDA template, repository or messaging tool the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: Ironclad repository error executed NDA not indexed in search

TL;DR: Fix this in Ironclad by acting on the exact problem first: in Ironclad, open the executed NDA record in the repository, check that its indexing status and extracted text are present, trigger a reindex of that one record, and confirm a search for a phrase from the document returns it. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one executed agreement or repository record first, then rerun the full scope and reconcile the results.