Council of High Intelligence Chairman Selection Algorithm: 4-Tier Priority Logic

The chairman selection algorithm follows a strict four-tier priority hierarchy—explicit CLI override, config file override, auto-selection from a non-panel provider, and single-provider fallback—to designate the synthesis model during STEP 1.7 of the coordinator protocol.

The 0xNyk/council-of-high-intelligence repository implements a deliberation protocol where multiple models analyze a prompt before a single Chairman synthesizes the final verdict. This selection process is not random; it is governed by a deterministic algorithm defined in SKILL.md and configured via configs/auto-route-defaults.yaml, ensuring the synthesis model ideally brings a distinct training bias compared to the deliberation panel.

Understanding the Chairman Role

In the council’s architecture, the Chairman is the dedicated model responsible for the final synthesis step (Step 6), occurring after the initial deliberation rounds (Steps 1-5). By design, the Chairman does not participate in the analysis rounds, creating a separation between deliberation and verdict generation. A hard constraint generally forbids the Chairman from sharing a provider with panel members to ensure diverse reasoning perspectives, though this rule is relaxed in single-provider environments.

The 4-Tier Selection Algorithm

The coordinator applies these rules in strict order; the first matching condition determines the Chairman.

Tier 1 – Explicit CLI Override

The highest priority is given to user input via the --chairman command-line flag. If supplied, the coordinator uses the specified provider tag or model alias directly.

Valid inputs include provider tags (anthropic, openai, google, ollama, nvidia_nim, cursor_cli) or specific model aliases (opus, sonnet, gpt-5.4, gemini-2.5-pro). This logic is implemented in STEP 1.7 of the protocol as documented in SKILL.md (lines 35-38).

# Explicitly designate Gemini 2.5 Pro as the Chairman

council --chairman gemini-2.5-pro

Tier 2 – Configuration File Override

If no CLI flag is present, the system checks configs/auto-route-defaults.yaml for a non-null chairman: block. When defined, this configuration statically assigns the provider and model, bypassing the auto-selection logic entirely.

According to SKILL.md (lines 38-39), the coordinator adopts these values immediately upon detection of the configuration block.

Tier 3 – Auto-Select from Distinct Provider

In the absence of overrides, the default auto-selection activates. The algorithm selects the highest-tier model available from a provider that is not already represented on the deliberation panel. This ensures the synthesizing model offers a fresh perspective.

Tier mappings (e.g., high → opus, sonnet) are defined per provider in configs/auto-route-defaults.yaml (lines 30-36). If multiple providers offer the same highest tier, the tie is broken by the provider order in the detection JSON.

Tier 4 – Single-Provider Fallback

When the system detects only one provider (e.g., an Anthropic-only setup), the algorithm defaults to the highest-tier model of that sole provider. In this scenario, the Chairman inherently shares a provider with panel members, and the verdict metadata notes this constraint. This fallback is described in SKILL.md (lines 39-41).

Configuration and Tier Mappings

The configs/auto-route-defaults.yaml file defines the default tier mappings and optional static overrides. The coordinator references this file to resolve model tiers during the auto-selection phase.

# configs/auto-route-defaults.yaml structure

chairman:
  provider: openai
  model: gpt-5.4

providers:
  anthropic:
    tiers:
      high: opus
      medium: sonnet
  openai:
    tiers:
      high: gpt-5.4

Practical Implementation Examples

The following commands demonstrate how the four-tier algorithm behaves in practice:

1. Explicit Override via CLI

council --chairman opus

2. Config Override via YAML Configure configs/auto-route-defaults.yaml as shown above, then run:

council

3. Auto-Select (Multi-Provider) With no flags and no config block, auto-select triggers:

council

# Selects highest-tier model from a provider not on the panel

4. Single-Provider Fallback In a Claude-only environment:

council

# Automatically selects Anthropic's `opus` model

Constraints and Metadata Recording

The selection algorithm operates under strict operational constraints. The chosen Chairman is strictly excluded from deliberation rounds (Steps 1-5) to prevent circular reasoning. Upon selection, the system records the choice in the verdict metadata using the format Chairman: <name> (<provider>), as implemented in SKILL.md (lines 54-57).

Summary

• The chairman selection algorithm is a deterministic, ordered priority system defined in SKILL.md STEP 1.7.
• Priority order: CLI flag (--chairman) → Config file (chairman: block) → Auto-select (distinct provider) → Single-provider fallback.
• Auto-selection prefers the highest-tier model from a provider not present on the panel, using tier mappings from configs/auto-route-defaults.yaml.
• Single-provider setups relax the distinct-provider constraint, selecting the highest-tier available model.
• Selection is recorded in verdict metadata as Chairman: <name> (<provider>).

Frequently Asked Questions

How do I force a specific model to become the Chairman?

Use the --chairman command-line flag followed by the model alias or provider name. For example, council --chairman sonnet explicitly designates Anthropic’s Sonnet model for synthesis, bypassing all automatic selection logic.

Can the Chairman be the same model as a panel member?

Normally, no. A hard constraint prevents the Chairman from sharing a provider with deliberation members to ensure cognitive diversity. However, in single-provider environments, this constraint is automatically relaxed, and the highest-tier model of that provider assumes the Chairman role.

How are model tiers defined for the auto-selection algorithm?

Tiers are defined in configs/auto-route-defaults.yaml. Each provider entry maps tier labels (e.g., high, medium) to specific model aliases. The coordinator uses these mappings to identify the "highest-tier" model when executing the Tier 3 auto-selection rule.

Where is the chairman selection logic documented in the source code?

The algorithm is explicitly defined in SKILL.md between lines 29-41, which describes STEP 1.7 of the coordinator protocol. The tier mappings and optional configuration overrides are specified in configs/auto-route-defaults.yaml (lines 30-36).

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}