Why Scripta does not show a live transcript while you record

Scripta does not show a live transcript because it does not send audio for transcription while the meeting is happening. You record in your browser, check the timer and level meter, pause when needed, and press Finish. Only then does the audio upload once and go to xAI Grok Speech-to-Text in a batch request.

That means the absence of live words is a product boundary, not a loading state.

What happens during the meeting

The recording tool lives on the meeting's Notes tab, above Discussion points. It asks one question at a time:

1. How will you capture the meeting? Write, record, or upload.
2. What will you record? Your microphone, or tab audio plus microphone for a browser call.
3. Is the recording live? The timer, mixed-audio level meter, pause control, and Finish button answer that.

The person operating the browser is doing the recording. Scripta does not join the conference, add a participant, or send a bot into the room.

During capture, the recorder holds the audio in the browser. There are no provisional transcript lines arriving from a transcription service because no transcription request has started.

Finish is the handoff point

Pressing Finish ends capture and begins a different stage. The browser uploads the completed audio once to private storage. Scripta then sends that recording to xAI Grok STT in one batch call.

The returned transcript belongs to the recording first. It does not immediately replace notes or a transcript already attached to the meeting. You choose whether to promote it, and Scripta asks before replacing existing material.

That separation matters. A generated result should not quietly take ownership of the meeting record. It should arrive as material a person can inspect and deliberately use.

Once promoted, the transcript can feed the minutes assistant. Decisions and action items are proposed for review, with supporting quotes checked against text that actually exists in the transcript. That is the same evidence principle behind AI meeting notes that show their work.

Why not post each audio chunk as it appears

Browser recording does produce chunks, but that does not make those chunks a streaming transcription protocol. With MediaRecorder, later chunks are not guaranteed to be independently decodable. The first chunk may contain container information the later pieces need.

Real streaming transcription uses a persistent connection and a service designed to consume an ongoing stream. It is also a different cost choice: in the implementation evaluated for Scripta, streaming was twice the batch rate.

Batch is not universally better. It gives up the ability to scan or correct words during the call. Scripta makes that trade-off explicit instead of drawing a live transcript the system is not producing.

What to check when there are no words on screen

Without a live transcript, the useful checks are simpler:

• confirm the correct capture source before starting;
• watch the level meter while both you and the far side speak;
• pause when a break or private exchange should not be captured;
• press Finish only when you are ready for upload and transcription;
• review the transcript before promoting it to the meeting.

The level meter confirms signal activity, not sentence accuracy. Speaker labels confirm that voices differ, not who those people are. The reviewed transcript remains the point where the raw recording becomes useful meeting material.

The honest trade-off

A live transcript can be useful. Scripta does not pretend otherwise. Its current recording path chooses a clear boundary instead: local browser capture during the call, then one upload and one batch transcription after Finish.

You lose words appearing in real time. You gain an interface that says exactly when the audio leaves capture and enters processing.

Record from your browser or bring any transcript—nothing of Scripta's ever joins your call. Afterward, the twenty minutes after the meeting are where source material becomes a record people can use.