# How Polarity Pairs Force Genuine Disagreement Between Council Members

> Discover how polarity pairs ensure authentic debate between council members by using different LLM providers. Prevent single model reframing and foster genuine disagreement.

- Repository: [nyk/council-of-high-intelligence](https://github.com/0xNyk/council-of-high-intelligence)
- Tags: internals
- Published: 2026-07-03

---

**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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/agents/council-watts.md) at line 11, the member declares:

```yaml

# 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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/SKILL.md) between lines 186 and 199. Here, the coordinator applies a non-negotiable rule called **Polarity pair separation**:

```markdown
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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/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:

```bash

# 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:

```bash

# 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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/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`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/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.