# AI workflow evaluation report

Sample deliverable · SynapseTel Cloud
Source: https://synapsetel.com/en/delivery-standards#automation-acceptance

> Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

## Scope

The workflow, approved data, permitted actions, and baseline.

- **Environment / release / date:** _Complete for the agreed engagement_
- **Accountable owner:** _Complete for the agreed engagement_

## Prerequisites

- [ ] Describe the process, approved data sources and permitted actions. Capture baseline cycle time, error rate and human review effort; document permissions and approval boundaries.

## Checklist

- [ ] Evaluate representative and adversarial cases: missing data, incorrect model output, connector failure, duplicate events and attempted instruction injection. Record outcomes and reviewer decisions.
- [ ] Agree acceptance thresholds and cost limits. Verify manual fallback, audit records, exception routing and ownership; compare pilot results with the baseline before widening access.
- [ ] Test normal, adversarial, and failure cases.
- [ ] Verify human approvals, audit records, and manual fallback.

## Pre-flight verification

Record pass, fail or not applicable in the status column and attach the evidence reference for every row before the change window opens.

| Check | Method / role | Pass criteria | Stop condition | Status |
| --- | --- | --- | --- | --- |
| Permitted actions and approved data sources documented | Workflow owner, permission inventory signed off | Every action and source is listed with a least-privilege credential and an owner | An undocumented action or a credential shared between workflows |  |
| Manual baseline measured | Workflow owner, cycle time, error rate and review effort on a representative sample | Baseline recorded with the sample size and the period it covers | No baseline or a sample that does not represent normal volume |  |
| Representative and adversarial evaluation set | Evaluation reviewer, cases for missing data, wrong output, connector failure, duplicate events and injected instructions | Every case has an expected outcome and a recorded result | Any adversarial case that leads to an unapproved action |  |
| Approval gate and exception routing | Named reviewer, approve and reject trial on live-shaped cases | Consequential actions wait for a recorded approval and exceptions reach a person | An action executes without the recorded approval |  |
| Time, retry and cost limits with manual fallback | Platform engineer, limits enforced in the connected systems and the manual path completed end to end | Limits enforced outside the model and the manual path completes within the agreed time | A limit enforced only in a prompt or a manual path that does not complete |  |
| Audit records for a full case | Security reviewer, audit trail for one approved and one rejected case | Proposal, approval, execution and outcome recorded separately with timestamps | Any of the four records missing or combined |  |

## Stop conditions

- A pre-flight row fails or its evidence reference is missing.
- The workflow proposes or performs an action outside its documented scope.
- Cost, retry or latency limits are reached during the pilot period.
- The named reviewer is unavailable while consequential actions wait for approval.

## Rollback triggers

- Pilot error rate or review effort is worse than the manual baseline.
- Audit records are incomplete for any case processed during the pilot.
- Records written by the workflow need reconciliation that the owners cannot complete inside the pilot window.
- The accountable owner withdraws approval on a stop condition the plan names.

## Acceptance

**Expected result / acceptance threshold**

> Illustrative expected result: Evaluation outcomes compared with the baseline; approvals, exception routing and manual fallback demonstrated.

**Observed result / evidence reference**

_Complete for the agreed engagement_

**Exception / decision / follow-up owner**

_Complete for the agreed engagement_

## Sign-off

| Role | Name | Date |
| --- | --- | --- |
| Prepared by |  |  |
| Reviewed by |  |  |
| Approved by (accountable owner) |  |  |
| Operations handover accepted by |  |  |

## Reference disclaimer

Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

Technology names describe the environments we work in. They do not imply vendor partnership, certification or authorization. Vendor licenses and support entitlements remain yours; our engineering assistance does not replace them.

Support hours, emergency coverage and response, restoration and resolution targets are stated beside each engagement option and in your agreement. Read them there rather than in a general note.