Partial transcripts are revisions, not confirmed commands

TL;DR: Treat partial recognition as a replaceable hypothesis scoped to a stream and segment. Only finalized, complete input can become a command candidate, and business authorization, explicit confirmation, and idempotent execution still require separate checks.

---

The recognizer first reports "cancel the order" and later reports "don't cancel the order." If the first string already triggered a tool, a better final transcript cannot undo the business action.

The repair starts at the event adapter. Store the current hypothesis for each segment instead of appending every event to a command log. Publish finalized input through a separate gate, and make the distinction visible in types, tests, and observability.

This article supplies a runnable Python adapter with synthetic revision, duplicate, reconnect, and confirmation fixtures. The example performs no network calls or business writes. It establishes an input boundary you can connect to your own authorized workflow.

As checked on November 9, 2026, Amazon Transcribe documents changing partial results, while Google Cloud's streaming result schema separates finality from stability. Neither property is a caller's authorization to execute a business command.

Table of contents

1. Define the recognition event contract
2. Keep transcript state separate from command authority
3. Build a revision adapter and input gate
4. Test revisions and delivery races
5. Connect finalized input to a business workflow
6. Measure correctness without hiding uncertainty
7. Frequently asked questions
8. Make the commit boundary observable

Define the recognition event contract

Streaming recognition produces observations about audio as context becomes available. A partial result is one hypothesis for a segment. A later event can replace words, punctuation, or the entire phrase associated with that segment.

An adapter must know whether its provider sends a full segment snapshot, an appended delta, a changed result index, or another documented update format. A generic text field is insufficient because identical-looking strings can have different update semantics.

Normalize the provider event into a local record with stream epoch, segment identity, revision order where available, text, finality, and provenance. Keep optional confidence or stability fields as metadata with their documented meaning. Do not collapse them into a single homemade "safe" score.

The Amazon result reference describes segment completion through IsPartial. Its item reference separately describes item stability when partial-result stabilization is enabled. A stable item and a completed segment answer different questions.

Provider finality has a specific scope

A finalized result generally closes a recognition segment under the provider's contract. It does not establish that the person finished the whole conversational turn, that the recognized words are correct, or that a proposed action is permitted.

A caller can finish one phrase and continue with a qualification. "Move the appointment" followed by "but only if the morning slot is free" can span more than one finalized recognition segment. Your turn policy needs an explicit boundary beyond segment finality.

Keep recognition completion, turn completion, and action confirmation as separate facts. A system can observe the first while waiting for the second, then request the third for a consequential action. This separation makes delay understandable instead of hiding every wait behind a single endpointing timeout.

The voice activity and turn-detection guide explains the broader input boundary. Speech silence, a recognizer final flag, and the end of a caller's intent need distinct evidence even when they often happen close together.

Snapshot and index protocols

Some APIs expose a session-level result list with changed indices. In the browser Web Speech API, resultIndex identifies the lowest changed result position. Reprocessing the entire list as new text can duplicate earlier finalized phrases.

The corresponding results documentation describes interim results being replaced or removed while final results persist. Implement the documented list semantics instead of converting every callback into append-only text.

A segment identifier may reset after reconnect or a new recognition session. Scope it to an epoch controlled by your adapter. Otherwise, a late event from an old stream can overwrite a new segment that happens to reuse the same identifier.

Revision order needs evidence

Use a provider sequence or revision value only when its ordering semantics are documented. A local arrival counter describes arrival order, not necessarily the producer's revision order. If the transport guarantees order, preserve that guarantee within its actual scope.

When the source supplies no revision number, the adapter can process ordered events serially and issue its own local version. Document that choice. It cannot detect a stale event delivered out of order by an intermediate relay unless another field supplies the missing evidence.

Keep text normalization after this protocol step. Removing punctuation or lowercasing for an intent matcher can be reasonable, but the raw normalized event should remain distinguishable from the derived command candidate. That distinction is useful when a transcript correction changes meaning.

Recognition provenance and durable business-operation identity solve different retry problems.

Keep transcript state separate from command authority

A partial transcript can update captions, help prepare a response, or start reversible speculative work. Those consumers must know that the input can change. Publishing the same event to an unrestricted tool executor erases the uncertainty boundary.

Define separate channels or data types for draft text and finalized input. A command parser should accept the latter type, not an arbitrary string from the caption UI. This is a small boundary that prevents future callers from accidentally bypassing the gate.

The speculative tool-calling guide distinguishes preparing work from committing an external side effect. A partial hypothesis can support a speculative read only if its policy handles privacy, cost, invalidation, and stale results. It does not justify an early business write.

Final text remains fallible

Finality describes the recognizer's update promise. A final transcript can still contain a wrong identifier, miss a negation, or attribute background speech to the caller. Consequential fields need their own validation and, where required, explicit confirmation.

For a synthetic appointment request, the system can parse a candidate time from finalized text, check availability, read the proposed appointment back, and ask for confirmation. The business service then checks the current state before committing the booking. Each step closes a different source of uncertainty.

Avoid reading a confidence value as a universal probability of safe execution. A recognizer score is not calibrated automatically for your language, acoustic conditions, critical fields, or business risk. Use observed error cases and abstention behavior rather than a round threshold chosen without evaluation.

Authorization belongs to the business boundary

A caller saying "yes" can confirm only the proposal currently pending for that caller and task. It should not authorize a different operation created by another turn, an old response, or a concurrent call sharing a phone number.

Bind confirmation to a proposal version, authenticated subject where required, task identity, and expiration policy. If the proposed action changes, invalidate the old confirmation. A transcript gate should produce evidence for that workflow without pretending to perform authorization itself.

The workflow enforcement guide provides the larger model. Tools should enforce the state and permission requirements in code, even when a language model produces a plausible command from finalized input.

Display state can still mislead

A caption interface should mark unstable text so a user does not mistake it for a committed command. Replacing draft text is expected behavior. Repeating it as new chat messages creates a false history and can confuse downstream summaries.

Accessibility matters here. Do not announce every partial replacement as a permanent success message through an assistive live region. Separate rapidly changing captions from durable status updates and provide a clear final representation under the UI's accessibility policy.

A transcript display also needs privacy limits. Recognition can capture background speech or another person. Keep access, retention, and downstream uses within the approved data policy, even when the text never reaches a business tool.

A finalized phrase can still be followed by a qualification that changes the request.

Build a revision adapter and input gate

The example below assumes normalized full-segment snapshots with a strictly increasing revision number per segment. A real provider adapter must establish that contract from its documented protocol or an ordered relay.

The code ignores strictly older revisions, including delayed drafts arriving after finalization, and refuses changed events at the finalized revision or higher. Exact retries of the current event remain duplicates; reusing the current draft revision with changed text or finality is an identity conflict, because this normalized contract requires a new revision for every change.

The confirmed-input gate is deliberately narrow. It requires a finalized result, an independently supplied turn-complete signal, and a matching explicit confirmation for the synthetic action. It is an illustration of boundary enforcement, not a complete authentication or business transaction implementation.

Save it as transcript-gate.py and run with Python 3. All identifiers and text are synthetic. There are no real customer values, recordings, credentials, tool calls, or external side effects.

from dataclasses import dataclass

@dataclass(frozen=True)
class Update:
    epoch: str
    segment: str
    revision: int
    text: str
    final: bool


class RevisionAdapter:
    def __init__(self, epoch):
        self.epoch = epoch
        self.latest = {}
        self.finalized = {}

    def apply(self, event):
        if event.epoch != self.epoch:
            return "old_epoch", None
        if type(event.revision) is not int or event.revision < 0:
            raise ValueError("non-negative integer revision required")
        if not event.segment or not isinstance(event.text, str):
            raise ValueError("segment and text required")
        key = event.segment
        previous = self.latest.get(key)
        if previous is not None:
            if event == previous:
                return "duplicate", None
            if event.revision < previous.revision:
                return "stale_revision", None
            if key in self.finalized:
                raise ValueError("update conflicts with finalized segment")
            if event.revision == previous.revision:
                raise ValueError("revision reused with different payload")
        self.latest[key] = event
        if not event.final:
            return "draft", None
        self.finalized[key] = event
        return "final", event


class ConfirmedInputGate:
    def __init__(self):
        self.used = set()

    def admit(self, event, *, turn_complete, proposal, confirmed_proposal):
        if not event.final or not turn_complete:
            return None
        if not proposal or proposal != confirmed_proposal:
            return None
        key = (event.epoch, event.segment, proposal)
        if key in self.used:
            return None
        self.used.add(key)
        return {"input_key": key, "text": event.text,
                "proposal": proposal}


if __name__ == "__main__":
    adapter = RevisionAdapter("stream-a")
    gate = ConfirmedInputGate()
    first = Update("stream-a", "segment-a", 1, "cancel the order", False)
    revised = Update("stream-a", "segment-a", 2, "don't cancel the order", False)
    final = Update("stream-a", "segment-a", 3, "don't cancel the order", True)
    assert adapter.apply(first) == ("draft", None)
    assert adapter.apply(revised) == ("draft", None)
    assert adapter.apply(revised) == ("duplicate", None)
    for conflict in (
        Update("stream-a", "segment-a", 2, "cancel the order", False),
        Update("stream-a", "segment-a", 2, revised.text, True),
    ):
        try:
            adapter.apply(conflict)
        except ValueError as error:
            assert "revision reused" in str(error)
        else:
            raise AssertionError("changed payload reused a draft revision")
        assert adapter.latest["segment-a"] == revised
    assert adapter.latest["segment-a"].text == "don't cancel the order"
    assert adapter.apply(first) == ("stale_revision", None)
    status, candidate = adapter.apply(final)
    assert status == "final" and candidate == final
    assert adapter.apply(first) == ("stale_revision", None)
    assert adapter.latest["segment-a"] == final
    assert adapter.finalized["segment-a"] == final
    assert adapter.apply(final) == ("duplicate", None)
    assert adapter.apply(Update("old", "segment-a", 9, "cancel", True))[0] == "old_epoch"
    assert gate.admit(revised, turn_complete=True,
                      proposal="keep-order", confirmed_proposal="keep-order") is None
    assert gate.admit(final, turn_complete=False,
                      proposal="keep-order", confirmed_proposal="keep-order") is None
    assert gate.admit(final, turn_complete=True,
                      proposal="keep-order", confirmed_proposal="cancel-order") is None
    assert gate.admit(final, turn_complete=True,
                      proposal="keep-order", confirmed_proposal="keep-order") is not None
    assert gate.admit(final, turn_complete=True,
                      proposal="keep-order", confirmed_proposal="keep-order") is None
    for revision in (3, 4):
        try:
            adapter.apply(Update("stream-a", "segment-a", revision, "cancel", True))
        except ValueError as error:
            assert "finalized segment" in str(error)
        else:
            raise AssertionError("conflicting final accepted")
        assert adapter.latest["segment-a"] == final
        assert adapter.finalized["segment-a"] == final
    print("Synthetic revision and gate fixtures passed")

The two classes enforce different properties. The adapter owns a provider-normalized transcript projection. The gate owns whether that specific input can become a candidate for a confirmed proposal. The business service must still validate the candidate and enforce durable operation identity.

The gate's in-memory used set prevents duplicate admission only within one process lifetime. It is not a distributed idempotency store. If a candidate can cause a write, the business service needs durable deduplication and concurrency control at the transaction boundary.

Improve the example only for a real contract

A multi-segment turn needs an ordered finalized-segment collection, not a concatenation of every draft seen. Store the segment order from a documented media or protocol field, then derive the turn text when the turn-complete policy permits it.

If the provider can revise finalized segments, represent those revisions as explicit corrections under that documented contract. The sample's conflict refusal is appropriate only for its stated immutable-final model. Do not silently discard a legitimate correction because another provider used the same word "final."

A bounded cache is also required in a long-lived process. Evict transcript state only after the owning stream or turn has closed and required downstream outcomes are reconciled. Retain durable action identity separately so memory cleanup cannot reauthorize a duplicate write.

Validate trust-boundary types

A normalized event should validate the final flag as an actual boolean, its identifiers as bounded strings, and its revision as an integer in the accepted range. Apply the same discipline to the turn-complete and confirmation events supplied by other components.

The example trusts construction of the dataclass inside its synthetic harness. A network adapter cannot rely on type annotations alone. Parse and validate external JSON with the project's existing validation tools before creating the normalized record, and reject malformed events with an observable reason.

Never coerce a string such as "false" into truthiness for a final flag. That single conversion can turn a partial transcript into apparently finalized input. Include malformed type fixtures at the actual protocol boundary, where they protect behavior rather than merely repeating a class definition.

Test revisions and delivery races

A useful suite describes the interleavings that can cross the boundary. Start with a partial phrase whose meaning changes, then add a duplicate final, an old stream event, a conflicting revision, and a confirmation that refers to the wrong proposal.

Preserve the exact sequence in each fixture. A final transcript-only corpus cannot reveal premature execution because it removes the unstable states that caused the action. Store synthetic event streams alongside the expected projection and command-admission outcomes.

The voice regression guide explains how to keep fixtures stable while versions change. For this boundary, the central assertion is that no external action becomes eligible from a draft event, regardless of how convincing its words look.

Delivery duplicates and semantic duplicates

A repeated event and a repeated user instruction are different. Deduplicate the former by protocol identity, not by text alone. Two legitimate turns can contain identical words and still represent different user requests.

A business operation needs a separate identity that survives retries and possibly redials. A recognition segment identifies an observation of audio. Reusing it as the only booking or cancellation key couples business correctness to a media session's lifetime.

A replay test should send the same final event twice and expect one admission for the same proposal. A second test should create a new proposal and verify that the business workflow, rather than text equality, decides whether it is a new legitimate operation.

Reconnect and delayed events

Create a new epoch when the recognition stream is replaced. After that transition, deliver a delayed partial and final from the old epoch. Neither should update the new caption projection or become a candidate for the new turn.

If a reconnect resumes the same provider session under an explicit continuation protocol, preserve the required cursor and ordering semantics. Do not invent a new epoch where the protocol requires continuity, or reuse an old epoch where identifiers have reset. The adapter's contract should make that choice visible.

Keep a small state-transition log without raw text when possible: stream replaced, draft updated, final accepted, stale event rejected, proposal changed, and candidate admitted. These events make a race diagnosable without publishing a transcript.

Finalization before turn completion

Construct a synthetic multi-phrase request with a qualification after a finalized first segment. Verify that the first final does not open the command gate while the turn remains active. Then finalize the qualification and close the turn under the chosen policy.

Include an explicit user interruption during the assistant's confirmation question. The expected result may invalidate the pending proposal and return to clarification. A late "yes" from an earlier recognition segment must not confirm a newly phrased action.

The sentence-boundary guide covers the output-side version of the same commitment problem. Input and output both need source identity and explicit invalidation, but their completion signals come from different owners.

Comparison criteria

A check means that the mechanism directly supplies the stated evidence. A cross means it cannot establish that property on its own. This is a boundary comparison, not a claim about any provider's complete product.

The table makes missing evidence explicit. A final-result flag cannot fill the authorization column because it describes a recognition process. A business transaction cannot repair a caption projection that has already duplicated words, though it can prevent an unauthorized write.

Connect finalized input to a business workflow

Use the finalized turn text to derive a candidate intent and typed fields. Validate each field against the tool schema and current business state. If a field is ambiguous, ask a specific repair question and keep the proposal pending.

For consequential writes, read back the action in terms the caller can verify. Bind the response to that exact proposal version. If availability, price, scope, or the requested target changes, require a confirmation appropriate to the new proposal rather than carrying the old "yes" forward.

A finalized instruction can still come from an unauthenticated person. Apply the business service's identity and permission checks independently. Recognition metadata such as speaker labels or acoustic confidence is not a replacement for an authorization contract.

Preserve negative intent

Negation and correction deserve specific fixtures because a small recognition error can reverse an action. Use synthetic pairs such as "cancel" and "don't cancel," or "move it" and "don't move it yet," with matching tool-admission expectations.

Do not create a parser that drops common words before determining intent if those words can carry negation or scope. A keyword hit on "cancel" is insufficient when the rest of the phrase forbids cancellation. Keep the complete finalized context available to the intent decision.

When the caller corrects a field, invalidate the previous proposal before preparing the new one. The correction should not create two independently executable pending actions. Test that a delayed result or confirmation for the old version remains rejected.

Keep read and write policy explicit

An early speculative lookup can also expose private information or consume money. Label read operations by their actual risk and authority requirements, rather than assuming every read is harmless. Partial input should not select another person's record without the required identity boundary.

If a speculative result returns after the input revision changed its target, reject it from the current response. A valid database answer to an obsolete question is still stale evidence. Carry proposal or input-version identity through the lookup so the result can be checked before use.

A write should execute through a task-scoped durable operation identifier. The recognizer event key can appear in provenance, but it should not be the only deduplication mechanism. Media retries and business retries have different lifetimes and failure modes.

Escalate uncertainty truthfully

When the input remains ambiguous, say what needs clarification. Avoid telling the caller an action failed if it was never authorized or attempted. Avoid saying it succeeded merely because the recognizer produced a confident final phrase.

The truthful waiting-speech policy applies while validation or tools run. Separate acknowledgment, pending status, unknown outcome, and verified success so a recognition event does not become a progress claim it cannot support.

If a human handoff is required, transfer the current proposal and its verification state under the approved data policy. The warm-handoff guide explains why a concise verified summary is more useful than treating every partial hypothesis as conversation truth.

Measure correctness without hiding uncertainty

Measure how often partial text changes before finalization, but use that metric to describe the tested corpus rather than as an automatic execution threshold. A low average revision rate does not make a critical negation safe to act on early.

Record draft-to-final delay separately from turn-completion delay and confirmation delay. If the overall workflow becomes slow, that separation shows which owner needs investigation. The latency benchmark provides a consistent clock and response-boundary framework.

Count false admissions, duplicate admissions, rejected stale events, conflicting finals, clarification outcomes, and missing final results. Keep denominators explicit. A stream with no final result should not disappear from a report merely because no command was emitted.

Critical-field outcomes

Evaluate identifiers, dates, quantities, and negations alongside aggregate transcript quality. A transcript can be mostly correct while naming the wrong order or appointment. The relevant test asks whether the workflow chose the right action under the right authority.

Keep abstentions visible. A gate that asks for clarification can prevent a wrong action, but excessive clarification can make the product unusable. Compare safe completion and repair behavior on a representative corpus rather than optimizing a single error rate without its user cost.

Use a held-out set with the same approved privacy rules as development fixtures. If you tune confirmation thresholds against every example you later report, the result describes a fitted test set rather than evidence about unseen calls.

Provider and version changes

A recognition update can change punctuation, segmentation, or finalization timing without changing your code. Pin the relevant model or API version where supported and preserve the observed configuration in each test run.

The browser's isFinal documentation defines a result-level property and notes the API's limited availability. Feature support and update semantics belong in the device matrix, especially when mobile browser lifecycle behavior affects stream continuity.

Run the adapter contract tests against captured synthetic protocol fixtures before adopting a provider change. Then run the end-to-end workflow tests. Correct final-flag parsing does not establish correct business outcomes, but it gives the later tests a trustworthy input boundary.

Migrate an append-everything consumer safely

Find every consumer of recognition events before changing the adapter. Captions, summaries, analytics, intent parsing, and tool execution may all receive the same callback today. Classify each consumer by whether it needs draft display, finalized text, or a confirmed command candidate.

Introduce the normalized projection at the boundary and keep the existing public event shape only where compatibility requires it. Do not force a caption consumer to wait for business confirmation merely because the command executor needs a stronger gate. Distinct consumers can share provenance while accepting different uncertainty levels.

Run the old and new projections in a read-only comparison harness using synthetic event sequences. Inspect differences in reconstructed text, draft replacement, final ordering, and duplicate handling. Keep the old executor disabled in that harness so comparison cannot accidentally create two action owners.

When the projection is correct, connect the new confirmed-input path to the existing business workflow in a test environment. Exercise a delayed final, a partial containing a tempting command, a changed proposal, and a retry after process restart. These tests check the seams that a unit-only adapter suite cannot cover.

Remove the old append-only command subscription once the new path is verified. Leaving both active as a fallback can reintroduce premature execution through the older consumer. Preserve an explicit rollback route that restores one known owner, rather than two competing consumers racing to commit the same request.

Test the service boundary after process failure

The sample gate records admission before returning its candidate. A production process can stop between recording local state and sending a tool request, or after the business service commits but before the response is recorded. Those windows cannot be closed by an in-memory set.

Use the existing business service's durable operation key and transaction behavior. If the operation outcome is unknown, query by that key or follow the service's documented reconciliation route. Creating a new key for every transport retry defeats deduplication because each retry appears to be a new business operation.

A useful synthetic integration fixture commits an operation, drops its response, and restarts the caller. The next attempt should recover the existing outcome under the same operation identity. It should neither perform the operation again nor tell the user it failed solely because the first response was lost.

Another fixture stops before commit. Recovery should either safely resume the same intended operation or leave a visible pending state, depending on the service contract. The test must distinguish confirmed nonexecution from an unknown result, since those states permit different retry behavior.

Keep recognition provenance with the operation record only to the extent required for audit and diagnosis. The business key represents the intended action; the transcript event key identifies the input observation that helped form it. That separation also allows a human operator to reconcile the action after the media session has ended.

Review aggregate errors without losing severe cases

A pooled recognition accuracy number can hide a small set of costly command errors. Build an error taxonomy that separates wrong target, wrong action, missed negation, lost qualification, duplicate attempt, and unauthorized admission. Give every category an expected workflow outcome in the test suite.

Review severe cases individually even when their count is low. A single synthetic fixture can prove a deterministic bypass, while a large average cannot make that bypass safe. Fix the boundary and preserve the fixture instead of adjusting a confidence threshold until the example disappears from a report.

The opposite mistake is treating every draft revision as a failure. Revising hypotheses is expected streaming behavior. A correct application can display those revisions and still execute the right confirmed action. Judge the adapter by its projection and the workflow by its outcomes, keeping those denominators separate.

If a change increases clarification, inspect whether it catches real ambiguity or merely repeats questions after duplicate delivery. Deduplication defects can look like cautious policy. Correlate the clarification event with its input and proposal version before deciding that the recognizer or confirmation policy needs tuning.

Specify retention at stream closure

Close the transcript projection when the stream ends, and decide which small records remain necessary for audit or reconciliation. A completed media stream should not leave an ever-growing dictionary of every provisional phrase in a long-lived worker. Keep unresolved business-operation state in its durable owner rather than retaining the entire transcript as a substitute.

Test eviction against late delivery. After a stream is closed, a delayed event must remain rejected even if its detailed segment state has been removed. A bounded closed-epoch marker or the existing session lifecycle can enforce that rule. The exact mechanism should match the application's current ownership model.

Give operational counters an explicit reset boundary. A process-wide rejected-event count can help detect a provider or relay problem, while a per-turn count explains a specific call. Combining them without labels makes a healthy new stream appear to inherit an old stream's failures.

For a retention review, enumerate the consumers of finalized text and draft text separately. Summaries, analytics, captions, and audit storage can have different legitimate needs. Removing a draft from the UI does not remove copies already sent downstream, so data handling must be enforced at each actual consumer.

A closure fixture should include a pending segment with no final result. The expected outcome is incomplete input, with no command admission. Do not promote the last partial merely because the connection ended. If the product offers repair, ask the caller to repeat the missing request under a new supported stream and proposal boundary.

Keep this incomplete-input category in evaluation reports. Otherwise a stricter gate can appear perfect by omitting streams that never produced a usable final result, while the caller experiences repeated failures to complete a task.

Operational evidence

Log rejection reasons as bounded categories, not entire transcripts. An operator should distinguish old epoch, stale revision, duplicate delivery, malformed event, and wrong confirmation version. Those categories point to different repairs.

Attach trace correlation without exposing customer identifiers. A session-scoped opaque test key is enough for many adapter incidents. If content inspection is needed, use approved access and retention rather than putting raw speech into broad application logs.

The observability guide connects those events to a turn trace. Keep the trace's state transitions faithful: finalized input accepted, proposal pending, confirmation received, business action attempted, and outcome verified should remain separate observations.

The following conceptual figure concerns admission to the finalized-input projection. "Accept once" does not authorize a tool; turn completion, proposal confirmation, and business authorization remain separate gates.

---

Inspect each subscriber before replacing an append-only transcript consumer.

Frequently asked questions

What is a partial transcript?

It is a provisional recognition hypothesis for audio under a provider's streaming contract. Later events can replace or remove parts of it. Store it as replaceable state scoped to the stream and segment, rather than treating every callback as new confirmed words.

Can a partial result trigger a tool?

Only under a specifically designed speculative policy for reversible work with appropriate privacy and cost controls. It should not authorize a consequential business write. Keep draft consumers separate from the confirmed-input path and invalidate speculative results when the input changes.

Does final mean the transcript is correct?

Final means the recognizer has completed that result under its update contract. It can still contain recognition errors. Validate critical fields and intent, apply turn-completion policy, and obtain the confirmation and authorization required for the proposed business action.

Is a stable word equivalent to a final segment?

No. Stability can describe an item within a still-partial result. Segment finality describes completion of the result. Read each provider's definitions and keep both fields separate if exposed. Neither property independently establishes that the caller finished the whole request.

Why do words appear twice in my transcript?

A common cause is appending full partial snapshots and then appending the final snapshot again. Follow the provider's replacement or index protocol. Deduplicate event delivery by identity while preserving legitimate repeated words in separate segments or turns.

Should I deduplicate by transcript text?

Text equality cannot distinguish a duplicate delivery from a legitimate repeated request. Use stream, segment, and documented revision identity for event handling. Use a separate durable business-operation identity to prevent repeated writes across retries, reconnects, and redials.

What if my provider has no revision counter?

Preserve the documented ordered event stream and issue a local arrival version if needed. State that it represents arrival order. Without additional producer evidence, it cannot identify an out-of-order stale revision introduced by a relay or an unsupported transport behavior.

Why add a stream epoch?

Segment identifiers can be reused after reconnect or restart. An epoch prevents an old event from overwriting a new segment with the same local identifier. Test delayed old-stream partials and finals after the replacement stream has begun receiving input.

Does a final segment close the user turn?

Not necessarily. A request can span several finalized segments, including a later qualification. Keep a separate turn-completion policy based on the interaction contract. Do not execute an incomplete request simply because one recognition segment has stopped changing.

How should I handle a conflicting final result?

Follow the provider's documented correction semantics. Under an immutable-final contract, surface a protocol conflict and avoid silent replacement. If final corrections are supported, represent them explicitly and reconcile any affected proposal or action rather than hiding the correction in the caption state.

Can a confidence threshold replace confirmation?

A recognition confidence value is not automatically calibrated for your workload or business consequence. Confirmation verifies a caller's response to a particular proposal. Use observed errors to design abstention and repair policy, while keeping required confirmation and authorization independent.

How do I handle a later don't or correction?

Preserve the complete revised phrase and invalidate any proposal derived from the earlier version. If an external action already occurred, use the business workflow's repair path. The input adapter should prevent early draft execution so recognition improvements do not arrive after an irreversible action.

Is a caller's yes enough?

It is meaningful only in the context of the exact current proposal and required identity boundary. Bind confirmation to a proposal version and task, and reject delayed confirmation for an old proposal. A generic affirmative transcript is not unrestricted tool authority.

What does the Python example prove?

It checks replacement of drafts, stale-revision rejection, old-epoch rejection, duplicate-final handling, and a narrow proposal-bound gate. It performs no real action. Durable deduplication, authentication, multi-segment ordering, and external transaction correctness remain integration responsibilities.

Can the in-memory used set prevent duplicate bookings?

It prevents repeated admission only within that process lifetime. A restart or another worker has different memory. The booking service needs durable operation identity and transaction-level concurrency control, with the recognition key retained only as input provenance.

What should a revision fixture contain?

Store the ordered synthetic events, expected current draft, finalized segments, turn state, proposal version, and expected admissions. Include changed negation, duplicate delivery, reconnect, stale confirmation, malformed fields, and delayed callbacks. A final-text-only fixture cannot reveal premature execution.

Should captions show interim text?

They can, provided the UI makes provisional status clear and follows accessibility and privacy requirements. Replace draft text rather than creating permanent history entries for every revision. Keep caption display separate from tool authority and verified business status.

How should I log adapter failures?

Use bounded reason codes and content-free state transitions where possible. Record enough identity to correlate a stream and segment without publishing customer text. Separate malformed events, stale revisions, duplicates, and conflicts so operators can choose the right recovery path.

How do I compare recognition providers fairly?

Normalize each documented event contract separately and run the same workflow outcomes, critical-field fixtures, and failure accounting. Keep language, device, model version, and acoustic cohorts explicit. A lower draft delay does not establish safer execution or better task completion.

How does this apply to 60db Agent?

Use the boundary as an external evaluation method around documented integrations. Verify how input revisions, confirmations, and tool outcomes appear in your application. This article describes generic engineering patterns and does not disclose private architecture or claim measured behavior for 60db Agent.

Make the commit boundary observable

Begin by proving that partial snapshots replace draft state and never become unrestricted commands. Add finality, turn completion, proposal confirmation, and durable business authorization as distinct gates with explicit rejection reasons.

Run the synthetic adapter tests, then connect the gate to your workflow-enforcement tests. Keep the first real integration trial read-only until its event projection and stale-input handling match the documented protocol and the approved action boundary.