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