When should the product ask instead of assume?
Fewer questions against a customer losing control of their own request.
Context
A customer writes "there's water under my sink and it's getting worse." A language model can reasonably conclude this is urgent. It is a good inference. But the customer never said urgent, and urgency changes who gets dispatched, how fast, and what it costs. If the request says urgent and the customer never agreed to that, nobody downstream can tell the difference between what was said and what was guessed.
What was on the table
Trust the inference and write it into the request.
Fastest, and wrong in a way that is invisible. A field that is wrong and confident is worse than a field that is empty.
Refuse to infer anything; only record what was literally said.
Safe and useless. It turns the conversation back into a form, and the whole point was to stop making people fill in forms.
- Chosen
Infer freely, record where the value came from, and gate commitment on confirmation.
The decision
Every value on a request carries its provenance — user_stated, ai_inferred, page_context or account_profile — and a separate confirmed flag. Inferred values land unconfirmed by design. The assistant asks: "It sounds like you need someone fairly quickly — should I mark this as urgent?" Submission is blocked while any inferred value remains unconfirmed.
The principleLet the AI work things out. Let the app decide what counts.
What it cost
An extra turn in the conversation for anything inferred, which is friction on exactly the fastest path. Provenance also cannot be reconstructed after the fact, so it has to be threaded through every layer that touches a value — the whole intake surface pays for it.
Evidence
- Provenance and the confirmed flag are separate fields; confirming a value does not rewrite where it came from.
- Anything that fails validation degrades to ai_inferred rather than inheriting a stronger claim.
- Readiness checks collect unconfirmed inferences and refuse submission while any remain.
Enforced in the product code, not only described here.
What would change my mind
If confirmation turns out to be where people abandon intake, and the corrections they make are almost always agreeing with the inference anyway, then the gate is costing more than the errors it prevents. The right answer would be to gate only fields that change dispatch or price, and let the rest ride.