From signed PDF to provable close evidence
FoundryOps verifies the signed close artifact against the approved quote baseline before a deal progresses.
Every extracted value carries path and hash provenance, so reviewers can see exactly how the evidence was produced.
This is not “AI read a PDF.” It is a routed, hash-backed, quote-anchored verification pipeline.
Preflight before extraction
Every close artifact is classified before field extraction runs, so the system knows whether it is looking at native text, a fillable form, a scan, mixed content, or an unknown file shape.
Provenance on every value
Document candidates, evidence rows, fields, and comparisons all carry format, path, and hash provenance so the reviewer can see exactly how each value was obtained.
Quote integrity before close
The signed document is checked against the quote baseline with binary hash comparison and semantic field comparison before close progression is allowed.
The gap nobody talks about
A deal closes. The signed PDF looks clean. The CRM looks clean. The quote baseline is from a different file revision. Nobody notices until finance, audit, or renewal operations inherit the wrong artifact.
That gap between “document found” and “document verified against the quote that was actually approved” is where close errors survive into the books.
Seven steps from attachment to close gate
The pipeline is routed on purpose. Provider-backed paths run first. Vision is fallback. Quote integrity is checked before close progression, not after.
Document Inventory
FoundryOps scans connected signature providers and CRM attachments for contract-like artifacts, ranks the candidates, and records exactly which documents may serve as close evidence.
Classify first, extract second
Before extraction, every close document is classified by format. The run captures confidence, notes, observed hash, and the extraction path that will be used — so the reviewer knows what kind of artifact is being handled.
Trusted sources before fallback
Provider-native and metadata-backed reads run first when available. The chosen extraction path is persisted on the resulting evidence so the reviewer can trace how each value was obtained.
Vision fallback when needed
Native PDFs use text extraction. Scanned or mixed artifacts use OCR/vision. Vision is the fallback path, not the implied default.
Semantic Comparison
FoundryOps compares the shared commercial field set across the signed document and the quote or CRM anchor: amount, term_months, service_start_date, and service_end_date.
Quote Integrity
Observed signed-document fingerprints are persisted per run and compared against approved quote fingerprints when available. Binary outcomes include matched, mismatch, missing_baseline, and missing_observation; binary mismatch is blocking.
Close Gate + Routing
Integrity findings and document discrepancies flow into the existing close-cert packet, review index, search filters, and next-action routing to RevOps or Finance. No separate workflow is required.
The system fails closed
If the document cannot be trusted or does not match the approved quote baseline, the system does not certify the close. No silent downgrade. No green badge without evidence.
- No executed document found across connected providers or CRM attachments
- Multiple candidate contracts with no clear primary — ambiguity unresolved
- Supported commercial fields cannot be reconciled to the configured quote or CRM anchor
- Binary quote integrity returns mismatch against the approved quote baseline
- Required fields are missing from both the signed artifact and the configured anchor
What a run looks like in practice
In this example, the executed PDF preflights as native text and extracts cleanly. Semantic quote integrity matches the commercial fields, but the signed-document hash does not match the approved quote baseline, so close progression is blocked.
| Check | Signed Artifact | Quote / CRM Anchor | Provenance | Rule | Outcome |
|---|---|---|---|---|---|
| Binary Quote Integrity | sha256:91c7f7c3...e21a | sha256:5af2cb84...44bd | Observed signed PDF vs approved CPQ quote | Exact hash match required | Blocking mismatch |
| Amount | $180,000 | $180,000 | Signed PDF (native_text) vs quote anchor | Exact required | Match |
| Term Months | 12 | 12 | Signed PDF (native_text) vs quote anchor | Exact match | Match |
| Service Start | 2026-04-01 | 2026-04-01 | Signed PDF (native_text) vs quote anchor | Within 7 days | Match |
| Service End | 2027-03-31 | 2027-03-31 | Signed PDF (native_text) vs quote anchor | Within 7 days | Match |
| Signature | Signed (2026-03-12) | — | DocuSign provider metadata | Present check | Present |
Audit Summary
4 of 4 semantic quote checks match. Binary quote integrity returns mismatch. The executed PDF is present and readable, but its observed hash does not match the approved CPQ quote baseline. Close progression is blocked and routed through the existing RevOps/Finance flow.
Provider coverage
Provider-backed extraction paths run first where available. Attachment PDFs are preflighted and hashed, with vision fallback when no provider path exists.
DocuSign
Adobe Sign
PandaDoc
Why this is different
No new workflow for your team
Document verification and quote integrity live inside the existing close-cert packet and review surface. Findings route through your current RevOps and Finance flow — no standalone tool to learn.
Works with your signature provider
DocuSign, Adobe Sign, and PandaDoc are first-class extraction paths. Gremlin uses provider APIs before falling back to document parsing.
Catches what field matching misses
Amount, term, and dates can all match while the signed PDF is a different revision than the approved quote. Binary hash comparison catches that.
Auditable by default
Every verification run produces a reviewable packet with extraction path, hash provenance, and comparison results. The evidence survives the run.
See document verification in action
Request a demo to review the verification pipeline, close-cert packet, quote integrity checks, and guided rollout options.
Guided implementation included.