Instrument runs and results
Test a version against pasted inputs, read a run's outputs, reason codes and trace in the run inspector, re-run from the same snapshot, and understand the result card operators see.
A run is one evaluation of one instrument version against one set of inputs. Runs are the evidence trail: every run keeps the version it used, the fingerprint of that version, the fingerprint of its inputs, the engine version, the outputs, the reason codes, and the evaluation trace.
Runs are never edited. A failed run stays failed and stays visible; correcting something means creating a new run.
Where runs come from
| Source | Created by |
|---|---|
| Test vector | You, from the test-vector runner on the instrument detail page. |
| Conversion page | A form submission on a page with an instrument binding. |
| CRM opportunity / CRM contact | A workflow using the Evaluate instrument action. |
The Recent runs table on the instrument detail page shows all of them, newest first, with the run id, status, version, source, reason codes and time.
Test a version before it goes live
The Test vector runner on the instrument detail page evaluates the selected version against inputs you paste as JSON keyed by input id:
{ "Q-01": 3, "Q-02": 4, "Q-03": true }Choose Run inline and the result appears immediately: status, reason codes, engine version, definition hash, input hash, and the workflow-safe outputs.
Test-vector runs are deliberately contained:
- They never touch a CRM record.
- They are stored as test vectors, visible only to people who can view instruments, and retained for 30 days.
- Each click is a genuinely new run, so re-running the same inputs gives you a second run rather than replaying the first.
If the selected version is not published, the runner says so — the platform may refuse to evaluate a draft or retired version.
Read a run in the inspector
Open any run row to reach the run inspector. It is organized around the question "what happened, and can I trust it?"
- Run — run id, result id, status, reason, reason codes, engine version, definition hash, input hash, created / started / completed times, and the correlation and trace ids for support.
- Outputs — every value the instrument produced, including narrative text.
- Workflow-safe outputs — the subset marked safe for workflow: whole numbers, yes/no values and choice codes only. This is the only part other parts of Vertiqa are allowed to consume.
- Trace — the evaluation tree: which rules fired, with what values, and which reason codes they contributed. This is what makes a score explainable rather than merely reproducible. Traces are returned to signed-in people only, and runs created before tracing existed have none.
- Raw result — the outputs as stored, read-only.
Reason codes are the instrument author's own vocabulary (TIE_UNRESOLVED,
BAND_A, LIMIT_EXCEEDED). Vertiqa shows them tidied into sentence case but
never invents a translation the instrument did not agree to — so if the codes
read badly to operators, fix the codes in the definition.
Re-run
Re-run creates a new run from the same stored snapshot of inputs. Use it when a run failed for a transient reason, or when you want the same inputs evaluated by the version that is live now. The original run is untouched; you land on the new one.
Re-run is unavailable once the snapshot has been deleted.
Delete a snapshot
Delete snapshot soft-deletes the stored inputs of a run. It is available to people who can manage instruments and it is audited.
After deletion:
- The run, its outputs and its hashes remain readable.
- Report access, re-running and email delivery for that run are blocked.
- A banner on the run records when it happened.
Use it to honour a data-removal request for the person the inputs describe. It is not an undo for a bad run.
What operators see
On a CRM opportunity that has been evaluated, people working the record see a compact result card — in Simple mode as well as Full mode. It shows only:
- the workflow-safe result values,
- the reason codes as plain phrases under Why,
- the run's state, with a refresh control while it is still running.
It never shows the trace, the hashes, the engine version, or the raw inputs. Those stay in the Full-mode run inspector.
A record that was never evaluated shows nothing at all — that is a fact, not an error. A failed run is shown, because hiding it would be the more dangerous choice.