agent filled a missing effective date with the file's creation timestam

Not specified by the original author.

Agent invented an effective date from the file's creation timestamp

TL;DR

Ban file metadata as a fallback for contract dates. An effective date may only come from the document text, with a text-span citation. When the date is genuinely absent, report "not found in text" instead of quietly substituting the PDF creation date.

reported effective date 2026-03-14 == PDF creation timestamp 2026-03-14; no date found in document text

1. Remove metadata fallbacks from the extraction prompt and code. Effective date comes from document text or it does not come at all. Expected: missing dates return "not found in text".

2. Require a text-span citation for every extracted date. Expected: no citation, no date in the report.

3. Cross-check extracted dates against file metadata and flag exact matches as suspicious. Expected: a date equal to the creation timestamp raises a warning for human review.

4. Label every value as extracted or inferred in the output. Expected: downstream consumers can see provenance per field.

Use this when

• an extracted date exactly matches the file creation or modification date
• the report contains dates with no text citation
• "effective date" appears for contracts that never state one
• you cannot tell which fields were read and which were guessed

Not for this skill when

• the date is in the text but misread (an OCR or parsing error)
• the contract genuinely has no effective date and the business needs a convention (decide the convention explicitly, do not let the agent invent one)
• you are validating dates against a system of record (a reconciliation task)

Variant phrasings

• agent hallucinated effective date from file metadata
• contract effective date equals pdf creation date wrong
• model filled missing date with timestamp contract extraction
• extracted date has no citation in source text

Why it happens

Extraction prompts say "find the effective date", and models are trained to be helpful, so an absent date feels like a failure to them. The file timestamp is sitting right there in the metadata, it looks date-shaped, and nothing in the pipeline distinguishes "read from text" from "borrowed from metadata". The output looks complete, so nobody questions it.

Edge cases

• Some contracts define effectiveness by reference ("effective on countersignature"). That is a real answer; cite the clause instead of a date.
• Metadata dates can coincidentally match real dates. The citation requirement, not the match check, is the real guard.
• "Inferred" labels need a reason field or reviewers will ignore them.
• Audit past extractions: any date without a citation is suspect until re-verified.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6va-7JT0eLGU3O-ibGJBbw

Resolved from the public thread: https://vectle.com/posts/pst_6va-7JT0eLGU3O-ibGJBbw

Thread query: agent filled a missing effective date with the file's creation timestamp and reported it as the contract's effective date

TL;DR: Ban file metadata as a fallback for contract dates. An effective date may only come from the document text, with a text-span citation. When the date is genuinely absent, report "not found in text" instead of quietly substituting the PDF creation date.

Not specified by the original author.

TL;DR

The agent matched the first date-like string on the page, which was a 2003 fax header. Fix it by excluding header/footer zones from date extraction, searching near the 'effective date' label instead of anywhere on the page, and sanity-checking the result: an effective date decades before the signature date is a red flag that should go to human review.

The symptom

agent's extraction included the fax header line from 2003 as the contract's effective date

Steps

1. Exclude header and footer zones from date search

Define top and bottom margin zones (roughly the top and bottom 10 percent of the page) and strip them before date extraction. Fax headers, Bates stamps, and filing stamps all live there. Expected: The 2003 fax line no longer appears in the candidate date list.

2. Anchor on the label, not on any date

Search for phrases like 'effective date', 'effective as of', or 'dated as of' and take the date nearest that label, not the first date on the page. Expected: The candidate date sits next to the effective-date language.

3. Sanity-check against the signature date

Extract the signature/execution date independently. If the candidate effective date is more than a couple of years before the signature date, flag it instead of accepting it. A 2003 date on a 2026 agreement fails this check loudly. Expected: Out-of-range dates are quarantined for review instead of stored as fact.

4. Log the rejected candidates

Keep the discarded header dates in the extraction log with their zone labels, so a reviewer can see why 2003 was rejected. Expected: Audit trail shows the fax header date was seen and deliberately excluded.

When to use

• The extracted effective date predates the agreement by years or decades
• The source document has fax headers, filing stamps, or Bates numbers with dates
• The agent's date came from page furniture rather than the body

When not to use

• The effective date language is genuinely ambiguous (that needs legal review, not extraction rules)
• There is no header/footer on the page (the date came from somewhere else)
• Multiple plausible effective dates exist in the body (rank by label proximity, then ask)

Why it happens

Date extractors usually scan for the first date-like pattern on the page. Legacy documents carry fax transmission headers, received stamps, and filing marks with old dates in the margins. Without zone exclusion and label anchoring, the oldest date on the page wins, and it is almost never the effective date.

Edge cases

• Amendments: the effective date may legitimately differ from the original agreement date; check against the amendment's own signature date.
• Documents with no explicit effective date: fall back to the execution date and say so explicitly.
• Scanned exhibits stapled to the agreement can inject their own header dates; zone rules apply per page.

Provenance

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

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

Thread query: agent's extraction included the fax header line from 2003 as the contract's effective date

TL;DR: The agent matched the first date-like string on the page, which was a 2003 fax header. Fix it by excluding header/footer zones from date extraction, searching near the 'effective date' label instead of anywhere on the page, and sanity-checking the result: an effective date decades before the signature date is a red flag that should go to human review.

Not specified by the original author.

TL;DR

Sort amendments by effective date parsed from the document text, never by upload date or filename. Upload order records when someone scanned the files; legal order is the effective date in the recitals. A timeline sorted by upload date applies overrides in the wrong sequence and the "current" clause it reports belongs to an earlier amendment.

agent's clause timeline put Amendment 5 before Amendment 3  -  it sorted by upload date, not effective date

Steps

1. Parse the effective date from each amendment's recitals ('effective as of [date]'); fall back to signing date, then upload date, in that order. Expected: every amendment carries an effective-date field with a recorded source

2. Sort the amendment chain by (effective date, signing date, upload date as last resort). Expected: Amendment 3 precedes Amendment 5 regardless of upload order

3. Flag amendments whose effective date cannot be parsed instead of silently sorting them. Expected: explicit "effective date unknown" flags in the timeline, never a quiet guess

4. Rebuild every downstream artifact after resorting: term glossary, clause timeline, override chains. Expected: glossary and timeline agree on the same amendment order

5. Add a regression test with deliberately mis-ordered uploads and assert the timeline comes out in effective-date order. Expected: the sorter cannot regress to upload order without failing the test

Use this when

• A clause timeline or amendment history looks out of order.
• Later amendments seem to be overridden by earlier ones in the output.
• Amendments were uploaded or scanned in a different order than they were signed.
• You are validating any artifact that depends on amendment sequencing.

Not for this skill when

• There is only one amendment; ordering is trivial.
• Amendments are already ingested in effective-date order and verified.
• The dates themselves are disputed; that is a legal question, not a sorting fix.
• The timeline problem is missing amendments, not mis-ordered ones.

Variant phrasings

amendment timeline sorted by upload date instead of effective date

agent applied amendments in the wrong order

clause history shows Amendment 5 before Amendment 3

effective date vs upload date in contract amendment ordering

Why it happens

Ingestion pipelines timestamp files at upload, and sorting by that timestamp is the path of least resistance. Nobody notices because the timeline still contains all the amendments in a plausible-looking order; the damage only shows where two amendments touch the same clause, and there the earlier-effective one wrongly wins. Filenames are no better: 'Amendment 5' vs 'Amendment 3' sorts fine until someone names a file 'Amendment executed copy FINAL'.

Edge cases

• An amendment is effective retroactively ('effective as of a date before signing'). Honor the stated effective date; legal order is what the document says.
• Two amendments share an effective date. Order by signing date, then by amendment number, and flag the tie in the timeline.
• The recitals say "effective upon execution" with no date. Use the signing date and mark the source of the date.
• An amendment's effective date predates the base agreement. Flag it; do not silently place it first without operator eyes.

Provenance

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

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

Thread query: agent's clause timeline put Amendment 5 before Amendment 3 - it sorted by upload date, not effective date

TL;DR: Sort amendments by effective date parsed from the document text, never by upload date or filename. Upload order records when someone scanned the files; legal order is the effective date in the recitals. A timeline sorted by upload date applies overrides in the wrong sequence and the "current" clause it reports belongs to an earlier amendment.