Skip to content

Ambiguity Register

A standing register — instantiates Grammar-Guided Structure Recovery

The standing record of every ambiguity the parser could not resolve, each entry tagged with its competing readings and a route to whoever or whatever decides it.

The Ambiguity Register is the archetype's memory for what recovery could not settle. It does not resolve anything; it captures each surviving ambiguity as a durable entry — the location in the input, the competing readings, why the ambiguity survived — and assigns each one an escalation path to a resolver: a human reviewer, a request for a new grammar rule, or an accepted-but-flagged default. Where the Controlled Disambiguation Test tries to kill an ambiguity, the register accepts that some will survive and insists they be made visible and tracked rather than silently defaulted. Its defining move is to treat residual ambiguity as first-class data to be logged and dispositioned — the archetype's own principle that ambiguity is information about the limits of the input, not a defect to hide.

Example

A data-integration service parses millions of user-submitted mailing addresses a day. Most resolve cleanly; a steady fraction do not — a Springfield with no state, a token that is equally a street name and a city, a unit number indistinguishable from a PO box. Instead of guessing, the pipeline writes each unresolved case to the register: the raw span, the candidate parses, the reason for the tie, and an escalation route chosen by policy. High-volume recurring patterns become a grammar-rule request; low-volume cases with a customer order waiting go to a human review queue; low-stakes cases accept a flagged default and move on.

By the end of the week the register has done something no single parse could: its top recurring patterns are the prioritized backlog for grammar improvement, and every address that shipped with a guess is auditable back to the entry that flagged it. The register turned a stream of silent guesses into a governed, countable work queue.

How it works

On an unresolved ambiguity the register appends an entry — location, competing readings, cause, timestamp, and a link back to the parse provenance — and assigns it a disposition by policy, keyed on volume, stakes, and whether a downstream consumer is blocked. Entries stay open until dispositioned, and resolutions (a human decision, a new rule, an accepted default) are recorded back against them. Because it is append-first and never overwrites, the register doubles as an audit trail; and because it aggregates, the same log that captures one-off oddities also surfaces the recurring patterns worth a permanent fix.

Tuning parameters

  • Capture threshold — how uncertain a case must be before it is logged. Log everything and the register drowns in noise; log only the severe and real ambiguities slip through unrecorded.
  • Escalation policy — the routing rules that map an entry to human review, a rule-request, or default-and-flag — the register's core behavior.
  • Aggregation window — keep entries per-item, or cluster them into recurring patterns; clustering is what converts the log into a prioritized backlog.
  • Retention & closure — when an open entry is retired: resolved, expired, or accepted-as-is.
  • Default stance — whether an un-escalated entry blocks downstream use or passes it through with a flag.

When it helps, and when it misleads

Its value is that nothing ambiguous is silently guessed: every unresolved case is visible, counted, and routed, and the aggregate becomes a roadmap for where the grammar or schema most needs work. Its failure modes are organizational as much as technical. A register nobody triages becomes a graveyard — entries logged, never dispositioned; over-capture buries the important ambiguities under trivia; and a permissive default stance quietly lets flagged-but-unresolved items flow downstream as though they were clean. The classic misuse is using the register as an alibi: logging an ambiguity to look like it was handled while the escalation path in fact goes nowhere. The discipline that guards against this is to give every entry an owner and a closure target, and to measure the register by its throughput — the rate at which entries are resolved — not by how many it holds.[1]

How it implements the components

The Ambiguity Register realizes the tracking-and-routing side of the ambiguity machinery — recording what survives resolution and steering it to a resolver:

  • residual_ambiguity_log — the append-only record of every unresolved ambiguity, each with its competing readings and cause.
  • ambiguity_escalation_path — each entry's assigned route to a resolver: human review, a grammar-rule request, or an accepted-and-flagged default.

It does not itself attempt to resolve the ambiguities it holds (that is the Controlled Disambiguation Test), and it does not score per-node confidence during parsing (that is the Controlled Disambiguation Test and Probabilistic Grammar Parsing); it records what those steps leave behind.

Notes

The register is a record, not a resolver, and its health is measured by closure rate rather than entry count. A log that grows while its closure rate stays flat is a warning sign — ambiguities are accumulating faster than anyone is dispositioning them — not evidence that the parser is being careful.

References

[1] Routing an unresolved case to a person rather than forcing an automated guess is the standard human-in-the-loop pattern: the machine handles the confident majority and escalates the genuinely uncertain remainder to human judgment, so accuracy on hard cases is bought without stalling the easy ones. ↩