Give every AI feedback statement an evidence state and an owner
AI feedback should avoid overcertainty because a fluent sentence can hide three different states: information supported by current input, an inference that holds only under stated conditions, or an unknown that the product cannot resolve yet. It should avoid unfulfillable promises because “I will handle it” says nothing about who owns the action, which outside service must respond, when the commitment expires or what the interface will show after failure. This is a product wording and interaction-design problem, not a lesson in how users should fact-check an answer. A useful feedback contract records seven fields: evidence state, inference condition, unknown item, action the user or system can control, external dependency, promise owner with time and failure state, and expiry. Certainty should follow observable state; tone should not manufacture it.
Separate evidence, inference, unknown and action status
Use four visible states before writing polished prose. “Supported now” means the displayed statement maps to a named current input, system record or completed event. “Conditional inference” names the premise that must remain true. “Unknown” identifies the missing input, unavailable source or unresolved conflict without filling the gap. “Action status” says requested, queued, sent, acknowledged, completed or failed only when the system can observe that transition. NIST’s Generative AI Profile explains that generated content may be erroneous yet confidently presented, so confident tone is not a state signal. Keep atomic claims separate: a calendar entry may be created while an external invitation remains unacknowledged. Do not merge both into “Everything is arranged.” Each card should expose its support and last checked time.
Turn every promise into ownership, dependency and terminal states
A promise is valid only when its owner can perform the action and observe completion. Write who owns the next step: this product, the user, a named external service, or a person outside the system. Then show prerequisites, a real deadline or an estimate, the checkpoint for checking again, and the possible terminal states: completed, declined, expired, failed or still waiting. “I’ll make sure they reply tomorrow” has no controllable owner. “Invitation sent by this app; recipient response is outside the app; check after Tuesday” separates control from dependency. Microsoft HAX recommends clear capability and performance boundaries. Do not let first-person assistant language silently transfer an external party’s obligation to the model. If no actor owns the result, phrase it as an option, not a commitment.
Attach conditions and expiry where the feedback appears
A footnote or general disclaimer cannot repair an unconditional status chip. Put the decisive condition beside the sentence: “Based on the schedule currently connected,” “if the venue hours remain unchanged,” or “no receipt has arrived yet.” Time has three different roles. The evidence timestamp tells when support was observed; the promised checkpoint tells when the owner will act or recheck; the expiry tells when the statement must no longer be reused. External data, permissions, app versions and user edits can change independently. When a dependency expires or disconnects, downgrade the status instead of keeping yesterday’s confident wording. OECD transparency guidance supports meaningful, contextual information about inputs and limitations. The interface should preserve previous wording in a log only when it is clearly dated, not as current truth.
Write the next controllable action without implying an outcome
A useful uncertain message still gives a bounded next action. Google PAIR recommends explaining what is missing and offering a path forward; that path can be retrying after a checkpoint, reconnecting a source, editing the input, switching to a manual route, cancelling the request or leaving it unresolved. The button label must describe the action, not promise its consequence: “Send request,” not “Get approval”; “Check availability,” not “Reserve successfully”; “Ask for clarification,” not “Resolve now.” Feedback controls also need an honest effect statement. If a correction changes only the current display, say so; if it enters a later review queue, name that scope and timing. A thank-you message must not imply that the underlying model has already changed.
Run five negative tests against confident copy
Use harmless test data and inspect observable UI states. Disconnect an external source after a positive response; revoke a required permission; delay the external acknowledgement past the checkpoint; provide a second input that conflicts with the first; reopen an old result after its expiry. In each case, check whether titles, badges, notifications, summaries and generated follow-ups downgrade together. A failure should not retain “done,” “certain,” “always,” or a future tense the product no longer owns. Verify that the available action still matches the state: reconnect, edit, retry, cancel, manual route or remain unknown. Do not probe hidden safeguards or create risky content. Record input, dependency, timestamp, expected terminal state, observed wording and version so the failure can be reproduced.
Use the seven-field contract as a release gate
Review every consequential feedback component in a seven-column ledger: evidence state; condition; unknown; controllable action; external dependency; owner, time and failure; expiry. A release passes when each sentence maps to one state, every promise has a capable owner, dependencies are visible, expiry causes a downgrade, and all negative tests reach an honest terminal state. It fails when visual confidence exceeds evidence, completion is inferred from sending, an estimate becomes a deadline, user feedback is described as an immediate model update, or stale output remains active. Pair copy review with event-state review: changing adjectives cannot fix a backend that exposes only success. This gate evaluates product feedback. The related fact-checking workflow remains the separate task for a user who must verify a particular answer.
Common questions
Is all confident language inappropriate?
No. Definite wording is appropriate for an observable completed state whose scope, source and time are clear.
Can an estimate be shown?
Yes. Label it as an estimate, name its basis and checkpoint, and define what appears if the dependency has not responded.
Should every unknown become an error?
No. Some items are legitimately unresolved. Keep them unknown and offer only actions that can actually reduce the gap.