Playback acknowledgments: prove what reached the caller

TL;DR: Track generated, sent, scheduled, and acknowledged audio as distinct evidence stages, and name the provider or player boundary each event proves. A clear, stop, disconnect, or missing event can leave playback uncertain; no media acknowledgment proves that a person understood or authorized the spoken content.

---

A log says the assistant completed its answer, yet the caller says they never heard the final instruction. Both observations can be true if completion means generation ended while playback was still queued.

The fix begins with vocabulary. Your application needs an evidence ledger that records what each component observed and preserves uncertainty when a cancellation races with completion.

The interruption safety guide describes response invalidation. Playback acknowledgments supply the narrower evidence needed to decide how much of that response can safely be treated as delivered at a declared media boundary.

This guide provides a runnable conservative ledger, public protocol examples, and a release test matrix. It applies to custom players and telephony adapters, including applications evaluating 60db Agent, without describing any product's internal architecture.

As of November 2026, Twilio's Media Streams contract returns marks for completed media and also for media removed by a clear. That difference is enough to invalidate a simplistic rule that every returned mark means the caller heard the associated sentence.

Table of contents

1. Name the evidence boundary
2. Map provider and player contracts
3. Build a conservative playback ledger
4. Handle clears and reordered observations
5. Align conversation history with evidence
6. Measure delivery without inventing hearing
7. Test transport-specific failure schedules
8. Operate a bounded evidence store
9. Frequently asked questions
10. Make delivery claims reviewable

Name the evidence boundary

A playback acknowledgment is evidence about a defined media boundary. Its meaning comes from the producer's contract and the surrounding event history, rather than from the friendly name of the callback.

Generated audio exists in a producer's output. Sent audio has been handed to a transport operation under that runtime's semantics, which can still leave bytes in a local queue.

Scheduled audio has been admitted to a player timeline or downstream playback queue. Acknowledged audio has reached the condition named by a documented provider or player event.

Those states need not form one universal ladder. A transport may expose sent and acknowledged events without exposing scheduling, and a local player may expose scheduling without any remote provider acknowledgment.

Record missing stages as unobserved. Inferring them from nearby timestamps makes a dashboard look complete while hiding the exact blind spot responsible for the incident.

A local synthesis completion event says the producer has finished creating content. It does not show whether the output gate accepted every chunk or whether the active response was invalidated before the last chunk arrived.

The audio backpressure guide explains how output can be valid when generated and stale when consumed. A ledger should preserve both events so the loss is attributed to the correct boundary.

A network send callback often describes local transport progress. Unless the API explicitly says otherwise, it cannot certify remote playback, acoustic output, or comprehension.

The WebSockets standard defines bufferedAmount around application bytes queued for network transmission. A low value helps inspect local sending pressure and supplies no direct evidence about a remote speaker.

An acknowledgment at a carrier or browser boundary also leaves the physical path partly unobserved. The user can lower their volume, remove a headset, or listen in a noisy room while the media system reports normal playback.

Use wording such as "provider playback acknowledged" or "local source ended normally." Reserve "caller confirmed" for an actual conversational confirmation collected under the workflow's rules.

This distinction matters for consequential instructions. If a spoken instruction contains a revised address or an action requiring consent, the media ledger can establish delivery evidence while workflow enforcement decides whether the application has valid authorization.

Avoid one overloaded completed field. Give generation, media delivery, conversation state, and business operation state separate names, because they can finish at different times and disagree without any component lying.

Map provider and player contracts

Read the exact API contract before designing the adapter. Similar event names across transports do not establish equivalent guarantees, and a provider's example can omit the failure path that your application depends on.

For Twilio bidirectional Media Streams, send a mark after the media whose completion you want to observe. Associate the mark name with your own opaque response and segment identifiers, avoiding text or account details in the identifier.

The same public protocol says a clear empties buffered audio and returns marks for remaining marked media. A returned mark needs the local clear history to distinguish an ordinary completion path from a cancellation-affected path.

For a local Web Audio player, an ended event also has multiple causes. The Web Audio specification allows it when scheduled playback finishes and when a source reaches its stop condition.

Keep the locally requested stop reason beside the callback. Otherwise a source deliberately stopped during interruption can be counted as a normally completed sentence.

For native players, check whether the callback refers to buffer consumption, device scheduling, or render completion. Record the strongest documented condition and leave everything downstream outside the claim.

For RTP, a reception report is a transport observation rather than a human hearing receipt. The RTP and RTCP specification defines report fields for media delivery monitoring; it does not convert packet receipt into comprehension.

The table uses ✓ for a conclusion supported within the named boundary and ✗ for a conclusion that still needs separate evidence. It describes event classes rather than promising every SDK exposes them.

Do not promote an adapter's derived field into a provider guarantee. If the adapter estimates played duration from local scheduling, name it an estimate and preserve the assumptions used to calculate it.

The transport guide helps identify ownership of playback. A client-managed output path creates obligations that a server-managed media path may handle differently.

OpenAI's public Realtime conversation guide makes that ownership distinction for its supported transports. Consult the current transport-specific contract before copying truncation behavior into a different player.

Keep source notes with a checked date and the exact fields used. That small record makes an SDK upgrade review possible without rediscovering why the ledger treats a particular callback conservatively.

Build a conservative playback ledger

A useful ledger records immutable identities and explicit transitions. For a small single-owner adapter, a dictionary of segment records is enough; do not introduce a distributed service before the application needs one.

Each segment needs a response generation, an opaque mark or chunk key, a send status, and a delivery outcome. The outcome can remain pending, reach an acknowledged boundary, or become uncertain after a clear or disconnect.

The example below is intentionally conservative. A segment pending when clear begins becomes ambiguous even if a later event might have represented completion, because the public mark alone does not identify its cause.

Save it as playback_ledger.py and run it with Python 3. It is a deterministic model with synthetic events, not a network client or a measured provider benchmark.

from dataclasses import dataclass


@dataclass
class Segment:
    generation: int
    sent: bool = False
    outcome: str = "pending"


class Ledger:
    def __init__(self):
        self.generation = 0
        self.closed = False
        self.clear_pending = False
        self.segments = {}

    def register(self, key):
        if self.closed or self.clear_pending or key in self.segments:
            raise ValueError("Closed ledger or reused segment key")
        self.segments[key] = Segment(self.generation)

    def sent(self, key):
        item = self.segments[key]
        if self.closed or self.clear_pending or item.generation != self.generation:
            raise ValueError("Stale send")
        item.sent = True

    def mark(self, key):
        item = self.segments.get(key)
        if item is None:
            return "unknown-key"
        if item.outcome == "pending" and item.sent and not self.closed:
            item.outcome = "acknowledged"
        return item.outcome

    def begin_clear(self):
        # Block new media until clear has entered the serialized wire order.
        if self.closed or self.clear_pending:
            raise ValueError("Cannot begin clear")
        self.clear_pending = True
        self.generation += 1
        for item in self.segments.values():
            if item.outcome == "pending":
                item.outcome = "clear-ambiguous"

    def clear_written(self):
        # Call only after the ordered writer has accepted clear before new media.
        if not self.clear_pending or self.closed:
            raise ValueError("No active clear barrier")
        self.clear_pending = False

    def disconnect(self):
        self.closed = True
        for item in self.segments.values():
            if item.outcome == "pending":
                item.outcome = "disconnect-unknown"


if __name__ == "__main__":
    normal = Ledger()
    normal.register("a")
    normal.sent("a")
    assert normal.mark("a") == "acknowledged"
    assert normal.mark("a") == "acknowledged"
    normal.begin_clear()
    assert normal.mark("a") == "acknowledged"

    raced = Ledger()
    raced.register("b")
    raced.sent("b")
    raced.begin_clear()
    assert raced.mark("b") == "clear-ambiguous"
    try:
        raced.register("too-early")
        raise AssertionError("New media must wait behind clear")
    except ValueError:
        pass
    raced.clear_written()
    raced.register("c")
    raced.sent("c")
    raced.disconnect()
    assert raced.mark("c") == "disconnect-unknown"
    assert raced.mark("missing") == "unknown-key"

    unsent = Ledger()
    unsent.register("d")
    assert unsent.mark("d") == "pending"
    print("Synthetic playback-ledger checks passed")

The code omits wire encoding, authentication, persistence, timeouts, and retention. Those concerns belong to the real adapter, and the example's in-memory records should never be described as a production evidence store.

Its central rule is easy to review: once a pending segment becomes uncertain because of a clear or disconnect, a generic late mark cannot upgrade it to acknowledged. A known normal acknowledgment observed earlier remains valid evidence at its documented boundary.

The sent flag has a narrow meaning. In the real adapter, set it under the send operation's documented local semantics and preserve failures rather than marking a failed write as a successful handoff.

Register the segment before sending media and its mark so an immediate callback has an identity to match. If the send fails, retain a failed-send reason and do not wait forever for a receipt that cannot arrive.

Use one serialized owner and one ordered outbound writer for each call. begin_clear closes admission before any await; keep that barrier closed until the writer has placed clear ahead of every new-generation media and mark, then call clear_written.

Never release the barrier merely because a clear task was created. If clear fails to enter that wire order, disconnect or retain the barrier; otherwise new media could be flushed by the old clear and its returned mark misclassified as normal playback.

A dictionary key is not a security credential. Validate the session, stream, and authenticated connection before accepting a callback, then match its opaque segment key inside that trusted context.

Unknown keys should produce bounded diagnostics. They can indicate duplicates after retention, a session mismatch, or malformed input, and should never create a new acknowledged segment on demand.

The observability guide describes how identifiers connect an event chain. Keep content out of keys so the ledger can remain useful without becoming a second transcript database.

Handle clears and reordered observations

A clear changes the interpretation of pending playback evidence. It also creates a race between the local cancellation decision, outbound transport work, provider processing, and inbound receipt observation.

Consider a segment that finishes at the provider just before the application sends clear. Its normal mark can be in flight while the local ledger has already invalidated the response.

Now consider a segment still queued when the provider handles clear. The returned mark can look the same to the application even though the audio did not finish playing.

Without a contract that distinguishes those causes, the adapter should preserve uncertainty. Labeling every post-clear mark as definitely cleared can overstate what was discarded, while labeling it definitely played can overstate delivery.

The ledger chooses a conservative boundary at the moment clear begins locally. That choice can undercount completed playback during a race, but it avoids using an ambiguous event to claim the caller received critical content.

State the trade-off in documentation. A diagnostic system can preserve richer evidence and later refine a classification if the provider exposes a stronger event, while the live controller should use the evidence available at decision time.

Duplicate acknowledgments need idempotent handling. A repeated event should return the same outcome and leave counters unchanged, rather than incrementing the played-segment total again.

A reconnect needs a new session boundary unless the provider explicitly supports continuation with stable identities. Do not attach an old stream's mark to a new call because its key happened to be reused.

Missing events remain missing. A timeout can close the operational wait and trigger recovery, but it cannot transform pending playback into either success or confirmed non-delivery.

Use an explicit timeout reason such as receipt-timeout-unknown. That state lets reporting separate a media failure from a monitoring gap and gives the resumption policy a conservative input.

The resumption guide uses that uncertainty to choose whether to repeat a self-contained instruction or ask for clarification. It should not infer a precise word boundary from a receipt timeout.

Clear and disconnect are also different. Clear can leave the call active and allow a new response generation, while disconnect ends the media observation channel and can remove the participant who would hear recovery speech.

Apply the shutdown contract before accepting late callbacks. A terminal call can retain evidence for diagnosis without allowing an old acknowledgment to reopen playback or trigger a new spoken response.

A timeout can end an operational wait without deciding whether the audio played.

Align conversation history with evidence

A conversation history should not contain an assistant paragraph as fully delivered merely because the model generated it. If the caller interrupted halfway through, later reasoning needs an honest account of what remains uncertain.

Keep generated text, approved response content, and delivery evidence as separate records. The language model can be given a compact conversation view derived from those records without forcing the transport ledger to become the entire conversation store.

A segment boundary can help when it corresponds to a self-contained phrase. It still does not establish exact word timing unless your player or alignment system provides verified mapping between text and rendered audio.

The streaming sentence-boundary guide explains why punctuation alone is a poor segmentation rule. Abbreviations, decimal values, and unfinished clauses can make a chunk look complete while its spoken meaning still depends on the next chunk.

Suppose a synthetic assistant says, "Use the blue entrance, then ask for the fictional parcel desk." If the first segment is acknowledged and the second is uncertain, a history entry can preserve the known first instruction while marking the follow-up as interrupted or unconfirmed.

Do not manufacture a partial transcript by slicing text at a percentage of audio duration. Speech rate changes within a sentence, and the position of a critical word can differ from its proportional character position.

If the provider offers an explicit truncation operation, follow its documented item and content identifiers. A local string edit does not necessarily change the remote conversation state used by a realtime service.

A repair can be conversationally simple. "I may have stopped before the next step. Please ask for the parcel desk" is safer than pretending the caller already received the second instruction.

Keep that wording proportional to the uncertainty. Avoid asking the user to repeat information you already have unless the missing delivery evidence affects what they need to do next.

For a confirmation request, preserve the exact proposal being confirmed and its revision. An acknowledgment of the audio is separate from the caller accepting that proposal, and qualified confirmations need their own intent handling.

A caller saying "yes, but use the other entrance" changes the task even if every prior audio segment was acknowledged. Media evidence cannot overrule the new correction.

The self-correction guide provides the field-revision side of this contract. Pair its revision identity with response ownership so old, well-delivered speech does not become the current truth after a correction.

Do not write an uncertain spoken claim into a business audit as a completed notification. Record the media status and the separate workflow result, then let the product's actual notification requirement determine whether another channel or explicit acknowledgment is needed.

Measure delivery without inventing hearing

Define every reported metric with a numerator, denominator, boundary, and exclusion rule. "Playback success" is too broad unless the report states which event counts and how interrupted, disconnected, and unknown segments are handled.

A segment-level acknowledgment fraction measures segments, not calls or people. One call with many short segments can contribute more observations than several calls with a single response.

A call-level measure needs its own rule. For example, a call can contain at least one acknowledged segment while still missing a critical final instruction, so "any acknowledgment" is weak evidence for successful delivery of the whole answer.

Track uncertainty as its own category. Combining clear-ambiguous events with confirmed failures can make a delivery service look worse than the evidence shows; dropping them can make it look better.

The outcome metrics guide separates task outcomes from intermediate signals. A playback ledger is one intermediate source, and it should not become a substitute for evidence that the caller's task succeeded.

For latency, report the interval precisely. Generation-to-send, send-to-mark-observation, and user-speech-end-to-first-output are different measurements with different clock and queueing boundaries.

The latency benchmark guide explains those distinctions. A send-to-mark interval can include queued audio ahead of the marked segment and return-path delay, so it should not be labeled a pure network latency measurement.

Use local monotonic time for the application's observation intervals. When comparing provider media positions with client timestamps, preserve clock-domain labels and the method used to align them.

The Performance timeline specification defines the browser timing model for performance entries. It can support local instrumentation without making independent device and server clocks interchangeable.

Avoid subtracting estimated player time from a server wall clock and presenting the result as exact played duration. The apparent precision of a decimal value does not repair missing clock synchronization.

For a batch report, include all terminal outcomes. A useful table lists acknowledged at the named boundary, canceled with ambiguity, disconnected unknown, send failed, and still pending at the observation cutoff.

Do not remove slow or interrupted calls from a latency distribution without reporting the removal. Those cases often contain the queueing behavior the team most needs to understand.

Separate normal speech from waiting speech when reporting delivery. The truthful waiting-speech guide explains why a successfully played acknowledgment says nothing about whether a slow tool completed.

Keep each duration inside its clock domain unless an explicit alignment method exists.

Test transport-specific failure schedules

A unit test should exercise event order, not just the normal completion path. The deterministic ledger checks show basic state transitions, while an adapter test must exercise the actual wire messages and callback semantics of the selected transport.

Begin with ordinary completion. Send synthetic media, register a matching mark, observe the documented receipt, and confirm that the application records exactly one acknowledged segment.

Then clear before the segment completes. Verify that returned marks do not upgrade the affected segments to normal completion and that a new response can use fresh identifiers without colliding with the old generation.

Test a mark observed just before local clear begins and another observed just after. The expected distinction should match the adapter's serialized event order rather than an assumption about when the remote speaker emitted its final sample.

Test send failure before the mark is queued. The ledger should preserve failed handoff evidence and stop waiting for a successful completion event from a segment that never entered the supported path.

Test disconnect after send and before acknowledgment. The result is unknown delivery unless a stronger provider contract or persisted event establishes more.

Test duplicate and unknown marks. Duplicates must not inflate counters, and unknown identifiers must not create trusted evidence or attach themselves to the current response.

A local player test needs explicit stop coverage. Schedule a source, stop it before its normal end, and verify that the resulting callback retains the requested stop reason.

For an implementation using a different browser primitive, consult that primitive's own contract. The HTML media element specification defines a separate state and event model, so a Web Audio adapter's meaning cannot be copied unchanged to an HTML audio player.

Use a network fault harness only when it preserves the event boundaries you need. Artificially delaying a JavaScript handler is useful for callback-order tests, but it does not reproduce every device buffer or carrier behavior.

The regression testing guide gives a structure for saving incident schedules. Include the expected evidence status and the conversation action, because a correct ledger can still feed an unsafe resumption decision.

For an end-to-end trial, use clearly synthetic speech and a consented listening endpoint. Keep the provider's acknowledgment result separate from the human listener's annotation so the experiment can reveal disagreements rather than forcing both into one success field.

Keep uncertainty and send failures visible when reporting segment delivery.

Operate a bounded evidence store

A ledger grows unless records have a lifecycle. Retain enough detail to reconcile late events and incidents, then compact or delete records under a documented policy instead of keeping every segment forever.

Use a terminal-call record with a retention window suitable for the transport's late-event behavior and the product's audit needs. A compact record can preserve counts and reasons while removing per-segment detail that no longer serves an operational purpose.

Do not reuse identifiers inside the period in which late events remain possible. Random opaque keys or a session-scoped counter can work when the complete session identity is part of matching.

Treat retention expiry as an evidence boundary. A receipt arriving after the detailed record was intentionally removed can be counted as an unmatched late event, but it should not reconstruct a new success record from incomplete state.

Keep payload content out of ordinary ledger entries. Segment identities, durations, reasons, and event times are often enough to diagnose delivery without storing the spoken names, addresses, or account details.

The cost-per-success guide helps explain why repeated speech has a cost even when generation is inexpensive. A missing evidence boundary can cause unnecessary replay, while an overconfident boundary can cause a failed task that needs another call.

Use alerts for changes in evidence quality as well as media failure. A sudden rise in unknown marks after an SDK deployment can indicate an adapter mismatch even if calls still sound normal during a spot check.

Keep an operational runbook for each alert. Identify the current provider contract, the adapter version, the event sample with content removed, and the deterministic replay that distinguishes an application classification bug from a transport failure.

If storage persistence is added, preserve transition ordering. A receipt and a clear processed by different replicas need a declared serialization model; copying the in-memory class into several processes does not provide one.

The simplest reliable owner is often the component already responsible for the call. Share compact evidence downstream rather than giving every service permission to reinterpret raw callbacks independently.

Before a deployment, verify that dashboards use the new status meanings. Renaming a field in code while leaving an old chart labeled "heard" can keep the original false claim alive after the adapter is fixed.

Review evidence requirements by spoken content

Different utterances need different follow-up even when the media status is identical. A greeting that might have been cut off can often be replaced by a short fresh introduction, while a critical instruction may need a complete repeat or an explicit question about what the caller needs.

Classify the content before using the ledger to choose a recovery. A progress acknowledgment, a reversible suggestion, a confirmation request, and an external-operation result have different consequences if the last phrase remains uncertain.

For a synthetic navigation instruction, repeat the smallest self-contained step whose delivery is unknown. For an action result, query the authoritative operation state before repeating a claim that an action succeeded, because playback evidence and business state can diverge.

The speculative tool guide covers that separate operation boundary. A media clear cannot undo a write that the external system already accepted, and a normally played response cannot prove a write succeeded if the response itself was premature.

Document these distinctions in the acceptance criteria. "No replay of completed segment" can be a reasonable goal for an ordinary explanation, while "repeat complete instruction after ambiguous stop" can be safer for a short task step.

The ledger should provide evidence to the policy rather than decide product intent on its own. Keep the recovery rule beside its content category so an engineer changing a transport adapter does not silently change how the application handles consequential instructions.

Keep a contract test beside the adapter

Store a small versioned fixture containing the public event shape and the interpretation your adapter assigns to it. The fixture should contain synthetic identifiers and no real media payload, while preserving the fields whose meaning matters for matching and cancellation.

A test should fail when the adapter receives an unexpected shape rather than silently inventing a completion. If a provider introduces an optional field, decide whether it changes evidence strength or merely adds diagnostics before changing the classification rule.

Separate parse failures from unmatched valid events. A malformed message suggests a boundary validation problem; a valid receipt for an unknown key suggests identity, retention, or session ordering needs investigation.

Keep the current source URL and checked date in the private engineering note that owns the fixture. This avoids copying a large external protocol document into the codebase while still giving the next maintainer a route to verify the assumption.

Do not make the test assert that every event eventually succeeds. Assert stable identities, idempotent duplicates, conservative cancellation handling, and terminal-state behavior, then let integration tests observe whether the real provider satisfies its documented normal path.

Explain unknown delivery to operators

Operators need a next action for each unknown status. A clear race can lead to a short repeat of the missing instruction, while a disconnected call may require a separate workflow that first checks whether contacting the caller again is allowed.

A dashboard should make those actions discoverable without presenting uncertainty as a defect in the caller. Use labels tied to observation, such as missing receipt after disconnect, instead of wording that claims the person ignored or failed to hear the agent.

Show the observation cutoff in reports. Pending evidence at a fixed cutoff can later become known, so compare reports built with the same window and retain the time at which a status was calculated.

When a support investigation needs more detail, provide the content-free event chain first. Escalate to restricted recordings only when they are available under consent and necessary to answer a specific question about the physical listening path.

Preserve evidence during handoff

If a call transfers to a human, the receiving summary should distinguish delivered facts from pending explanations. A useful handoff says the caller requested a revision and the final instruction's playback is uncertain, rather than claiming the caller has already been told everything in the generated transcript.

Use the warm handoff guide to keep that summary bounded. The receiving person needs current intent, action state, and relevant delivery uncertainty, not every intermediate audio callback.

A handoff can also end the original player's authority. Close its output gate before accepting late synthesis or mark events, while allowing the evidence store to finish reconciling under its own lifecycle.

Test the handoff race explicitly. A segment acknowledgment arriving after transfer may be useful for diagnosis, but it should not make the old agent speak into a call now owned by another participant.

---

Frequently asked questions

What does a playback acknowledgment prove?

It proves the condition named by the provider or player that produced the event. State that boundary explicitly, because transport acceptance, source completion, and physical audibility describe different observations.

Does synthesis completion mean the caller heard the answer?

No. Synthesis completion concerns content production, while queues, cancellation, transport failure, and device playback remain downstream. Keep generation and delivery statuses separate so a complete model response cannot masquerade as complete playback.

Why can a returned Twilio mark be ambiguous?

Twilio returns marks after playback completion and when clear removes pending buffered media. If clear races with a normal receipt, the returned mark alone does not tell the application which cause produced it.

Should post-clear marks always mean audio was discarded?

That claim can overstate the evidence because some audio may have completed before clear was processed. Use a conservative ambiguous status unless the provider exposes stronger cause-specific evidence for the affected segment.

Can a local ended event represent a stop?

Yes, depending on the player API. For Web Audio scheduled sources, retain whether the application requested a stop so the callback is interpreted with the correct local reason.

Does bufferedAmount measure remote playback delay?

No. It concerns application data queued for network transmission under the browser WebSocket contract. It can help diagnose local pressure while leaving remote buffers and device output unobserved.

What should happen when an acknowledgment is missing?

Keep delivery unknown and use an explicit timeout to end the operational wait. A timeout can trigger recovery or an alert, but it cannot prove either playback completion or definite non-delivery.

How should duplicate marks be handled?

Process them idempotently against the same segment identity and preserve the existing outcome. Do not increment completion counters again or attach a duplicate from an old session to a new response.

Can acknowledgment identifiers contain spoken text?

Use opaque identifiers instead. Putting names, addresses, or transcript fragments in keys spreads sensitive content into logs, metrics, and provider event streams without helping the evidence model.

Is a packet reception report a hearing receipt?

No. Packet reception and transport statistics describe media delivery conditions rather than a person's listening or comprehension. Keep human confirmation under a separate conversational and authorization contract.

How should interrupted conversation history be stored?

Preserve generated content separately from the portion supported by delivery evidence. Mark the uncertain remainder explicitly so later reasoning does not assume the caller heard a sentence that may still have been queued.

Can I estimate word position from audio duration?

A proportional text slice is unreliable because speech timing varies across words and pauses. Use verified alignment if available, or resume with a self-contained phrase rather than claiming a precise heard word boundary.

Should every audio chunk have a mark?

Choose mark granularity based on the provider contract, operational overhead, and the semantic boundary you need. A very fine receipt stream still cannot prove comprehension, and a very coarse one can leave a large uncertain span after interruption.

What is the difference between clear and disconnect?

Clear can discard pending media while keeping the call active for a new response. Disconnect closes the observation channel and can leave pending delivery unknown while also removing the participant who would hear recovery speech.

Can a ledger authorize a payment or booking?

No. Delivery evidence can support a record of what was played at a media boundary, while authorization requires the correct caller intent, policy checks, and authoritative operation state.

Which clock should measure receipt observation latency?

Use a local monotonic clock for intervals within one process. If you combine provider media positions, browser clocks, and server clocks, state the synchronization method and uncertainty rather than subtracting them directly.

How long should segment evidence be retained?

Choose retention according to late-event behavior, incident investigation needs, and the product's privacy rules. After expiry, count unmatched late events without reconstructing trusted success from missing context.

How do I test an acknowledgment adapter?

Replay normal completion, clear races, explicit stop, disconnect, duplicate receipt, unknown key, and send failure. Then verify the actual provider messages or player callbacks with synthetic media under the deployed adapter version.

Should a human handoff include delivery uncertainty?

Include it when it changes what the receiving person should say or do. A compact summary should distinguish a confirmed action from an explanation whose final audio may not have reached the declared playback boundary.

What should I ask a voice platform during evaluation?

Ask which events prove generation, transport handoff, playback progress, cancellation, and terminal state for your selected transport. Use those observable contracts to build your own ledger rather than accepting an unlabeled "completed" event as sufficient evidence.

Make delivery claims reviewable

A playback ledger is useful when another engineer can explain each status from its source event, local history, and documented boundary. Keep ambiguous clears, missing receipts, and disconnects visible so operational reports remain faithful to what the system observed.

Start with the in-memory model and the adapter's real completion and cancellation paths. Verify the event schedules, connect the evidence to conversation history, and use content-aware recovery when delivery remains uncertain.

When evaluating 60db Agent or another voice platform, request the public events your integration can observe and test them with synthetic media. The practical result should be a precise delivery claim and a safe recovery path, rather than a stronger claim about human hearing than the media system can support.