Legal & Contract Analysis

Turning 1.6 Million Raw SEC/SEDAR Filings Into a Clean, De-Duplicated Contract Corpus

How Pfactorial Technologies built the recurring, dual-path ingestion and cleaning pipeline that every downstream contract-analytics system in this engagement depends on.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Every downstream system in our client's contract-analytics stack - search, extraction, domain-specific databases - depends on one thing: a clean, de-duplicated corpus of SEC and SEDAR filings. Raw filings arrive as a messy mix of scanned images, non-agreement correspondence, redacted documents and repeat filings under different accession numbers.

This isn't a one-time cleanup. New filings publish every quarter, and each new batch has to pass through the same cleaning pipeline and merge correctly into an already-cleaned corpus of over 1.5 million documents - without duplicating work or drifting in consistency from one quarter to the next.

Pfactorial built a dual-path ingestion pipeline - one path for machine-readable text, one for OCR recovery of scanned filings - converging into a shared sequence of classification, redaction-filtering and deduplication stages, designed from the start to run indefinitely on a quarterly cadence.

Why this engagement is representative This engagement is the foundational, unglamorous layer every other contract-analytics capability in this project depends on - and it's a clear example of Pfactorial building for a corpus that keeps growing indefinitely, not a fixed one-time dataset.

THE CHALLENGE

Turning a raw, ever-growing filing stream into a trustworthy corpus meant solving problems that don't show up in a one-off cleanup.

1. A meaningful share of filings aren't machine-readable text

Some agreements are filed as scanned images rather than text, and a plain text-based ingestion process would silently drop them entirely without a dedicated recovery path.

2. Filings mix genuine agreements with unrelated material

Press releases, cover letters and correspondence appear alongside real agreements in the same filing stream, and a keyword list built to exclude them was itself found to exclude some genuine agreements.

3. The same agreement is often filed multiple times

Re-filings under different accession numbers create duplicate records unless a dedicated deduplication stage checks new filings against the full existing corpus, not just against the current batch.

4. The pipeline has to stay consistent quarter over quarter

Filtering and classification logic has to produce the same result run after run, or the corpus would drift in quality and consistency as new batches are added indefinitely.

The real brief Not “clean up this dataset” but “build a pipeline that keeps cleaning an ever-growing dataset consistently, forever, on a quarterly cadence.”

THE SOLUTION

Pfactorial built two parallel intake paths - text and OCR - that converge into one shared, rule-based cleaning sequence, with deduplication checked against the full corpus rather than just the incoming batch.

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 2

Figure 2 - Text and OCR intake converge into one standardized, cleaned corpus.

Architectural principles

Dual intake by design, not as a fallback - A dedicated OCR side-pipeline exists specifically to recover agreements that exist only as scanned images, producing output in the same text/PDF/HTML shape as the text path so downstream stages can't tell the two apart.
Rule-based, repeatable filtering - Agreement classification, financial classification and redacted-document detection are all built to be rule-based and repeatable, producing consistent results run after run rather than drifting between quarterly batches.
Corpus-wide deduplication, not batch-local - New filings are checked for duplicates against the full existing corpus, not only against other filings in the same incoming batch.
Quarterly cadence as an architectural assumption - Ingestion is built around the SEC EDGAR quarterly index structure specifically because that's the natural unit new filings arrive in, not an arbitrary batching choice.

CAPABILITIES DELIVERED

Each stage narrows and cleans the corpus, with results tracked at every step.

CAPABILITY	WHAT IT DOES
Dual-path ingestion	Text-based EDGAR intake plus a dedicated OCR path for scanned, image-based filings.
Agreement vs. non-agreement classification	Rule-based filtering extended to a trained classifier after keyword-only filtering proved insufficient.
Financial vs. non-financial classification	Regex-based classification chosen over cosine-similarity after evaluation showed the accuracy gain didn't justify the runtime cost.
Redacted document filtering	Rule-based detection excluding agreements with withheld or blacked-out content from downstream extraction.
Corpus-wide deduplication	Title and date matching followed by content-level comparison, run against the full existing corpus.
Full traceability	Every classification and extraction stage tied to a specific regex reference and notebook, with rollback support via versioned files.

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 3

Figure 3 - From 1.59 million raw agreements to a cleaned, deduplicated corpus.

Design note The non-agreement exclusion keyword list was found to contain genuine agreements - a false-positive problem with a purely rule-based filter. Rather than tuning the keyword list indefinitely, the approach was extended to a trained classification model requiring a golden set of 4,000+ examples per class, treating the limitation as a signal to change methods rather than a bug to patch around.

ENGINEERING FOR SCALE AND RELIABILITY

Six decisions keep the pipeline trustworthy as it runs indefinitely against a corpus that never stops growing.

Evaluated alternatives on runtime, not just accuracy

Cosine-similarity-based financial classification performed well but its runtime cost didn't justify the marginal accuracy gain over regex - so the faster method was adopted for production, an explicit cost/accuracy tradeoff rather than a default to the fancier approach.

Golden-set manual verification at every classification stage

Financial/non-financial and redacted/non-redacted classifications were each checked against manually verified golden sets (479 and 500 agreements respectively) before being trusted at full-corpus scale.

Multi-signal deduplication

Title matching, then date comparison, then content-level duplicate checking, then redaction-status comparison - a staged approach rather than a single similarity threshold.

Documented, not hidden, structural limitations

Exhibit-number fragmentation (single filings appearing as multiple partial 'agreements') and amendment-to-original mapping are both recorded as known, only partially solved problems - with the two tested approaches for amendment mapping documented as insufficient for production rather than silently shipped.

Independent stage logging and rollback

Each classification and extraction stage is tied to a specific regex pattern reference and notebook, checked in independently, with older versions retained under a '_revert' naming convention for independent rollback.

Hosted, traceable execution

Key stages run as hosted notebook services with logged outputs, so any given result can be traced back to the specific code that produced it - important for a pipeline that keeps running quarter after quarter.

DELIVERY APPROACH

The engagement built the dual intake paths first, then the shared cleaning sequence, with deduplication and traceability as later-stage hardening.

1. Text intake pipeline (Path A) - automated EDGAR index download, good-filing categorization, and keyword-based agreement detection.

2. OCR recovery pipeline (Path B) - image detection, OCR extraction, and re-verification against agreement keywords for scanned filings.

3. Agreement classification - rule-based filtering extended to a trained classifier after keyword-only limitations surfaced.

4. Financial and redaction classification - evaluated approaches (regex vs. cosine similarity) with production method selected on cost/accuracy tradeoff.

5. Corpus-wide deduplication - title, date and content-based duplicate detection run against the full 1.4M+ agreement corpus.

6. Traceability and quarterly automation - hosted logging, versioned rollback, and the recurring quarterly ingestion cadence.

RESULTS AND IMPACT

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 4

Figure 4 - Key outcomes from this engagement.

The pipeline turned a raw, ever-growing filing stream into a clean corpus of 1,589,567 unique agreements at snapshot, with 68,426 previously-inaccessible scanned agreements recovered via OCR.

Every downstream system in the engagement - the Contract Application, the Core Extraction Engine, and the Lease/Service Fee/Royalty databases - depends on this corpus, making its consistency and quarterly reliability foundational to everything built on top of it.

What it enabled commercially

The client got a self-sustaining data foundation that keeps producing a clean, trustworthy corpus every quarter without manual reprocessing, letting every downstream analytics and extraction capability build on a consistent base rather than re-solving data quality problems repeatedly.

WHY PFACTORIAL

This engagement reflects Pfactorial's willingness to build the unglamorous foundational layer - OCR recovery, keyword classification, deduplication, quarter-over-quarter consistency - that every more visible downstream capability actually depends on.

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organizations that need a large, continuously-growing document corpus turned into a clean, trustworthy foundation for downstream analytics. If you're evaluating a large-scale document ingestion and cleaning initiative, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_Material_Contract_Processing_Pipeline image 6

© 2026 Pfactorial Technologies. Client identity and product-specific implementation detail are withheld or generalized; no client data, credentials, source code, or infrastructure detail is included in this document.

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built the recurring, dual-path ingestion and cleaning pipeline that every downstream contract-analytics system in this engagement depends on.