A correction changes a prior claim, not the original transcript. Keep the target turn and the remaining uncertainty visible.
Conversation repair: corrections, clarification and unresolved targets
Identify the repair target
A customer says “the east worker failed,” then “sorry, I meant the west worker.” The second turn repairs a specific entity in the first. Store both turns, the repaired span, replacement span and speaker. Do not globally replace every occurrence of east in the conversation. If several earlier turns mention a worker, ask which one was corrected. Span offsets anchor the change to the original wording.
Distinguish correction from new information
“The worker failed again” may add another event rather than retract the first failure. A repair signal, target and compatible context should support the edit. Keep the old claim as superseded with its reason, rather than deleting it from the audit. A partial correction might change only a time or region while leaving the action intact. Claim conflict review helps detect when two active statements cannot both be used.
Ask a narrow clarification when needed
If the user writes “not that one,” the referent may be unclear. Preserve candidate targets and ask a question naming the alternatives; do not select the nearest noun by default. Clarification is a dialogue act with a pending answer, not a random new intent. When a reply arrives, link it to the open question and update only the affected slot. The slot contract maintains those pending values.
Measure repair quality over turns
Test corrected entity, quantity, date and action, plus cases where a later turn is not a correction. Score target identification, preserved unaffected fields, false repairs and clarification burden. Group whole conversations before splitting evaluation. A system that overwrites the first message may appear correct in final-state scoring while losing the evidence needed to explain a disputed support action. The audit project checks repair before commitments are staged.
Implementation
def apply_turn_repair(turns, target_turn_id, field, replacement, repair_turn_id):
if target_turn_id not in turns:
return {"state": "clarify", "reason": "target-turn-missing"}
previous = turns[target_turn_id]
if field not in previous:
return {"state": "clarify", "reason": "field-not-in-target"}
updated = {**previous, field: replacement}
return {"state": "proposed-repair", "target_turn": target_turn_id,
"repair_turn": repair_turn_id, "before": previous, "after": updated}
turns = {"turn-47": {"service": "worker-east", "action": "failed"}}
repair = apply_turn_repair(turns, "turn-47", "service", "worker-west", "turn-82")
assert repair["after"]["service"] == "worker-west"
assert turns["turn-47"]["service"] == "worker-east"
Performance and operating cost
A hash-map target lookup and shallow field copy are expected O(1) for a fixed-size turn record, or O(f) for f fields. Discovering the intended target from a long history may require O(h) candidate inspection. Retaining both versions costs storage, but prevents a correction from silently erasing the basis of earlier decisions.
Common Mistakes
- Globally replacing a corrected word throughout the conversation.
- Treating every later disagreement as a correction of the nearest turn.
- Deleting the original claim after applying a repair.
- Updating an authorized action before an ambiguous repair is resolved.
Read next
- Speech acts: requests, reports and commitments in support dialogue
- Project: audit support commitments and conversation repairs
- Dialogue state: apply slot updates, corrections and deletions
- Entity spans: align annotations to the original text
- Review claim conflicts across time and source revisions
Continue the workflow: Email thread state: corrections, commitments and stale claims.
