Runs

See what actually happened

flowchart LR
    Action[Action] --> Run[Run]
    Run --> Artifact[Artifacts]
    Run --> Status[Status]

Runs are the execution record for automation in TrialStack. They show what happened, what is still in progress, and what output or artifacts a workflow produced.

Follow the attempt

A run gives the team a place to inspect:

• status and queue-backed progress
• the execution timeline
• output artifacts and generated results
• the difference between a clean completion, a failure, and an aborted attempt

Use runs for operational review

Open a run when:

• a team needs to inspect one specific execution
• operators need to understand failures, retries, or timing
• reviewers need to decide whether a result is usable

Replay without splitting the record

Replay starts a new execution attempt while keeping the persisted TrialStack run as the stable operational record. The run follows the latest executor attempt and reconciles its displayed status with the persisted action result, so successfully persisted replay output clears a stale failure instead of creating a contradictory duplicate run.

The Runs list, task popover, and run links keep that record together. Opening a popover item goes to the run detail view, while the run still retains the entity and workflow context needed to understand what produced it.

Status shown while reading a run can reflect fresher action, export, or executor evidence before the stored row is repaired. Reading the list or detail view does not itself write workflow state; executor completion, replay, or another explicit recovery action owns durable repair.

The Runs list reconciles active recovery candidates before applying terminal-status and recent-window filters. A run that has finished in the executor therefore remains discoverable in Archived even when its persisted status has not yet been repaired.

Completion is not approval

A completed run only means the execution finished. Teams still need to judge the output quality, decide whether retry is useful, and keep approval decisions in the workflow that actually owns the result.

For structured generation, TrialStack preserves existing values when one generated field or row is unsupported, records a scoped generation finding, and saves meaningful sibling output. If an explicitly requested section contains no meaningful editable output at all, that section and its parent run fail coherently while accepted sibling output and findings remain available for review.

Saved generation provenance follows the governed record after navigation or reload. An AI Generated section badge shows the generation time, presents findings in the same reviewer-facing format as verification results, and links to the originating run when that run is available.

Verification results also remain available after navigation or reload, including a clean result with no open findings. Deterministic authoring findings offer Fix and return reviewers to the exact governed field or row identified in the submitted snapshot. AI-assisted or older findings offer Improve and start the relevant scoped generation flow. Running verification again supersedes deterministic findings that the current canonical content has resolved while retaining the prior result as evidence.