Proof

Proof is a run record, not a claim.

These pages show the delivery record from different angles: one real full-spend run, two recorded demo runs, and screenshots rendered from run artifacts. The point is not a polished demo; it is whether a reader can inspect why the work was accepted or blocked.

01 REAL RUN, FULL RECEIPT

One command. 2h 45m hands-off. Approved, with receipts.

Not a demo: a real engine feature shipped at full spend — 7 review rounds, 5 repair rounds, one P1 caught and fixed, every blocking gate green.

/proof/run-receipt/

02 FALSE-READY, CAUGHT

The worker says done. The gate disagrees.

A live recording: review rejects with a named blocker, the run stays blocked, repair resumes the same record.

/proof/false-ready/

03 CROSS-SYSTEM

One spec. Two repositories. One verdict.

A live recording: a cross run plans once, works per repo, and the contract check judges the boundary.

/proof/cross-system/

04 SIGNAL, NOT PROSE

Typed verdicts over monologues.

Rendered from a run's own artifacts: findings with severity, one-line verdicts, drill-down on demand.

/proof/signal-not-prose/

Docs-backed demos

Selling points with the receipts behind them.

Each recording is hosted on the public documentation site. Symphos gives the buyer reason to care; the linked docs page explains the technical anatomy.

LIVE CLI

The run is readable while it is still alive.

Orcho turns the agent session into an operating surface: envelope, phase map, plan review, implementation, final acceptance and closing receipt.

A reviewer can see the active contract before code changes: profile, workers, verification policy and evidence paths.
Rejected planning rounds stay in the same record instead of becoming lost chat history.
The closing rollup explains what shipped, what it cost and which gates backed the verdict.

Read the live-run guide

Source recording is hosted by the public docs. This page frames the product reason; the docs page explains the stream anatomy.

PLAN GATE

A weak plan can be rejected before code starts.

The value is not a nicer checklist. A gate changes the run state: reject, re-plan, continue, pause or require a human decision.

Plan validation catches unclear scope before an implementation worker mutates the checkout.
Automatic retries are bounded, so control does not quietly turn into an infinite agent loop.
Findings resolve into evidence the final reader can inspect, not a vague memory of review.

Read plan contracts and DAGs

The same recording powers the docs explanation of plan contracts; Symphos uses it to show why review belongs inside control flow.

CROSS-SYSTEM

The delivery unit can be the feature, not the repo.

For cross-system work, Orcho keeps one feature intent while projecting scoped runs into each repository and judging the boundary as one delivery.

API and web workstreams keep their local evidence while the cross-run keeps the shared verdict.
The contract check reads the seam between repositories, where single-repo success often misses product breakage.
Cross final acceptance blocks the set until the delivery, not just one patch, is ready.

Read cross-project projection

The docs page explains the projection model; the selling point is simpler: the product boundary becomes visible.

ANY MODEL

The delivery protocol is not tied to one vendor's model.

This run routed every phase — plan, validation, a four-subtask implementation DAG, review and final acceptance — through a GLM-compatible worker on a non-Anthropic model, and still produced the same contract, gates, attestations and a real pull request.

Runtime identity stays visible in the record: the run reads as glm-5.2, not hidden behind the original CLI name.
Plan contract, per-criterion attestations and the verification gate hold regardless of which model does the work.
It proves portability, not a routing default: spend top-model reasoning where it matters and keep review independent of the author.

Read runtime adapters

The docs page explains the adapter boundary; Symphos uses the same asset to show the protocol is model-neutral end to end.

MCP CONTROL

Your AI client can drive the run without owning the truth.

MCP gives an agent client typed controls over Orcho while Orcho remains the run system of record: start, watch, inspect evidence, return a verdict.

The client operates through typed tools instead of scraping terminal output.
Evidence and diff stay in Orcho, so the client reports on the record rather than replacing it.
The operator still owns the decision while the client handles the mechanics.

Read the MCP front door

This is the agent-client front door: lighter to operate, still backed by the same run record.

RECOVERY

A paused run can resume as the same delivery record.

Long agent work should not restart from a fresh prompt every time a gate pauses or a worker fails. Orcho treats recovery as lifecycle, not cleanup.

Resume starts from the existing run state, not a reconstructed story.
Handoffs preserve the plan, findings, artifacts and human decisions already made.
The next worker sees the same record the reviewer and operator will inspect later.

Read recovery and resume

The technical page covers recovery semantics; the business point is continuity across interruption.

LIFECYCLE

The run gets a contract before action.

Intake is where Orcho turns an operator request into a run envelope: task, project, profile, policy and observable state before work begins.

The first screen tells the reader which profile and verification posture will govern the work.
The lifecycle has named phases, so later review is anchored in state rather than prose.
Every surface can point back to the same run anatomy: CLI, docs, evidence and MCP.

Read the run lifecycle

The docs page teaches the lifecycle. Symphos uses the same asset to show why the contract appears before action.

Start with one task

See the protocol work before reading every layer.

Install the public alpha for a self-serve run, or open the proof hub and inspect why a delivery was approved or blocked.

Open the quickstart Inspect the proof