Council of Logic

The Default Being Overridden

Left unchecked, LLMs default to:

First-answer bias: The first plausible solution surfaces and gets committed to immediately
Confirmation anchoring: Evidence that supports the initial hypothesis gets weighted higher than contradicting evidence
Mono-perspective reasoning: Analysis from a single angle, missing structural weaknesses that another lens would catch
Premature convergence: "This looks right" treated as "this is right" without stress-testing
Complexity blindness: Elegant-looking solutions that hide failure modes not immediately visible

This skill overrides those defaults by requiring adversarial multi-perspective analysis before concluding.

The Four Advisors

Before committing to any complex technical decision, consult all four:

Advisor 1: Turing — Formal Correctness

"Does this solution actually compute the right answer? Can you prove it?"

Turing asks about correctness, not elegance. Questions:

Is the algorithm provably correct, or is it "probably correct"?
Are there inputs that produce wrong outputs?
Are there off-by-one errors, boundary conditions, integer overflow, null cases?
Can you write a test that would catch if this breaks?
Is there any path where the code returns silently without doing its job?

Turing's verdict format: Identifies the formal correctness risk, states whether the solution handles the edge case.

Advisor 2: Shannon — Information & Signal

"Where is the information? Where is the noise? What are you actually measuring?"

Shannon asks about signal quality and information flow. Questions:

What data does this decision depend on? How reliable is that data?
Is there latency between reality and what the system knows?
Are you measuring the right thing or a proxy for the right thing?
If the input is noisy/wrong, how does the system fail?
Is there information loss at any point in the pipeline?
Are there race conditions where two parts of the system have different views of the same fact?

Shannon's verdict format: Identifies information gaps, data quality risks, and race conditions.

Advisor 3: Von Neumann — Systems Thinking

"What does this do to the system as a whole, not just to this component?"

Von Neumann asks about emergent system behavior. Questions:

What are the second-order effects of this change?
How does this interact with the parts of the system you're NOT modifying?
What happens under load? Under concurrent access?
Does this create a bottleneck elsewhere?
Does this add a hard dependency that limits future flexibility?
What does the failure mode look like from the user's perspective?

Von Neumann's verdict format: Identifies system-level risks, cascading failures, bottlenecks.

Advisor 4: Gödel — Completeness & Limits

"What can this approach NOT solve? What are its inherent limits?"

Gödel asks about completeness and self-reference. Questions:

What category of problems is this approach fundamentally unable to handle?
Is there a case where this solution generates a problem that the solution itself can't solve?
What assumptions does this approach require to hold true? If they stop holding, what breaks?
Is there a simpler solution that the chosen approach's complexity is obscuring?
Are we inside the problem (self-referential) in a way that blinds us to a dimension of it?

Gödel's verdict format: Identifies the conceptual limits of the approach, the simplest alternative not yet considered.

How to Apply the Council

For any decision that warrants multi-perspective analysis:

Council Review: [Decision being made]

TURING (Correctness):
[Statement of the formal correctness risk, if any. Or "No formal correctness risk identified."]

SHANNON (Information):
[Statement of data/signal quality risk. Or "Information flow is sound."]

VON NEUMANN (Systems):
[Statement of system-level impact. Or "No adverse system-level effects identified."]

GÖDEL (Completeness):
[Statement of approach limits and simplest unconsidered alternative.]

SYNTHESIS:
[The recommendation, incorporating all four verdicts. Where advisors conflict, state the tradeoff explicitly.]

When to Use the Full Council

Use all four advisors when the cost of getting it wrong is high:

Architectural decisions that will be hard to reverse
Security-sensitive implementations (auth, RLS, data access)
Performance-critical paths (database queries, caching strategies)
Complex bugs with unclear root causes
Feature designs with multiple competing constraints
Refactoring scope decisions (how much to change at once)

Abbreviated Council (Turing + Von Neumann only) for:

Medium-complexity component implementations
Standard CRUD patterns in a new context
Debugging with a likely-but-unverified cause

No Council needed for:

Mechanical, unambiguous tasks (rename a variable, add a CSS class)
Fully-specified implementations (the spec covers every case)
Copy changes, documentation updates

The Dissenting Voice

Before finalising any non-trivial solution, generate one dissenting argument:

"The strongest argument against this approach is: [argument]. This matters because: [why]. The counterargument is: [why I'm proceeding anyway]."

If you cannot generate a genuine dissenting argument, the solution may be trivially correct — or you haven't thought hard enough. One of these is fine. Know which.

Pattern: Complex Debugging

When debugging a non-obvious issue, the Council applies in order:

Turing: What does the code actually do? (Read it literally, not as you intended it)
Shannon: What data does the code actually receive? (Log it, don't assume)
Von Neumann: How does the system reach this code? (Trace the call path)
Gödel: What assumption is the code making that might not hold in this context?

The answer is almost always in step 4.

References

The Council pattern is named in SKILLS-INDEX.md as one of four P1 auto-loaded skills. It is derived from multi-model adversarial review patterns (cf. Anthropic's multi-agent reliability research) — where separate evaluator models stress-test outputs before they are accepted as final.

council-of-logic