Guild Stack

Run ledger · Illustrative contract

Trust the run record, not the recap.

A completed route leaves its starting contract, frozen settings, lane receipts, review result, verification, and provenance under .guild/runs/. The example shown here illustrates the contract shape, not a customer run.

Inspect run anatomyFollow the illustrative demo

Page evidence

.guild/runs/<run-id>/

Run directory

  1. .guild/runs/run-8f3c/run.yaml start manifest, task, host, phase
  2. resolved-settings.json frozen host, substrate, rigor, review, tiers
  3. logs/v1.4-events.jsonl canonical trace, local by default
  4. handoffs/<lane>.md specialist receipt, assumptions, changes, evidence
  5. review/<gate>/ packet, result, trail, and independence status
  6. quality/ + ops/ release-readiness verdict and runbook records when those phases run
  7. verify.md done-gate evidence
  8. provenance.json close-shape, gates, touched files, benchmark eligibility

Canonical trace

One line, tied to its run.

logs/v1.4-events.jsonl is the single canonical trace, one JSON object per event. Raw traces and payloads stay local by default; the canonical log is never in the shareable set.

Trace event

guild.trace_event.v1

The benchmark engine analyzes the trace; the plugin records it. Neither imports the other.

event
The discriminator, one line of the frozen 12-event v1.4 vocabulary.
ts + run_id
Carried by every event, so any line ties back to its run.
span_id + tier + model + tokens
Additive v2 fields on LLM-call events; pruned when undefined.
terminator
Why the round ended: satisfied, cap_hit, escalation, or error.

Review, paired

A packet in. A bound decision out.

Review packets and results are paired records, not loose feedback. The loop stays inspectable because each verdict points back to scope, artifact evidence, independence posture, and blocking findings.

Review decision

map / active

Challenge the bound artifact, then route the verdict.

  1. 01 / PacketBind scope + artifactChecksum, evidence, reviewer posturereview packet
  2. 02 / ChallengeTest the current workCross-host when available; weaker modes recordedreview result
  3. 03 / DecideBlock or satisfyFindings route to rework; satisfaction advancesverdict + trail
  4. 04 / VerifyProve doneRun checks against the final diffverify.md
Blocking findings return to bounded rework. A satisfied result advances to verification with the review trail intact.

Two phases, kept apart

Release readiness is not task done.

Quality selects checks from on-disk signals and computes release readiness. Operations records runbooks, dry-runs, incident plans, and rollback readiness. Both are separate from the per-run done gate.

Operational mapDone, release ready, and safe to operate answer different questions.
Quality
  1. discover harnesses
  2. run selected checks
  3. release verdict
Operations
  1. prepare runbook
  2. dry run + rollback
  3. approval record
Verification
  1. reopen scope
  2. trace lane evidence
  3. verify.md

One gate cannot silently promote another. Each result remains separately inspectable.

Task done, release ready, and operations approval remain separate gates.

Source pages

Read the contracts behind the proof surfaces.

Doc

Observability

The run-lifecycle contract, trace boundary, payload privacy, and replay/export model.

Doc

Adversarial Review

How review packets, rounds, independence status, and verdict trails work.

Doc

Quality and Operations

How release readiness, runbooks, incidents, rollback, and hard approval gates stay distinct.

Next

See these artifacts in a narrative run.

The demo route follows one run from a loose request to the same inspectable record.
Open demoBrowse docs