Handle 'yes, but...' as a repair, not a completed confirmation

TL;DR: A qualified answer such as "yes, but change the day" reopens the proposal instead of confirming its earlier version. Wait for the complete answer, invalidate approval when material fields change, and require fresh confirmation tied to the current proposal before the business controller can commit.

---

The agent asks whether to book the proposed appointment. The caller says "yes, but make it Friday," and the application submits the original day as soon as it recognizes "yes." The rest of the sentence becomes a correction to an action that should still have been pending.

This failure crosses several boundaries. Streaming recognition exposes a prefix, endpointing closes an answer, language interpretation labels its meaning, and business logic decides whether to act. A prompt telling the model to be careful cannot replace a contract across those boundaries.

The practical fix is a versioned proposal with a repair state. This guide provides an executable confirmation controller, negative conversation fixtures, and release criteria that make it possible to prove which proposal was approved and which action was committed.

Every conversation example and test is synthetic. Figures are conceptual, and no customer data or private implementation of 60db Agent is described. Public documentation was reviewed on November 9, 2026; the article does not claim a measured reduction in confirmation errors.

Table of contents

1. Define what the caller is confirming
2. Interpret the complete answer
3. Make repair an explicit state
4. Implement versioned confirmation
5. Build negative conversation fixtures
6. Protect the business commit boundary
7. Evaluate recognition and task outcomes
8. Handle late changes honestly
9. Frequently asked questions
10. Ship a confirmation invariant

Define what the caller is confirming

A proposal is the specific set of action parameters presented for approval. It needs an identity and version, along with the material fields that determine what the action will do.

For an appointment, that may include the service, date, time zone, location, and any material condition. For an address change, it may include the target account, destination address, and effective scope. The exact fields belong to the task contract rather than a universal confirmation schema.

An affirmative word is meaningful only relative to a pending question. The caller can say "yes" to hearing a repeat, to understanding an explanation, or to a proposal. A global affirmative intent cannot safely decide among those meanings without context.

The Amazon Lex confirmation documentation distinguishes confirmation, decline, and failure responses and allows validation before fulfillment. It supplies a public example of separate stages; it does not prove that every qualified answer will be resolved correctly in your workflow.

Store the proposal version with the prompt that presented it. When playback completion is observed, record the actual endpoint and its limitations. It does not prove the caller heard or understood the material terms.

The playback evidence guide explains those boundaries. An answer to a half-played read-back needs clarification when the unplayed portion contains a material condition.

Separate acknowledgment from approval

A listener can acknowledge what the agent is saying without authorizing an action. A caller saying "right" during a long explanation should not approve a booking that has not yet been fully presented.

The Amazon Lex confirmation slot reference normalizes several acknowledgment-like expressions. Keep that interpretation scoped to the current question and preserve uncertainty rather than treating the normalized value as business authority.

The backchannel floor guide covers the conversational consequence. Whether the agent should stop talking is a different decision from whether an operation may execute.

This separation helps tests stay precise. A fixture can require the agent to stop for a caller correction while also requiring the proposal to remain unapproved and the business-action count to remain unchanged.

Define material changes

A material change alters what the caller is approving or the conditions under which it will happen. Changing the appointment day is material; correcting a harmless display spelling may or may not be, depending on the task and downstream use.

Write that classification in the application contract. Do not let a language model silently decide which fields are safe to change after approval because a sentence sounds minor.

If a change affects a material field, increment the proposal version and clear confirmation. Present the revised proposal in an appropriate read-back and obtain a new scoped answer before commit.

For low-risk presentation changes, keep the audit trail even when reconfirmation is unnecessary. The reason for preserving approval should be deterministic and reviewable, not an undocumented exception in a prompt.

Conceptual: Confirmation evidence must match the current proposal and answer attempt before further checks can pass.

Interpret the complete answer

A streaming prefix is an observation, not a completed answer. "Yes" can become "yes, but..."; "sure" can become "sure, if the fee is waived"; and "okay" can begin a question rather than acceptance.

The Google streaming result reference defines finality for a particular recognition result. It does not establish that the caller finished the entire confirmation turn, so keep recognition finality separate from answer closure.

Use the partial-transcript gate before any consequential interpretation. Interim text can drive reversible UI feedback, but it should not directly commit a business action.

The endpoint controller needs to preserve continuation evidence. An answer that ends in "but," "unless," or an unfinished replacement should remain pending or move to clarification rather than accepting the opening affirmative.

Classify answer meaning with a bounded contract

Useful dispositions include unconditional acceptance, decline, repair, conditional acceptance, question, and unresolved. These labels should describe the complete scoped answer and carry evidence identity back to the proposal version.

A repair supplies a change to the proposal. A condition introduces a requirement that must be resolved before approval is valid. A question asks for information and leaves approval pending. Unresolved input requires clarification.

Do not merge these labels into a boolean too early. The original meaning is needed for a useful response: a repair needs a revised read-back, while a question needs an answer before another confirmation attempt.

The following table is a proposed application contract. ✓ means the action is permitted by the stated evidence; ✗ means it is prohibited. It is not a claim about any vendor's classifier.

An incomplete answer should not be labeled as a repair merely to force a category. Keep its completion state separate from meaning so that the controller can wait without inventing the missing change.

Avoid lexical shortcuts

A rule that looks only for the word "but" misses many qualifications. Callers can say "yes, except the address," "okay, make it later," or "fine, provided..." without using the same cue.

A rule that rejects every occurrence of "but" can also misread quoted text or a sentence whose qualification does not concern the proposal. Use full scoped meaning and retain an unresolved path when the target is unclear.

The structured endpointing guide helps preserve incomplete clauses. The confirmation controller should receive a complete-answer decision and an interpretation, rather than trying to infer both from one keyword.

A semantic model can supply bounded interpretation evidence. The application still owns field allowlists, proposal versioning, authorization, and the final commit gate; a plausible model label is not proof that the business operation is permitted.

Make repair an explicit state

Repair suspends the previous proposal's approval and identifies what needs changing. It should begin as soon as the controller has sufficient evidence of a material qualification, while preserving the full answer for interpretation.

If the caller starts speaking while approval is pending, block commit until that new input is resolved. Otherwise a race can submit the action between the opening "yes" and the later correction.

The only path to commit goes through fresh confirmation of the current proposal. A repair creates a new proposal version. There is no shortcut from the qualified answer directly to the original action.

Preserve unaffected fields deliberately

A caller changing the day usually does not intend to erase the service or destination. Apply a scoped patch to the current proposal, validate the resulting whole, and keep unchanged fields with their existing provenance.

Do not infer the patch target when several fields are plausible. "Make the other one Friday" may refer to another appointment or another participant. Ask a targeted question before replacing a field.

The field revision ledger provides a deeper treatment of targeted changes. Confirmation repair consumes the revised projection and invalidates approval for the previous version.

Reconfirm the resulting proposal

After validation, present the current material terms at a level appropriate to the task. A local read-back can be enough for a narrow field change when the rest of the proposal remains explicit; a full read-back may be needed when several dependencies changed.

Keep the read-back tied to the proposal version. If a tool refresh changes availability or price after the read-back, the old confirmation cannot silently apply to the newly returned terms.

The Amazon Lex intent API exposes confirmation state separately from fulfillment state. That separation is useful in any implementation: approval and completed execution are distinct facts.

Use state names that reflect those facts. approved means the current proposal passed the confirmation gate; committed means the business owner accepted the action under its own authoritative contract.

Implement versioned confirmation

The following Python program models proposal and confirmation transitions in one serialized controller. It consumes explicit interpretation evidence; it does not pretend to recognize qualified speech with a keyword parser.

Save it as confirmation_repair.py and run python3 confirmation_repair.py. All values and fixtures are synthetic, and commit records an in-memory result rather than calling a real booking service.

from dataclasses import InitVar, dataclass, field
from types import MappingProxyType
from typing import Mapping

@dataclass
class Proposal:
    initial_fields: InitVar[dict]
    version: int = 1
    state: str = "awaiting"
    input_open: bool = False
    input_generation: int = 0
    approved_version: int | None = None
    committed: dict | None = None
    allowed: frozenset = field(default_factory=lambda: frozenset({"day", "service"}))
    _fields: Mapping[str, str] = field(init=False, repr=False)

    def __post_init__(self, initial_fields):
        if any(not isinstance(v, str) or not v.strip() for v in initial_fields.values()):
            raise ValueError("proposal values must be nonempty strings")
        self._fields = MappingProxyType(dict(initial_fields))

    @property
    def fields(self):
        return self._fields

    def begin_input(self):
        if self.state == "committed":
            return "late_change"
        self.input_generation += 1
        self.input_open = True
        self.approved_version = None
        self.state = "evaluating"
        return "collect"

    def resolve(self, attempt, version, complete, meaning, patch=None):
        if self.state == "committed":
            return "late_change"
        if version != self.version:
            return "stale"
        if attempt != self.input_generation:
            return "stale"
        if not self.input_open:
            return "no_open_input"
        if not complete:
            return "listen"
        self.input_open = False
        if meaning == "repair":
            if (not patch or set(patch) - self.allowed
                    or any(not isinstance(v, str) or not v.strip()
                           for v in patch.values())):
                self.state = "clarify"
                return "clarify"
            self._fields = MappingProxyType({**self.fields, **patch})
            self.version += 1
            self.approved_version = None
            self.state = "awaiting"
            return "present_revised_proposal"
        if meaning == "accept":
            self.approved_version = self.version
            self.state = "approved"
            return "approved"
        self.approved_version = None
        self.state = "declined" if meaning == "decline" else "clarify"
        return self.state

    def commit(self, version):
        if (self.state != "approved" or self.input_open
                or version != self.version or self.approved_version != version):
            return "blocked"
        self.committed = dict(self.fields)
        self.state = "committed"
        return "committed"

if __name__ == "__main__":
    p = Proposal({"day": "Thursday", "service": "inspection"})
    p.begin_input()
    assert p.resolve(p.input_generation, 1, False, "accept") == "listen"
    assert p.commit(1) == "blocked"
    assert p.resolve(p.input_generation, 1, True, "repair", {"day": "Friday"}) == "present_revised_proposal"
    assert p.version == 2 and p.fields["day"] == "Friday"
    assert p.resolve(p.input_generation, 1, True, "accept") == "stale"
    assert p.commit(1) == "blocked"
    p.begin_input()
    assert p.resolve(p.input_generation, 2, True, "accept") == "approved"
    old_attempt = p.input_generation
    p.begin_input()
    assert p.resolve(old_attempt, 2, True, "accept") == "stale"
    assert p.commit(2) == "blocked"
    assert p.resolve(p.input_generation, 2, True, "condition") == "clarify"
    p.begin_input()
    assert p.resolve(p.input_generation, 2, True, "accept") == "approved"
    assert p.commit(2) == "committed"
    assert p.committed["day"] == "Friday"
    assert p.begin_input() == "late_change"
    assert p.commit(2) == "blocked"
    q = Proposal({"day": "Thursday", "service": "inspection"})
    q.begin_input()
    assert q.resolve(q.input_generation, 1, True, "repair", {"unexpected": "value"}) == "clarify"
    assert q.commit(1) == "blocked"
    supplied = {"day": "Thursday", "service": "inspection"}
    r = Proposal(supplied)
    r.begin_input()
    assert r.resolve(r.input_generation, 1, True, "accept") == "approved"
    supplied["day"] = "Monday"
    try:
        r.fields["day"] = "Tuesday"
    except TypeError:
        pass
    else:
        raise AssertionError("public fields must be read-only")
    try:
        r.fields = {"day": "Wednesday", "service": "inspection"}
    except AttributeError:
        pass
    else:
        raise AssertionError("public fields cannot be rebound")
    assert r.fields["day"] == "Thursday"
    assert r.version == r.approved_version == 1
    assert r.commit(1) == "committed"
    assert r.committed == {"day": "Thursday", "service": "inspection"}
    print("Synthetic confirmation-repair checks passed")

begin_input removes approval before interpreting the new speech. That prevents a previously approved proposal from committing while the controller is evaluating a possible correction.

The version check rejects a delayed affirmative tied to the old proposal. It also prevents a response generated for one read-back from approving a revised set of fields.

Construction copies the supplied dictionary into an owned read-only snapshot. Values are immutable strings, and the public fields property supports neither item mutation nor rebinding; an accepted repair replaces the private snapshot and invalidates approval through the versioned path. Mutating the original dictionary after approval cannot change the committed proposal.

This is a boundary for cooperating code in one trusted, serialized controller. It does not protect against arbitrary code that can rewrite private state or approval fields, and it does not replace authorization at the business service. The regressions exercise original-alias mutation, public item mutation, rebinding, and a same-version commit that preserves the approved snapshot.

The patch allowlist keeps the example's repair scope explicit. A production validator must also enforce the task's actual date, service, authorization, and consistency rules; a nonempty string is intentionally only a structural check in this exercise.

Bind interpretation to one input attempt

The program checks an input-generation token as well as proposal version. A late interpretation from an older attempt cannot resolve a newer attempt against the same proposal version. The production adapter must preserve both identities through every asynchronous interpretation callback.

Keep the current prompt identity too. An answer should attach to the proposal and question that elicited it, rather than whichever question happens to be pending when the callback arrives.

Do not infer playback or authorization from resolve. Those are separate preconditions owned by the integration and business service. The example isolates versioned confirmation behavior so its claims remain small enough to verify.

The workflow enforcement guide supplies the broader execution boundary. Use it to keep the dialogue controller from becoming the only defense against an invalid business action.

Keep confirmation revocation monotonic

Once a material repair invalidates approval, duplicate evidence from the old version cannot restore it. Only a fresh answer to the current proposal can create current approval.

A duplicate commit request must also be safe at the business owner. The in-memory exercise blocks a second local commit, while a real service needs its own durable idempotency or operation-identity contract across retries and process restarts.

Avoid turning a transport retry into a new proposal. The proposal identity describes the intended action; the request identity describes one delivery attempt. Keeping them separate helps reconcile uncertain outcomes without asking the caller to approve the same action repeatedly.

Build negative conversation fixtures

The happy path is insufficient. A confirmation system needs examples where approval must remain absent, especially when an affirmative prefix makes the input look easy to classify.

Start with full synthetic exchanges that include the presented proposal, the caller's answer, the expected patch or clarification, and the allowed number of business actions. Keep the model's interpretation and the business verdict as separate assertions.

The reference label should come from the complete exchange. If annotators cannot identify the intended target of a correction, mark it unresolved and test the clarification path rather than inventing a patch.

Include partial transcripts separately. The input sequence yes followed by yes but Friday should exercise revision handling and prove that the first prefix cannot reach the action boundary.

Test event order and duplication

Replay a late old-version acceptance after a repair. Replay duplicate repair events. Replay an approval callback after new speech begins. Replay a commit response after the conversation has moved to an amendment.

A controller should serialize these events or use an equivalent concurrency contract. Without serialization, a version check followed by a separate write can still race with a correction that arrives between them.

Keep a precise observable invariant: no business commit may use a proposal version whose approval was invalidated before the commit boundary. The trace must identify the boundary and event order rather than relying on an after-the-fact transcript summary.

The regression testing guide explains how to version replay fixtures. Label changes should be reviewed because they can change apparent quality without any code change.

The diagram shows a stale affirmative routed to rejection after a correction creates a new version. Current confirmation remains a separate path. The figure illustrates a proposed invariant and contains no measured failure rate.

Include presentation failures

A prompt can omit a material field, mispronounce a date, or be interrupted before completion. A transcript of the generated read-back is insufficient to prove that the caller received the intended proposal.

Test the prompt and playback boundary alongside the semantic answer. If a material condition was not presented under the contract, the answer should lead to clarification or a fresh read-back rather than approval by assumption.

The sentence-boundary TTS guide addresses one upstream risk: streaming text chunks can produce incomplete or misleading spoken units. Keep confirmation phrasing reviewable as a complete material proposition.

Protect the business commit boundary

The business owner must validate current authorization, proposal version, and business state at commit time. A correct dialogue decision cannot prevent a stale availability read or an expired permission from changing the operation's validity.

A generic HTTP example is a conditional update using a current entity tag. MDN's If-Match reference describes how that precondition can prevent a lost update; the exact server resource contract still determines whether the operation is valid.

Do not confuse proposal version with a backend resource version. The proposal represents what the caller approved, while the resource version represents the business state the action depends on. A safe commit may need both.

If the backend rejects a stale precondition, refresh the authoritative state and decide whether the changed terms require another proposal. MDN's conditional-request guide describes the lost-update pattern and failed preconditions as a public reference.

Keep unknown outcomes unknown

A timeout after submission does not prove that the action failed. The backend may have committed before the response was lost, so blindly retrying with a new operation identity can create a duplicate action.

Reconcile through the authoritative business operation state. The dialogue should say the result is still being checked when that is the truth, rather than claiming success or failure to keep the call moving.

The truthful tool-waiting guide covers this caller-facing language. A progress message should reflect observed state and avoid promising a successful result before one exists.

A correction during an unknown outcome requires care. Preserve the desired amendment, reconcile the original operation, and then apply the appropriate update or cancellation contract. Do not silently replace the original request and pretend it never existed.

Make invalidation reach tool preparation

Reversible preparation can start before confirmation if the workflow permits it, but it must remain separate from execution. A repair should invalidate cached preparation tied to the old proposal version when the changed fields affect it.

The speculative tool-calling guide explains that boundary. Reading availability or drafting a request is different from reserving, charging, or sending an irreversible instruction.

Record which preparation version produced the candidate action. A fresh confirmation cannot make an old prepared payload current if it still contains the original day or address.

Conceptual: Approval precedes business execution; a change after commit needs the supported modification workflow.

Evaluate recognition and task outcomes

Measure qualified-answer handling by its final consequence. Did the original proposal remain uncommitted, did the intended repair survive, and did the caller approve the revised version before execution?

Keep component errors visible. Recognition may omit a negation, endpointing may cut before the qualification, interpretation may misclassify the complete answer, or the controller may accept stale approval despite correct interpretation.

A single success metric cannot identify which layer failed. Use a trace with audio or transcript evidence where governed, answer completion, interpretation result, proposal revision, approval version, and authoritative operation result.

The voice observability guide provides a broader trace model. Avoid raw customer content in ordinary metric labels, and use synthetic fixtures in public examples.

Define the denominator before the rate

A qualified-confirmation error rate needs the number of reference qualified-answer opportunities. Include counts for repairs, conditions, questions, declines, and unresolved answers so that a pooled metric does not hide one expensive class.

Report false repair separately. A controller that asks for confirmation repeatedly on an unambiguous acceptance can be safe against premature action while still making the conversation unnecessarily difficult.

Use paired replay for policy changes, then appropriately governed real interaction evaluation for caller behavior. A deterministic fixture pass proves the state transition under its inputs; it does not establish acoustic recognition accuracy or user preference.

The task outcome metrics guide helps distinguish a correctly declined request from a failed booking. A caller changing their mind is a legitimate outcome when the application preserves that choice.

Keep release criteria concrete

Require every mandatory qualified-answer fixture to leave the original version uncommitted. Require old-version approvals to be rejected, incomplete answers to remain pending, and new input to suspend current approval before evaluation.

Also require that a revised proposal can eventually complete through a fresh valid answer. A controller that blocks every action would satisfy one narrow safety invariant while failing the requested task.

Document what was not tested. If the suite uses labeled text evidence, acoustic recognition, transport timing, and caller-observed playback remain separate validation work. Do not convert the absence of failures in a synthetic suite into a production reliability claim.

Conceptual: Evaluate recognition, proposal approval, and authoritative business fields separately.

Handle late changes honestly

A change before commit is a repair to a pending proposal. A change after authoritative commit is an amendment, cancellation, or new operation under the business service's rules.

The caller-facing response should reflect that boundary. If the original action succeeded, say that it exists and explain the supported change path. If its outcome is unknown, reconcile it before claiming that the requested correction has replaced it.

Do not edit the historical confirmation record to make the final state look clean. Preserve which version was approved, what operation was submitted, and what later amendment occurred, subject to the deployment's privacy and retention rules.

The shutdown semantics guide addresses related late callbacks. A call ending does not erase a submitted operation or make a delayed result irrelevant to reconciliation.

Ask a focused repair question

When a qualification is ambiguous, ask only what is missing. "Which day should replace Thursday?" is more useful than restarting the entire booking flow if every other field remains valid.

Avoid presenting uncertain interpretation as a fact. If the model inferred Friday from unclear speech, phrase the clarification as a question and keep approval absent until the value is confirmed under the current proposal contract.

The same approach works when the caller's condition is outside the agent's authority. The controller can explain the available terms or offer a real handoff without implying that the condition was accepted by the business.

For 60db Agent or any other deployment, evaluate this through observable public interfaces and controlled fixtures. The needed property is a defensible proposal-to-commit chain, independent of unpublished internal architecture.

Walk the two commit races

Consider a synthetic schedule in which the caller first approves the current proposal, then begins a correction while a commit request is waiting in the local queue. The controller must serialize the new-input event with the commit decision. If new input is processed first, approval is suspended and the queued commit is blocked. If the authoritative commit already happened, the correction enters amendment. The system must record which boundary won rather than claiming that both outcomes are equivalent.

Now consider a delayed interpretation of an earlier answer. The proposal may still have the same version because the newer input has not yet produced a patch. Version checking alone cannot distinguish these two attempts. An input-generation token prevents the old acceptance from resolving the newer pending input and restoring approval while the caller's current qualification remains unevaluated.

Add both schedules to the replay suite. The first tests serialization between conversation and execution; the second tests identity across asynchronous interpretation. Neither requires a real customer booking, and both expose defects that a transcript-only happy path can miss.

Reconstruct one complete repair

For the synthetic appointment example, the trace should first identify the original Thursday proposal and its presentation attempt. The caller's complete answer then proposes Friday, the controller clears old approval, and the revised projection becomes a new proposal version. A fresh read-back and scoped acceptance precede the business commit.

Inspect the actual submitted payload at the end of that chain. It must contain Friday and the current service, together with the operation identity and whatever backend precondition the service requires. A correct final conversational reply is insufficient if an earlier queued payload still contains Thursday.

Keep the original presentation and the revised presentation distinguishable in the evidence. This allows a reviewer to answer whether the caller approved the same terms that the business service received, without treating a generated transcript or a normalized affirmative label as proof of hearing or consent.

Keep the release evidence usable

A release packet should include the proposal field contract, the material-change rule, the negative fixture revision, and the exact commit boundary. Attach the controller version and the adapter schema used to bind answers to prompts. These facts allow a reviewer to distinguish a language interpretation problem from a stale-event or business-state problem.

Keep the packet free of raw caller content unless a governed review specifically requires it. Synthetic exchanges can document the invariant, while a protected replay identifier points to permitted evidence for an incident. Copying a real address into a general release note creates a privacy problem without improving the state-machine explanation.

Record the rollback action and the untested scope. A confirmation fix validated only on labeled text still needs acoustic and live media evaluation before it supports claims about caller experience. The correct release statement names the tested controller behavior and leaves unmeasured recognition or playback performance unclaimed.

---

Frequently asked questions

Why is "yes, but" unsafe as an immediate confirmation?

The opening affirmative can be qualified by a material change or condition later in the same answer. Committing on the prefix can execute the original proposal before the caller finishes. Keep the answer open until its boundary closes, interpret the complete scoped meaning, and clear approval when a repair changes the proposal.

What is a qualified confirmation?

It is an answer that contains apparent acceptance together with a change, condition, question, or unresolved limitation. The qualification determines whether the proposal is still acceptable. Treat it as a distinct dialogue outcome instead of reducing the whole utterance to a boolean based on the first affirmative word or a global intent label.

Should every sentence containing "but" trigger repair?

No. The meaning and target of the qualification matter. A keyword rule can miss repairs without that word and misread quoted or unrelated content. Use the complete answer in the pending question's context, and keep an unresolved category when the target cannot be identified safely from the available evidence.

Does a final transcript prove that confirmation is complete?

A provider's final transcript typically establishes finality for a particular recognition result. It does not prove that the full caller turn ended or that the answer applies to the current proposal. Preserve separate recognition, turn-completion, interpretation, and authorization boundaries so that one convenient flag does not trigger an action.

What should happen after a material field changes?

Increment the proposal version, clear approval tied to the previous version, validate the resulting proposal, and present the revised terms for fresh confirmation. Keep unaffected fields deliberately rather than resetting the whole task. If the change target is ambiguous, clarify before creating a new accepted field value or action payload.

Why does confirmation need a proposal version?

The version identifies the exact material terms that an answer can approve. Without it, a late affirmative from an earlier read-back can accidentally approve a revised day, address, or price. Reject old-version evidence and require an answer tied to the current proposal and its current question identity before commit.

Is acknowledgment the same as approval?

No. A caller may acknowledge an explanation without authorizing a business action. Keep the floor-ownership decision separate from the confirmation gate, and attach affirmative interpretation to a specific pending question. A listener cue during a read-back should not silently approve terms that the caller has not yet been presented under the contract.

How should conditional acceptance be handled?

Resolve the stated condition before treating the proposal as approved. If the caller says acceptance depends on a waived fee, the application must establish the actual terms and its authority to offer them. If the condition cannot be met, explain the available option or real handoff rather than committing the unqualified original proposal.

Should new speech revoke an existing approval?

While the proposal is still pending, new caller input should block commit until its meaning is resolved. It may contain a correction or withdrawal. This creates a clear serialized boundary between input evaluation and execution. After authoritative commit, a later change follows the amendment contract rather than silently rewriting the original result.

Can a model decide when to commit?

A model can provide interpretation evidence within a bounded schema. The business controller should still enforce current proposal version, field validation, authorization, input completion, and operation identity. A plausible acceptance label does not establish those facts and should not become direct permission to execute a consequential external action.

What if the correction target is unclear?

Ask a focused question and keep approval absent. A phrase such as "change the other one" can refer to another field, appointment, or participant. Guessing the target may create a valid-looking proposal that the caller never intended. Preserve the original evidence and resolve the scope before applying a patch.

How should old affirmative callbacks behave?

They should be rejected when their proposal version or input-attempt identity is no longer current. Exact duplicates should not create new approval or repeat an action. Keep callback identity and evidence version with the controller so that asynchronous interpretation cannot attach to whichever question happens to be pending on arrival.

What does the runnable example prove?

It proves deterministic proposal-version and repair transitions for synthetic labeled inputs in one serialized controller. It does not recognize speech, validate real appointment dates, prove hearing, or execute a booking. A production adapter needs input and prompt identities, and the business service needs its own authoritative validation and durable operation contract.

How does backend version checking relate to confirmation?

Proposal versioning identifies what the caller approved. Backend resource versioning identifies the business state the action depends on. They serve different purposes, and a safe operation may need both. If availability or terms changed after read-back, refresh the state and decide whether a new proposal and confirmation are required.

What if the booking request times out?

A timeout leaves the result unknown until the authoritative service can reconcile it. The operation may have committed before the response was lost. Avoid submitting a new action with a new identity blindly, and do not claim failure or success without evidence. Preserve any caller-requested amendment while checking the original outcome.

Can preparation happen before confirmation?

Reversible preparation can occur when the task contract permits it, but it must stay separate from execution. Tie prepared payloads and reads to the proposal version, and invalidate them when a material repair changes their inputs. Fresh confirmation cannot make an old payload correct if it still contains superseded fields.

How should changes after commit be explained?

State the confirmed original result and use the supported amendment or cancellation path. Do not imply that the original action disappeared because the caller corrected it later. If the outcome is unresolved, reconcile first. Keep historical proposal, approval, operation, and amendment evidence distinct under the applicable privacy and retention rules.

Which negative fixtures are most useful?

Include affirmative prefixes followed by repairs, conditions, questions, declines, and unfinished continuations. Add stale approvals, duplicate callbacks, new speech after approval, and changes after commit. Assert both the dialogue state and business-action invariant so a correct-sounding reply cannot hide execution of the wrong proposal version.

What should the evaluation report count?

Count qualified-answer opportunities, premature commits, lost repairs, stale approvals accepted, unnecessary repair prompts, and final task outcomes. Keep underlying case counts and unresolved labels visible. Separate recognition, endpointing, interpretation, and controller failures so a single pooled score does not hide the component that needs correction.

What is the smallest safe confirmation design?

Use an explicit proposal identity and version, complete-answer gating, a repair state, and a deterministic commit check. Invalidate approval on material change or unresolved new input, then require fresh scoped confirmation. Keep authorization and authoritative business-state checks at the service boundary, and retain the negative fixtures as regression tests.

Ship a confirmation invariant

Choose one consequential action and write the exact condition under which its current proposal can commit. Add the shortest qualified affirmative that violates the old behavior, then test its partial, complete, stale, and late variants through the same controller.

Use the workflow enforcement guide to connect the conversation to business authority. Release only a chain you can reconstruct from presented proposal through accepted confirmation to authoritative result, with repairs and unknown outcomes preserved along the way.