DOCS · CUSTOMER SERVICE · TECHNICAL REFERENCE

Resolution Contract Specification

A reference for deciding when an AI customer-service task is actually resolved rather than merely answered, attempted or handed off without a confirmed outcome.

Resolution reference · draft 1.0 · 2026-09-19

1. What counts as resolved?

A customer-service task is resolved when the required answer or external effect is complete enough to verify and the customer is told the resulting state. A plausible response is not the same as a completed service action.

Request understood → required context → evidence → permitted action → target-system result → confirmation → retained evidence

2. Resolution contract

Request identification

Define the customer's intended outcome and the specific service task the system is attempting to complete.

Required context

Collect the account, order, booking, policy or case context required for that task. If required context is missing, the action path remains open.

Knowledge and evidence

Use permitted knowledge sources for factual answers and preserve the evidence needed to support consequential decisions.

3. Allowed system actions and authority

Separate what the agent can read from what it can change. A tool being available does not automatically authorize every action exposed by that tool.

• ALLOW. The configured action may proceed under the resolved policy.
• ASK. Wait for the approval that is bound to the requested operation before execution continues.
• DENY. Keep the blocked effect unresolved; do not present it as completed.

External effect

For a request that requires a write, the service outcome depends on the target-system result rather than the model's intention to act.

Target-system result

Treat the action as complete when the relevant target state or returned result is verified. A timeout, failed write or ambiguous response remains unresolved.

Confirmation

Tell the customer what happened: answered, changed, booked, canceled, escalated or still pending. Do not confirm an external effect before verification.

4. Failure, unresolved state and handoff

If the required action fails, is unavailable or cannot be verified, keep the task unresolved and move to a permitted recovery path.

Unavailable action

If the target system or configured action is unavailable, the system can provide the verified information it has, but it should distinguish that answer from completion of the requested write.

Escalation

Where the configured workflow supports context transfer, pass the request, known context, attempted actions, policy or failure reason and the next expected human step.

Human handoff

A handoff changes ownership of the unresolved work. It does not retroactively make the original task resolved unless the downstream outcome is later confirmed.

5. Evidence relationship

Retain the decision and execution evidence needed to reconstruct why the system answered, acted, waited or escalated. Policy evidence shows why an action was permitted or blocked; execution evidence shows what happened after that decision.

Answered ≠ acted. Acted ≠ verified. Verified outcome + communicated state is the resolution boundary for action tasks.

6. Limitations

• This specification defines operational completion for a configured task; it does not guarantee customer satisfaction.
• It does not guarantee policy correctness, SLA performance or success in every connected system.
• It does not make an unavailable integration or unauthorized action available.

7. Resolution authority graph

Customer Service combines conversation with knowledge, memory, tools and governance. Each layer contributes a different part of the resolution contract.