Turning patent PDF extraction into analyst-ready delivery through structural invariants.
Companies with large patent portfolios do not need another system that says it can extract text from PDFs.
They need a system that turns difficult patent documents into reliable, analyst-ready data.
That difference is the work.
In one engineering session, several USPTO grant PDF patterns were identified, tested, and reduced to executable validation logic. These were not assumptions and not marketing claims. Each pattern had to survive actual commands against a batch of 7,923 USPTO grant PDFs retrieved through the API.
One invariant connects the parser-derived page count to the value encoded in the PDF subject field:
countif((page_count != main."substring"(subject, 2, 3))) count_star()
-------------------------------------------------------- ------------
0 7923
This is a punishing test. For every row, the system compares the parsed page count against the exact subject segment. countif counts every mismatch. The result is zero only if all 7,923 files pass.
One mismatch means the rule is not structural. It cannot become pipeline logic.
A second invariant proves the USPTO title pattern:
countif((((len(title) - 2) - len(regexp_extract(title, '[0]{4,6}'))) = 18))
---------------------------------------------------------------------------
7923
The rule is exact: remove the fixed US prefix, remove the zero-padding block defined as [0]{4,6}, and the remaining identifier must be 18 characters. Across the full batch, it is.
A third control signal comes from the PDF creation timestamp. This value is captured from raw PDF metadata before OCR, before text conversion, and before field extraction:
SELECT max(CAST(substring(creationdate,3) AS BIGINT)) FROM file;
max(CAST(main."substring"(creationdate, 3) AS BIGINT))
------------------------------------------------------
20260319171846
SELECT min(CAST(substring(creationdate,3) AS BIGINT)) FROM file;
min(CAST(main."substring"(creationdate, 3) AS BIGINT))
------------------------------------------------------
20260309165515
The substring(creationdate,3) is deliberate. The PDF date prefix is fixed, so the ordered timestamp begins at the third position. No regex is used because the deterministic operation is simpler, faster, and more suitable for scale.
That metadata timestamp becomes an independent boundary for later extraction. After the PDF is converted and a filing-date candidate is extracted from the conversion output, the candidate must satisfy the file-level chronology:
filing_date_candidate_from_conversion_output <= pdf_creation_timestamp_from_metadata
If it does not, the extraction is invalid. Not low-confidence. Not queued for review. Invalid.
This is why the approach is different from standard OCR, PDF conversion, or generic document AI.
Those systems usually stop at extraction: text, fields, entities, coordinates, normalized values. This system goes further. It discovers the document-standard structure, expresses it as commands, tests it across the full batch, and promotes only the patterns that hold without exception.
That is the difference between extracting and delivering.
Extracting means producing candidate output. Delivering means proving which output is allowed to enter the data model.
The pipeline is built from exact checks: page count against subject structure, title length against prefix and padding rules, metadata timestamps against extracted filing dates, file identifiers against metadata identifiers, page geometry against per-page indexes. Each check is independent. Each check is executable. Each check either holds or fails.
There is no hidden tolerance for almost-correct patterns. No try/except path that turns structural failure into usable data. No human review loop required to make the result acceptable. If a rule fails once within its intended scope, it is removed or the feature is redesigned.
This is the standard that makes the system suitable for client infrastructure. The work is done before deployment: identify the invariant, prove it on real documents, encode it as an assertion, and let the pipeline enforce it at scale.
The value is not that the system can read a patent PDF. Many tools can produce converted text. The value is that the system can determine which extracted patent facts are structurally valid, connect them to cleaner sources such as XML and API records, reject impossible values, and deliver data analysts can use without re-checking every document.
We do not stop at extraction. We deliver patent data that has survived the document’s own evidence.