Canonical-Entity Grounding

Problem

Asked for an identifier it does not have, a model will supply one from parametric memory that is well-formed and confidently wrong — a close-enough part number, an account code from a similar company, a supplier id that no longer exists. In an enterprise system there is no credit for close: a transaction posted to a plausible-but-wrong GL account is a real error, not an approximation. Because the fabricated identifier is syntactically valid, downstream format validation often accepts it, and the mistake surfaces only later as a misposting or a failed integration.

Solution

Give the agent a resolver tool over master data that takes a description or a candidate identifier and returns the canonical id with a confidence, or an explicit no-match. Require every identifier that will enter an action — especially a write — to pass through this resolver first; the model proposes intent ('post to the marketing-travel account for the Munich entity') and the resolver returns the exact code, rather than the model emitting the code directly. Treat the resolver's output, not the model's text, as the identifier of record. On a no-match or a low-confidence result the agent asks for clarification or halts rather than guessing. Once an identifier is resolved, the rest of the operation runs against that canonical id deterministically. Where volume is high, the resolver can present a fetched candidate set the model selects among, so the model chooses among real entities rather than inventing one.

When to use

• The agent writes to or acts on a system whose entities are identified by exact codes that must match a record.
• Wrong-but-well-formed identifiers would pass format validation and corrupt downstream data.
• Authoritative master data exists and can be queried at action time.
• Identifiers change after the model's training cut-off.