Multi-LLM Deliberation Policy

Scope: All M3 (Deliberation Chamber) sessions. Governs when Chamber can be invoked, how panelists are queried, how arbitration occurs.

Governance: Operates under Constitution. Primary Laws: 5 (Human Veto), 6 (Decision Trace), 7 (Verify), 8 (Tokens are Capital).

Invocation Rules

When Chamber is appropriate

• Strategic decisions with genuine uncertainty (not just “I’m curious”)
• Questions where single-model bias is a material risk
• Cross-domain questions where different training data matters
• High-stakes decisions where multi-source validation adds value

When Chamber is NOT appropriate

• Factual questions with clear authoritative answers (use web search instead)
• Routine development tasks (use Claude Code or Claude directly)
• Questions requiring real-time data (LLMs have stale knowledge; use tools)
• Questions where cost of Chamber ($0.30-1.20) exceeds value of answer
• Questions where founder already has strong conviction (confirmation bias risk)

Approval requirement

Every Level 3 Chamber session requires explicit founder approval. See CriticalityPolicy for the Level 2 auto-quorum exception (reversible decisions, mandatory post-factum trace).

• Pipeline agents propose but cannot commit (Level 3)
• Approval must be in chat interface, not inferred
• Approval is per-session, not blanket
• Founder sees estimated cost before approving

Panelist Query Rules

• All panelists receive identical question + context
• No panelist is told what others said in Phase 1 (independent responses)
• Panelists are NOT instructed to agree or disagree — neutral framing
• Panelist system prompt includes: “Your task is to provide your best independent answer. Do not moderate your view to match expected consensus.”

Divergence Detection

Cross-examination triggered if any of:

• Panelist stances differ (yes/no, go/no-go)
• Confidence scores vary by >30%
• Panelists cite materially different primary evidence
• Arbiter’s initial assessment flags meaningful disagreement

Cross-examination limited to one round. Infinite deliberation loops forbidden.

Arbitration Rules

Arbiter’s mandate

The arbiter does NOT:

• Vote (“Claude’s answer is correct”)
• Average (“split the difference”)
• Default to majority (“2 vs 1 so majority wins”)
• Default to consensus (“all agree so the answer is X”)

The arbiter DOES:

• Evaluate evidence quality per position
• Distinguish surface disagreement (different wording, same substance) from substantive disagreement
• Return honest uncertainty when warranted
• Preserve minority viewpoints in output
• Document reasoning for synthesis decisions

Conflict of interest mitigation (Claude as arbiter)

Since Claude is both panelist and arbiter:

• Arbiter system prompt explicitly addresses: “You will see your own earlier response as Panelist. Do not favor it for that reason.”
• Arbiter output includes self-check: “Am I giving Claude-panelist’s view undue weight?”
• Periodic founder review of arbitration patterns — if Claude-panelist view wins >50% of arbitrated cases, re-evaluate arbiter choice

Audit Trail (Constitution Law 6)

Every session preserves:

• Exact question and context
• Verbatim panelist responses (all phases)
• Divergence detection evaluation
• Cross-examination responses (if occurred)
• Arbiter reasoning
• Final synthesized answer
• Founder’s subsequent action (accepted / revised / rejected)
• Session cost breakdown per panelist
• Session duration

Storage: same as other Synth Nova artifacts per ObservabilityContract.

Rate Limits and Cost Control (Constitution Law 8)

• Maximum 10 Chamber sessions per day (prevents runaway costs)
• Per-session cost cap: $3.00 (hard stop; abort if session approaches)
• Monthly Chamber budget: $100 (reviewed quarterly)
• Every session’s cost logged and tracked against budget

When budget approaching limits — founder notified, not silent blocking.

Honesty Principles

Arbiter must return uncertainty when warranted

If panelists genuinely disagree with high confidence on all sides, arbiter must report: “Chamber could not reach arbitrated consensus. Three qualified perspectives disagree substantively. Founder review recommended.”

This is a valid outcome, not a failure. Forcing synthesis when panelists disagree produces bad advice.

No hidden model changes

If a panelist API returns an unexpected model version (e.g., GPT-4 upgraded to GPT-5 mid-session), log and notify. Never silently substitute models.

Disclosure of arbiter identity

Final report explicitly states arbiter was Claude Sonnet 4. Do not present arbitrated answer as anonymous “panel consensus” — be honest about synthesis authorship.

Criticality Assessment

Pipeline agents MUST evaluate criticality per CriticalityPolicy before deciding whether to invoke Chamber and at which level. The three levels are:

• Level 1 — agent resolves alone, no Chamber
• Level 2 — auto-quorum Chamber, no founder
• Level 3 — full-quorum Chamber with founder participation

Agents do not independently decide to “skip” Chamber when Level 2 or Level 3 criteria fire. Criticality assessment is enforceable policy, not advisory heuristic. See CriticalityPolicy §Criticality Assessment Procedure for the four-step evaluation and the audit.criticality_assessment log format. Invocation is governed by EscalationPolicy Trigger 7.

Auto-Quorum Rules (Level 2)

Chamber can run without founder approval for decisions that meet Level 2 criteria per CriticalityPolicy. Rules specific to Level 2 sessions:

• Trigger: any Level 2 criterion fires (confidence between 0.5 and 0.8, non-exclusive agent disagreement, estimation/forecast where reasonable models can legitimately disagree) AND no Level 3 criterion fires.
• Panel: identical v1 panel (Claude Sonnet 4.5, GPT-4o, Gemini 2.5 Pro) per ADR-0015-m3-chamber-implementation.
• Resolution rule: arbiter confidence ≥ 8/10 → auto-accept, pipeline continues. Arbiter confidence < 8/10 → auto-escalate to Level 3 (the threshold itself is the escalation trigger — this is not “no consensus,” it is a deterministic rule).
• Trace (mandatory, Law 6): full session artifact is written for every auto-quorum session. Founder can review any Level 2 session post-factum. The trace includes arbiter confidence explicitly so escalation-triggered sessions can be audited for threshold correctness.
• Budget: Level 2 sessions count against the same per-session cap ($3),dailylimit(10sessions/day),andmonthlybudget($100) defined in §Rate Limits.
• Constitutional basis: Law 5 (Human Veto) applies to irreversible decisions. Level 2 scope is restricted to reversible decisions (estimates, forecasts, sizing). Law 1 (Founder Interests First) and Law 6 (Trace) are satisfied via the post-factum review mechanism.

Level 2 is not a loophole for avoiding founder oversight. It is a narrow carve-out for the class of decisions where blocking on founder input provides no marginal safety and introduces real cost (pipeline latency, founder attention).

Founder Participation Rules (Level 3)

When a Level 3 session runs, the founder participates actively in one of four roles per CriticalityPolicy §Level 3 (Approver / Challenger / Contributor / Verifier). This section defines the operational rules for the Contributor and Verifier modes, where the founder’s input materially shapes the arbiter’s synthesis.

Structured founder input

In Contributor and Verifier modes, founder input follows the same schema as a panelist response:

• Stance — the founder’s position on the question (e.g., “lean GO”, “lean NO-GO”, “defer pending X”)
• Reasoning — why, in the founder’s own words (free text, not required to cite sources)
• Confidence — founder’s self-reported confidence (1-10), same scale as panelists
• Optional evidence pointers — any artifacts, past conversations, or external sources the founder wants the arbiter to weight

Structured input is captured in the session artifact under a dedicated founder_input field so the audit trail is explicit about where the founder’s voice entered the synthesis.

Arbiter treatment of founder input

The arbiter’s system prompt is extended for Level 3 sessions with the following clause:

You will also see the Founder’s input. Treat it as an informed domain expert’s perspective — give it appropriate weight but do not automatically defer to it. Your job is still to evaluate evidence quality. If the Founder’s reasoning is strong and verifiable, weight it accordingly; if it rests on intuition without evidence, say so and preserve the panel’s view alongside. The Founder can accept, revise, or reject your synthesis downstream — your job is to produce the best honest synthesis, not to predict what the Founder wants to hear.

This clause is stored verbatim in the arbiter prompt template (not regenerated per session) so behavior is auditable and stable across sessions.

Interaction with Challenger and Verifier modes

• Challenger mode — founder’s input triggers an agent re-run (new data fetch on a specified aspect), then the quorum re-runs with updated context. Up to two challenge rounds before the session must resolve to GO / NO-GO / NEED MORE DATA.
• Verifier mode — founder’s claim is treated as a hypothesis to verify, not as evidence. Agents fact-check via sources; the verified-or-falsified result feeds into the quorum as normal evidence, not as founder voice. The founder’s original claim and the verification outcome are both preserved in the trace.

Trace

The session artifact includes founder_role (one of: approver, challenger, contributor, verifier) and founder_action (one of: accepted, revised, rejected, challenged, contributed, verified). These fields are required for every Level 3 session.

Cross-References

• Constitution: Constitution — supreme governance
• Module M3: Deliberation-Chamber-Module — primary consumer of this policy
• CriticalityPolicy: CriticalityPolicy — three-level decision classification driving Chamber invocation
• EscalationPolicy: EscalationPolicy — Trigger 7 (Chamber Escalation)
• ObservabilityContract: ObservabilityContract — storage and retention
• DecisionRights: DecisionRights — approval escalation rules
• Integration Triage Policy: IntegrationTriagePolicy — LLM provider additions
• ADR-0014: ratification of M3 + this Policy
• ADR-0015: v1 implementation record
• ADR-0016: Chamber v2 vision (criticality levels, founder participation)