Preserve intent through spoken self-corrections

TL;DR: A spoken self-correction revises a specific field or part of an answer; it should not silently append old and new facts. Preserve the correction's target, evidence, and base version in a revision ledger, clarify ambiguous scope, and invalidate confirmation whenever a material current value changes.

---

A caller says "Tuesday, sorry, Thursday," and the final request contains Tuesday in one field and Thursday in another. The transcript captured the words, but the application lost the caller's intended revision.

Another caller spells a code, changes one character, and hears the entire old prefix concatenated with the replacement. A simple append-only transcript is useful evidence, yet it is the wrong data structure for the current accepted value.

The engineering problem is revision scope: what is being replaced, what remains valid, and which version of the task the change applies to. This guide provides a field-revision ledger, runnable replay tests, and a validation method that keeps recognition revisions, caller corrections, and committed business changes distinct.

All utterances, values, and tests are synthetic. The figures are conceptual, and no private architecture or customer data from 60db Agent is described. Public source contracts were reviewed on November 9, 2026; no production accuracy or benchmark result is claimed.

Table of contents

1. Separate evidence from current values
2. Identify the correction target
3. Represent revisions explicitly
4. Run a field-revision ledger
5. Validate the resulting task state
6. Replay corrections and conflicts
7. Connect revisions to business actions
8. Operate a private evidence trail
9. Frequently asked questions
10. Ship the intended value

Separate evidence from current values

An evidence stream records what arrived and how it was interpreted. A current-value projection records the latest accepted task fields. Those structures serve different purposes and should not be confused just because both can be represented as JSON.

Keep the original speech evidence under the deployment's governance rules. Keep the current field value small and explicit. The ledger connects the accepted value to the revision that produced it without forcing every consumer to reinterpret the whole conversation.

For the synthetic phrase "Tuesday, sorry, Thursday," the current day is Thursday only after the application has enough evidence that the caller meant to replace Tuesday. The evidence can retain both words, while the field projection contains one current value and its provenance.

Do not overwrite evidence to make it match the final field. That destroys the explanation of the repair. Do not append all evidence into the field either, because downstream tools need the intended value rather than a transcript of the correction.

Recognition revisions differ from caller repairs

A recognizer can revise its hypothesis without the caller changing their mind. An interim result might show Tuesday and later resolve to Thursday from the same audio portion. That is an ASR revision, not necessarily a spoken self-correction.

A caller repair is new communicative evidence that changes or clarifies the intended value. The caller may explicitly say "sorry," "I mean," or "change that," or provide a scoped replacement without a standard cue.

Google's streaming recognition result reference distinguishes interim stability and finality for a result. Preserve provider result identity and revision semantics before converting text into application-level repair events.

The partial-transcript adapter guide covers that input boundary. Treating every interim hypothesis as an accepted field revision can pollute the ledger with values that the caller never intended to state.

Normalization is another separate step

A recognizer's surface text and a normalized field value can differ without any correction. A spoken weekday, a relative date, and a canonical date representation are related but distinct artifacts.

The Amazon Lex slot-value reference exposes original, interpreted, and resolved values. That public example shows why an adapter should retain the distinction rather than presenting a normalized result as a verbatim caller statement.

Normalization must preserve uncertainty. If "next Thursday" depends on a locale, reference date, or caller convention, capture the needed context and clarify when the interpretation affects a consequential action.

Keep the normalized value's provenance and version. A later repair should replace the intended field rather than rerun an unrelated normalization rule over the entire transcript and accidentally change unaffected fields.

Recognition updates, caller repairs, and normalization are different events.

Identify the correction target

A correction needs a target scope. It may replace a whole field, one character, one list item, a range of items, or the entire pending task.

Start with the narrowest scope supported by evidence. "Thursday instead" after a day question can replace the day; "the second one should be blue" requires an identifiable ordered collection; "start again" may invalidate the whole input attempt.

Do not assume that a correction always targets the most recent recognized token. A caller can revise an earlier field after hearing a read-back, and a delayed transcript can arrive after the application has already asked another question.

Attach question and task identities to the evidence. The correction must remain associated with the answer it revises rather than whichever field happens to be active when an asynchronous callback returns.

The figure places scope validation before the current-value update. Ambiguous scope goes to clarification; it does not produce a guessed field patch that later appears authoritative because it is stored in a database.

Use a target table before writing a parser

A target table makes the permitted operations reviewable. ✓ means the example evidence supports that update shape; ✗ means the shape would lose or invent intent. These are application criteria rather than claims about a vendor's interpretation accuracy.

The table prevents a single "correction" intent from hiding different operations. A whole-field replacement, a list append, and an action cancellation need different validation and authorization even if the caller uses similar language.

Preserve ambiguity instead of merging candidates

If the caller says "change that to Friday" after discussing two appointments, the application needs the target appointment. Combining Friday with whichever record is easiest to update creates a plausible but unsupported task state.

Ask a focused question that names the ambiguous choice without exposing unnecessary information. Keep both the old projection and the pending repair evidence until the target is resolved.

Avoid merging candidates into one value such as "Tuesday or Thursday" unless uncertainty is an explicit supported field type. A downstream scheduler may interpret that string as data rather than a request for clarification.

The qualified-confirmation guide covers this case during approval. A repair that changes material terms must clear the previous confirmation even when the intended replacement still needs clarification.

Distinguish replacement from addition

"Another cable" can add quantity; "the other cable" can replace an item. The words are close, yet the data operations differ.

Use the pending task structure and complete utterance to infer a candidate operation, then validate it. If the distinction remains unclear, ask before updating the projection.

For spelling, a character correction should identify the sequence version and position. If the sequence changed while interpretation was pending, the old position may refer to a different character and should be rejected or reinterpreted with explicit context.

The structured answer endpointing guide keeps these sequences open until completion. Correct endpointing prevents a partial repair from being treated as a final new value.

Represent revisions explicitly

A minimal accepted revision needs an event identity, task identity, field or path, base version, operation, replacement value where applicable, and evidence reference. Add interpretation version when a model or parser proposes the revision.

The base version says which current state the revision was derived from. If that state changed before application, the controller must detect the conflict rather than silently applying a patch to a different projection.

Use a small operation vocabulary. Whole-field set and clear can be enough for many tasks. Add indexed replacement or list operations only when the task requires them, with tests for their positional and ordering semantics.

An accepted revision should produce one new projection version atomically. Validation failure should leave the current projection unchanged while preserving a separate rejected or unresolved evidence record where the governance contract permits it.

Keep event identity immutable

An exact duplicate accepted event should not apply again. The same event identity with different content is a conflict, not a retry that can be accepted by convenience.

Deduplication needs the event payload or its canonical digest as well as the identity. Otherwise a producer bug can reuse an identity for a different replacement and make the ledger silently disagree with the caller.

Keep recognition-result identities separate from accepted revision identities. Several ASR revisions can contribute evidence to one caller repair, and one complete caller turn can propose changes to several fields.

If a multi-field correction is one semantic unit, validate and apply it atomically. Updating the day while rejecting the related time can produce a task state that was never intended as a combination.

Invalidate confirmation on material revision

A field ledger must notify the proposal controller when material values change. Approval belongs to a projection version, so a later revision cannot inherit it automatically.

A clear operation also invalidates approval. Removing a required field leaves the task incomplete even if all remaining fields still look valid.

The workflow enforcement guide places that invariant at the action boundary. Every business consumer should receive the current validated projection and its version rather than reading an arbitrary transcript summary.

For a provider-managed form, inspect both form state and session parameters. Dialogflow CX parameter documentation describes several ways those values can be set; an invalidation path must reach the actual value consumers, not only a visible prompt state.

A changed or cleared material value must not retain approval from the old proposal.

Run a field-revision ledger

This Python program implements whole-field set and clear operations in one serialized in-memory ledger. It consumes validated interpretation events rather than trying to parse arbitrary speech into patches.

Save it as revision_ledger.py and run python3 revision_ledger.py. All examples are synthetic. The code demonstrates projection, duplicate handling, stale-base rejection, and confirmation invalidation; durable storage and speech recognition remain outside its boundary.

from dataclasses import dataclass

@dataclass(frozen=True)
class Revision:
    event_id: str
    base_version: int
    field: str
    operation: str
    value: str | None
    evidence_id: str

class Ledger:
    def __init__(self):
        self.version = 0
        self.values = {"day": None, "service": None}
        self.events = []
        self.accepted = {}
        self.confirmed_version = None

    def apply(self, r: Revision):
        prior = self.accepted.get(r.event_id)
        if prior is not None:
            return "duplicate" if prior == r else "identity_conflict"
        if r.base_version != self.version:
            return "stale"
        if (not r.event_id or not r.evidence_id or r.field not in self.values
                or r.operation not in {"set", "clear"}):
            return "invalid"
        if r.operation == "set":
            if not isinstance(r.value, str) or not r.value.strip():
                return "invalid"
            next_value = r.value
        else:
            if r.value is not None:
                return "invalid"
            next_value = None
        self.values = {**self.values, r.field: next_value}
        self.version += 1
        self.confirmed_version = None
        self.events.append(r)
        self.accepted[r.event_id] = r
        return "applied"

    def confirm(self, version):
        if version != self.version or any(v is None for v in self.values.values()):
            return "blocked"
        self.confirmed_version = version
        return "confirmed"

    def ready(self):
        return self.confirmed_version == self.version and all(
            v is not None for v in self.values.values())

if __name__ == "__main__":
    l = Ledger()
    first = Revision("r1", 0, "day", "set", "Tuesday", "e1")
    assert l.apply(first) == "applied"
    assert l.apply(first) == "duplicate"
    assert l.version == 1
    conflict = Revision("r1", 0, "day", "set", "Thursday", "e2")
    assert l.apply(conflict) == "identity_conflict"
    assert l.values["day"] == "Tuesday"
    assert l.apply(Revision("r2", 1, "service", "set", "inspection", "e3")) == "applied"
    assert l.confirm(2) == "confirmed" and l.ready()
    correction = Revision("r3", 2, "day", "set", "Thursday", "e4")
    assert l.apply(correction) == "applied"
    assert l.values == {"day": "Thursday", "service": "inspection"}
    assert not l.ready()
    assert l.confirm(2) == "blocked"
    assert l.apply(Revision("late", 1, "day", "set", "Friday", "e5")) == "stale"
    assert l.confirm(3) == "confirmed"
    assert l.apply(Revision("r4", 3, "service", "clear", None, "e6")) == "applied"
    assert l.confirm(4) == "blocked" and not l.ready()
    before = (l.version, dict(l.values), len(l.events))
    assert l.apply(Revision("bad", 4, "unknown", "set", "x", "e7")) == "invalid"
    assert (l.version, l.values, len(l.events)) == before
    print("Synthetic revision-ledger checks passed")

The duplicate check comes before stale-base rejection because a delivered retry of an already accepted event should be recognized as the same event, even though the projection has advanced since its original application. It returns a non-mutating status and never replays the update.

The identity-conflict branch prevents the same event identifier from changing meaning. That condition deserves operational attention rather than an automatic retry with a new identity, because the producer and ledger no longer agree about what happened.

Every accepted revision invalidates confirmation in this conservative exercise. A production contract can distinguish material and presentation-only fields, but the distinction must be explicit and tested before approval is preserved across any change.

Bound the example's trust boundary

The program expects a typed Revision created by an internal adapter. External JSON still needs schema validation for field types, allowed operations, length limits, task scope, and authorization before constructing the event.

A nonempty string is not complete business validation. Real date, address, service, and identifier rules belong to the task validator, and the resulting whole projection must pass before action.

The confirm method models approval attachment only. It does not prove caller identity, complete prompt playback, informed consent, or successful business execution. Keep those observations and checks in their owning layers.

The example stores only accepted events. A service may also keep rejected or ambiguous proposals in a governed evidence trail, but they should not become current values simply because they were retained for diagnosis.

Persist the projection and ledger together

A durable implementation must avoid a state where the event is stored but its projection is missing, or the projection changes without the event that explains it. Use the storage system's existing transaction or equivalent atomic-update contract.

If optimistic concurrency rejects the base version, reload the current projection and reconsider the correction's scope. Do not blindly replace the base version and replay a positional patch against different state.

PostgreSQL's serialization-failure documentation explains that applications must retry the complete transaction logic after serialization failure. That is a storage-level rule, while deciding whether a spoken correction still applies is an application-level semantic check.

Keep those responsibilities separate. A successful database retry does not prove that an old interpretation remains meaningful after another field revision or a new caller instruction.

Validate the resulting task state

Validation must examine the projection after the repair, including dependencies among fields. A changed day can affect availability; a changed country can affect address format; a changed service can affect required information.

Preserve unaffected fields only where their meaning remains valid. A narrow patch should not erase unrelated information, but a dependency rule may need to mark some retained fields as requiring revalidation.

Dialogflow CX webhook validation guidance shows form invalidation and clearing session parameters for reprompting. The transferable point is to make invalidation reach both the dialogue state and the data consumers under the actual interface contract.

A stale field hidden behind a new prompt is still stale data. Test the payload sent to the business service, not only the text spoken by the agent.

Clearing is an explicit operation

"Remove that detail" differs from a missing field in an update payload. Missing can mean unchanged, unknown, omitted by an adapter, or intentionally cleared depending on the protocol.

Define clear semantics rather than relying on truthiness. An empty string, zero, null, and absent property are not interchangeable values across structured fields.

The Dialogflow CX query-parameter reference specifies explicit null for removing a session parameter. Other interfaces can differ, so preserve their exact contract in the adapter and test the resulting projection.

The runnable ledger uses operation="clear" with value=None. This makes the intent reviewable and prevents a malformed set from quietly deleting a value.

Validate a multi-field repair atomically

A caller can say "make it Thursday afternoon instead." That may update both day and time window as one intended correction. Applying one half while rejecting the other can create a combination the caller did not request.

Stage the proposed patch, validate all changed fields and dependencies, then apply the whole accepted revision. If any part remains ambiguous, preserve the old projection and ask a focused question about the missing part.

The small program intentionally limits operations to one whole field. Extend it with an atomic patch only when the task requires multi-field changes, and add failure tests proving that partial validation never leaks a half-applied projection.

Do not introduce a general patch language solely for flexibility. A small explicit operation vocabulary is easier to audit and test against real caller repair patterns.

Replay corrections and conflicts

A useful replay suite tests the current projection, provenance, and confirmation state after each event. Checking only the final transcript misses the exact class of failure this ledger is meant to prevent.

Build full synthetic exchanges around specific repair shapes. Include immediate self-correction, correction after read-back, ambiguous target, clear, list addition, character replacement, and task cancellation as distinct cases.

The expected confirmation state depends on whether new input itself suspends approval before interpretation. Keep that controller rule explicit: a ledger handling accepted events cannot by itself stop a commit while an unprocessed correction is still in flight.

The confirmation repair controller handles that earlier boundary. Together, input evaluation and revision application prevent old approval from racing a new caller instruction.

Replay event permutations carefully

Do not assume every event can arrive in arbitrary order. Preserve any guarantees the provider or transport actually gives, and permute only the schedules that the integration can observe.

Test a stale interpretation after a newer accepted revision. Test an exact retry after the projection advances. Test a duplicate recognition result that should update evidence but should not create another caller repair event.

When the same semantic final state is reached through different schedules, compare the caller-visible behavior too. An early read-back of the wrong value remains an interaction error even if a later correction restores the final projection.

The voice regression testing guide provides fixture-version discipline. Record interpretation model and normalization version where they influence which revision event is proposed.

The figure separates duplicate, stale, and conflict fixtures from the projected value and approval version. It describes a test plan, with no claimed error rates or measured performance.

Evaluate repair survival, not transcript similarity alone

A transcript can contain every correct word while the business payload still contains the superseded value. Measure whether the intended replacement appears in the accepted projection and whether old values are excluded from the fields that drive action.

Keep ambiguity as an outcome. A targeted clarification can be the correct response to unclear scope even if it takes another turn; guessing a value that happens to match a label is not a defensible general policy.

The voice outcome metrics guide helps connect component evidence to task correctness. Separate lost repairs, unnecessary clarifications, stale-event acceptance, and final action outcome rather than compressing them into one recognition score.

Use denominators tied to repair opportunities. Report the number of labeled corrections and the specific operations covered, because a large ordinary-speech corpus can conceal a very small and weak repair subset.

Connect revisions to business actions

The current field projection is still a proposal until the business controller validates and commits it. A ledger revision does not directly authorize a booking, address change, payment, or disclosure.

Pass the projection version with the action payload. The business controller should verify that it is executing the currently approved version and that its authoritative resource state still permits the operation.

MDN's If-Match reference provides a public example of conditional writes that reject stale resource updates. A spoken-revision version and a backend resource version remain different identities and may both be needed.

A field correction can invalidate speculative preparation. If an availability read or prepared payload used Tuesday, accepting Thursday must not leave the old payload ready to submit.

The speculative tool-calling guide covers reversible preparation versus consequential execution. Tie preparation to its input projection and discard or recompute it when relevant fields change.

Handle corrections after submission

If the action is pending, preserve the correction and reconcile the original operation. A timeout does not establish failure, and silently resubmitting a changed payload with a new operation identity can create two actions.

If the original action committed, the repair becomes an amendment or cancellation under the business service's contract. Explain that status honestly rather than editing the ledger to imply the original request never existed.

Keep operation outcome separate from call lifecycle. The shutdown semantics guide explains why a late result can still matter after media ends or the caller disconnects.

A reconciliation record should link the approved projection, submitted operation, authoritative result, and later amendment. It should not expose raw caller content to every consumer that needs the operation status.

Keep callers informed without replaying history

Read back the material current value and any dependency that changed. Avoid reciting every superseded value unless it is necessary to resolve ambiguity.

For a simple day repair, a concise revised read-back can confirm the intended replacement. For a multi-field change, a fuller summary may be needed to make the resulting proposal understandable.

The agent should acknowledge the repair without claiming success before validation and commit. "I have the day as Thursday; shall I use that?" describes a pending proposal, while a successful booking claim needs authoritative operation evidence.

Operate a private evidence trail

A revision ledger can contain sensitive values even when it excludes full transcripts. Names, addresses, identifiers, and combinations of task fields can identify callers or reveal private circumstances.

Use access controls and retention appropriate to the data, and avoid copying accepted revision values into ordinary metric labels. Operational counters can record operation type, reason, and governed evidence identity without publishing the content.

Dialogflow CX parameter documentation describes parameter redaction and its documented scope. Do not assume a text-log redaction setting also removes recordings, external tool payloads, or copied incident notes.

Define deletion across the evidence graph. Removing the original audio while retaining a verbatim correction in an unrestricted report does not remove the same information from the system.

Keep provenance useful and minimal

A provenance record should answer which input scope produced the revision, which interpretation version proposed it, which validation accepted it, and which projection version resulted. It does not need every audio sample in every database row.

Use governed references for deeper evidence. Keep the current projection easy for business consumers to use, while limiting access to historical values that those consumers do not need.

For public documentation, use synthetic fixtures and documented example values. Do not anonymize a real transcript by removing a name while leaving a rare combination of dates, locations, and task details that can identify the caller.

Review a synthetic incident end to end

Suppose the accepted projection contains Tuesday and a caller then says Thursday. First inspect whether the incoming speech was a recognition revision of the same audio or a new caller repair. That determines whether the input adapter should replace evidence or propose an application revision.

Next inspect target scope and base version. A correct day replacement tied to the current task should update only that field, while a delayed interpretation from a superseded task should remain stale. Compare the accepted event with the resulting projection and verify that confirmation was invalidated before any current action became eligible.

Finally inspect prepared and submitted tool payloads. If the projection is Thursday but a prepared request still contains Tuesday, the failure belongs after the ledger. Replaying the recognizer will not fix a stale-payload bug. Retain a synthetic fixture for that exact handoff so a future adapter change cannot reintroduce the mismatch.

This incident walk also establishes what can be known from retained evidence. A final field alone cannot tell whether recognition, interpretation, concurrency, or action preparation lost the repair. A small chain of governed identities and state transitions is enough to narrow the owner without copying an entire caller conversation into every operational report.

Prepare a repair-specific incident view

When a caller reports that a correction was lost, inspect the chain in order: recognition evidence, answer completion, candidate operation, target scope, base version, accepted revision, approval invalidation, and business payload.

This locates the owning boundary. If the candidate operation was correct but rejected as stale, investigate concurrency and task scope. If the ledger was correct but the payload used the old value, investigate the action adapter or stale preparation.

If the evidence is unavailable under retention rules, say what cannot be established. Do not reconstruct a confident story from the final field alone; several different failure paths can produce the same stored value.

The observability guide provides the broader trace structure. For 60db Agent or another system, use observable interfaces and controlled replay rather than assumptions about unpublished internal mechanisms.

---

A correct ledger does not prove that a prepared business payload used its current values.

Frequently asked questions

What is a spoken self-correction?

It is new caller evidence that revises or clarifies an intended value, such as replacing a day or correcting a character. The application needs the target and operation, not just the words. Preserve the evidence while updating a separate current-value projection so downstream tools receive the intended result rather than a transcript of the repair.

How is a caller repair different from an ASR revision?

An ASR revision changes the recognizer's hypothesis about an audio portion. A caller repair changes or clarifies the intended task through new speech. Keep provider result identities and revision semantics in the adapter, then create accepted application revisions only from sufficient scoped evidence. Otherwise recognition uncertainty can look like repeated changes of mind.

Why should old and new values remain separate?

The old value explains the repair, while the new projection drives the current task. Combining them can send an unsupported string or inconsistent fields to a tool. Overwriting all evidence loses provenance. Keep history under governance and expose one current accepted value per field, with explicit uncertainty where the schema supports it.

What information identifies a correction target?

Use the pending question, task identity, field or path, relevant sequence version, and complete utterance. A correction can target an earlier field after read-back, so the most recent token is not always the right scope. If several targets remain plausible, ask a focused clarification before applying a patch or changing approval.

Should the newest mentioned value always win?

No. The latest mention may be a quoted value, a question, an alternative, or a correction to a different field. Apply a replacement only when the target and intended operation are supported by the scoped evidence. A timestamp-based last-write-wins rule cannot preserve semantic intent when the application has not identified what changed.

How should "Tuesday, sorry, Thursday" be stored?

Under a day-question contract with clear replacement intent, retain the evidence of the phrase and project Thursday as the current day. Record a revision connecting that replacement to its base version and evidence. Do not leave Tuesday in another action-driving field, and invalidate confirmation if the material proposal changed.

How do you handle one corrected letter?

Identify the sequence version and character position or range before replacement. Preserve unaffected characters and validate the resulting whole sequence. If the caller's target is unclear or the sequence changed while interpretation was pending, clarify or reject the stale patch. Appending the replacement to the full old sequence usually loses the intended repair.

What does a revision base version mean?

It identifies the projection state against which the correction was interpreted. If the current state has advanced, the patch may no longer apply to the same field meaning or position. Detect that conflict and reconsider scope rather than silently substituting the latest version number and applying an old interpretation to different data.

Why must event identities be immutable?

An exact retry should refer to the same accepted revision. If the same identity arrives with different content, the producer and consumer disagree about what happened. Treat that as an identity conflict, preserve the current projection, and investigate. Accepting the changed payload would make deduplication silently overwrite caller intent.

Should duplicate revisions increment the version?

No. An exact duplicate accepted event should return a non-mutating duplicate result. It should not repeat the update, invalidate a fresh confirmation, or create another history entry. Keep the accepted payload with the event identity so the ledger can distinguish a genuine retry from conflicting content that reused the same identifier.

How should a field be cleared?

Use an explicit clear operation with protocol-specific semantics. Missing, null, empty text, and zero can mean different things, so do not rely on truthiness. Clearing a required field makes the task incomplete and should invalidate approval. Verify that the clear reaches both the dialogue state and every business consumer of the field.

Can several fields change in one repair?

Yes. A phrase such as changing a day and time window can be one semantic unit. Stage and validate the whole patch, including dependencies, then apply it atomically. If part is ambiguous or invalid, preserve the old projection and clarify rather than committing a half-applied combination that the caller never requested.

Does every revision require confirmation again?

Material changes should invalidate approval for the previous proposal version. A deployment may define presentation-only changes that preserve approval, but that distinction must be deterministic and tested. The example ledger conservatively invalidates on every accepted revision so no material repair can silently inherit an earlier confirmation.

Can the ledger stop a commit while speech is still being interpreted?

The accepted-event ledger alone cannot handle that earlier boundary. The dialogue or proposal controller must suspend approval when new caller input opens, then resolve the complete answer before allowing commit. Connect that controller to the revision ledger so a pending correction cannot race an already queued action using the old approval.

What does the runnable ledger prove?

It proves deterministic whole-field projection, duplicate handling, identity-conflict rejection, stale-base rejection, and confirmation invalidation for synthetic typed inputs. It does not parse arbitrary speech, authenticate callers, validate real business dates, or provide durable storage. Those boundaries need their own adapters and tests before the artifact becomes a production service.

How should durable storage handle revisions?

Persist the accepted event and projection update atomically using the storage system's existing contract. On a concurrency failure, reload state and reconsider the correction's scope as well as retrying storage logic. A successful transaction retry cannot prove that an old positional or semantic patch still applies after another accepted revision.

Which tests expose lost repairs?

Use immediate replacement, correction after read-back, ambiguous target, exact retry, reused identity with changed payload, stale base version, explicit clear, and multi-field failure. Assert current values, provenance, confirmation state, and the final business payload. A transcript that contains all the right words can still feed a tool with superseded data.

How should corrections after submission behave?

Preserve the requested change and reconcile the original operation through its authoritative identity. If the action committed, use the supported amendment or cancellation path. If the result is unknown, do not claim that the correction replaced it. A timeout is insufficient evidence to submit a second changed action blindly.

What repair metrics are useful?

Count labeled repair opportunities, intended replacements preserved, stale revisions accepted, identity conflicts, unnecessary clarifications, and final task outcomes. Keep counts by operation and input contract. Transcript similarity alone can miss a lost repair, while a pooled ordinary-speech score can hide a weak correction subset with very few evaluated cases.

How should sensitive historical values be retained?

Use the deployment's access, consent, and retention rules for both evidence and ledger values. Keep raw content out of routine metric labels and use governed references for deeper review. Deletion must cover copied reports and derived stores where the same information remains; removing only the original recording leaves the privacy boundary incomplete.

Ship the intended value

Choose one field that callers commonly revise, define its supported repair operations, and add a synthetic replay that proves the old value cannot reach the action payload after replacement. Test duplicate delivery and a stale base version before adding more operation types.

Use the regression testing workflow to retain the repair and the workflow boundary to protect execution. A useful release preserves the caller's current intent while keeping evidence, uncertainty, approval, and authoritative action status separate.