What a Chatbot Can Say, Offer and Confirm

Separate information from a change in the world

Start with the visitor's intended result. 'What is your cancellation policy?' asks for information. 'Cancel my appointment' asks to change something. The same topic can require different permissions, identity checks, tools and evidence depending on the instruction.

Write down the actual systems involved. An assistant may explain a policy, point to an existing form or submit through an authorized connection. Do not infer the last capability from the first two. A visible booking link is evidence of a destination, not evidence that the assistant can create bookings.

NIST's AI RMF emphasizes documenting intended tasks, limits and human oversight. The state model here is our practical specification tool. It is not an external certification, and it makes no claim that a particular product supports the illustrated actions.

• NIST AI RMF: intended tasks and oversight

Use the right source for the claim

A static page is appropriate for a stable published rule. Current availability, order state or a payment result needs a source that can establish that particular state. Preserve when the information was retrieved and which object it described; a result for one appointment cannot support a claim about another.

Visitor statements remain visitor statements. 'I was promised a discount' can be included in a request for the team to review, but it does not authorize the assistant to apply that discount. Likewise, a model's interpretation that someone is ready to buy does not authorize an arbitrary purchase.

For US and Canadian workflows, include the relevant region, currency and timezone in the evidence when those details affect the result. Do not silently convert a USD price to CAD or infer a local appointment time from an ambiguous message. Ask the necessary clarifying question before committing to a specific interpretation.

Define authority without adding unnecessary ceremony

A clear instruction can authorize the action it actually describes. Determine what is being changed, whose record it is and which safeguards the business requires. Ask for further confirmation when the instruction is ambiguous or the consequence calls for it, rather than mechanically asking again after every deliberate submission.

Identity and authorization solve different problems. Someone may be identifiable but not permitted to change a particular order. A visitor who authorizes a request also does not grant the assistant permission to use an unrelated destination or expose another customer's information.

Have the implementation owner verify permitted destinations, identity requirements, repeated-submission handling and available stop controls. These are requirements to inspect in the actual workflow, not features that a marketing label proves. If the evidence is unavailable, keep the claim limited and provide a usable human or page route.

Read the receipt before writing the success message

A receipt should identify the operation, object, state and observation time. Keep intermediate states visible: accepted, pending review, saved, delivered and completed mean different things. A successful network response may show that a request reached an endpoint without proving the business outcome the customer wanted.

Stripe's Checkout documentation provides a concrete provider-specific example: it warns against relying only on a return landing page for fulfillment and describes checking payment state with server-side events and retrieval. That guidance illustrates why an observed click or page visit is insufficient; it does not establish any HostDesk payment capability.

Design the user-facing message from the available result rather than from the desired outcome. If the action times out, say the outcome is unconfirmed and explain the safe next step. Blindly retrying a consequential operation can create a second effect unless the system's repeat handling is established.

• Stripe: authoritative Checkout fulfillment and payment-state checks

Worked example: change only the evidence

All records in this example are fictional. A workshop's approved page says visit requests are reviewed before appointments are confirmed. The visitor says, 'Please request Tuesday afternoon.' Keep that instruction fixed while changing the result available to the assistant.

With only a verified form link, the assistant may offer that route and explain the process. With a hypothetical saved-request receipt R-41, it may confirm the request was saved. With a hypothetical booking record A-12 showing confirmed Tuesday at 2 pm in America/Toronto, it may state that exact appointment result if the workflow was authorized.

Now remove A-12 while leaving the visitor's request unchanged. The assistant must stop claiming a confirmed booking. This counterfactual is useful because the language should follow the evidence rather than the visitor's wish. No real request, booking or integration test was executed for this example.

Turn the matrix into reviewable requirements

For each proposed action, write the visitor instruction, required evidence, allowed destination, identity requirement, possible result states and permitted message for each state. Have the business owner approve commercial limits and the implementation owner prove the actual state transitions.

Keep tests for missing evidence, stale results, mismatched objects, repeated requests and unavailable tools. Preserve actual replies and receipts when testing the deployed workflow. The worked matrix above is a teaching fixture; your acceptance record must contain observations from your own implementation.

Review the wording again when the provider, policy or workflow changes. A previously correct success message can become misleading if a system changes from immediate confirmation to queued review. Reliable actions depend on maintaining the relationship between authority, evidence and the words the customer sees.

• Use a worked acceptance record
• Design a human handoff packet