master-brain

Overview

No inference without evidence. No conclusion without verification.

Every analysis passes through a mandatory 5-stage reasoning loop. Every stage is processed as a distinct, demarcated unit of work. The loop repeats from Observation if Verification fails.

Violating the letter of the rules is violating the spirit of the rules. This principle binds at every stage. No stage may be skipped or waved off as "obvious."

When to Use

Analysis, decision, or evaluation needed?
├─ No  → Don't use this skill
└─ Yes → Can it be answered in a single step?
          ├─ Yes → Don't use this skill
          └─ No  → USE this skill

Use this skill for:

• Complex multi-step decisions with trade-offs
• Document analysis: claims, findings, evidence, gaps
• Quality control of structured analysis (yours or someone else's)
• Gap analysis, benchmarking, evaluation against a standard
• Any inference, evaluation, or judgment that must be defensible

Do not use for:

• Simple informational queries ("where is this file?")
• Single-step operations ("rename this variable")
• Routine code writing or refactoring
• Tasks with no judgment component

Configuration

Set analysis parameters before the loop. Every parameter has a safe default; omit any to use the default.

config:
  rigor: Type 2        # Type 1 / Type 2 / Trivial
  evidence: Default    # Restricted / Default / Extended
  audit: Standard      # Standard / Full
  checks: Standard     # Minimal / Standard / Full
  confidenceFloor: Default  # Default / HighOnly / Relaxed

| Parameter | Default | Options | Effect | |-----------|---------|---------|--------| | rigor | Type 2 | Type 1 / Type 2 / Trivial | Loop depth. Type 1 forces all checks | | evidence | Default | Default / Restricted / Extended | Evidence sources. Restricted = user-provided only | | audit | Standard | Standard / Full | Output detail. Full = metadata table appended | | checks | Standard | Minimal / Standard / Full | Which checks run. Full = Fallacy + Bias + Assumption Audit | | confidenceFloor | Default | Default / HighOnly / Relaxed | Minimum confidence to recommend. HighOnly = all decisions need High |

Evidence scope

| Scope | Available sources | |-------|-------------------| | Restricted | User-provided documents, data, references only | | Default | User sources + agent training knowledge | | Extended | User + agent + web search / API tools (where available) |

Audit output

| Mode | Output | |------|--------| | Standard | [Severity] [Direction] + confidence + recommendation | | Full | Standard + Analysis Metadata table (loop count, hypotheses, claim confidence distribution, check results) |

Checks profile

| Profile | Checks run | |---------|------------| | Minimal | Formal Fallacy Check only | | Standard | Cognitive Bias Check + Formal Fallacy Check | | Full | Bias + Fallacy + Assumption Audit |

Confidence floor

| Floor | Rule | |-------|------| | Default | Type 1 → Medium+ required; Type 2/Trivial → any | | HighOnly | Every recommendation requires High confidence | | Relaxed | Type 2 accepts Low (exploratory analysis) |

All-default: Rigor: Type 2, Evidence: Default, Audit: Standard, Checks: Standard, ConfidenceFloor: Default.

To use: include a config block before the loop, or state parameters inline.

The 5-Stage Loop

OBSERVATION → HYPOTHESIS → EVIDENCE → CONCLUSION → VERIFICATION
   ↑________________________________________________|
              (loop back if verification fails)

| # | Stage | Question | |---|-------|----------| | 1 | Observation | What is present? | | 2 | Hypothesis | What could it mean? | | 3 | Evidence | What supports or refutes each candidate? | | 4 | Conclusion | What is the final judgment? | | 5 | Verification | Under what conditions is this wrong? |

Rules that bind at every stage:

• Run the stages in order. Do not skip.
• Process each stage as a distinct unit. Do not batch.
• If Verification fails, return to Observation with the new evidence. Do not patch the conclusion.

Stage 1 — Observation

Collect data without interpretation. List facts, not opinions.

Do:

• For a document: itemize claims, structure, sections, evidence cited, gaps.
• For a decision: list current state, constraints, stakeholders, timeline, prior attempts.
• For a claim: restate it precisely; identify what would need to be true for it to hold.
• For QA: extract structure, numbering, headings, paragraph count.

Do not:

• Add commentary, judgment, or "I think" statements.
• Pre-classify findings (that is Hypothesis work).
• Skip items because they seem irrelevant.

Stage 2 — Hypothesis

Generate candidate explanations for each observation. Force at least two hypotheses per observation — do not stop at the first plausible reading.

Do:

• "This could mean X..."
• "A rule could be violated if Y..."
• "Alternatively, Z is also possible..."

Do not:

• Settle on one hypothesis without considering alternatives.
• Treat the first hypothesis as the conclusion.
• Skip the stage because "it's obvious."

Stage 3 — Evidence

Gather concrete evidence. For each hypothesis, list what supports it and what contradicts it.

Do:

• Cite the specific rule, document section, or fact.
• Verify cross-references (does the cited section actually exist?).
• Check statistics, dates, names — every concrete claim.
• Match claims against any supplied domain rules.
• Annotate each load-bearing claim with a confidence level (High / Medium / Low) and a brief source-quality note. The Evidence output feeds the weakest-link rule in Stage 4; without per-claim confidence, the rule cannot be applied.

Do not:

• Accept a hypothesis on its own plausibility.
• Use vague evidence ("generally accepted that...").
• Skip the contradictions.

Stage 4 — Conclusion

State the conclusion clearly, with a severity/urgency label, a confidence level, and a concrete recommendation.

Do:

• For findings: end with a [Urgency] [Direction] label in bold and a confidence level. Format: "Therefore, Major Gap] has been identified. Confidence: High." See "Severity / Urgency Guidance" and "Confidence Level" below for the taxonomy.
• For Type 1 (irreversible) decisions, see "Calibrating Rigor" — Medium-or-High confidence is required before issuing a recommendation. If confidence is Low, return to Stage 3 to gather more evidence.
• For decisions: state the recommended action, the reason, the alternative, and the cost of not acting.
• For QA: state pass/fail with reason.
• Recommendations should be concrete and actionable. Use the modal form "should" or "must."
• If audit: Full, append the Analysis Metadata table (see Self-Audit Output below).

Do not:

• Issue a conclusion without a [Urgency] [Direction] label.
• Issue a conclusion without a confidence level, or one set without applying the weakest-link rule.
• Issue a finding without a recommendation (a finding without a fix is a complaint, not an analysis).
• Hedge with "I think" or "in my opinion."
• Assign a confidence level you cannot justify with evidence.

Stage 5 — Verification

Test the conclusion adversarially. Apply intellectual honesty.

Do:

• Ask: "What would have to be true for this conclusion to be false?"
• Try alternative scenarios: "What if the data is wrong?"
• Check the conclusion against every domain rule in scope.
• Run the rule-by-rule checklist (if a domain rules file is in use).
• Run the cognitive bias check (see below).
• Run the formal fallacy check (see below).

Pass: Loop ends. Present the conclusion. Fail: Return to Observation with the new evidence. Increment the loop counter. If no new evidence is available: Exit with the current confidence level; document the limitation.

Stage Markers

Each stage produces a marker — a labelled unit of work. The marker is the contract for what each stage emits; the implementation can vary.

| Stage | Marker label | Loop counter | Next stage | |-------|--------------|--------------|------------| | Observation | Observation | 1 (or N+5 on loop-back) | Hypothesis | | Hypothesis | Hypothesis | 2 (or N+6) | Evidence | | Evidence | Evidence | 3 (or N+7) | Conclusion | | Conclusion | Conclusion | 4 (or N+8) | Verification | | Verification (pass) | Verification | 5 (or N+9) | — (loop ends) | | Verification (fail) | Verification | 5 (or N+9) | Loop back to Observation |

Implementation options:

• Step-by-step tool (e.g., sequential-thinking_sequentialthinking): one tool call per stage. Set nextThoughtNeeded=true except on Verification pass. On loop-back, set isRevision=false and needsMoreThoughts=true.
• Prose with section headers: use ## Observation, ## Hypothesis, etc. as section dividers. One section per stage, no merging.
• Numbered list: 1. Observation: ... 2. Hypothesis: .... Compact, useful for short analyses.

The contract is the same regardless of implementation: one stage per unit, no merging.

Calibrating Rigor

Before running the loop, set rigor in the config block. Rigor scales with reversibility.

Is the decision reversible at low cost?
├─ No  → config: rigor: Type 1 — run the FULL loop with high rigor.
│        Examples: choosing a database, signing a contract, hiring, deleting production data.
├─ Yes, but with non-trivial cost → config: rigor: Type 2 — run the loop, accept that speed matters.
│        Examples: refactoring a function, drafting a document, picking a library.
└─ Yes, with negligible cost → config: rigor: Trivial — Observation + Conclusion may suffice; document the abbreviated path.

Implications:

• Type 1: Force ≥ 2 hypotheses. Spend extra effort in Evidence. Run the bias check and fallacy check explicitly. Do not issue a recommendation unless confidence is Medium or High.
• Type 2: Run the standard loop. Document the reversibility so future readers know why speed was prioritized over depth.
• Trivial: Skip Hypothesis and Evidence only if the cost of being wrong is also trivial. Otherwise run the full loop.

Assumption Audit

Before running the loop, identify what the analysis takes for granted. Hidden assumptions cause more errors than flawed logic.

Process:

1. List assumptions the analysis framework depends on — what must be true for the framework to be valid?
2. Classify each by risk:

• High: conclusion reverses if assumption is false.
• Medium: conclusion weakens but does not reverse.
• Low: negligible impact on the conclusion.

1. Mark any assumption testable during Evidence as testable.
2. During Evidence, verify every testable assumption as a claim with its own confidence level.

| # | Assumption | Risk | Testable | |---|-----------|------|----------| | 1 | Data source is current and authoritative | High | Yes | | 2 | Stakeholder's problem description is complete | Medium | Limited | | 3 | No regulatory change pending | Low | No |

If a High-risk assumption is unverified by the end of Evidence: it counts as a load-bearing claim with Confidence: Low. The weakest-link rule applies automatically. Document it:

"Therefore, Note has been recorded (conclusion assumes X]; this could not be verified).

Worked Examples

Example 1 — Database choice

A team is choosing between PostgreSQL and MongoDB for a new application.

• Observation: Current stack is JavaScript/TypeScript. Data model: users, orders, line items — highly relational. Team has 3 years of Postgres experience, no Mongo experience. Traffic: ~10k DAU projected. Cost ceiling: $500/mo for managed DB.
• Hypothesis: A) Postgres fits the relational model and team experience. B) Mongo's document model could simplify some access patterns. C) A hybrid is overkill at this scale.
• Evidence:
• A: 4 years of Postgres in production elsewhere; team velocity is high; relational queries are the hot path.
• B: One access pattern (user profile + preferences) is document-shaped, but a JSONB column in Postgres covers it.
• C: Hybrid adds operational cost; not justified at this scale.
• Conclusion: Use PostgreSQL. Two findings:
• Therefore, Note has been recorded (the relational data model fits Postgres; the team has 3 years of Postgres experience). Confidence: High (multiple independent signals).
• Therefore, Strength has been observed (the team's 3-year Postgres experience is a competitive capability relative to the no-Mongo experience baseline). Confidence: High (verifiable, recent).

Recommendation: should adopt Postgres; must define migration plan and JSONB usage convention.

• Verification: What if access patterns shift toward document-shaped? Postgres + JSONB covers it for the foreseeable scale. Switching cost is bounded. Decision holds.

Example 2 — Blog post accuracy review

A blog post claims: "Postgres handles 10x more concurrent connections than MySQL out of the box."

• Observation: Claim is in paragraph 3. Source cited: a 2019 Stack Overflow answer.
• Hypothesis: A) Claim is accurate. B) Claim is oversimplified — "out of the box" is misleading because both DBs require configuration. C) Claim is outdated.
• Evidence:
• Postgres default max_connections=100; MySQL default max_connections=151. Numbers don't support a 10x claim.
• Both DBs scale via connection pooling in practice; raw connection count is rarely the bottleneck.
• Source is 7 years old.
• Conclusion: Claim is misleading. Therefore, Major Gap has been identified (it would mislead readers). Confidence: High. Recommendation: should rephrase to "Postgres and MySQL both require pooling; their default max_connections values are similar"; or remove the claim.
• Verification: Re-read the source — it does compare connection limits but the 10x figure is not in it. Decision holds.

Domain Rule Integration

The Evidence and Verification stages need a rule set to check against. Two ways to supply it:

Option A — User-supplied rules file. A project-specific rule document (style guide, framework, assessment standard) is provided. Evidence compares claims to the file; Verification runs a rule-by-rule checklist.

Option B — Runtime construction. No file is provided. Construct the rule set from the user's stated requirements at the start of the loop, then use it for Evidence and Verification. To elicit requirements, ask four questions during the Observation stage:

• Success criteria — what does "done" look like for this analysis?
• Constraints — budget, time, technical, regulatory.
• Acceptable trade-offs — what is preferred when two requirements conflict?
• Out of scope — what should Evidence and Verification ignore to prevent scope creep?

If the user does not answer, proceed with conservative defaults and note "requirements pending" as a finding in the Evidence stage.

The skill works either way. If neither is supplied, Evidence and Verification degrade to "logical consistency and stated requirements" — useful, but weaker than an explicit rules file.

Domain Rules File Format

A domain rules file is structured as:

markdown
# Domain: <name>
# Scope: <when these rules apply>

## Rule Group: <group name>
- **Rule:** <one-line statement of the rule>
  - **Example:** <concrete instance showing the rule satisfied>
  - **Violation indicator:** <how to detect a breach>

## Rule Group: <group name>
...

Excerpt example:

markdown
# Domain: Engineering Blog Standards
# Scope: technical blog posts published under our company name

## Rule Group: Claim verification
- **Rule:** Empirical claims must cite a source published within the last 5 years.
  - **Example:** "Postgres handles 10x more connections (Smith, 2024) [link]."
  - **Violation indicator:** Empirical claim with no citation, or citation older than 5 years.

## Rule Group: Severity tagging
- **Rule:** Every finding must end with a `[Urgency] [Direction]` label in bold.
  - **Example:** "...therefore **Major Gap** has been identified."
  - **Violation indicator:** Finding paragraph ends without a bold severity label, or the label lacks a direction.

The Evidence stage checks claims against each rule's example and violation indicator. The Verification stage walks the entire rules file rule-by-rule.

Severity / Urgency Guidance

A finding has two independent axes: urgency (how fast it must be addressed) and direction (deficit vs strength). Conflating them — as a single 7-level list does — produces ambiguous labels.

Urgency axis (default 4 levels)

| Level | When to use | |-------|-------------| | Critical | Severe negative outcome if not addressed immediately | | Major | Must be addressed within months; affects correctness, quality, or safety | | Minor | Must be addressed within a year; affects polish or completeness | | Note | Worth recording; no required action |

Direction axis

| Direction | When to use | |-----------|-------------| | Gap | Requirement not met, or under-met | | Strength | Requirement clearly exceeded (positive finding) |

Combining

The full label is [Urgency] [Direction], formatted in bold and stated with a fixed verb:

• "Therefore, Major Gap has been identified."
• "Therefore, Strength has been observed."
• "Therefore, Note has been recorded."

Confidence Level

Confidence is the orthogonal axis to severity: severity says "how serious if true," confidence says "how well-supported is it."

Two dimensions

Breadth — how many independent sources support the claim:

• Multiple independent sources
• One credible source + logical inference
• Single unverified source

Quality — how reliable the sources are:

| Quality | Examples | |---------|----------| | High | Peer-reviewed paper, official documentation, primary source | | Medium | Established secondary source (industry report, well-known expert blog) | | Low | Anonymous, outdated, unattributed, or self-published without review |

Combined levels

| Level | When to use | |-------|-------------| | High | Multiple independent High-quality sources, OR a rule-by-rule check passes against the domain rules file | | Medium | One strong source, OR multiple Medium-quality sources, OR a logical inference from High-quality evidence | | Low | Single unverified source, OR contradictory evidence, OR Low-quality evidence only |

The weakest-link rule

Confidence = weakest link in the chain. If any supporting claim in the Evidence stage is Low confidence, the whole conclusion is Low — unless that claim is non-critical to the main finding (e.g. an illustrative aside, not load-bearing evidence).

Walk the chain claim-by-claim. The conclusion's confidence equals the lowest confidence among the load-bearing claims.

Format

Append to the finding after the severity label. Example: "Therefore, Major Gap has been identified. Confidence: Medium."

Rules

• For Type 1 (irreversible) decisions, do not issue a recommendation with Low confidence. Gather more evidence first.
• Low confidence is a finding in itself: it tells the reader to verify before acting.

Combining Severity and Confidence

Severity and confidence are independent axes. The same severity with different confidences means very different things:

| Severity | Confidence | Meaning | Implied action | |----------|------------|---------|----------------| | Major Gap | High | Serious issue, well-supported | Act now | | Major Gap | Low | Possibly serious, evidence thin | Verify before acting | | Critical Gap | Medium | Severe if true, evidence partial | Verify urgently, prepare to act | | Strength | High | Clear positive finding | Preserve and replicate | | Strength | Low | Possibly a strength, evidence thin | Verify before claiming | | Note | Medium | Recorded, no action | Acknowledge in the analysis |

This table is read-only — it is the reader's decoder, not a rule the agent generates against. Use it to set reader expectations clearly when issuing a conclusion. The table shows common combinations as examples; for unlisted combinations, derive the implied action from the same axes (severity tells you how serious, confidence tells you how well-supported).

Cognitive Bias Check

Run this short protocol before issuing the Conclusion, and again during Verification.

| Bias | Self-check | If failed | |------|------------|-----------| | Confirmation bias | Did I seek evidence against my preferred hypothesis, or only for it? | Return to Stage 3, gather counter-evidence. | | Anchoring | Am I overweighting the first number/source I encountered? | Explicitly compare to a second, independent source. | | Sunk cost | Am I defending a past decision because of what was already invested? | State the decision on its own merits, ignoring prior investment. | | Availability | Am I overweighting recent or vivid examples? | Look for base rates and historical data. | | Overconfidence | Is my confidence level justified by the evidence, or by intuition? | Lower the confidence level; flag the uncertainty. |

If any check fails, return to Stage 3 (Evidence) and re-collect.

Formal Fallacy Check

Run alongside the Cognitive Bias Check before issuing the Conclusion, and again during Verification.

| Fallacy | Self-check | If failed | |---------|------------|-----------| | Affirming the consequent | If P→Q and Q is true, did I conclude P without checking alternative antecedents? | Return to Stage 3, test whether other causes could produce the same effect. | | Denying the antecedent | If P→Q and P is false, did I conclude ¬Q? | Return to Stage 3, check whether Q could still hold through other paths. | | False dilemma | Did I frame the options as A-or-B when A, B, C, ... exist? | Return to Stage 2, generate at least one alternative beyond the binary. | | Circular reasoning | Does my evidence assume the conclusion it is meant to prove? | Return to Stage 3, find independent evidence that does not presuppose the claim. | | Straw man | Am I attacking a weaker version of the opposing position? | Return to Stage 1, restate the opposing position in its strongest form. | | Appeal to authority | Am I citing an authority outside their domain, or without corroborating evidence? | Return to Stage 3, gather domain-specific evidence independent of the authority. | | Correlation ≠ causation | Am I inferring causation from correlation alone? | Return to Stage 3, identify confounders and test directionality. |

If any check fails, return to Stage 3 (Evidence) and re-collect.

Self-Audit Output

When audit: Full, append an Analysis Metadata table after the Conclusion. This table documents what the loop produced and which checks it passed, making every conclusion auditable.

The agent generates this automatically from the loop's internal state.

markdown
---
### Analysis Metadata

| Metric | Value |
|--------|-------|
| Loop iterations | 1 |
| Hypotheses generated | 3 |
| Evidence claims collected | 8 |
| Claims with High confidence | 5 |
| Claims with Medium confidence | 2 |
| Claims with Low confidence | 1 |
| Checks profile | Standard |
| Cognitive bias check | Pass |
| Formal fallacy check | Pass |
| Assumption Audit | Skipped (checks: Standard) |
| High-risk assumptions identified | 2 |
| High-risk assumptions verified | 2 |
| Evidence scope | Default |
| Weakest-link confidence | Medium |
| Rule set used | Runtime-constructed |
| Domain rules file | None |

The metadata table is read-only documentation of the analysis — it records what was done but does not change the conclusion. If audit: Standard, omit the table.

Red Flags — STOP and Restart the Loop

If any of these occur, cancel the current loop and restart from Observation:

• A stage was skipped or waved off as "obvious" → Return to Observation.
• Conclusion issued without a [Urgency] [Direction] label → Return to Observation, apply severity guidance.
• Conclusion issued without a confidence level → Return to Observation, assign confidence.
• Recommendation missing, or not in "should/must" form → Return to Observation, formulate a concrete recommendation.
• Verification marked "passed" without running the full rule check → Return to Observation, re-run checklist item by item.
• Verification marked "passed" without running the bias check → Return to Observation, run the bias check.
• Verification marked "passed" without running the fallacy check → Return to Observation, run the fallacy check.
• Personal language used ("I think," "in my opinion") → Return to Observation, rewrite in objective voice.
• Cross-references not verified → Return to Observation, locate the referenced section and confirm it exists.
• A single paragraph mixes a finding with its recommendation → Return to Observation, separate them.
• A single paragraph covers more than one topic → Return to Observation, split into separate paragraphs.
• High-risk assumption unverified and not acknowledged in the conclusion → Return to Observation, document the assumption.

All of these mean: cancel the loop, restart from Observation.

Rationalization Table

Agents will try to skip the loop. Pre-empt the common excuses:

| Excuse | Reality | |--------|---------| | "This is obvious, no loop needed" | Obvious-looking cases contain the most errors. Run the loop. | | "The fix is already clear" | Only Verification proves the fix is not incomplete or wrong. | | "One thought is enough" | Each stage is its own unit. Combining stages breaks the loop. | | "5 stages is too long, I'll summarize" | Skipped stage = skipped error. Correctness beats speed. | | "Just an impression, no severity needed" | A finding without severity doesn't communicate seriousness. Assign one. | | "I can skip confidence, it's obvious" | Confidence is a separate axis from severity. Always assign. | | "Bias check is overkill for this" | The bias check is 5 questions. Skipping it skips the most common failure mode. | | "The recommendation is obvious, skip writing it" | A finding without a fix is a complaint, not an analysis. Write it. | | "Not enough data for this section" | Data absence is itself a finding; note "review pending." | | "Verification passed" | Verification passes only when every checklist item is checked. |

Common Mistakes

| Mistake | Fix | |---------|-----| | Treating the analysis framework as given without checking its premises | Run the Assumption Audit before Observation | | Skipping the loop and writing the conclusion directly | Run all 5 stages for every analysis | | Adding interpretation during Observation | Observation is raw data; interpretation belongs in Hypothesis | | Stopping at a single hypothesis | Generate ≥ 2 hypotheses; force alternative explanations | | Skipping Evidence and going straight to Conclusion | Evidence-less conclusion is unfounded judgment. Collect evidence first | | Treating Verification as a formality | Verification is the most critical stage; run the checklist exhaustively | | Issuing a finding without a [Urgency] [Direction] label | Every finding ends with "Therefore, Urgency Direction] has been identified / observed / recorded." | | Issuing a finding without a confidence level | Append "Confidence: level]" after the severity label | | Setting confidence by source count only (ignoring quality) | Apply both breadth and quality dimensions; walk the weakest-link rule | | Skipping per-claim confidence in Evidence | Annotate each load-bearing claim with High / Medium / Low + a source-quality note; without this, the weakest-link rule has no chain to walk | | Issuing a Type 1 recommendation with Low confidence | For irreversible decisions, refuse to recommend until confidence is Medium or High | | Skipping the bias check | Run the 5-question check before issuing the Conclusion | | Skipping the fallacy check | Run the 7-question check alongside the bias check | | Writing recommendations outside the "should/must" form | Use "should be done," "must be ensured" — concrete and directive |

Theoretical Foundations

Each component of this skill traces to established work in epistemology, decision theory, and cognitive science. The skill itself is an applied synthesis encoded as a procedural checklist for AI agents — it is not a peer-reviewed work, but every component has a documented source.

| Component | Foundation | |-----------|------------| | 5-stage loop (Obs → Hyp → Ev → Conc → Ver) | Popper, The Logic of Scientific Discovery (1934, DOI: 10.4324/9780203994627) — falsificationism; Deming / PDCA cycle (1950) | | Loop-back on failure | Popper — conjecture and refutation; Lewin, Action Research (1946, DOI: 10.1111/j.1540-4560.1946.tb02295.x); Schön, The Reflective Practitioner (1983, DOI: 10.4324/9781315237473) | | Verification = what would falsify this | Popper — falsifiability as the demarcation criterion (Logic of Scientific Discovery, §§6–9) | | ≥ 2 hypotheses per observation | Feyerabend, Against Method (1975, DOI: 10.2307/j.ctt17kkc4t) — epistemological anarchism; Toulmin, The Uses of Argument (1958, DOI: 10.1017/CBO9780511840005) | | Per-claim evidence annotation | Toulmin — grounds / warrant / backing / qualifier (The Uses of Argument, ch. 3); Goldman, "What is Justified Belief?" (1979, DOI: 10.1007/978-94-009-9479-1_1) — reliabilism | | Weakest-link confidence rule | Argument chain logic (Sosa, "How to Defeat Opposition to Moore," 1999, DOI: 10.1111/0029-4624.33.s13.7; Sosa, A Virtue Epistemology, 2007, DOI: 10.1093/acprof:oso/9780199292246.001.0001, ch. 2) — safety condition for knowledge | | Severity (urgency × direction) | CVSS (first.org/cvss); FMEA (ISO 31000) — risk = likelihood × impact | | Confidence (breadth × quality) | Bayesian belief updating (Jaynes, Probability Theory, 2003, DOI: 10.1017/CBO9780511790423); source criticism in historiography | | Calibrating rigor by reversibility | Bezos, 2015 shareholder letter — Type 1 / Type 2 decisions; Myers & Majd, "Abandonment Value and Project Life" (1990) — real options theory | | Adversarial verification | Red team / devil's advocate methodology; dialectical reasoning | | Cognitive bias check (5 biases) | Tversky & Kahneman, "Judgment under Uncertainty" (1974, Science, 185(4157), 1124–1131, DOI: 10.1126/science.185.4157.1124); Stanovich & West, dual-process theory (2000, DOI: 10.1017/S0140525X00003435); Kahneman, Thinking, Fast and Slow (2011) | | Formal fallacy check (7 fallacies) | Classical syllogistic logic (Aristotle, Prior Analytics); Hamblin, Fallacies (1970); Walton, Informal Logic (1989) — argumentation schemes and critical questions | | Self-audit / analysis metadata | Tetlock, Expert Political Judgment (2005, DOI: 10.1515/9780691185972) — calibration tracking; Kahneman — WYSIATI; reproducibility practices in metodoloji | | Anti-rationalization safeguards | Cialdini, Influence (1984, DOI: 10.4324/9781912282557) — persuasion principles; Kahneman — WYSIATI ("what you see is all there is") | | "Violating the letter violates the spirit" | Kant, Groundwork of the Metaphysics of Morals (1785, DOI: 10.1017/CBO9780511809637) — deontological ethics; rule-based ethical formalism |

Quick Reference

| Situation | Action | |-----------|--------| | Single document, claim, or decision to analyze | Run the full 5-stage loop | | Complex multi-step decision | Observation → Hypothesis → Evidence → Conclusion → Verification | | Irreversible / one-way-door decision | Full loop + all checks + Medium-or-High confidence required | | Trivial / fully reversible decision | Observation + Conclusion may suffice; document the path | | Quality control of a prior analysis | Run Verification against the rule set in scope | | Need to assign a severity/urgency label | Pick urgency (Critical / Major / Minor / Note) and direction (Gap / Strength); combine in bold | | Need to set analysis parameters | Include a config block before the loop | | Need to see what the loop produced | Set audit: Full for metadata table | | Need to limit evidence sources | Set evidence: Restricted | | Need to detect cognitive bias | Run the 5-question bias check | | Need to detect logical fallacy | Run the 7-question fallacy check | | Step-by-step tool available | One tool call per stage with the stage as the marker | | No step-by-step tool available | Section headers or numbered list; one stage per unit | | Red Flag triggered | Cancel the loop, restart from Observation | | Verification failed | Return to Observation, run the loop again with new evidence | | No domain rules file available | Construct the rule set from the user's stated requirements at the start | | Unstated assumptions to audit | Run the Assumption Audit; verify testable ones in Evidence |