Application Fill

Insurance applications completed from the information brokers already have.

Built by Mahmoud Ebied, Application Fill turns a completed application or a collection of submission documents into filled insurance PDFs, with field-level provenance and a broker review workflow.

I built this for brokerage work, sold it into brokerages, and used it as one of my most-used tools. Customer brokerages reported a 95% success rate when supplying submission documents or one completed application. Development first established strong performance on ACORD forms, then expanded into specialty applications through progressively harder test cases.

Explore the workflow · Read the architecture · Inspect every feature · Understand the results · Run locally

Why I built it

Brokers repeatedly move the same business information between documents: a prior application, a policy, a location or vehicle schedule, and each insurer's own application. Questions recur, but field names, layouts, sections and required calculations vary.

Application Fill handles that transfer while keeping the broker in control. It supports both one completed application → other applications and multiple submission documents → a target application. The output is a completed PDF that preserves the original form and remains editable.

Practical results and engineering evidence

Evidence	Result	Scope
Brokerage experience	95% reported success with submission documents or a completed application	Customer feedback reported by the author; not a field-accuracy benchmark. Sample size and a standardized success definition are not included here.
Initial ACORD testing	100% accuracy reported by the author on evaluated ACORD forms	Evaluation records will be added later. This repository does not claim 100% on every ACORD form or specialty application.
Specialty expansion	Successful development of broader form handling, deterministic schedule processing, page-aware field discovery and an evaluation framework	Harder stress cases, with the actual historical metric snapshot retained in evaluation documentation.

The specialty tests represent deliberate expansion beyond the initial successful use case. They helped expose layout ambiguities, unavailable source information and aggregation errors, and guided concrete engineering improvements. Their field-level metrics measure a different population and outcome from brokerage-reported practical success.

The broker workflow

1. Create a project. Add a name and submission notes.
2. Upload sources and targets. Supply one completed application or multiple supporting documents, plus one or more blank fillable PDF applications.
3. Process in the background. Discover target fields, extract source facts, match answers and generate filled PDFs. Track processing status and inspect document failures.
4. Review answers beside the PDF. Select field overlays, filter flagged or unfilled answers, inspect confidence and reasoning, and open source documents from attribution.
5. Edit and approve export. Save broker corrections with audit events and regenerate the PDF.
6. Finalize and download. Generate the final artifact from current answers, record its hash and export statistics, and obtain a signed download URL.

What makes the implementation interesting

• PDF engineering: real AcroForm discovery; coordinates and widget-to-page mapping; nearby text enrichment for generic field names; text, checkbox, radio and choice filling; font sizing and overflow handling.
• Multiple document paths: completed applications, PDF policies and loss runs, Excel schedules and Word documents. Text extraction is used where possible, with LlamaParse for OCR-dependent paths.
• Hybrid matching: AI identifies relevant facts and transformations; code applies arithmetic, section gating, constraints and reuse checks. Deterministic spreadsheet parsing handles recognized schedules, with an AI fallback.
• Field-level provenance: source document, attribution, confidence, reasoning and transformation travel with each answer. Broker edits retain their own value and edit metadata.
• Human review: a PDF with status-colored field overlays, a status-filtered review list, source inspection and editable controls.
• Workflow infrastructure: authenticated APIs, Supabase records and storage, Trigger.dev jobs, partial-failure handling, regeneration and finalization.
• Evaluation discipline: answer keys, critical-field scoring, false-fill checks, blank-section checks, source-gap diagnostics, cached/full pipeline modes and regression gates.

Architecture

flowchart LR
    Broker[Broker: sources + target PDFs] --> UI[Next.js review workspace]
    UI --> API[Authenticated API routes]
    API --> DB[(Supabase: projects, documents, fields, audit)]
    API --> Storage[(Document storage)]
    API --> Jobs[Trigger.dev processing]
    Jobs --> Target[PDF fields + page geometry]
    Jobs --> Facts[Source extraction]
    Facts --> Providers[OpenAI / LlamaParse when required]
    Target --> Match[Matching + deterministic checks]
    Facts --> Match
    Match --> Fill[pdf-lib: filled application]
    Match --> DB
    Fill --> Storage
    DB --> Review[Provenance + broker corrections]
    Review --> UI
    UI --> Final[Regeneration + final export]

Loading

Stack: Next.js / React / TypeScript, shadcn/ui / Tailwind, Supabase Auth / Postgres / Storage, Trigger.dev v4, OpenAI, LlamaParse, pdf-lib, PDF.js / react-pdf, SheetJS and Mammoth.

Explore without credentials

pnpm install
pnpm dev

Open http://localhost:3000/demo. The sample uses the real field-review component, PDF viewer and PDF filler with fictional answers. Inspect evidence, edit a value and download a regenerated PDF. Its answers are authored fixtures, not an AI benchmark. No credentials or external processing calls are needed for this sample.

The sample files include a blank application, source application, filled output and a fictional location schedule. Recreate them with pnpm demo:generate.

For the full authenticated application, database and background workers, follow Setup. The live workspace is /app/app-fill.

Where to look in the code

Area	Starting point
End-to-end background pipeline	app-fill-process.ts
Target PDF analysis and page geometry	pdf-target.ts, pdf-text-extract.ts
Source-specific extraction	source-extractors
Matching and arithmetic	matcher.ts, transforms.ts
Review and provenance	review page, components
Original-form output	pdf-filler.ts
Database and authorization	historical schema migration, API routes
Evaluation and regression gates	run-suite.ts, scorer

Validation

pnpm typecheck
pnpm test
pnpm check:public

Offline tests cover PDF page assignment without optional widget page references, editable output and broker precedence, flat-target detection, scoring behavior and schedule transformations. CI runs these checks without provider credentials. See Validation for what was actually checked during extraction.

Scope and project history

This is a standalone extraction of my Application Fill implementation, with its feature code, schema, workers and evaluation tools. The portfolio shell, fictional sample and offline regression tests make that work easier to inspect. The feature map and extraction notes document what was carried over and what was adapted.

Current target support is fillable PDFs; flat target PDFs are rejected. AI-generated answers still require broker review. The preserved storage schema uses a public document bucket; use fictional documents for the reference setup and read the storage notes before adapting it to confidential submissions. Audit events are recorded, but the historical schema does not enforce an immutable audit trail.

Customer documents, credentials and internal evaluation caches are not distributed. ACORD evidence can be added under docs/evidence/acord. ACORD is referenced as a form family; this project is not affiliated with or endorsed by ACORD.