Asynchronous summary generation
Understand why summaries can lag behind live transcript flow, what is normal, and when delay indicates a real issue.
This guide explains why RoomRadar summaries and transcript lines do not always update at the same speed. Use it when facilitators see fresh transcript activity but summary panels update later. In a hurry: treat transcript as the live steering layer, let summaries settle before final reporting, and investigate only when lag keeps growing after activity drops.
What is happening in the system
RoomRadar separates two jobs:
- transcript ingestion for live visibility
- summary generation for structured synthesis
Because these jobs are decoupled, transcript updates usually appear first. Summary updates follow in cycles based on available context and processing load.
This is intentional. If summary generation blocked transcript flow, live facilitation would become less reliable in busy moments.
What you will notice during real workshops
Normal behavior during high activity:
- transcript stays active across tables
- summaries update in batches
- summary freshness improves when discussion intensity drops
Behavior that needs attention:
- summary lag grows continuously for one table while others are healthy
- summary lag remains high near closeout after traffic has stabilized
- one table never catches up despite healthy transcript flow
If transcript flow also degrades, diagnose latency first with [Troubleshooting transcription latency](/guides/advanced/troubleshooting-transcription-latency).
Fast facilitator response when summaries lag
- Confirm whether lag is room-wide or table-specific.
- Keep facilitation decisions anchored in transcript + table observation.
- Mark high-stakes statements as "pending summary stabilization."
- Recheck summary state after the discussion peak passes.
- Finalize report language only from stabilized summaries.
This avoids overreacting to temporary lag while still protecting decision quality.
Why this matters for decision accuracy
Summary lag is mostly harmless until teams treat provisional text as final output. Problems start when:
- early summaries are forwarded as commitments
- participants assume no change should ever occur
- facilitators merge live draft wording into final reports without verification
A safer operating rule:
- live phase: use transcript to guide interventions
- closeout phase: use stabilized summaries for commitments
That split prevents most false escalations.
Failure modes and practical fixes
Failure mode: "No summary update" panic in peak traffic
Fix: verify transcript health first, then wait one summary cycle before escalating.
Failure mode: table-level lag mistaken for room-wide issue
Fix: compare one affected table and one healthy table side by side.
Failure mode: stakeholders see conflicting summary versions
Fix: label early summaries as provisional and publish only stabilized closeout versions.
Failure mode: delay is real and persistent
Fix: flag the run for post-session reliability review and correlate with latency, reconnects, and duplicate-capture events.
When to ignore vs when to escalate
Ignore short lag when all of these are true:
- transcript remains healthy
- lag appears during known activity peaks
- summaries catch up after load drops
Escalate when one or more of these are true:
- lag keeps increasing for 10+ minutes with no recovery trend
- only one table remains delayed across multiple cycles
- closeout reporting window is at risk and summary state is still unstable
A simple escalation log keeps decisions clean:
Time | Affected tables | Transcript health | Summary lag trend | Action takenThis avoids subjective debate later about whether the delay was normal or operationally harmful.
This guide is for...
Use this guide when your issue is summary freshness timing.
If your issue is summary content changing meaning over time, use [How revision-aware summaries work](/guides/advanced/how-revision-aware-summaries-work). If your issue is duplicate summary artifacts, use [Preventing duplicate summaries](/guides/advanced/preventing-duplicate-summaries).
Related guides
- [How revision-aware summaries work](/guides/advanced/how-revision-aware-summaries-work)
- [Preventing duplicate summaries](/guides/advanced/preventing-duplicate-summaries)
- [Troubleshooting transcription latency](/guides/advanced/troubleshooting-transcription-latency)
- [Turning summaries into reports stakeholders can use](/guides/workflows/turning-summaries-into-reports)
- [What to do when summaries feel wrong](/guides/analysis/what-to-do-when-summaries-feel-wrong)