How Polarity Pairs Force Genuine Disagreement Between Council Members

Polarity pairs guarantee authentic debate by hard-coding opposing council members to run on different LLM providers, preventing a single model from simply reframing the same underlying reasoning.

The council-of-high-intelligence repository implements polarity pairs as a core architectural device to ensure genuine disagreement. Each member's YAML front-matter declares a polarity (its guiding paradox) and polarity_pairs (specific opposing members), while the coordinator enforces a strict separation rule that routes paired members to distinct model families like Claude versus OpenAI.

Declaring Polarity Pairs in YAML Front-Matter

Every council member defines its dialectical stance through metadata in its agent file. Members declare their opposites via the polarity_pairs field, establishing who they must argue against when assembled.

For example, in agents/council-watts.md at line 11, the member declares:

# agents/council-watts.md

name: council-watts
description: "Council member..."
polarity: "Dissolves false problems"
polarity_pairs: ["torvalds", "socrates"]   # ← declares opposing members

This declaration creates a network of forced disagreements. When council-watts sits on a panel with either torvalds or socrates, the coordinator recognizes them as a polarity pair and triggers the separation protocol.

The Hard Constraint: Polarity Pair Separation

The enforcement mechanism lives in SKILL.md between lines 186 and 199. Here, the coordinator applies a non-negotiable rule called Polarity pair separation:

1. **Polarity pair separation** (hard constraint): For any polarity pair where both members are on the panel,
   assign them to different providers. Check the `council.polarity_pairs` field in each member's frontmatter.
2. **Provider spread** (hard constraint): Distribute members across available providers as evenly as possible.

This rule mandates that paired members cannot share the same underlying LLM stack. If one member runs on Claude, the other must run on OpenAI or a cross-family Cursor model. Because each provider possesses distinct inductive biases and training distributions, the paired members generate truly orthogonal reasoning rather than cosmetic variations of the same conclusion.

How the Polarity Pair Enforcement Pipeline Works

The mechanism operates through four distinct stages when assembling a council:

1. Declaration – Each member's front-matter lists its opposite(s) via polarity_pairs (e.g., council-watts.md line 11).

2. Selection – When the --duo flag or an explicit --members list picks a pair, the coordinator checks the council.polarity_pairs field.

3. Enforcement – The Polarity pair separation rule (lines 198-199 in SKILL.md) mandates that the two members be placed on distinct providers.

4. Result – Different model families produce divergent reasoning styles, guaranteeing a genuine debate that surfaces conflict, trade-offs, and richer insight.

This structural tension prevents scenarios where a single model simply reframes the problem. For example, when Socrates (who destroys assumptions) pairs with Feynman (who rebuilds from first principles), their disagreement stems from fundamentally different cognitive architectures rather than prompt-engineered opposition.

Running a Polarity Pair Dialectic

You can trigger this enforced disagreement through the command line interface.

Use the built-in duo mode to let the coordinator auto-select a polarity pair:

# Auto-selects a polarity pair and routes them to different providers

council --duo "Should we ship the beta this week or wait for the security audit?"

Explicitly specify a polarity pair to force specific opposites:

# Force the Torvalds ↔ Musashi pair (ship-now vs. strategic timing)

council --duo --members torvalds,musashi "Should we ship the beta this week?"

The coordinator validates the council.polarity_pairs metadata before execution, ensuring that torvalds and musashi route through different provider APIs even if the user manually specifies them.

Summary

• Polarity pairs are declared in YAML front-matter using the polarity_pairs field, creating a network of forced oppositions between council members.
• The Polarity pair separation rule in SKILL.md (lines 186-199) acts as a hard constraint that routes paired members to different LLM providers.
• Provider spread complements this by balancing the panel across available model families like Claude, OpenAI, and Cursor.
• Running the --duo flag automatically selects and enforces polarity pairs, ensuring genuine disagreement rather than echo-chamber consensus.
• Different model inductive biases guarantee that paired members generate truly divergent arguments, surfacing dialectical tension and deeper insights.

Frequently Asked Questions

What happens if two polarity members accidentally route to the same provider?

The coordinator treats Polarity pair separation as a hard constraint. According to the source code in SKILL.md, the assembly logic validates provider assignments after member selection. If a collision occurs, the coordinator re-allocates one member to an alternative provider or fails the request, ensuring the structural tension remains intact.

How does the --duo flag know which members form a polarity pair?

When you invoke --duo without explicit --members, the coordinator queries the council.polarity_pairs fields across all agent files. It selects two members who list each other as opposites, then applies the provider separation rule before executing the query. This automation ensures you always get a genuine dialectic without manually parsing the YAML metadata.

Can a single council member belong to multiple polarity pairs?

Yes. The polarity_pairs field accepts an array of member names. For instance, council-watts declares ["torvalds", "socrates"] as opposites. In multi-member panels, the coordinator checks all pairwise combinations and enforces provider separation for every declared opposition, creating a web of structural tensions across the entire council.

Why enforce different providers instead of using different system prompts?

Different system prompts on the same model family still share identical inductive biases, training data distributions, and safety alignment patterns. The council-of-high-intelligence architecture specifically routes polarity pairs to different provider families (e.g., Claude vs. OpenAI) because distinct foundation models possess genuinely different reasoning architectures. This prevents the "cosmetic rewrite" problem where the same underlying model simply reformulates its output, ensuring the disagreement reflects real cognitive divergence rather than prompt-level variation.

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