tribunal

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; 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.