/tribunal

name: tribunal
version: 0.0.3
license: MIT
description: >-
  Runs a doer -> verifier-panel -> consensus loop to verify a deliverable before it ships.
  An orchestrator freezes acceptance criteria before implementation, dispatches a doer, then
  convenes a context-walled panel of independent verifiers - including an adversary with an
  explicit must-oppose mandate - for evidence-anchored review adjudicated to a SHIP /
  SHIP_WITH_CAVEATS / ITERATE / BLOCK / ESCALATE verdict logged to a ledger. Use for
  multi-agent verification of any artifact - code slices, plans, documents, audits -
  whenever asked to verify a deliverable, vet a plan, run a consensus review or independent
  review, set up a doer-verifier loop, or gate a ship decision. Works on any platform with
  parallel subagents; degrades to sequential fresh-context sessions without them; on
  detached, sandboxed or asynchronous runtimes the artifact is handed over by fetchable
  address and the budgets travel in the handoff. Not for trivial single-file edits or
  ordinary code review.

Tribunal

The orchestrator builds nothing and scores nothing itself — it slices the work, dispatches a *separate* doer, convenes *separate* verifiers, and adjudicates on evidence. Three behaviors carry the value: an **adversarial second look** that catches what a single pass ships silently, as named failure scenarios; **calibrated verdicts** — locally fixable defects get ITERATE, not "rewrite everything", and passing math is overridden only by verified evidence; **evidence before claims** — nothing is "done" without fresh reproduction; refuted claims are excluded, never averaged in. Announce at start: "Running this through the tribunal pattern: doer -> verifier panel -> consensus."

When to use

Multi-part or high-stakes deliverables where a shipped defect costs more than a panel. Not for trivial edits, anything one verification command proves, or ordinary code review (dialogue improving a change vs independent measurements of a frozen artifact against pre-declared criteria, adjudicated to a ship decision). Never nest tribunals — no role runs the protocol on its own output.

The loop

1. Freeze acceptance criteria and verification commands BEFORE implementation; derive scoring dimensions, weights, and a pass target from them, recorded so re-panels reuse the rubric. Identify the operative skills in play — those bearing on how the artifact is built or judged (e.g. production-grade); never the tribunal skill itself nor pure orchestration skills — and fold their standards into the criteria. Verify-only entry (artifact already exists): write criteria from the original request — never reverse-engineered from it — freeze, start at step 3. 2. Spawn a SEPARATE doer agent (never the orchestrator itself) with the full slice spec pasted in (never "read the plan file") and the operative skills named with an instruction to load them (load production-grade, etc.) — if it cannot load a named skill it says so rather than proceeding. If the orchestrator writes or edits the deliverable, there is no independent artifact to verify and the run collapses to one context. The doer implements, runs the verification commands, materializes the artifact durably — committed, pushed, or published so it outlives the doer's session — and reports a diff summary, verbatim output, the artifact's fetchable address, and exactly one status (table below). DONE without an address is not DONE. 3. Check the report against the actual diff yourself; dispatch the panel in parallel, context-walled. 4. Adjudicate per [consensus-mechanics.md](references/consensus-mechanics.md); record verdict, dissents, caveats, and round count in the ledger. 5. SHIP -> next slice. ITERATE -> findings become a fix list for a fresh doer; re-panel with fresh verifiers re-scoring every dimension, prior findings as risks.

Invariants (low freedom — these are the skill)

1. **Context wall.** Four roles, four separate sessions: the orchestrator (slices, dispatches, adjudicates, owns the ledger — produces NO deliverable content and assigns NO scores itself), the doer, and each verifier. One agent never plays two roles (shared context = shared blind spots = no triangulation, the entire point). The doer finishes first; then the verifiers run in parallel, each RECEIVING exactly: frozen criteria; the artifact by **fetchable address** — a commit SHA, branch, or URI a verifier in a *different* sandbox can retrieve on its own, plus the diff (or the document and its predecessor) inline; bare working-tree paths are insufficient, since they resolve only inside the doer's session and die with it; reference materials; permission to run the verification commands; known risks; the operative skills (named, to load). Verifiers NEVER receive: the doer's reasoning or self-assessment, design rationale, each other's first-round views or identities, expected or prior scores. Naming shared standards is not a wall breach — the wall withholds the doer's reasoning and scores, not the bar everyone is measured against. 2. **Evidence anchoring.** High scores require a verbatim quote from the artifact; failure claims require file:line or command output; evidence-free findings are discarded. Before any consensus math the orchestrator greps every verdict-driving citation against the artifact and spec: a quote that cannot be located verbatim discards its finding; factually refuted scores are EXCLUDED and logged as refuted dissent. Adjudicate on evidence — never average disagreement away. 3. **Explicit opposition.** At least one panel member must oppose: build the strongest case against shipping as NAMED failure scenarios (which input, what wrong behavior). Attack vectors: hidden assumptions; over-engineering hiding bugs; missing constraints; drift risk; spec gaps; composition fragility. Generic skepticism is worthles