> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dubot.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Evaluation guide

> Prove one valuable customer outcome against the current product

## Start with one outcome worth proving

A Dubot evaluation should produce operational evidence, not only a polished demo. Choose one
recurring request whose current answer still leaves meaningful work for the customer.

## A good first journey

Choose a request that is:

* common enough to matter;
* completed through a product path the team understands;
* bounded enough to test safely;
* measurable through a visible product state or action result;
* feasible with current-build capabilities or an explicitly agreed controlled rollout.

Avoid a first journey dominated by destructive changes, unclear ownership, many exceptional
states, or a connector that does not yet exist.

## Evaluation sequence

<Steps>
  <Step title="Confirm feasibility">
    Map each required behavior to a current product feature, controlled-rollout dependency, or
    customer-owned integration. Do not use a prototype as the availability decision.
  </Step>

  <Step title="Define the boundary">
    Agree identity, origin, data, knowledge, action, confirmation, and stop conditions.
  </Step>

  <Step title="Build in Test">
    Configure the narrow wizard, guide, Resource Center entry, and actions needed for the outcome.
  </Step>

  <Step title="Exercise failures">
    Test invalid identity, missing callback, unpublished dependency, rejected confirmation,
    customer API error, unavailable UI target, navigation, and user stop.
  </Step>

  <Step title="Publish deliberately">
    Publish only the reviewed entities and verify the Production experience on the target origin.
  </Step>

  <Step title="Measure and decide">
    Review completion, safe stops, errors, customer effort, maintenance cost, and operational
    ownership before expanding scope.
  </Step>
</Steps>

## Evidence to collect

| Evidence                   | Why it matters                                                       |
| -------------------------- | -------------------------------------------------------------------- |
| Baseline volume and effort | Establishes whether the outcome is worth improving                   |
| Successful completions     | Shows the intended customer result occurred                          |
| Safe stops and declines    | Shows controls work without forcing completion                       |
| Failure categories         | Identifies product, integration, content, or model gaps              |
| Maintenance work           | Tests whether the experience stays economical as the product changes |
| Customer or agent feedback | Captures effort and trust not visible in technical logs              |

## People to include

| Role        | Smallest useful contribution                                          |
| ----------- | --------------------------------------------------------------------- |
| CX          | Recurring request, examples, current resolution path, desired outcome |
| Product     | Expected product states, edge cases, and ownership                    |
| Engineering | Identity, origin, customer-owned execution, and test environment      |
| Security    | Data, action, authorization, retention, and review boundary           |
| Dubot       | Configuration, integration guidance, test plan, and evidence review   |

<Info>
  Confirm the status shown on each relevant product page. Keep current-build, controlled-rollout,
  planned, and design-only dependencies visible throughout the evaluation.
</Info>