ELVINA · RESEARCH
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.
Example scenario with sample data.
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
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.
- How often do we re-verify? When the product revision, the source or the approver changes. A dated record makes the trigger obvious.