Back
OCR & Document Extraction

Scoping an AI-Powered Form Automation System That Learns From Prior Submissions

A three-phase design for turning unstructured inquiry documents into accurately filled forms, with the hardest problem - reliably extracting the right information - identified and scoped as the primary engineering focus before any of it was built.

August 21, 2026
Share
ENGAGEMENT SNAPSHOT

CS-028_AI_Form_Automation image 1
Figure 1 - Key figures from this engagement, at a glance.
EXECUTIVE SUMMARY
Our client's form-filling workflow depended on someone reading a source document and manually keying its contents into the correct fields - a process this proposal set out to automate, learning from previously filled forms to improve accuracy and reduce manual effort over time.
Pfactorial Technologies scoped the system as a three-phase workflow: extracting text from whatever document format arrives, capturing the specific information that actually needs to go in the form, and then filling the form automatically. The proposal is explicit that the first and third phases are relatively straightforward with existing OCR and automation tooling - the real engineering challenge, and the intended focus of the work, is the middle phase: reliably identifying which extracted text belongs in which field.
The proposed approach combines rule-based extraction, Named Entity Recognition, and AI-powered language models rather than betting on any single technique, informed by a previously delivered resume-builder system that used a comparable OCR-plus-language-model pipeline to populate structured fields from unstructured input.
Why this engagement is representative This engagement demonstrates Pfactorial's approach to scoping automation proposals honestly: naming the genuinely hard part of the problem - accurate information capture, not text extraction or form filling - as the focus of engineering effort, rather than presenting the whole pipeline as equally difficult.
THE CHALLENGE
Manual form filling from unstructured source documents is slow and inconsistent, and the proposal identifies three distinct problems the system needs to solve, of very different difficulty.

1. Source documents arrive in inconsistent formats

Inquiries can appear as text-based PDFs, image-based PDFs, scanned images, or, in rarer cases, hybrid PDF forms mixing both - each requiring a different extraction path before any information capture can happen.

2. Accurately capturing relevant information is the hard part

Text extraction and form filling are relatively straightforward with existing technologies; correctly identifying which piece of extracted text belongs in which field, especially across varied document layouts, is the core challenge the proposal is scoped to focus on.

3. A single extraction technique is not enough on its own

Rule-based extraction alone breaks on layout variation, pure Named Entity Recognition misses context-dependent fields, and language models alone can be inconsistent on structured fields - the proposal combines all three rather than relying on one.

4. Form filling needs to plug into different target systems

Depending on the target system, filling a form can mean populating structured fields directly or automating an external web-based submission, which the system needs to support either way.
The real brief Not "build a form filler" but "solve accurate information capture from unstructured documents, since extraction and form filling are the comparatively easy parts."
THE SOLUTION
Pfactorial proposed a three-phase workflow, explicitly weighting engineering effort toward the middle phase - information capture - as the phase most likely to determine whether the system is actually useful.
CS-028_AI_Form_Automation image 2
Figure 1 - The proposed three-phase workflow: text extraction, information capture, and automated form filling.

Architectural principles

  • Name the hard problem before building around it - the proposal states plainly that extraction and form filling are relatively straightforward, and that information capture - correctly identifying relevant data in extracted text - is where the project's primary engineering effort belongs.
  • Combine extraction techniques rather than choosing one - rule-based extraction and regular expressions, Named Entity Recognition, and AI-powered language models are proposed together, so each technique's blind spots are covered by the others rather than the system depending on a single approach.
  • Handle the input format, not just the ideal case - the system is scoped from the outset to support text-based PDFs, image-based PDFs, scanned images, and hybrid PDF forms, rather than being designed around one clean document type and extended later.
  • Draw on a comparable, already-delivered pattern - a previously built resume-builder system, which used OCR and NLP/LLM techniques with predefined templates to populate structured fields, is cited directly as the pattern this design extends rather than reinvents.
CAPABILITIES DELIVERED
The proposed system's capabilities span the full path from an unstructured inquiry document to a completed form.
CAPABILITY
WHAT IT DOES
Multi-Format Text Extraction
Processes text-based PDFs, image-based PDFs, scanned images, and hybrid PDF forms through OCR and text-parsing pipelines.
Rule-Based Extraction
Applies predefined rules and regular expressions to pull structured values from predictable document patterns.
Named Entity Recognition
Identifies and labels relevant entities within extracted text as a complement to rule-based matching.
AI-Powered Information Capture
Uses language models to interpret context-dependent or less-structured information that rules and NER alone would miss.
Automated Form Filling
Populates structured target fields directly, or automates external web-based form submission using browser automation where direct integration isn't available.
Learning From Prior Submissions
Uses previously filled forms as a reference to improve extraction accuracy and reduce manual correction over time.
CS-028_AI_Form_Automation image 3
Figure 2 - Why information capture, not extraction or filling, is the phase the engagement is scoped around.
Design note This proposal is a design-stage scoping document: no system has been built or delivered against it, and the source material does not include performance results, accuracy figures, or a production deployment. The one delivered reference point cited is a separate, previously built resume-builder system that uses a comparable OCR-plus-language-model approach.
ENGINEERING FOR SCALE AND RELIABILITY
The proposal's scoping decisions concentrate effort on the part of the problem most likely to determine real-world usefulness, rather than spreading effort evenly across all three phases.

Effort is weighted, not evenly distributed

the proposal states directly that extraction and filling are relatively simple with existing tooling, and structures the project so that the majority of design and engineering attention goes to information capture.

Three extraction techniques, chosen for complementary coverage

rule-based extraction, Named Entity Recognition, and AI-powered models are proposed together specifically because each is expected to catch cases the others miss, rather than any one being sufficient alone.

Form filling is scoped for two integration paths

the design accounts for both direct integration with a target system's structured fields and external automation via tools such as Selenium for web-based form submission, rather than assuming one integration path fits every target system.

A prior delivered system as a concrete reference point

the previously built resume-builder system - OCR plus NLP/LLM parsing plus predefined templates - is cited as evidence this general pattern has worked before, giving the proposal a real precedent rather than a purely theoretical design.

Scope is explicit about what is deferred

the source material sets out a broad recommended technology stack without committing to every element, leaving specific technology selection (for example, among Tesseract OCR, Google Document AI, and AWS Textract) as a decision to be finalized during implementation.
DELIVERY APPROACH
As a proposal, the engagement's delivery plan is scoped as a build for the three phases described, rather than reflecting phases already executed.
1. Text extraction - build the OCR and text-parsing pipeline covering text-based PDFs, image-based PDFs, scanned images, and hybrid PDF forms.
2. Information capture - implement and combine rule-based extraction, Named Entity Recognition, and AI-powered models as the project's primary engineering focus.
3. Automated form filling - implement direct field population where the target system allows it, and browser-based automation where it does not.
4. Validate against real form types - test extraction accuracy and form-filling correctness against representative real-world documents before wider rollout.
RESULTS AND IMPACT

CS-028_AI_Form_Automation image 4
Figure - Key outcomes from this engagement.
As a proposal, the source material does not report delivered accuracy figures, processing volumes, or production results - and none are represented here as such. What the proposal does establish is a scoped, three-phase architecture with the hardest sub-problem, information capture, explicitly identified as the primary engineering focus.
The proposed design is grounded in a real precedent: a previously delivered resume-builder system using a comparable OCR-plus-language-model extraction approach, giving the client a concrete reference point for what a similar architecture has produced before, rather than a purely speculative design.

What it enabled commercially

If built as proposed, the system is intended to reduce the manual effort of reading source documents and re-keying their contents into forms, with accuracy expected to improve over time as the system learns from previously filled forms rather than staying static.
WHY PFACTORIAL
This engagement draws on Pfactorial's AI product engineering capability: scoping automation proposals around the genuinely hard sub-problem rather than the parts existing tooling already solves well, and grounding new designs in patterns already proven on comparable, delivered systems.
CS-028_AI_Form_Automation image 5
Figure - Service lines this engagement draws on.
Engagement enquiries Pfactorial Technologies works with teams evaluating whether a form-automation or document-extraction problem is worth solving properly. If you are scoping a project where accurate information capture is the real challenge, we are happy to give you an honest read on scope, cost, 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.
CS-028_AI_Form_Automation image 6

Result and Analysis

ENGAGEMENT SNAPSHOT

A three-phase design for turning unstructured inquiry documents into accurately filled forms, with the hardest problem - reliably extracting the right information - identified and scoped as the primary engineering focus before any of it was built.

CS-028_AI_Form_Automation image 1
CS-028_AI_Form_Automation image 2
CS-028_AI_Form_Automation image 3
CS-028_AI_Form_Automation image 4
CS-028_AI_Form_Automation image 5
CS-028_AI_Form_Automation image 6