You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the current architecture when someone submits a description or transcription, even if the description doesn't contains the mandatory fields, the form will be completed, their are no checks to look for that. The current code implementation just marks the field with -1 which is eventually marked as None.
For something like a CAL FIRE incident report, that's a real problem. A field being blank isn't always obvious until someone reviews the printed form.
The Idea
I propose an architecture such that after the first LLM pass, instead of immediately generating the PDF, show the user which fields came back empty and ask them to speak again specifically about those. Run that second input through the LLM, fill in what it finds, and if there's still something missing — ask once more.
Something like:
"We couldn't extract: Supervisor Name, Phone Number. Can you say those again?"
flowchart TD
A[User submits transcription] --> B[LLM pass on all fields]
B --> C{Any fields = -1?}
C -- No --> D[Generate & return filled PDF]
C -- Yes --> E[Show missing fields to user on UI]
E --> F{User action}
F -- Speak again --> G[Append new transcript to previous]
G --> H[LLM pass on missing fields only]
H --> C
F -- Skip field --> I[Mark field as blank]
I --> C
F -- Max 3 attempts reached --> J[Generate PDF with remaining blanks + warn user]
Loading
Keep doing this until everything is filled — or the user explicitly says they don't have a value for something and skips it.
A Few Things Worth Thinking Through
Each new voice input should be combined with the previous transcript before being sent to the LLM, not processed in isolation. Otherwise references like "same department as I mentioned" won't resolve.
There should be a skip option per field and a max retry cap (maybe 3 attempts) so the loop has a clean exit even when the user genuinely doesn't have a value.
Only the still-missing fields should go through the LLM on each subsequent pass — no need to re-process fields that already have values.
Why This Matters
FireForm's whole premise is that non-technical users in the field can fill forms with their voice. Asking them to re-record a perfect end-to-end transcript is unrealistic. An iterative loop makes the experience forgiving and actually usable in the field.
The Problem
Based on the current architecture when someone submits a description or transcription, even if the description doesn't contains the mandatory fields, the form will be completed, their are no checks to look for that. The current code implementation just marks the field with -1 which is eventually marked as None.
For something like a CAL FIRE incident report, that's a real problem. A field being blank isn't always obvious until someone reviews the printed form.
The Idea
I propose an architecture such that after the first LLM pass, instead of immediately generating the PDF, show the user which fields came back empty and ask them to speak again specifically about those. Run that second input through the LLM, fill in what it finds, and if there's still something missing — ask once more.
Something like:
flowchart TD A[User submits transcription] --> B[LLM pass on all fields] B --> C{Any fields = -1?} C -- No --> D[Generate & return filled PDF] C -- Yes --> E[Show missing fields to user on UI] E --> F{User action} F -- Speak again --> G[Append new transcript to previous] G --> H[LLM pass on missing fields only] H --> C F -- Skip field --> I[Mark field as blank] I --> C F -- Max 3 attempts reached --> J[Generate PDF with remaining blanks + warn user]Keep doing this until everything is filled — or the user explicitly says they don't have a value for something and skips it.
A Few Things Worth Thinking Through
Why This Matters
FireForm's whole premise is that non-technical users in the field can fill forms with their voice. Asking them to re-record a perfect end-to-end transcript is unrealistic. An iterative loop makes the experience forgiving and actually usable in the field.