Staff already scan and email filled forms today. This is the other half of the fill engine — instead of Mortware-style manual re-entry after a scan lands in an inbox, the scan files itself.
Kearney already scans filled forms and emails them to an internal address — someone eyeballs the scan, files it into a SharePoint folder named for the deceased, and re-keys anything Mortware, SRS, or an internal spreadsheet needs later. Staff don't need to learn a new habit. RequiemOS intercepts that same email, replaces the SharePoint folder with the case's own document library, and — where it can — skips the re-keying step entirely.
A form can arrive filled in three different ways, and each implies a different amount of work for the platform to do with it.
RequiemOS generates the form and the signature is digital, start to finish. Nothing to ingest — this is the existing Documents & Signing pipeline, unchanged.
Already builtRequiemOS pre-fills and prints the form; staff add checkboxes, write-ins, or a wet-ink signature by hand before it comes back scanned. We already know most of what's on the page.
This document — primary caseA flat, third-party, or uncatalogued form — BC Death Registration, hospital notes — printed and completely hand-filled. We know nothing about the page except that it exists.
Filing works today · mining is future work"AI reads the scan" is the wrong mental model. Case identification and checkbox reading are both deterministic; a vision model only ever sees free-text handwriting, and only when someone actually wants that data extracted.
Every ingested scan runs the first three steps. The rest only run if a document's content is actually wanted, not just its filing.
A deterministic library read — no AI involved. If the form was generated by RequiemOS and stamped with its case-identifying code, this step alone resolves the case.
No QR, or it didn't decode? Fall to a printed case number wherever the form carries one (still typed text, still cheap), then to matching the extracted name and date of birth against existing cases. Ordinary matching logic — never a judgment call.
Every scan that reaches a case gets filed here, visible in the case's right-nav, whether or not anything below this line ever runs. This step alone replaces the SharePoint folder.
Optional — runs only when someone wants this document's data mined, not just filed. A vision model transcribes free-text fields: names, dates, addresses.
Also optional, and deliberately not a vision-LLM call. A coordinate-threshold check against the form's known widget positions — no AI involved. Whether this holds up on real messy scans is being tested in isolation before it ships.
Nothing above this line writes to the case. Extracted values are proposals, shown for accept, edit, or reject — the same posture the platform already uses for at-need conversion.
Same write path as any other case update. Ingestion never gets a shortcut around it.
Filing and mining are two different jobs. Every scan gets filed. Only some get mined — and mining can fail completely without losing the document.Scanned Form Ingestion — Scope & Validation Plan
The fast path (step 1) only exists for forms RequiemOS generated in the first place. That means adding a small stamped QR to the templates we want to round-trip cleanly.
Reuses the same stamping mechanism already used for the document-identity QR on generated PDFs — same pipeline, a different payload, same per-template placement setting. A footer corner is a common choice when there's room, but the header, a margin, or wherever the layout has space works just as well; placement isn't fixed to one spot on the page. Not every template needs it: family-facing keepsakes and government forms opt out, same as they already do for the existing QR.
Nothing changes about how staff produce a filled form — they scan and email it, exactly like now. What happens after the email lands is where the work moves.