Legal & Contract Analysis

An Analyst Search Application Over a 1.6-Million-Contract Corpus

How Pfactorial Technologies built the extraction engine and analyst-facing search application that turns a raw contract corpus into structured, filterable records.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_Contract_Application_Search image 1

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

EXECUTIVE SUMMARY

Our client had a large corpus of cleaned contract text and no way for analysts to actually work with it - no search, no filtering by fee terms or industry, no way to find agreements by clause type without reading them one by one.

The structured fields that make a contract corpus searchable - title, fee type, parties, clause type, effective dates - don't exist in raw agreement text. They have to be extracted, and extraction quality directly determines whether the resulting search application is actually useful or just a database of noise.

Pfactorial built both halves of the system together: a Core Extraction Engine combining QA, NER and rule-based models to produce the structured fields, and an analyst-facing application with combinable filters, full-text search and a REST API, backed by two purpose-built data stores.

Why this engagement is representative This engagement shows Pfactorial building both ends of a data product at once - the extraction layer that creates structured value, and the application layer that makes that value usable - where neither half is worth anything without the other.

THE CHALLENGE

A cleaned text corpus and a usable analyst tool are two very different things. Three problems stood between them.

1. Structured fields don't exist in raw text

Title, fee terms, clause type and parties all have to be extracted from unstructured agreement text before an analyst can filter by any of them - the application has nothing to filter on without this layer.

2. No single extraction method works for every field

Structured fields like dates respond well to rule-based patterns; free-form fields like titles need a learned model; different approaches had to be evaluated per field rather than picking one method for everything.

3. Different extraction outputs need different storage

Metadata is relatively fixed per agreement, while fee results have a variable, flexible structure per agreement - a single database design couldn't serve both well.

The real brief Not “build a search box” but “build the structured data the search box depends on, and the application that makes it useful to an analyst.”

THE SOLUTION

Pfactorial built a forward data flow: extraction runs write structured fields into two purpose-matched data stores, and the application only ever reads back through an API layer.

Pfactorial_Case_Study_Contract_Application_Search image 2

Figure 2 - Extraction writes forward; the application reads back through the API.

Architectural principles

Per-field extraction method selection - QA models (RoBERTa/DeBERTa on CUAD) and NER models were evaluated against regex for title extraction, with each field type matched to whichever technique performed best rather than a single method applied everywhere.
Storage matched to data shape - PostgreSQL holds agreement and company metadata, which is relatively fixed per record; MongoDB holds fee extraction results, which need a flexible document structure for varying numbers of fee mentions per agreement.
Independent, combinable filters - Agreement type, fee terms, industry, company and free-text search are each independent filters that combine, with their own result counts, rather than a single monolithic search query.
API-first access - Search and filter results are exposed as API calls with the same parameters as the UI, so the corpus is consumable programmatically, not just through the analyst-facing screen.

CAPABILITIES DELIVERED

Each capability gives analysts a way to narrow 1.6 million agreements down to the ones that actually matter for their question.

CAPABILITY	WHAT IT DOES
Multi-dimension filtering	Agreement type, fee terms, industry (SIC), company/CIK, filed-date range, and clause type - independently combinable.
Three-section keyword search	Title, recitals and full-text search, each returning its own result count.
Clause-type search	Agreements matching a clause type shown with their corresponding clause section, separated from fee excerpts and recitals.
Project workflow	Analysts can add agreements to a project, remove them, or like them directly from search results.
REST API access	Every filter and search parameter available in the UI is also exposed programmatically.
Document viewer	Full agreement view in a separate window without leaving the results list.

Pfactorial_Case_Study_Contract_Application_Search image 3

Figure 3 - Three extraction tracks converge into one structured-fields output.

Design note Clause-type search was deliberately redesigned to filter by clause type alone rather than requiring a keyword match within it - a small change that made the primary, left-positioned filter dramatically more usable for analysts who know what clause they're looking for but not the exact wording.

ENGINEERING FOR SCALE AND RELIABILITY

At 1.6 million agreements, extraction errors compound fast. Five decisions kept the structured output trustworthy.

CUAD-pretrained models for legal text

RoBERTa and DeBERTa models pre-trained on the Contract Understanding Atticus Dataset outperformed general-purpose QA models for title extraction, reflecting the value of domain-specific pretraining over generic models.

Purpose-trained NER alongside QA

A spaCy NER model trained specifically for title extraction on manually created annotations was evaluated in parallel with the QA approach, rather than committing to one method upfront.

Denominator-aware volume tracking

Extraction output volumes are tracked against field-specific eligible bases (e.g. fee types against non-financial, non-redacted agreements) rather than a single blanket corpus count, keeping coverage metrics honest.

Documented, evolving filter logic

The clause-matching approach was revised after initial deployment - changing from keyword-plus-clause-type to clause-type-alone - with the change explicitly documented and dated rather than silently replacing the old behavior.

Default exclusion categories

A defined list of agreement categories is excluded from clause-type search and from API results by default, keeping the application scoped to the categories it's actually designed for.

DELIVERY APPROACH

The engagement built the extraction engine and application layer together, since one has no value without the other.

1. Extraction method evaluation - comparing QA, NER and rule-based approaches per field type against a common sample set.

2. Core Extraction Engine build - parallel QA, NER and rule-based model tracks producing title, fee, clause-type and date fields.

3. Data store design - PostgreSQL for fixed metadata, MongoDB for variable-structure fee results.

4. Filtering layer & API - combinable filters, three-section keyword search, and REST API parameter parity with the UI.

5. Iteration on real usage - revising clause-type search based on observed analyst filtering behavior.

RESULTS AND IMPACT

Pfactorial_Case_Study_Contract_Application_Search image 4

Figure 4 - Key outcomes from this engagement.

Analysts can now filter and search a 1.6-million-agreement corpus by fee terms, industry, company and clause type in seconds, instead of manually reading agreements to find relevant terms.

The API layer lets the client's engineering team consume the same structured data programmatically, extending the corpus's value beyond the analyst-facing UI.

What it enabled commercially

The client's structured contract data went from unusable raw text to an analyst-searchable, API-accessible asset, unlocking use cases - fee-term benchmarking, clause-type analysis at scale - that were simply not possible against the raw corpus.

WHY PFACTORIAL

This engagement reflects Pfactorial's ability to deliver a complete data product - extraction and application together - rather than treating structured-data extraction as separable from the tool that makes it useful.

Pfactorial_Case_Study_Contract_Application_Search image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organizations sitting on large text corpora that need to become structured, searchable assets. If you're evaluating a document extraction and search application, 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_Contract_Application_Search 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 extraction engine and analyst-facing search application that turns a raw contract corpus into structured, filterable records.