# Separate a workflow diagram from operational evidence

A proposed AI workflow should be judged by the operations that were actually tested, not by its diagram. This protocol separates the two, and its worked example uses a fictional regional bank.

Updated October 15, 2026

## Who this is for, and when

A CTO, a risk owner or a procurement analyst who is shown a workflow diagram and asked to approve it. It is written for a vendor review. A diagram with five boxes says nothing about which boxes have been exercised, by whom, on which revision.

## How it works in Elvina

An evidence record lists source retrieval, draft creation, human approval, delivery and observed result separately, with a tested revision for each.

- Split the proposed workflow into its operations: source retrieval from Company Knowledge, draft creation in Creation Studio, human approval in the Web workspace, delivery in the Learning Platform, observed result.
- For each operation, record whether it was tested, on which product revision, by whom and with what input.
- Treat an untested operation as a diagram, not evidence, regardless of how it is drawn.
- Re-run the record when the product revision or the source changes.

## A worked example

A regional bank's risk team reviews a proposed workflow: a policy change triggers a lesson update that reaches tellers. Their evidence record has five rows. Retrieval, draft and approval were tested on a sanitized policy last month. Delivery was tested with two internal accounts. The observed-result row is still empty.

- The record shows four rows with a date, a tester and a revision, and one row marked not yet observed.
- The risk team approves a pilot limited to the four tested operations and sets a date to fill the fifth row.
- A later product revision triggers a re-test of the draft creation row only.

## What to check before relying on it

A successful website demonstration verifies that demonstration only. It does not establish connector reliability, security controls or unattended production behavior.

- Each operation has its own row with a test date and a tester.
- Untested operations are labeled as such, not inferred from the diagram.
- The record is tied to a product revision and re-run when it changes.

## Where a person stays in charge

This is an editorial piece. A successful website demonstration verifies that demonstration only; it establishes nothing about connector reliability, security controls or unattended production behavior. Elvina's design keeps a person in the approval step, and the evidence record should show that step was exercised, not assumed.

## Questions people ask

**Q:** Is a vendor demo evidence?

It is evidence that the demo ran. Your record should note the demo's inputs, revision and who watched it, then test the operations with your own material.

**Q:** How often do we re-verify?

When the product revision, the source or the approver changes. A dated record makes the trigger obvious.