Meetings and transcription
BetaWrengle keeps a meeting's transcript and final report in one saved note. The visible workflow is deliberately simple: Transcript → Final notes.
Capture and meeting context
The meeting view provides Record, a Recording for... context picker, and More meeting actions for diagnostics and secondary actions. Depending on platform support, you can record Mic + System, Mic only, or System only. Mic + System is the default when supported. Only one meeting owns the capture lifecycle at a time; pressing Stop keeps that slot until final transcription and note save finish and any detached automatic report has settled. This prevents a second capture from competing with the first meeting's admitted final local-model or report work. One bounded exception is a provider setup that entered non-abort-safe synchronous platform code, such as a managed-local cold load: it can continue quiescing after its deadline releases logical capture ownership.
Recording is blocked only when capture or saving would be unsafe, such as when no vault is open, no suitable local Whisper model is available, another recording is active, or the selected source lacks a startup-approved platform permission. The context picker does not block ad-hoc recording. You can choose a timed calendar event or No calendar event; Wrengle snapshots that choice when recording starts.
Meeting capture can require microphone access and, where supported, system audio capture permission. On macOS, Wrengle asks for those grants during startup and rechecks their status without prompting when you press Record. A denied or revoked grant blocks only the affected source and links to Settings → Privacy & Data → Desktop access; Wrengle does not silently change Mic + System to another source or show an operating-system prompt over the meeting view. A new macOS screen-capture grant can require Restart Wrengle before it is usable.
The current unpackaged Windows build reports native capture permission as Not required because it cannot reliably request or report per-app capture consent. Startup does not probe a device or the global desktop-app microphone switch. If that switch or the selected device prevents capture, Record fails prompt-free with a source-specific device-open error. The Privacy settings page always offers a Windows microphone Settings link for recovery.
Configured transcription, report-provider, account, Calendar, action, plugin, and workflow secure items are also preloaded during startup into native process memory. Startup does not begin capture, sync Calendar, refresh OAuth, contact a provider, or prepare a report. If a required item is unavailable, the meeting view reports that capability as limited instead of retrying the Keychain read during recording.
Transcript to final report
Live captions run locally during the recording. When you choose Stop, Wrengle completes the final transcript, saves it to a stable meeting-note target, and, in Automatic mode, then creates one final report. Manual mode waits for Generate report. There is no intermediate notes stage.
The report has six fields:
- Summary — a concise recap.
- Decisions — decisions reached in the meeting.
- Action items — owner-tagged follow-up tasks.
- Follow-up — a ready-to-send message.
- Discussion — the main topics in order.
- Open questions — unresolved items.
An empty field remains present and shows None. The report is written into one
managed region that renders as normal editable blocks. While recording, a
read-only Live draft can extract likely decisions, actions, and questions
from committed local captions as soon as they arrive, without calling an AI
provider. A later refinement corrects the same caption's contribution. Eligible
Auto preparation can replace it with a Live AI draft after a validated
rolling provider update. After Stop, the current preview remains visible and is
labeled Final report draft. A UI reload can reattach to the preview while the
active desktop process retains the meeting session. All three are bounded,
copyable, process-memory-only previews that may change; they are cleared on
every terminal outcome or desktop restart and are never written to the note,
recovery files, another disk file, logs, or telemetry.
Separately, after transcript finalization, Wrengle can retain the bounded canonical transcript display state in process memory for up to 30 seconds so a UI reload that crosses immediate recovery cleanup still converges on the final text. It is scoped to the exact open-vault epoch and is cleared on vault switch, expiry, or desktop restart.
For an automatic live meeting, Ready means the managed report region and its recovery metadata are durable. The best-effort whole-vault Git snapshot is scheduled afterward and does not hold the Ready UI behind a large repository scan. Manual saved-note operations keep their existing scoped commit ordering.
If the report provider fails, times out, or returns an invalid or oversized response, the saved transcript remains usable and Wrengle shows a retry. If the report region was edited after it was generated, Wrengle preserves the edit and shows Review final report instead of overwriting it. A user edit to the transcript does not prevent an otherwise valid report from becoming ready.
Report settings
Three settings control the workflow:
-
Prepare final transcript while recording (
meeting.rollingFinalize) is on by default for eligible local meeting transcription. It prepares bounded final-quality transcript chunks on device so Stop usually processes only the remaining tail. This setting is independent of report generation and never sends audio off device. Turn it off to run the entire local final pass after Stop. -
Meeting report generation (
meeting.report.mode): Automatic creates the report when the transcript is saved. Manual keeps the transcript ready and waits for Generate report. -
Report preparation (
meeting.report.preparation): After Stop is the clean-install default and defers report preparation until recording ends. Auto is an opt-in optimization that prepares eligible report work during capture. Turning it off stops report-provider work during capture without discarding the independent local transcript cache.
For a saved meeting whose report is idle, Generate report remains available in both modes. This provides an explicit recovery path if automatic scheduling was cancelled, the resolved route changed, or the generation setting could not be saved; Wrengle shows the setting error instead of claiming the report is still scheduled.
Both settings fail closed when their stored values cannot be read. Manual mode changes scheduling only; it does not change what a cloud route can receive.
Preparation while the meeting is happening
The caption-based Live draft is independent of report mode and report preparation. It is a conservative view over committed captions, not a saved note or an AI conclusion. It appears from committed text immediately and recomputes the same caption ID when refinement arrives, so corrected wording does not leave stale facts in the draft.
With Report preparation: Auto and Meeting report generation: Automatic, Wrengle can additionally update an in-memory six-field AI report from completed, final-quality transcript chunks while capture continues. The worker is event-driven, processes one bounded update at a time, coalesces newer transcript frontiers, and enforces caps on source text, prompts, responses, report state, list sizes, and field sizes. This path also requires a saved note target, local chunked final transcription with enough decode capacity, and a report route that can prove request-specific cancellation. Current local report backends do not meet that during-capture cancellation gate, so they wait until Stop; eligible cloud routes can prepare while capture continues.
This prepared state is advisory. It is not a live-notes document, is never saved to recovery storage, and is bound to the exact provider/model route and destination. At Stop, a detached tail task gives the worker a bounded opportunity to cover the final transcript frontier while transcript persistence proceeds independently, so waiting for a slow final preparation request does not delay the saved-transcript event. Physical Stop closes ordinary rolling dispatch. A provider request admitted before Stop may finish. If complete final coverage is still missing, the provider was prewarmed, and the entire bounded remainder fits one update, the worker may then start at most one full six-field canonical tail.
Report generation waits for that tail decision and uses prepared state only when coverage, revision, schema, route, and note bindings still match. If no tail was admitted, an invalid or oversized remainder uses the canonical saved-transcript fallback. Once a tail starts, no second automatic request is sent; ambiguous exposure or a later note-context change requires manual review and retry.
Inputs at or below 32,000 transcript characters are complete. Longer transcripts retain five bounded windows spanning the beginning, interior, and end, with visible omission markers; user-owned note context is complete through 8,000 characters and uses the same five-window strategy above that cap. Wrengle labels the context Condensed whenever either cap applies.
Ordinary Markdown, chart projection, and editor-sidecar reads have a 16 MiB per-file cap; app-owned meeting-note writes use the same cap. A larger note fails closed before report, save, or recovery processing. Ordinary document and editor-sidecar operations, plus privacy-sensitive recovery inputs, reject hardlinked files, unsafe symlink/reparse paths, and parent or target identity swaps. This single-link/no-follow rule is scoped to those app-managed document, sidecar, and recovery paths; it does not describe every file a user may keep in a vault.
Current local report backends are held during capture when they cannot prove request-specific cancellation has fully stopped their work before local transcription resumes. They still generate the six-field report locally after Stop. An eligible cloud route can receive several bounded transcript-text requests during capture, so provider usage, billing, logging, and retention can apply even if Wrengle later discards prepared state and falls back.
Before each cloud preparation request is dispatched, Wrengle durably records a
content-free provider-exposure claim under .app/live/, bound to the exact
route and destination. It records completion after the request settles. The
claim is not prepared report content. If an interruption leaves a request's
completion unproven, Wrengle does not start another automatic provider request;
the meeting shows Manual retry required so a person can choose whether to
retry with the currently resolved route.
Auto preparation can reduce stop-to-report time, but it cannot guarantee a particular latency or fuller coverage on every device or route. Choosing After Stop avoids report-provider work during capture.
Local and cloud report generation
Reports use the provider and model selected under Settings → Models. Wrengle Local and Ollama keep report text processing on the device. Auto prefers Wrengle Local when available but can resolve to a configured cloud provider.
Compatible OpenAI and Anthropic models, plus Wrengle Local, request the native
six-field structured-output contract. Legacy, custom, and other routes keep the
strict JSON prompt and bounded parser fallback. Wrengle sends no app-defined
OpenAI prompt_cache_key or Anthropic cache_control directive for meeting
reports; provider-default caching, logging, and retention may still apply.
Provider preparation cannot retain the meeting slot indefinitely. Changing the route or model, disabling Automatic generation, losing recovery ownership, or reaching the preparation deadline cancels that attempt and releases the slot. Setup already inside synchronous platform code can physically quiesce later; its result is discarded and cannot repopulate report state. OS credential reads use one blocking lane with a 30-second caller deadline, while the report-specific deadline may end the attempt sooner. Explicit Ollama routing performs one direct model-list request to the configured Ollama endpoint; the request is capped at three seconds and a 1 MiB response, does not use ambient system proxies, and shares the existing 8.5-second Ollama preparation budget. Other provider preparation is capped at 20 seconds.
Settings → Meetings → Reports → Cloud meeting report access discloses the exact resolved provider, effective model, and destination for a cloud meeting report route before report input is dispatched there. Selecting a cloud model is your consent to send bounded transcript excerpts or text, bounded user-owned meeting-note text, and meeting title/prompt context to that provider; model selection is under Settings → Models, and switching to a local model keeps report generation on device. Report requests send text, not meeting audio. Changing the provider, model, or destination cancels an in-flight request bound to the old route; stale work is cancelled or discarded. A request that may have reached a provider is not automatically replayed on either the old or a new route; it requires an explicit manual retry. The disclosure is read-only; there is no separate authorize or revoke step.
A request already received by a provider cannot be retracted, so the provider's billing, logging, and retention terms can still apply after local cancellation.
Cloud final-pass transcription is a separate audio boundary with its own provider key and explicit consent. Choosing a cloud report route never authorizes an audio upload.
Transcription models
Meeting transcription is separate from in-app dictation. Live captions always use local Whisper. Local model files are downloaded into the operating-system app-data directory rather than bundled with the app, and the app can use a smaller installed rung while a selected larger model downloads.
For a local final pass, Wrengle processes long recordings in bounded chunks. In the default Prepare final transcript while recording mode, it can prepare completed final-transcript chunks during capture when the device has enough decode capacity, leaving only the tail for Stop. This continues even when report preparation is After Stop or report generation is Manual.
Cloud meeting transcription, when selected and separately consented, applies only to the final audio pass after Stop. Live captions remain local. If the cloud final pass fails, times out, produces no usable text, or cannot accept the audio size, Wrengle falls back to the local chunked final pass. ElevenLabs is not a meeting final-pass provider in this release.
Recovery
During capture, finalization, save, and report generation, Wrengle writes a
strict, versioned recovery record under .app/live/ in the open vault. A record
can contain transcript text, immutable final-transcript records, the exact note
target and identity, selected meeting context, exact provider exposure state,
and a contiguous report attempt revision. It does not contain raw meeting audio
or the in-memory prepared report state. Replaceable live partial captions are
not written as immutable recovery records; committed, refined, and final text
is. Provider exposure claims are
content-free request-safety records, not persisted report content.
Because .app/live/ is inside the vault, configured filesystem sync or backup
can copy these temporary records to its service or another device while they
exist. They are not guaranteed to remain on only the recording machine.
Each live session also owns a content-free lease containing only a random owner identifier and timestamps. Wrengle refreshes it every 15 seconds through capture, finalization, save, and detached automatic report work. Its monotonic generation and OS file lock fence cooperating Wrengle processes only when they open the same underlying lock-capable filesystem object in one clock domain.
Orderly completion makes a non-blocking release attempt after a bounded helper drain. On a responsive filesystem this completes promptly. If another process keeps the lock busy or the filesystem stalls, teardown continues instead of hanging the app; recovery becomes available when that filesystem's clock observes the last heartbeat as at least two minutes old. Ordinary synced replicas are separate, potentially stale objects, not a distributed lock. Independently clocked or future-skewed replicas are outside this fencing guarantee, so do not open or recover the same temporary meeting item concurrently on multiple synced devices.
Recovery is transcript-first. After an interruption, Wrengle uses a completed final transcript when one exists, otherwise the latest completed live transcript record. The active incomplete write can still be lost. Provider work is never started merely by scanning recovery files. When Stop durably recorded an automatic-report request, a successful user-initiated save retry or recovery resumes that request; it must still satisfy the current mode, the resolved route's credential and destination bindings, note identity, and attempt revision. A visible retry uses the current resolved route.
If recovery finds a cloud request whose completion was not durably recorded, automatic generation remains stopped at Manual retry required. This avoids silently repeating a request that the provider may already have received.
Recovery records are temporary, not an archive. Wrengle removes them after a successful save/report, recovery, discard, or no-speech cleanup. If cleanup fails, the meeting view keeps a visible cleanup action. Back up the whole vault folder only if you intentionally need to preserve an unsaved recovery item. Recovery reads, accumulated transcript text, and directory enumeration have hard byte and entry caps. An oversized or malformed session is isolated as an unsupported, discard-only row while other valid sessions continue to scan; a session whose owner lease itself is unreadable or oversized stays hidden and fails closed while sibling sessions continue to scan. A root-wide session-count overflow fails the scan safely until excess app-managed entries are removed.
Saved notes and review
Meeting notes are created under notes/meetings/. Calendar-linked notes use a
safe slug from the event title and recording timestamp; ad-hoc recordings use a
meeting- prefix. The meeting view exposes Open note when the transcript is
saved, while report status remains visible as preparing, ready, retryable,
manual retry required, or review required.
An edited or malformed report region is preserved for review. Before preparing a new post-Stop provider, Wrengle checks that region locally. Check note and retry repeats the provider-free check after the user repairs the note; while the issue remains, it makes no provider request.
Final local transcripts label channels as You and Participants. This is channel attribution, not identification of individual speakers. A transcript saved from a cloud final pass has no speaker labels in this release.
Before saving, finalization keeps one copy of immediately adjacent segments whose cleaned text and channel are exactly the same. It preserves differently cased or punctuated text, cross-channel and nonadjacent repetition, and repeated phrases contained inside one segment.
Wrengle does not save a raw recording archive. Transcription quality depends on audio quality, model choice, hardware, and platform support; review important transcripts and reports before treating them as authoritative.