Read the result

This is the third way to observe a run: after it finishes. While the run is active, the live CLI stream is the strongest surface — use it first.

Afterwards, Orcho records the run state in artifacts. Use orcho status and orcho evidence to inspect the recorded result without replaying the whole terminal stream.

Before reading artifacts, check the profile. A result only makes sense against the workflow it promised to run: which phases were expected, which gates could block, and what evidence had to exist before final acceptance.

Start with the profile

The profile answers:

what kind of run this was;
which phases were expected;
which gates were allowed to reject;
what evidence should exist;
whether a rejection means repair, correction follow-up, or operator decision.

Without that layer, status and evidence look like logs. With it, they become a delivery decision.

Use status as the index

orcho status

Status answers:

which run is current;
whether it is running, done, halted, failed, or awaiting a decision;
which phases completed;
what the next action likely is.

Status is not meant to be the most compelling demo surface. It is the fastest way to locate the current run and understand its terminal state.

Use evidence as the recorded explanation

orcho evidence --format md

Evidence answers:

what plan was accepted;
which commands were run;
what findings were raised;
which receipts exist;
where artifacts live on disk.

Evidence is the durable explanation layer. It matters for review, handoff, and later recall, but it should not replace the live output as the first way to understand Orcho.

Real attestation excerpt

For implementation-heavy runs, look for the subtask attestation. It connects the work back to the accepted contract:

ORCHO subtask 1/1 ATTESTATION (met): T1
7/7 done-criteria met

  ✓ derive_effective_policy does not accept cheap.
  ✓ mode × tier table is implemented as specified.
  ✓ dead cheap plumbing was removed from blocking policy.
  ✓ tests were reconciled in place and guard tests were added.
  ✓ plugin.py declares tier and cost explicitly.
  ✓ docs and ADR match the code.
  ✓ ruff and targeted pytest are green.

Implementation
  progress  1/1 subtasks done
  files     5 changed
  summary   subtask T1 ok

This is the bridge between “the agent said it finished” and “the run can show which done criteria were actually satisfied.”

Inspect the project diff

git diff

The diff tells you what changed. Evidence tells you why the system believes the change is or is not ready.

If a run rejects

A rejected run is not failure theater. It is useful information.

When final acceptance rejects, Orcho should expose the blocker and the recovery path. In many cases the correct next move is a correction follow-up, not a blind resume.

Read Correction follow-ups next.