MSB
All posts

Field Notes AI: Interviews That Survive a Dead Zone

A look back at an offline-first mobile app that turns recorded field interviews into structured records, built for a client under strict privacy rules.

What the app is for

Field Notes AI was built with a team of six for an industry client whose staff conduct interviews out in the field. Their work produces two things at once: a conversation, and a form that has to be filled in accurately afterwards. The app closes that gap. It transcribes the interview and drafts the structured record from it, so the person who conducted the interview is reviewing and correcting rather than starting from a blank page.

Two constraints shaped almost everything. Connectivity in the field can't be assumed, and the information being captured is sensitive enough to fall under Alberta's privacy legislation: FOIP, HIA, and PIPA.

How it works

A recorded interview goes through Azure Speech Services for transcription. An Azure-hosted language model then reads the transcript and pulls out the information the client's forms ask for. Before any of that reaches a form, the output is validated against what the form expects.

Everything in progress is stored encrypted on the device, so an interview captured with no signal is still safe and still editable. When the device reconnects, records synchronize through authenticated APIs, and every change is written to an audit log so it stays attributable.

What worked

  • Treating offline as a normal state rather than an error. Designing around it from the start means an interview isn't at the mercy of a signal bar.
  • Putting validation between the model and the record. A language model can produce something that reads well and still be wrong for a form, so nothing it returns is trusted by default.
  • Iterating with stakeholders on prompts, validation rules, and error handling, which kept the extraction grounded in what the people using the forms actually need.
  • Building privacy into the data flow itself, with encryption at rest, authenticated APIs, and audit logging as part of the feature rather than added at the end.

The honest trade-offs

Offline-first doesn't make complexity disappear; it moves it into synchronization, where records created on a disconnected device eventually have to reconcile with everything else. And language-model extraction speeds up the paperwork without removing the need for a person to review it. The app is designed around that review step, which is the right design, but it means the time saved depends on how often the draft is already right.

There's also a limit on what I can share. Because this was client work, I can't show the interface in detail, the forms, or anything captured in the field. The screen on this site is sanitized, and this write-up sticks to the parts I can speak about openly.

Key takeaways

  • An LLM feature is only as reliable as the validation between its output and the record it writes.
  • Designing offline as a first-class state removes a whole category of lost-work failures.
  • Under privacy regulation, encryption and attributable changes are part of the product, not extras.