Grounding an AI feature so it cannot invent an event that does not exist

A concierge that recommends an event which does not exist is not a minor defect. It is the product failing at the one thing it is for. The temptation is to fix it in the prompt: 'only recommend events from the list below'. That reduces the rate. It does not make the failure impossible, and a control that only reduces a failure rate is not a control.

Prompt-level grounding is not a control

The firm's position is that grounding happens after generation, on the server, by validating what the model produced against the real records. If the model names an event, the event must resolve to a record. If it names a time, the time must match that record. Anything that fails validation is dropped or regenerated, and the user never sees it.

Deterministic rules for anything with a consequence

Where an output has a compliance or safety consequence, it is not generated at all. It is a rule. A care product's escalation logic, a health product's crisis routing, an insurance process's suitability check: these are deterministic, versioned, owned by the accountable function and carry effective dates. AI is confined to conversation, extraction and drafting, where a wrong answer is recoverable.

Write the boundary down

Every product carries an explicit boundary table: what the system may do, and what requires an authorised human. It is written before the first screen, and it is published with the product. The table is what a regulator, a partner or a buyer actually wants to see.

• Multi-provider failover, so that a provider outage is not a product outage.
• Human review queues for any generated content that reaches a user.
• Prompt-injection defence: retrieved content is data, never an instruction, and an injection suite runs in the release gate.
• Model, cost and latency governance with a spend cap and a static fallback.