# Personal observer notetaker

Concept v0.1 · 13 September 2026 · Design only, no bot deployed

The observer speaks or types naturally. The notetaker preserves the account, asks a few useful questions and does the classification work in the background. Keep the existing Form available. Decide whether a bot note replaces a Form submission or supplements it before the pilot so the same account is not counted twice.

## A short conversation

**Illustrative example, not an additional exercise observation:**

> Observer: “We planned the same trip twice, once with Logistics and once with Telecoms.”
>
> Bot, after durable storage: “Saved. Which trip or location was this?”
>
> Observer: “The assessment trip to the north camp this afternoon.”
>
> Bot: “What makes you think this was avoidable duplication rather than two different technical tasks?”
>
> Observer: “I don’t know yet. We should compare the plans.”
>
> Bot: “Recorded: two plans reported for a trip to the north camp. Whether they duplicated work is still unclear. Suggested follow-up: compare the plans at debrief. You can add or correct this later.”

This yields a useful raw account and a reality-check question without manufacturing a finding. Do not silently map “north camp” to an official site or turn “this afternoon” into a timestamp when the reporting context is unclear.

## Proposed flow and branches

1. **Receive and save:** retain the original text or audio with channel message identity and received time. A failure to store means no “saved” receipt. Retry safely by message ID.
2. **Transcribe:** store a transcript separately from the audio, including language and uncertain passages. An edited transcript never replaces the original.
3. **Suggest context:** use the current catalogue, known schedule and confirmed observer assignment. Record the basis for each suggestion. Preserve unknown event, camp or lens values. Multiple events in one message become linked segments under the same original note.
4. **Ask selectively:** first recover a missing factual anchor or event identity. If those are clear, ask the most useful reality-check question. Start with at most two follow-ups, then allow “save for debrief” or further voluntary discussion. Never force completion to save an account.
5. **Read back:** show a short account, unresolved points and proposed follow-up. Observer confirmation establishes fidelity to their account, not approval by the Reflection Group. Record corrections as linked amendments.
6. **Review centrally:** the agent proposes phase, topic, lens, impact levels, candidate grouping and possible links to existing Form rows. The analyst checks ambiguous mappings and prepares the visual board. The group owns the synthesis.

Other branches: an observer says “this is only an idea” → label prospective discussion. They refer to earlier field experience → retain that evidence basis. They challenge the current synthesis → add a feedback event linked to the finding version. A message raises safety/security/safeguarding → point to the existing immediate escalation route in the ToR, without waiting for daily synthesis.

## Channel choice

| Option | Why consider it | Decisive dependency |
| --- | --- | --- |
| Existing Form + facilitator | Already in use, compatible with the current export | Add missing context and retain manual clarification |
| Telegram bot | Official Bot API supports message updates, voice-file references and file retrieval | Observers use Telegram and an approved service can store, transcribe and review the notes |
| WhatsApp Cloud API | Fits observers whose established communication channel is WhatsApp | An approved Business Platform setup and webhook/media-processing route must be available |

**Conditional recommendation:** pilot Telegram with a small willing group if it fits existing use and approved processing. Prefer WhatsApp if observer adoption is decisive and a suitable Business API route already exists. Do not choose a channel solely because its prototype is easier to build. Transcription, methodological questioning and ledger integration are our application work, not capabilities established merely by choosing a chat platform.

The official [Telegram Bot API](https://core.telegram.org/bots/api#voice) documents voice messages and [file retrieval](https://core.telegram.org/bots/api#getfile). Meta’s [official WhatsApp Cloud API collection](https://www.postman.com/meta/whatsapp-business-platform/documentation/wlk6lh4/whatsapp-cloud-api) documents the platform, including media messaging. These references establish technical building blocks. Account eligibility, current platform rules, costs and the organisation’s processing approval must be checked for the selected implementation. No account, bot, hosting or external processing has been set up here.

## Pilot acceptance criteria

- Original notes survive interrupted connectivity and repeated delivery without duplicate records.
- A reviewer can compare audio, transcript, correction and proposed finding.
- Wrong or uncertain M-codes, lens assignments and camp names remain visible and correctable.
- The observer can stop responding while keeping the saved note.
- Repeat capture through the Form is linked for review, never automatically deleted because wording resembles a chat note.
- Observers assess time and interruption burden. A reviewer checks factual fidelity and whether follow-ups improved the evidence.
- One approved daily brief can be traced back to its source notes and retained dissent.

Choose channel, context memory, question budget and processing ownership in [Interview 1, Branch G](../interview-1.md#branch-g-personal-voicetext-notetaker).