Private preview · 0.2.0-preview.1
Grounding and candidates
How is intent grounded?
Grounding connects a proposed action to the exact record, resource, account, item, document, service, or other target that the application intends to change. A candidate is a bounded possible match; the referent is the exact identity selected for later stages. A candidate match is not authorization or proof of an effect.
Where candidates come from
A proposal may originate in a web application, copilot, API, workflow, webhook, messaging interface, voice interface, or another agent or framework. The host may query or receive bounded candidates from a service catalog, CRM, database, document index, inventory system, identity directory, or other named source.
The host supplies candidate records, their exact identifiers, provenance, and snapshot or revision. Core associates the proposal with the selected candidate and that provenance; it does not invent the list or silently choose among ambiguous records.
Ambiguity and exact selection
Grounding follows trusted-context admission and precedes authorization. If candidates are missing, stale, foreign, contradictory, or ambiguous, the application asks for clarification or returns NOT_DISPATCHED. A model ranking can help an application choose what to ask about, but confidence is not evidence for selecting a production record or another consequential target.
Example: targeting the payments API
A developer or operations copilot proposes restarting “the payments API.” The organization’s service catalog contains separate production and staging services with similar names. The backend supplies bounded candidates with their environment, tenant, and service identifiers.
Grounding must bind the proposal to one exact service record before authorization. If both records remain plausible, the application asks for clarification or returns NOT_DISPATCHED; it does not let a confident model ranking select production. AnswerUp Core does not operate infrastructure or restart the service.
Normalization limits
Normalization can compare approved formatting differences. It cannot erase meaningful differences such as production versus staging, tenant, currency, timezone, product size, or resource identity. It cannot invent a missing identifier, prove ownership, or establish that an external effect happened.
Failure and ownership
The host owns source queries, candidate limits, provenance, snapshot freshness, and clarification UX. It also decides how to handle a candidate that becomes stale between preparation and dispatch. Core preserves the bounded candidate and referent association and keeps ambiguity from becoming an implicit choice. Grounding does not prove authorization or effect truth; authorization still applies only to the exact grounded operation, and independent authoritative verification determines any external effect.