Scoping a policy PDF form job before you buy document AI

The job is not “chat with a PDF.” It is: take a form that already exists on paper or as a file, and emit a structured list of inputs — type, label, section, checkbox default — that another system can trust.

Teams usually arrive with a folder of revisions. Layouts drift. Headings nest. A checkbox that looks empty is sometimes a default. If you skip that map, every later fill or agent step sits on sand.

What the first assessment is for

On a consultancy pass we pick a small, ugly set: one current revision, one older revision, one page that is mostly checkboxes.

We ask what “done” means. Coordinates for a later fill engine? JSON for an eligibility agent? A queue for a reviewer? Those are different builds. The policy form annotation case study is the first of those jobs: parse the page, classify each input, keep geometry, and refuse to invent a field when the model is unsure.

The PDF fill conversion write-up is the next job — only after the annotation is stable. We will say that order out loud. Buying a fill product first is how you pay twice.

When we tell you not to automate yet

If every page still needs a lawyer or case worker to interpret a sentence, software should sit behind that person, not replace them. If the PDFs are scans with no consistent text layer, the first slice is OCR and review, not an agent.

If the schema is clear and the volume is the problem, we scope a pipeline with a second-model check and an audit log. That is AI consultancy first, then a narrow build.

Bring two real files and the downstream system that has to consume the JSON. Book the consult or email hello@jamilglobal.com.