jz.
Let’s talk ↗
↖ THE NOTEBOOK

BUILD NOTE 02 / PRODUCT SYSTEMS

The state behind
a good interruption.

What happens to a podcast when a question becomes a conversation? The answer starts with ownership of state.

JIAHANG ZHANG2 MIN READRSS ↗

Keep the thread

A question during a podcast is an interruption with a purpose. The listener wants to understand something, possibly ask a follow-up, and return to the original thread. That makes the return path part of the main interaction.

Aside explores this flow with timestamped transcripts, contextual questions, and natural resume points. The interesting engineering problem is how playback, microphone input, answers, and follow-ups share responsibility without losing the listener’s place.

Give the interruption one anchor

The first interruption establishes a resume anchor. Follow-up questions belong to that same interruption and keep the anchor. Returning to the show uses the saved semantic boundary, so the listener resumes at a complete thought.

A transcript timestamp is useful context, but an interaction also needs to know which task owns the right to resume playback. A delayed answer from an earlier question must not restart a newer listening session. Aside uses explicit state transitions and revision checks to keep those responsibilities clear.

LISTEN→ASK→FOLLOW UP→RESUME

Separate the responsibilities

The domain engine defines playback transitions, resume anchors, and shared contracts. The frontend connects those rules to audio devices and the interface. The backend handles analysis, storage, and model-facing work. This keeps the central interaction understandable without making it depend on a particular UI component or model SDK.

A transcript, a playback bar, and a conversation view can then present the same runtime state. They should not each maintain a competing answer to “are we listening?” or “where do we resume?”

A USEFUL BOUNDARY

One runtime owns the listening session. Views describe it; adapters connect it to devices and services.

Test the return path

The easy path is one question followed by one answer. More revealing cases include a second question during the first answer, a manual pause while a request is pending, an audio connection failure, or a seek to another part of the episode.

Each case needs a clear outcome for the original audio, the pending question, and the resume anchor. A trustworthy interface makes those outcomes predictable. The project’s state machine, cancellation rules, and integration tests are ways of making that behavior explicit.

The same idea applies beyond podcasts: whenever an interface temporarily takes someone away from a task, the handoff back deserves a deliberate design.

Follow the thread

Aside source and project overview ↗Listening and question ownership ↗
KEEP EXPLORINGExplore the Aside project