Unfamiliar surnames: clarification without silent substitution

TL;DR: Preserve the caller's name and ask about the uncertain segment instead of substituting a more familiar surname. Keep spelling, preferred pronunciation, identity evidence and permission to retain a hint separate, and invalidate affected approval whenever the caller repairs the proposed value.

---

The recognizer offers a common surname that resembles the caller's less familiar one. The agent accepts it, speaks confidently and attaches the task to the wrong record. Familiarity has replaced evidence about what the caller intended.

Start with a preserved original and a targeted clarification. Record caller-provided spelling and preferred pronunciation as different fields. A caller can clarify the current interaction without granting permission to create a durable pronunciation entry.

W3C's personal-name guidance explains why assumptions about name structure can fail across cultures and applications. It is guidance about handling names, not an authority that assigns every person's pronunciation or proves identity from spelling. The scoped alias method keeps that identity boundary explicit.

The standard-library artifact below validates synthetic clarification revisions, confirmation request identities and retention-proposal metadata. It does not identify a person, infer ethnicity, generate phonetics, record audio or measure surname recognition for 60db Agent. Its useful result is an inspectable flow in which a correction cannot silently preserve approval of an older value.

Table of contents

1. Preserve the name before resolving uncertainty
2. Ask about the uncertain segment
3. Separate spelling from preferred pronunciation
4. Bind confirmation to the current revision
5. Keep session use separate from retention
6. Run a bounded clarification contract
7. Review listening evidence without inventing scores
8. Diagnose failure without a common-name shortcut
9. Frequently asked questions
10. Preserve one repaired name end to end

Preserve the name before resolving uncertainty

The original name field is evidence of what the system received. It can be imperfect recognition output, caller-entered text or another declared source. Preserve that provenance rather than pretending every initial string is already a verified canonical identity.

A proposed spelling is a current task value. The caller can correct it. Keep the original and revised value separately so another engineer can explain the change without relying on whichever spelling remains visible in the last transcript.

Do not silently replace an unfamiliar value with a more frequent one. A recognizer's candidate ranking or a directory's first result is not confirmation of the caller's intended entity. An unresolved name should remain unresolved until the task's permitted clarification supplies enough evidence.

CLDR's person-name formatting specification describes locale-related formatting concerns. It does not turn a displayed name into a universal given-name and surname decomposition or establish a preferred spoken form. Keep any field-structure assumptions inside the actual application contract.

A task titled surname clarification still needs to allow that the application's name model may be too narrow. Ask for the name information the operation actually requires. Do not force every caller into a Western family-name pattern simply because a form uses that label.

The shared-phone identity boundary is relevant when several people can use one number or account. A familiar device, surname or pronunciation preference can provide context without establishing which person is acting or whether an action is authorized.

Use a trusted opaque scope for the clarification flow. That scope can be associated with a session and, only through an appropriate external process, a person record. Never derive the association by normalizing the name string and treating a match as identity proof.

The first useful regression fixture is simple: preserve a synthetic unfamiliar spelling while a more common suggestion is present elsewhere. The expected behavior is clarification or explicit uncertainty, not a selection based on convenience. No demographic or acoustic claim is needed to verify that software boundary.

Write the task's uncertainty contract before collecting examples. Identify whether the operation needs written spelling, a spoken preference, an intended record or some combination. A flow that only needs to address the caller respectfully should not collect another person's private account facts as an improvised pronunciation aid.

Keep initial recognition output labeled as a candidate when that is its actual provenance. The original field in the reference means first received value, not verified legal spelling. A later caller correction can become the current proposal without rewriting what the recognizer originally supplied.

A directory result should carry its own candidate evidence. If several records share a name, preserve the candidate set and use the approved disambiguation route. A pronunciation preference cannot narrow that set by itself, and an uncommon spelling does not authorize searching outside the current scope.

For public reproductions, use synthetic name tokens and task identities. A realistic-looking real surname paired with a rare preference or account context can identify someone even after another field is removed. The logical failure can be demonstrated without using an actual person's record.

Ask about the uncertain segment

A clarification should identify the uncertainty the task needs to resolve. If only part of a spelling is unclear, ask about that segment rather than forcing the caller to restart an entire explanation. Preserve the response as evidence and update the proposed value deliberately.

Avoid offering a common-name substitution as if it were the only reasonable answer. A question can repeat the current candidate while making clear that correction is welcome. The workflow should accept a new spelling without interpreting the repair as an error by the caller.

If the caller declines to repeat the name, follow the approved unresolved route. That can involve another input method or an authorized handoff. Do not infer the missing characters from a directory frequency table merely to make the task appear complete.

DTMF and voice identifier capture offers a different input channel for appropriate sequences. It is not a universal solution for names, and it still needs the owning task's identity, permission and outcome checks.

A historical phonetic TTS question asks how to render a supplied name pronunciation and notes that one spelling can have different desired sounds. Treat it as a real question about representation, not a validated pronunciation reference for its example names.

A pronunciation clarification can ask what form the caller prefers in the current interaction. That preference does not establish nationality, ethnicity, language background or legal name. Keep the agent's next action tied to the caller's stated preference rather than an inferred category.

Spoken self-corrections should revise the active proposal. An earlier partial transcript must not retain authority merely because it arrived first or looked complete. Keep material repairs visible in the task state.

A qualified affirmative can contain another correction. The "yes, but" repair contract prevents the first affirmative word from approving the old candidate. Interpret the complete response before marking the revised name confirmed.

The review rubric should reward appropriate clarification. If a test expects a confident guess for an ambiguous synthetic name, it trains the workflow toward silent substitution. Define uncertainty and permitted fallback as valid outcomes where the evidence does not support selection.

Make the prompt's scope understandable. If the uncertain part is spelling, ask which characters need correction. If the spelling is settled and the caller wants another spoken form, ask for that preference separately. Do not imply that the caller's name is invalid because the selected voice does not render it well.

A synthetic clarification sequence can preserve the initial token, accept a caller-supplied spelling, repeat the current proposal and wait for confirmation. Label the sequence synthetic and avoid treating its phrasing as a tested conversational optimum. The useful engineering property is which values and approvals change at each step.

Keep repair opportunities explicit in the evaluation protocol. A system allowed several clarifications has a different task from one scored on its first interpretation. Record the questions actually asked and the final evidence, so successful recovery is not presented as perfect initial recognition.

When the caller declines further clarification, retain unresolved state and the permitted next route. A handoff or another authorized input method can be useful. Guessing a familiar replacement simply moves uncertainty into a hidden wrong-value state.

Separate spelling from preferred pronunciation

Spelling and preferred sound are different values. A caller can confirm one while correcting the other. A single overloaded field makes it difficult to know whether an update changed the written name, a speech aid or the intended entity.

Unicode normalization provides canonical text relations, not identity or pronunciation. Preserve raw spelling and apply only the owning field's declared policy. Canonical-equivalent text is not proof that two records belong to one person.

Unicode security mechanisms addresses visual and mixed-script concerns. A visually similar spelling can motivate review without authorizing substitution. A small name flow should not claim complete confusable detection or infer identity from appearance.

The mixed-script preparation method preserves originals while deriving explicitly scoped projections. Do not delete diacritics, spaces, joining controls or non-Latin characters by default to make a name easier for the current synthesizer.

A preferred pronunciation can be represented as a caller-provided explanation or reviewed alias under the task policy. It is not automatically IPA, and an application should not label generated phonetic notation approved without qualified review. The reference program stores an opaque preference string and produces no phonetic transcription.

SSML 1.1 and PLS describe pronunciation-control representations. Target engine support remains separate. An adapter must select documented supported controls and serialize preference values safely rather than interpreting caller text as markup.

A historical browser SSML question reports unexpected behavior for names. It motivates checking the actual interface and voice, not claiming that all current browsers support or reject the same pronunciation mechanism.

Recognition phrase lists can bias a documented recognizer toward supplied terms. Biasing recognition is not verifying which person the caller intended. Keep candidate generation, caller confirmation and authorized entity selection distinct.

The following table describes evidence boundaries. A check means sufficient for the named narrow property under the declared workflow, while a cross requires another proof. It does not rank names, accents or voices.

A pronunciation aid can be lossy. A caller may describe a preferred sound using ordinary words, syllable hints or another representation the selected interface does not directly consume. Preserve what was supplied and identify the reviewed transformation before constructing an engine-specific control.

Do not present automatically generated IPA as the caller's verified preference. A generated candidate can be reviewed under an authorized process, while the original caller explanation remains distinct. A text value looking phonetic is not proof that it matches the person's intended sound.

Keep surname spelling exact through that process. An alias for speech is a projection, not a corrected written name. If the caller changes the spelling too, create a material proposal revision and determine which earlier preferences and confirmations still apply.

A similarity score can help identify a review need, but it cannot resolve person identity or decide the preferred pronunciation. This reference deliberately supplies no fuzzy matcher or demographic classifier. Its state transitions are useful because they preserve uncertainty rather than invent an answer to a question they did not evaluate.

Bind confirmation to the current revision

A confirmation should name the exact proposed spelling and pronunciation values being approved. In the reference exercise both must be present before the combined clarification can be confirmed. That is a declared small task, not a rule that every real workflow must obtain pronunciation before any other operation.

A material repair creates a newer value revision and clears approval of the earlier value. Preserve the earlier state as history. Changing a mutable object in place while leaving an approved flag attached would make the approval describe content the caller never accepted.

Keep stale revisions separate from same-revision conflicts. An older value arriving late is stale. Different material values presented under the current revision are conflicting. An exact duplicate remains the same proposal and does not require inventing another observation.

Confirmation requests also need identities. An exact retry uses the original request ID and immutable payload. A new confirmation after a repair needs a new ID. Reusing the old ID with changed values should be a conflict rather than silently replacing its history.

The identifier confirmation method uses the same evidence principle. A completed-looking sequence is a candidate until the task obtains the required approval. A name's familiarity does not justify a weaker boundary.

A historical retry should not restore current approval. If a request approved an old spelling and the caller later repaired it, replaying that exact request can report its historical disposition while leaving the newer proposal unconfirmed. The code makes that behavior explicit.

A surrounding live controller must also enforce cancellation and age. The pure value flow below contains no clock or asynchronous action. An adapter must check current deadline before policy queries or replacement admission and recheck generation, age and terminal state after waiting.

Shutdown semantics separates history from active authority. Retaining an old pronunciation hint for diagnosis cannot revive a canceled operation or renew permission to speak it in another person's interaction.

A confirmation event should preserve its request identity and exact proposed value. That allows an exact retry to be recognized without assigning new meaning to old evidence. The code's history records the value and disposition for each newly admitted confirmation request.

The historical-retry disposition is intentionally descriptive. It reports what happened under that request identity while returning the current flow unchanged. A historical confirmed result after a repair therefore cannot set approval on the new proposal.

Do not fix a request conflict by deleting history. The conflict means the identity has been reused for another payload. Issue a new identity for the new confirmation, and retain the old one for reproduction. This is especially useful when an earlier request ended with missing pronunciation and a later repair completes the proposal.

The surrounding adapter still owns interpretation of the caller response. The helper assumes a trusted confirmation event has been supplied; it does not listen to audio, authenticate a speaker or determine whether an affirmative contained another correction. Those are separate evaluated boundaries.

Keep session use separate from retention

A caller may help the current interaction without wanting a permanent pronunciation entry. Ask for retention under the appropriate policy and keep that permission separate from the spelling and pronunciation fields. Declining retention should not force silent substitution or prevent the approved session clarification route.

The consented dataset boundary distinguishes purpose-specific permission from collected material. A supplied preference is not permission to record, publish, train on or globally redistribute a person's voice or name.

The reference creates only a retention proposal value when supplied permission metadata matches the exact current confirmed value and scope. It does not write a dictionary or prove informed consent. Evidence authenticity and actual durable storage belong to their owning adapters.

Memory across repeat calls requires a separate identity and expiry boundary. Do not find a prior preference by surname alone and assume that the current caller is the same person. Shared spelling is not a person key.

The same spelling can also have different preferred sounds for different people or sessions. Preserve those scoped preferences rather than deciding that one is globally correct. A durable target should be associated through trusted identity evidence outside this name-clarification function.

A change in current permission must be enforced at the real storage boundary. A previously returned proposal is historical metadata, not an irrevocable right to persist. If another asynchronous component waits before writing, it needs a fresh current permission and task-state check after that wait.

Keep recording permission separate from retaining text preferences. A listener review corpus can include only appropriately authorized samples. A caller's spoken correction does not automatically make the recording available for another purpose.

A dictionary release process can publish reviewed rules under its own scope, but it should not ingest personal preferences automatically. Preserve purpose, identity association and current eligibility instead of treating every correction as crowd-sourced dictionary content.

Name the retention purpose and target clearly. Session presentation, durable text preference, audio recording, public release and model training are different operations. A single remembered yes should not be reused across all of them merely because the material originated in the same call.

Keep permission bound to the exact confirmed value and trusted scope. If spelling or preferred sound changes, a previously bound metadata record no longer matches the current value. The helper returns a mismatch or unconfirmed disposition instead of attaching an old grant to newly proposed content.

A trusted scope does not mean a name string. The application must supply the association through its own authorized identity process. Two people sharing a spelling can then retain distinct preferences without a global lookup silently choosing one person's sound for another.

If permission is declined, preserve the approved session value while producing no durable proposal. That separates respect for the current preference from storage. A real retention adapter should also apply current revocation and expiry rules at its final write boundary rather than trusting an old cached proposal indefinitely.

Run a bounded clarification contract

The artifact uses immutable value revisions and confirmation request history. It preserves original spelling, keeps pronunciation separate, rejects changed content under a current revision and clears approval on a newer proposal. A separate helper checks trusted retention metadata without performing storage.

Its trusted inputs are the opaque scope, caller-provided proposed values, interpreted confirmation events and retention evidence metadata. The code cannot prove that those events came from the caller or that a scope identifies a real person. It validates the relationships the trusted adapters supply.

Save the complete fence as name_clarification.py and run it with Python 3.12 or newer. Every name, scope and preference token is synthetic. The script emits its final flow and retention proposal so a reader can inspect the promised values.

from dataclasses import dataclass, replace, FrozenInstanceError
from hashlib import sha256
import json

def text(x):
    if type(x) is not str or not x or any(0xD800 <= ord(c) <= 0xDFFF for c in x):
        raise ValueError("nonempty scalar text required")
    return x

@dataclass(frozen=True)
class Value:
    revision: int
    spelling: str
    pronunciation: str | None

    def __post_init__(self):
        if type(self.revision) is not int or self.revision < 1:
            raise ValueError("positive integer revision required")
        text(self.spelling)
        if self.pronunciation is not None: text(self.pronunciation)

    @property
    def digest(self):
        raw = json.dumps((self.revision, self.spelling, self.pronunciation),
                         ensure_ascii=False, separators=(",", ":"))
        return sha256(raw.encode("utf-8")).hexdigest()

@dataclass(frozen=True)
class Request:
    identity: str
    value: Value
    outcome: str

@dataclass(frozen=True)
class Flow:
    scope: str
    original: str
    current: Value
    approved: Value | None = None
    history: tuple = ()

def start(scope, spelling):
    return Flow(text(scope), text(spelling), Value(1, spelling, None))

def propose(flow, value):
    if type(value) is not Value: raise ValueError("admitted value required")
    if value.revision < flow.current.revision: return flow, "stale"
    if value.revision == flow.current.revision:
        return flow, "duplicate" if value == flow.current else "conflicting_revision"
    return replace(flow, current=value, approved=None), "proposed"

def confirm(flow, identity, value):
    identity = text(identity)
    if type(value) is not Value: raise ValueError("admitted value required")
    for request in flow.history:
        if request.identity == identity:
            if request.value != value: return flow, "request_conflict"
            return flow, "historical_" + request.outcome  # never reapprove current state
    if value.revision < flow.current.revision: return flow, "stale"
    if value != flow.current: return flow, "proposal_mismatch"
    outcome = "needs_clarification" if value.pronunciation is None else "confirmed"
    history = flow.history + (Request(identity, value, outcome),)
    return replace(flow, history=history,
                   approved=value if outcome == "confirmed" else None), outcome

@dataclass(frozen=True)
class RetentionProposal:
    scope: str
    spelling: str
    pronunciation: str
    value_digest: str
    evidence: str

def retention_proposal(flow, permission):
    if type(permission) is not dict or set(permission) != {"scope", "digest", "allow", "evidence"}:
        raise ValueError("explicit permission metadata required")
    if type(permission["allow"]) is not bool:
        raise ValueError("explicit boolean permission required")
    if permission["scope"] != flow.scope or permission["digest"] != flow.current.digest:
        return None, "permission_mismatch"
    if not permission["allow"]: return None, "session_only"
    if flow.approved != flow.current or flow.current.pronunciation is None:
        return None, "unconfirmed"
    evidence = text(permission["evidence"])
    return RetentionProposal(flow.scope, flow.current.spelling,
        flow.current.pronunciation, flow.current.digest, evidence), "eligible_metadata"

def permission(flow, allow=True):
    return dict(scope=flow.scope, digest=flow.current.digest, allow=allow,
                evidence="synthetic-permission-evidence")

f = start("synthetic-scope-A", "SyntheticSurname-A")
f, outcome = confirm(f, "request-A", f.current)
assert outcome == "needs_clarification"
old = f.current
f, outcome = propose(f, Value(2, "SyntheticSurname-A", "caller-preferred-form-A"))
assert outcome == "proposed" and f.approved is None
assert confirm(f, "request-A", f.current)[1] == "request_conflict"
assert confirm(f, "request-A", old)[1] == "historical_needs_clarification"
f, outcome = confirm(f, "request-B", f.current)
assert outcome == "confirmed" and f.approved == f.current
hint, state = retention_proposal(f, permission(f, False))
assert hint is None and state == "session_only" and f.approved == f.current
hint, state = retention_proposal(f, permission(f))
assert state == "eligible_metadata" and hint.pronunciation == "caller-preferred-form-A"
other = start("synthetic-scope-B", "SyntheticSurname-A")
other, _ = propose(other, Value(2, "SyntheticSurname-A", "other-preferred-form"))
other, _ = confirm(other, "other-request", other.current)
other_hint, _ = retention_proposal(other, permission(other))
assert hint.spelling == other_hint.spelling and hint.scope != other_hint.scope
assert hint.pronunciation != other_hint.pronunciation
owned_permission = permission(other)
owned_hint, _ = retention_proposal(other, owned_permission)
owned_permission["evidence"] = "mutated"
assert owned_hint.evidence == "synthetic-permission-evidence"
approved_old = f.current
f, outcome = propose(f, Value(3, "SyntheticSurname-B", "caller-preferred-form-B"))
assert f.original == "SyntheticSurname-A" and f.approved is None
assert confirm(f, "request-B", approved_old)[1] == "historical_confirmed"
assert f.approved is None
assert retention_proposal(f, permission(f))[1] == "unconfirmed"
assert propose(f, Value(2, "older", None))[1] == "stale"
assert propose(f, Value(3, "different", None))[1] == "conflicting_revision"
assert retention_proposal(f, {**permission(f), "scope": "other"})[1] == "permission_mismatch"
assert retention_proposal(f, permission(start("other", "SyntheticSurname-B")))[1] == "permission_mismatch"
f, outcome = confirm(f, "request-C", f.current)
assert outcome == "confirmed"
assert len(f.history) == 3
for make in (lambda: Value(True, "x", None), lambda: Value(1, "", None),
             lambda: retention_proposal(f, {**permission(f), "allow": "yes"})):
    try: make()
    except ValueError: pass
    else: raise AssertionError("invalid value admitted")
try: f.current.spelling = "mutated"
except FrozenInstanceError: pass
else: raise AssertionError("name mutation accepted")
print("Synthetic clarification flow:", f)
print("Synthetic retention proposal:", retention_proposal(f, permission(f)))
print("Clarification fixtures passed; no identity verification, audio or durable write.")

The flow preserves the first received spelling while current values advance explicitly. Exact repeated proposals remain duplicates, older revisions are stale and changed values reusing the current revision conflict. A newer proposal invalidates approval without deleting confirmation history.

The request history distinguishes exact historical retry from a new confirmation. A retry of the old confirmed payload reports its historical outcome and does not approve the current repaired value. This prevents cached confirmation evidence from silently restoring approval after a correction.

The retention helper produces metadata only. It checks current value, scope, explicit permission and evidence reference under a trusted adapter contract. The returned proposal is not proof of identity, informed consent, recording permission or an actual durable write.

Test ownership at the returned-value boundary. The current proposal and request records contain immutable scalar values. A caller cannot rebind the accepted spelling through the frozen object. Retention output also captures strings rather than retaining the mutable permission mapping passed to the helper.

Test disagreement between revisions as well. A lower revision must remain stale, a changed current revision must conflict, and a higher revision must clear approval. These are software facts the synthetic fixtures can verify without claiming that any real surname was recognized or spoken correctly.

The artifact intentionally has no policy clock. A live controller must own deadlines and cancellation rather than assuming that a frozen value remains approved forever. If it waits for directory lookup, synthesis or storage, it needs the relevant final admission check after each wait.

Keep empty and unresolved states explicit in the actual workflow. The constructor rejects an empty spelling, while a missing pronunciation remains a declared clarification state. Those cases need different recovery actions and should not be concealed behind one empty result that appears successful.

Review listening evidence without inventing scores

A preferred string is not a recording of how the selected voice spoke it. If the task requires pronunciation review, capture actual output under the pinned provider, voice, locale, dictionary and source-plan conditions. Preserve the audio identity and the caller-preferred reference separately.

Confirmation prosody helps define a meaningful question: can the listener distinguish the material value being confirmed? An aesthetic preference alone does not prove that the right name or record was understood.

Qualified reviewers need a declared task and an uncertainty option. Keep disagreement and incomplete evidence rather than forcing an invented quality rating. This article provides a rubric and synthetic software fixtures, not a completed listening study.

The rubric should separate spelling recognition, preferred pronunciation, intelligibility and intended entity. A reviewer can accept a caller's chosen sound without establishing any unrelated identity attribute. Do not use disagreement as a reason to replace the name with a more familiar one.

Real audio needs format, sample clock, channels, codec, decoder and capture point recorded. A clipped speech boundary can remove a material sound even when the preference and selected rule were correct.

Voice consistency and speaking-rate behavior are separate conditions. If they change during a review, preserve that fact rather than attributing every difference to the name preference.

A cohort report needs appropriate participant and task denominators. Repeated clips of one name do not become independent people. Avoid extrapolating a small synthetic or consented sample into a claim about surnames from a population.

No listener scores or recognition measurements are reported here. The next useful evidence is an authorized task-specific observation with its limits, not a fabricated comparison chart or a guessed pronunciation labeled as expert ground truth.

Define the listener's reference before playback. The reference can be a caller-provided preferred form plus a task that asks whether the output is distinguishable. It should not be a reviewer's unsupported assumption about how a surname is usually pronounced.

Keep review conditions stable when comparing a changed pronunciation rule. Different voices, surrounding sentences, rates or playback channels can change the task. Record those conditions and avoid attributing a joint configuration change solely to the retained preference.

A qualified reviewer can also report that the available representation is insufficient to judge the sound. Preserve that uncertainty instead of producing a numerical rating by default. A small corpus can expose a concrete problem without supporting a broad name, accent or population ranking.

When recordings are unavailable or not authorized, publish the method and software fixtures only. Do not synthesize a result-shaped listening table to fill the gap. The article's executable output is a flow and retention metadata proposal, not an acoustic assessment.

Diagnose failure without a common-name shortcut

Begin with the preserved original, current proposal and caller repair evidence. Determine whether the failure arose in recognition, spelling interpretation, preferred sound, confirmation or entity selection. A final wrong-name report can contain several distinct owners.

If a common suggestion replaced an unfamiliar value, inspect the admission rule. Candidate frequency or search order should not bypass clarification. Keep a synthetic fixture where the intended less familiar spelling remains unresolved until the required evidence arrives.

If approval survived a repair, inspect ownership and revision handling. The partial-transcript contract prevents early text from masquerading as a final command. A mutable name object with an old approved flag is another path to the same wrong state.

If a new confirmation conflicts, inspect request identities. Reusing a completed or incomplete request ID with changed payload is a conflict; the correction is a fresh request identity, not deletion of the old event's history.

If one person's preference appears in another session, inspect scope and identity association. The cache-key method explains why name text alone is insufficient for reuse. Historical preference lookup needs current authorization and appropriate identity evidence.

If the spoken form is correct but the task updates another record, inspect the independent action receipt. Outcome metrics keeps pronunciation success separate from completed business intent. A correctly spoken surname cannot prove an authorized account selection.

Keep diagnostic records appropriately controlled. A name represented as phonetic text, a unique spelling or a voice sample can still identify a person. Use synthetic reproductions publicly and preserve real evidence only under the owning access and retention policy.

A release handoff should let another engineer reconstruct one repaired name from stored evidence. They should find the original, current spelling, current preference, scope, proposal revision, confirmation request and retention disposition. If one value is known only from the author's memory, capture it before treating the interaction as reproducible.

Repeat the audit for a declined-retention case and for a historical confirmation retry after repair. The current session value should remain usable under its declared policy, no durable hint should be proposed without permission, and old approval must not reappear on the new value.

Keep the final outcome separate from those checks. An agent can preserve the name respectfully while an external operation remains pending or unknown. The report should say which boundary is verified rather than using correct pronunciation as a substitute for an independent action receipt.

---

Frequently asked questions

How should an agent ask about an unfamiliar surname?

Target the uncertain segment and invite the caller's correction under the task policy. Preserve the current candidate without pretending it is verified. A focused clarification can resolve material uncertainty without substituting a more familiar spelling or asking the caller to restart unrelated context.

Why is a common-name substitution unsafe?

Frequency and familiarity do not establish what the caller intended. A confident replacement can attach the task to another record. Keep suggestions as candidates, obtain the required clarification and confirmation, and preserve unresolved state when the evidence does not support selection.

Does correct spelling imply correct pronunciation?

No. Keep spelling and caller-preferred sound as separate fields. A person can correct one while confirming the other. Neither field alone proves identity, and a speech-friendly alias should not overwrite the written name or become a global rule for everyone sharing that spelling.

Who decides the preferred pronunciation?

The caller can state a preference for the current interaction, under the application's policy. Qualified source and listening review can help implement it. Do not infer ethnicity, nationality or language identity from the preference, and keep permission to retain it separate.

Can one spelling have multiple pronunciations?

A system should preserve separately scoped preferences rather than assume one universal sound. The same written form can occur in different records or sessions. Use trusted scope and appropriate identity association instead of making the spelling itself a durable person key.

Should the system infer language from a surname?

Not under this contract. A name string does not establish a caller's language identity or preferred sound. Ask for the relevant preference when needed and keep any language configuration as an explicit trusted task value with its own evidence.

How do I preserve diacritics and spacing?

Retain the original and apply only the owning field's declared transforms. Avoid blanket deletion or simplification for synthesis convenience. Keep any derived speech projection separately so a later reviewer can distinguish an intentional presentation choice from corruption of the caller's supplied value.

Can Unicode normalization merge two people?

It must not be treated as permission to do so. Normalization establishes a text relation under a chosen policy, not entity identity. Keep registry scope, caller confirmation and authorized identity evidence separate even when two written forms are canonically equivalent.

Should a phrase list decide identity?

No. A documented phrase list can influence recognition toward supplied terms. It cannot verify which person the caller meant or authorize an action on a record. Preserve candidate, confirmation, identity and outcome evidence at their own boundaries.

What should a clarification prompt target?

The material uncertainty needed for the task, such as a specific spelling segment or preferred spoken form. Avoid demanding unrelated personal information as an improvised discriminator. If the approved route cannot resolve the name, preserve an explicit unresolved disposition rather than guessing.

How many repair attempts should a workflow allow?

Define that in the interaction policy for the actual task. This pure value example supplies no universal limit or timing controller. Preserve each material revision and use an approved fallback when further clarification is declined or cannot resolve the uncertainty.

What if the caller declines to repeat the name?

Follow the declared unresolved or alternative-channel route. Do not fill the missing value with a common suggestion. The example preserves uncertainty and implements no identity guess; a live workflow must separately decide which safe actions remain permitted.

Can a preferred pronunciation be session-only?

Yes, when the session policy permits that use. Declining durable retention should not automatically block current clarification. Keep the session preference and retention permission separate so the system does not create a durable dictionary entry from every corrected pronunciation.

When is permission needed to retain a hint?

Use the actual collection and retention policy, with appropriate review, rather than treating this example as legal advice. The helper checks explicit trusted metadata bound to the current value and scope. It does not prove informed consent or perform storage.

Should audio recordings enter a dictionary automatically?

No. A spoken correction does not automatically authorize recording reuse, public release, training or durable pronunciation storage. Resolve the purpose and permission boundary first, then use qualified review and an explicit dictionary process if an authorized retained rule is appropriate.

How do consented listening reviews work?

Use appropriately authorized samples, a caller-preferred reference, declared task instructions and actual reviewer responses. Preserve audio and configuration identity. Separate preference, intelligibility and entity questions rather than collapsing them into a score that hides what was observed.

What does reviewer disagreement mean?

It means the current observations differ under the recorded rubric. Preserve the responses and uncertainty. Do not invent a consensus or replace the caller's preferred name with a familiar form merely to make the report easier to summarize.

Can a text fixture establish pronunciation quality?

No. It can validate revision, ownership, confirmation and metadata relationships on synthetic values. Actual sound requires captured synthesis and qualified review under the target conditions. The code reports no acoustic, recognition or population-level surname performance.

What should a spelling correction invalidate?

Invalidate approval of affected material values and re-evaluate associated pronunciation and retention bindings. The example creates a newer value and clears its combined approval. An exact historical confirmation retry cannot approve that new value; a fresh confirmation request needs its own identity.

How do I test the flow without real personal data?

Use synthetic spelling, scope and preference tokens with explicit expected states. Include corrections, stale revisions, request conflicts, historical retries, declined retention and wrong-scope metadata. These fixtures test the software contract without exposing a real person's name, recording or account relationship.

Preserve one repaired name end to end

Run the full synthetic revision and retention fixtures, then connect the flow only to trusted task adapters. Preserve original spelling, ask for the uncertain information and keep a fresh confirmation bound to the current value.

Treat preferred sound, identity and retention as separate evidence. That gives the interaction a respectful unresolved route and gives the next engineer enough history to diagnose a failure without replacing uncertainty with a familiar surname.