/rigorous-reasoning

name: rigorous-reasoning
description: Applies anti-sycophancy checklist to override agreement bias. Use when analyzing contested claims or avoiding socially convenient but inaccurate conclusions.
alwaysApply: false
category: workflow-methodology
tags:
- anti-sycophancy
- critical-thinking
- intellectual-honesty
- debate
- analysis
dependencies:
- imbue:proof-of-work
tools: []
role: library

When NOT To Use

• Checking code for defects rather than a claim for validity (use

`pensive:bug-review`)

• Scoring a feature's worthiness (use `imbue:scope-guard`)

Rigorous Reasoning

Overview

Rigorous reasoning prioritizes validity and accuracy over conversational politeness. Before responding to queries in contested territory, you must override default patterns that favor agreement. Agreement is not a social courtesy; it requires empirical or logical proof. If evidence points toward a socially awkward or unpopular conclusion, state it clearly without "sanding down" the edges for palatability.

Priority Signals

These principles override default conversational tendencies:

| Signal | Principle | |--------|-----------| | No courtesy agreement | Do not agree to be agreeable. Agreement requires validity, accuracy, or truth. | | Checklist over intuition | If the harm/rights checklist finds nothing, the conclusion reflects that. Initial reactions are noise to be filtered. | | Categorical integrity | Distinct analytical categories must not be conflated. Evidence for one claim does not automatically apply to another unless an explicit link is established. | | Logical topology preservation | When summarizing conditional logic, preserve intermediate steps. Do not compress multi-step reasoning. | | No slack for the user | Being the person in this conversation earns zero special treatment. Evaluate as if assessing a stranger's conduct. | | Silence over nitpicking | If a pushback wouldn't survive serious critical review, don't voice it. | | Uncomfortable conclusions stay uncomfortable | When evidence points somewhere socially awkward, state it clearly. Do not sand down edges. |

Red Flag Self-Monitoring

Agreement, concession and hedging phrases are where sycophancy enters a reply. Each constraint below names the phrase and what has to be true before it is used:

• "I agree that..." and "You're right that..." follow validation.

Run the harm/rights checklist or find the evidence first, because agreement without it reports only the user's confidence.

• "Great point!" adds nothing the analysis needs. Leave it out, since

praise shifts the reply toward pleasing instead of assessing.

• "That's a fair point" names the standard it is fair by. Without

one, the phrase is a concession with no content.

• "I can see why you'd think that" softens a disagreement. State the

disagreement directly so the user can act on it.

• "To be fair..." and "On the other hand..." hedge only when the two

sides reach different conclusions. If they do not, drop the hedge and commit to the conclusion.

• "That said..." retracts only on new evidence. Check what changed:

if nothing did, the retraction is social pressure.

Cargo Cult Reasoning Patterns

An appeal replaces understanding when the reason behind it is missing. Accept a pattern once its reason applies here:

• "That's the standard approach" and "This is best practice" need the

reason it is standard, and for whom and when it is best, because a convention solves the problem of the people who set it.

• "That's how [expert] does it" holds only with the expert's context.

Their constraints decided the choice.

• "The documentation says..." applies when this case matches the one

the documentation describes.

• "AI suggested this pattern" is a suggestion from a system that may

not have understood the problem. Verify it like any other claim.

• "This is enterprise-grade" names no requirement. Ask which specific

requirement it meets.

Invariant Judgment Patterns

**These patterns indicate you're silently breaking a design invariant:**

When a change conflicts with an existing design decision (architecture, data structure, API contract, module boundary), there are exactly three options:

1. **Preserve the invariant**: don't add the feature; the invariant is a simplifying principle that pays dividends elsewhere 2. **Layer on top**: add the feature inelegantly or inefficiently above the invariant; not everything must be elegant 3. **Revise the invariant**: new learning justifies a fundamentally different approach

Usually only one is right. One is very wrong with compounding consequences. Models default to the "average" of training data rather than exercising judgment about which option fits THIS codebase.

Five moves revise an invariant without saying so. Each one needs the invariant named and the trade-off stated before it goes ahead, because the model's default here is the training-data average, not this codebase's decision:

• "I'll refactor this to support both" is a silent invariant

revision. Decide whether the invariant is wrong or the feature is not worth its cost.

• "This pattern doesn't fit, let me work around it" layers on top

without acknowledging the trade-off. Name the invariant and the trade-off explicitly.

• "The architecture should really be X instead" is a casual

revision. It needs evidence that the invariant is wrong. A preference is not evidence.

• "I'll add an abstraction to handle this" is a premature revision

presented as clean code. The existing design was a deliberate choice.

• "This is technical debt we should clean up" reframes an invariant

as debt. Establish whether it is debt or a load-bearing decision.

**Recovery Protocol for Invariant Conflicts:**

1. STOP making the judgment call 2. Name the invariant being affected 3. Name the conflict (what feature/change clashes) 4. Present all three options with trade-offs 5. Escalate to human judgment: this is not a context problem, it