We have changed the default behaviour of the platform. From this release, every factual claim an assistant makes about a customer, a policy, a booking or a benefit must be traceable to a record it read. Answers that cannot be traced are not generated.
What changed
Three things, in order of how much they affect a live deployment.
Answers carry provenance. Each response now records which reads produced it, with the identifiers and the retrieval timestamp. This is visible in the conversation log and available through the API, so a supervisor can ask not just what the assistant said but why it believed it.
Unsupported answers route instead of generate. Where the assistant would previously have produced a plausible general answer in the absence of a read, it now says what it cannot see and offers a person. This is a deliberate trade: slightly lower containment, materially fewer confidently wrong answers.
Stale reads are treated as no read. Every read path carries a freshness budget. A cached balance from four hours ago is not a basis for telling a customer what they owe, and the platform now enforces that rather than leaving it to configuration.
What it means for existing deployments
Most teams will see a small shift in containment in the first fortnight, concentrated in a handful of intents where the assistant had been answering generally. Those intents are worth reviewing: in nearly every case the fix is a read path that was never wired up, not a rule that is too strict.
The provenance data is on by default and retained under your existing retention settings. No transcript content is added to it beyond the identifiers already present.
Why now
Grounding has always been our position; enforcement was configurable, and configuration drifts. Making it the default removes a class of failure that is hard to detect from a dashboard and obvious to the one customer it happens to.
If you would like a walkthrough of the provenance view or help auditing read paths in an existing deployment, your account team can arrange it.
