Filly AI

Dear Gal, Thank you very much for your Feedback!

Dear Miguel, thank you very much for your useful feedback. Noted for implementation.

You've put your finger on the right trust axis, so let me be precise about where Filly actually sits — including where it doesn't. On editability: yes, and it's deliberate. When you describe a document in plain English, what comes back isn't a black box — it's a typed field schema you can open and change. Every field the AI inferred is editable: its label, its type (text, date, boolean, select, currency, number, signature), whether it's required, and the options on a select. You can add fields it missed or delete ones it invented. Then at fill time, every value is colour-coded by confidence and you can correct any of it before a single thing is exported or sent. Nothing leaves without you approving it. And the corrections stick: remap a field or nudge one into place once, and Filly saves that to the form — so the next fill is deterministic rather than re-guessed. But I should be straight about scope, because your comment describes something bigger than what Filly is today. It generates a fillable document — a typed field schema plus the body — not a workflow engine. There's no conditional-logic or validation-rule layer, and there are no downstream workflow steps to publish. So "I know the process I need" → "the process is live" is a promise I'm not going to make yet. What it does collapse is the narrower gap: "I need this document, filled correctly, for this person" → filled from a saved profile, reviewed, signed, and remembered for next time. If conditional logic and validation are the actual blocker in your process, I'd genuinely like to hear the specific workflow. That's a far better roadmap signal than me nodding along.

Dear Richie, thank you very much for your feedback. honestly it means a lot to me in this stage.

Thank you so much for your feedback!

Dear Haowen, Thank you verymuch for the feedback! yes, all corrections will be saved for future use.

Dear Cina, thank you very much!

Great question — you've put your finger on exactly the hard part, so let me be straight rather than quote a number I can't back up. There are two paths under the hood. If the PDF has a real AcroForm layer, it's deterministic. We read the actual field objects out of the PDF — type, rect, page, radio groups — and fill them natively. No guessing, and the export is pixel-identical to the original. If it's flat or scanned (i.e. the government reality), there's no field layer to read. So: OCR for the text, then an AI + geometry pass that locates the blanks and checkbox squares from the rendered layout and builds a typed field map — label, type (text / checkbox / radio / date / signature), page, and bounding box. On your multi-page point: the whole document's text goes to the model in one pass, not page-by-page. So a field on p7 can be resolved from a definition on p2. Each detected field keeps its page and rect, so placement stays correct even when the semantics came from elsewhere. But the thing that actually makes "my info → the right field" reliable isn't the first pass — it's that the field map and your per-form mappings are persisted. The first fill of a nasty 10-pager may need you to correct a few fields in review; every fill of that form afterwards is deterministic and instant. It stops being a guess. Nothing exports without a human review step — values are colour-coded by confidence, and you can drag, retype, toggle checkboxes, or drop in a field where the AI missed one. On accuracy: I don't have a benchmark I'd defend publicly yet, so I won't invent one. What I can tell you is where it's been weakest — nested-table checkbox groups were the worst area (long forms were silently truncating the detected field list; we fixed that this week), and a few structurally-broken government PDFs fail to parse outright, where we tell you so rather than silently mangle the output. If you've got a specific scanned 10-pager that's been beating other tools, send it over. That's exactly the case I'd rather fail on in private than in your workflow.

Thanks — and yes, that's exactly the bet. A one-off autofill saves you five minutes once; a saved profile compounds every time the same client hits a new form. On the page-3-depends-on-page-1 case, let me split it in two, because they behave very differently: Consistency — the same value appearing in several places (name, SSN, case number, entity type). This one is genuinely solved, and solved deterministically: every instance is filled from the one client profile, so page 1 and page 3 can't disagree with each other. That's the class of error most autofill tools actually make, and profiles kill it by construction rather than by guessing well. Derived values — "enter the amount from line 12", or "if you checked 3a, skip to line 7". Here I'll be straight with you: there's no computed-field engine. The model does see the entire document's text in a single pass rather than page-by-page, so it usually understands the reference — but I'm not going to dress that up as a dependency graph. Those land in the review step flagged for you instead of being silently guessed. I'd rather you correct one field than unknowingly trust a wrong one. On scanned / non-fillable: there's no field layer to read, so we OCR the text, then an AI + geometry pass locates the blanks and checkbox squares and builds a typed field map with page and bounding box. Anything it can't confidently place surfaces as an unplaced value you can drop into position (or have a vision pass place for you). The part that matters: once placement is right for that form, it's persisted — every future fill of it is exact and instant. So the honest version: the first pass on a nasty scan may need a nudge. The second one shouldn't. If HR paperwork is your world, that's squarely who this is for — I'd love to hear which forms are eating your week.

plugin is in the roadmap

Ha — appreciate the skepticism, and since you build these too I'll skip the pitch. You're right that scans are where it's weakest, so let me tell you what actually happens rather than claim it holds up. Two paths. If the PDF has a real AcroForm layer, we read the field objects straight out of it — type, rect, page, radio groups — and it's deterministic. Boring, works. If it's flat or scanned there's no field layer to read, so: OCR the text, then an AI + geometry pass that locates the blanks and checkbox squares from the rendered layout and builds a typed field map — label, type, page, bounding box. On a clean scan that's fine. On a photocopy of a photocopy, it degrades. Exactly like you'd expect, and I'm not going to pretend otherwise. What I optimised for instead is failing loudly. The dangerous failure in this category isn't a missed field — it's a confidently wrong one. So anything the model can't place with confidence doesn't get silently dropped or guessed into the neighbouring box; it surfaces as an unplaced value, flagged, that you drag into position (or have a vision pass place). Everything's colour-coded by confidence and nothing exports without you approving it. Two specifics, since you'd find them anyway: - Nested-table checkbox groups were the worst area. On long forms the detected field list was silently truncating — that was a real bug, fixed this week. - A handful of structurally broken government PDFs (dangling page-tree refs) fail to parse outright. We now say so and tell you to re-save, rather than quietly mangling the output. And the part that actually matters for your photocopy scenario: corrections persist. Fix the placement on that awful county form once and it's saved to that form — every future fill of it is exact and instant. First pass may need a nudge; the second shouldn't. No accuracy benchmark I'd defend publicly, so I won't quote one. If you've got a genuinely cursed scan, send it over — I'd much rather it fail on my machine than yours.

yes i did