Synth Nova Manifest

ADR-0016: Chamber v2 Vision — Criticality Levels, Founder Participation, Go/No-Go

9 min read

ADR-0016: Chamber v2 Vision — Criticality Levels, Founder Participation, Go/No-Go

Status

accepted

Context

ADR-0014-m3-deliberation-chamber ratified the strategic decision to build Module M3 (Deliberation Chamber) as a structured multi-LLM deliberation primitive. ADR-0015-m3-chamber-implementation recorded the v1 implementation — a CLI tool with three panelists (Claude Sonnet 4.5, GPT-4o, Gemini 2.5 Pro), Sonnet-4.5 arbitration, and explicit founder approval gating every session per Constitution Law 5.

v1 is shipped and working. During and after the v1 build, the founder articulated a deeper vision for Chamber’s role in the product: Chamber should not be a standalone tool sitting beside the Investment Navigator. It should be the resolution mechanism the Investment Navigator falls into whenever a pipeline question is uncertain enough to warrant multi-model scrutiny, and it should integrate the founder as an active participant — not just an external approver — for the decisions that matter most.

Three concrete shifts were required:

  1. Criticality tiering. v1 treats every Chamber-eligible question identically (founder approves → session runs). In practice, pipeline questions fall into a distribution: many are factual and deterministic (no Chamber needed), many are uncertain-but-reversible estimates (Chamber is valuable, but blocking on founder approval adds latency without marginal safety), and a smaller set are strategic, irreversible, or reputationally significant (founder participation is essential). A single policy cannot serve all three classes.
  2. Founder-as-participant. v1’s founder role is binary: approve the session up-front, read the output, take action. This is sufficient for many questions but too coarse for the ones where the founder has domain knowledge the panel lacks, or wants to challenge the panel’s data inputs before accepting synthesis. The founder’s actual working mode is richer — accept, challenge, contribute, verify — and the system should represent that.
  3. Go/No-Go as the ultimate output. The Investment Navigator’s job is to decide whether to enter niches. Chamber is the natural place for that decision to crystallize, with three valid outcomes (GO / NO-GO / NEED MORE DATA) rather than a forced binary. Production experience (BADs Russia at -302% ROI on estimated cost inputs) showed that NEED MORE DATA is a real and necessary outcome.

This ADR captures the v2 vision. Implementation is scoped to a separate sprint. What’s ratified here is the policy envelope: criticality levels, founder participation model, Go/No-Go outcomes, and the partial supersede of ADR-0014’s “System never auto-delegates” clause.

Decision

Expand Chamber from a standalone CLI primitive to an embedded decision mechanism inside the Investment Navigator, governed by a three-level criticality policy and a four-role founder participation model.

Specific commitments:

  1. New policy ratified. CriticalityPolicy defines three levels:
    • Level 1 — agent auto-resolves (no Chamber), gated by five AND-conditions
    • Level 2 — Chamber auto-quorum runs without founder; auto-accept at arbiter confidence ≥ 8/10, auto-escalate to Level 3 at < 8/10; mandatory trace for post-factum review
    • Level 3 — full Chamber with founder participation; always required for Go/No-Go, irreversible decisions, reputational/legal exposure, or when arbiter confidence threshold is missed
  2. Founder participation model. For Level 3 sessions, the founder operates in one of four roles: Approver, Challenger, Contributor, Verifier. Operational rules (structured input schema, arbiter prompt extension, Challenger round limits, Verifier fact-checking flow) are defined in MultiLLMDeliberationPolicy §Founder Participation Rules.
  3. Go/No-Go outcomes. Every Go/No-Go decision is Level 3. Three valid outcomes: GO, NO-GO, NEED MORE DATA. NEED MORE DATA is a first-class outcome that protects against both false-GO (acting on bad data) and false-NO-GO (rejecting on insufficient data).
  4. Partial supersede of ADR-0014 §3. ADR-0014’s clause “System never auto-delegates” is narrowed. It remains true for Level 3 (founder approval explicitly required per MultiLLMDeliberationPolicy §Approval Requirement as edited). It is superseded for Level 2: the system auto-invokes Chamber without founder approval when Level 2 criteria fire. This narrowing is constitutionally justified because Level 2 scope is restricted to reversible decisions (estimates, forecasts, sizing) — Law 5 (Human Veto) applies to irreversible decisions and is not triggered at Level 2. Law 6 (Trace) and Law 1 (Founder Interests First) are satisfied via mandatory post-factum review. ADR-0014 itself is not edited (ADRs are immutable records); this ADR is the amendment of record.
  5. Pipeline integration. Pipeline agents (Scout, Researcher, Financial Modeler, Judge) evaluate criticality per CriticalityPolicy §Criticality Assessment Procedure at every decision point and invoke Chamber via EscalationPolicy Trigger 7. Criticality assessment is enforceable, not advisory.
  6. UI integration. Chamber becomes a tab in app.synth-nova.com (the Streamlit app hosting the Investment Navigator). The tab renders auto-populated context, streaming panelist responses, divergence analysis, the founder-input field for Level 3, arbiter synthesis, and the inline report.
  7. Context auto-population. When Chamber is triggered from the pipeline, session context is assembled automatically from Researcher findings, Financial Model data, Judge assessment, and prior Chamber sessions on the same niche. The founder does not manually formulate the context.

Alternatives Considered

Option A: Keep CLI-only, no pipeline integration

  • Pros: no UI work; no pipeline integration work; v1 is already shipped.
  • Cons: courier work persists (founder must manually open Chamber with formulated question + pasted context); Chamber remains a tool rather than a product mechanism; no scalable way to apply criticality-based routing.

Option B: Simple Streamlit page without pipeline integration or criticality tiers

  • Pros: easier than full embedded system; moves off CLI.
  • Cons: solves the UI problem but not the policy problem. Without criticality tiers, every session still blocks on founder approval — either inviting Chamber on trivial questions (Law 8 waste) or requiring manual judgment calls about when Chamber is worth it (inconsistent, unauditable). Without pipeline integration, context auto-population and agent-initiated escalation are impossible.

Option C: Full embedded system with criticality levels and founder participation ← chosen

  • Pros: matches founder’s actual working model; scales cleanly across pipeline (Level 1 stays cheap; Level 2 removes founder-approval latency on reversible questions; Level 3 preserves full oversight for high-stakes decisions); Go/No-Go outcomes are first-class; context auto-population removes courier work end-to-end; constitutional envelope remains tight (Law 5 is narrowed only where reversibility justifies it).
  • Cons: new policy document (CriticalityPolicy); amendments to MultiLLMDeliberationPolicy, EscalationPolicy, DecisionRights; implementation sprint required for UI and pipeline hooks; partial supersede of ADR-0014 requires clear documentation (this ADR). Founder must choose role per Level 3 session (small interaction cost).
  • Why chosen: the founder’s stated vision. The constitutional analysis supports it (Level 2 auto-quorum is compatible with Law 5 because scope is restricted to reversible decisions; Laws 1/6/8 are satisfied by mandatory trace and budget controls). The alternative of keeping all Chamber invocation manual does not scale to pipeline integration.

Consequences

Positive:

  • New policy artifact: CriticalityPolicy — three-level decision classification.
  • Updated operational artifacts: MultiLLMDeliberationPolicy (Criticality Assessment, Auto-Quorum Rules, Founder Participation Rules sections added; Approval Requirement narrowed to Level 3).
  • Updated governance artifacts: EscalationPolicy (Trigger 7 added); DecisionRights (three Chamber rows added).
  • Chamber becomes scalable — pipeline questions route to the right resolution tier without manual judgment per question.
  • Founder attention preserved for Level 3 decisions; not consumed on Level 2 reversibles.
  • Auditable: every Level 2 session writes the same full artifact a Level 3 session does, so post-factum review is complete.

Negative / Trade-offs:

  • v1 is implemented as CLI-only; v2 requires a UI sprint (Streamlit Chamber tab) and a pipeline-integration sprint (agent hooks for criticality assessment, auto-invocation, context auto-population). Neither is scoped in this ADR.
  • Level 2 auto-quorum introduces a new failure mode: an auto-quorum session that arbitrates incorrectly on a decision the founder would have disagreed with. Mitigations: (a) the < 8/10 threshold auto-escalates to Level 3; (b) mandatory post-factum review; (c) any Level 2 session can be re-opened as Level 3 if founder flags it during post-factum review.
  • Criticality assessment is a new agent responsibility. Misclassification (Level 3 question routed to Level 2) would bypass founder oversight on a decision that warranted it. Mitigations: explicit enumeration of Level 3 triggers in CriticalityPolicy; bias toward upward escalation under Law 9; monthly audit of classification distribution.
  • Partial supersede of ADR-0014 §3 complicates the governance history (readers must check both ADR-0014 and ADR-0016 to understand current auto-delegation policy). Mitigation: this ADR explicitly names the narrowed clause and the reason; the amendment is recorded in MultiLLMDeliberationPolicy §Approval Requirement with an inline cross-reference to CriticalityPolicy.

Mitigations (cross-cutting):

  • Post-factum review mechanism ensures Level 2 decisions remain reversible in practice, not just in theory.
  • Rate limits and budget caps from MultiLLMDeliberationPolicy §Rate Limits apply identically to Level 2 and Level 3 sessions — auto-quorum cannot run away with capital.
  • COI monitoring (Claude-as-arbiter) from MultiLLMDeliberationPolicy continues to apply; Level 2 volume may accelerate data collection for the periodic audit.

Follow-ups

  • UI sprint: implement Chamber tab in app.synth-nova.com (Streamlit), including Level 3 founder-input field with role selector.
  • Pipeline integration sprint: implement criticality assessment hooks in Scout, Researcher, Financial Modeler, Judge; audit.criticality_assessment log format; context auto-population for pipeline-triggered sessions.
  • Arbiter prompt update: add Level 3 Founder-input clause (verbatim text from MultiLLMDeliberationPolicy §Founder Participation Rules) to the arbiter prompt template.
  • Session artifact schema extension: add level, founder_role, founder_action, founder_input fields.
  • Post-factum review UI: allow founder to open any completed Level 2 session and inspect the full trace.
  • Classification distribution audit: monthly review of Level 1 / 2 / 3 distribution; flag misclassification candidates.
  • Update _Constitution_gaps if any gap surfaces during implementation.

References

Graph View

Backlinks