Domain P - Perspective (P1-P20)

• P1 First Principles Framing
• P2 Stakeholder Mapping
• P3 Identity Stack
• P4 Lens Shifting
• P5 Empathy Mapping
• P6 Point-of-View Anchoring
• P7 Perspective Switching
• P8 Narrative Framing
• P9 Cultural Lens Shifting
• P10 Context Windowing
• P11 Role Perspective-Taking
• P12 Temporal Framing
• P13 Spatial Framing
• P14 Reference Class Framing
• P15 Assumption Surfacing
• P16 Identity-Context Reciprocity
• P17 Frame Control & Reframing
• P18 Boundary Object Selection
• P19 Sensemaking Canvases
• P20 Worldview Articulation

Domain IN - Inversion (IN1-IN20)

• IN1 Subtractive Thinking
• IN2 Premortem Analysis
• IN3 Problem Reversal
• IN4 Contra-Logic
• IN5 Negative Space Framing
• IN6 Inverse/Proof by Contradiction
• IN7 Boundary Testing
• IN8 Contrapositive Reasoning
• IN9 Backward Induction
• IN10 Red Teaming
• IN11 Devil's Advocate Protocol
• IN12 Failure First Design
• IN13 Opportunity Cost Focus
• IN14 Second-Order Effects (Inverted)
• IN15 Constraint Reversal
• IN16 Inverse Optimization
• IN17 Counterfactual Negation
• IN18 Kill-Criteria & Stop Rules
• IN19 Harm Minimization (Via Negativa)
• IN20 Antigoals & Anti-Patterns Catalog

Domain CO - Composition (CO1-CO20)

• CO1 Synergy Principle
• CO2 Chunking
• CO3 Functional Composition
• CO4 Interdisciplinary Synthesis
• CO5 Emergence
• CO6 Gestalt Integration
• CO7 Network Effects
• CO8 Layered Abstraction
• CO9 Interface Contracts
• CO10 Pipeline Orchestration
• CO11 Pattern Composition (Tiling)
• CO12 Modular Interoperability
• CO13 Cross-Domain Analogy
• CO14 Platformization
• CO15 Combinatorial Design
• CO16 System Integration Testing
• CO17 Orchestration vs Choreography
• CO18 Knowledge Graphing
• CO19 Multi-Modal Integration
• CO20 Holistic Integration

Domain DE - Decomposition (DE1-DE20)

• DE1 Root Cause Analysis (5 Whys)
• DE2 Factorization
• DE3 Modularization
• DE4 Layered Breakdown
• DE5 Dimensional Reduction
• DE6 Taxonomy/Classification
• DE7 Pareto Decomposition (80/20)
• DE8 Work Breakdown Structure
• DE9 Signal Separation
• DE10 Abstraction Laddering
• DE11 Scope Delimitation
• DE12 Constraint Isolation
• DE13 Failure Mode Analysis (FMEA)
• DE14 Variable Control & Isolation
• DE15 Decision Tree Expansion
• DE16 Hypothesis Disaggregation
• DE17 Orthogonalization
• DE18 Scenario Decomposition
• DE19 Critical Path Unwinding
• DE20 Partition-and-Conquer

Domain RE - Recursion (RE1-RE20)

• RE1 Recursive Improvement (Kaizen)
• RE2 Feedback Loops
• RE3 Meta-Learning (Learn-to-Learn)
• RE4 Nested Narratives
• RE5 Fractal Reasoning
• RE6 Recursive Framing
• RE7 Self-Referential Logic
• RE8 Bootstrapping
• RE9 Iterative Prototyping
• RE10 Compounding Cycles
• RE11 Calibration Loops
• RE12 Bayesian Updating in Practice
• RE13 Gradient Descent Heuristic
• RE14 Spiral Learning
• RE15 Convergence-Divergence Cycling
• RE16 Retrospective -> Prospective Loop
• RE17 Versioning & Diff
• RE18 Anti-Catastrophic Forgetting
• RE19 Auto-Refactor
• RE20 Recursive Governance (Guardrails that Learn)

Domain SY - Systems (SY1-SY20)

• SY1 Leverage Points
• SY2 System Boundaries
• SY3 Stocks & Flows
• SY4 Requisite Variety
• SY5 Systems Archetypes
• SY6 Feedback Structure Mapping
• SY7 Path Dependence
• SY8 Homeostasis/Dynamic Equilibrium
• SY9 Phase Transitions & Tipping Points
• SY10 Causal Loop Diagrams
• SY11 Governance Patterns
• SY12 Protocol/Interface Standards
• SY13 Incentive Architecture
• SY14 Risk & Resilience Engineering
• SY15 Multi-Scale Alignment
• SY16 Ecosystem Strategy
• SY17 Policy Feedbacks
• SY18 Measurement & Telemetry
• SY19 Meta-Model Selection
• SY20 Systems-of-Systems Coordination

Total: 120 models. Full registry in Base120_Canonical_Model_Registry.yaml.

Installation

From PyPI

pip install base120

From source

git clone https://github.com/hummbl-io/oss.git && cd oss/packages/base120
pip install -e ".[test]"

Requirements

• Python 3.11+
• Zero runtime dependencies (stdlib only)

Python SDK

Core API

from base120 import Engine, Ledger

engine = Engine()

# Look up an operator by ID
operator = engine.get("P6")
print(operator.name)  # → Point-of-View Anchoring
print(operator.family)  # → P (Perspective)
print(operator.description)  # → Anchor analysis to a specific viewpoint

# Generate an operator-specific prompt for a problem
prompt = engine.prompt("P6", "How should we price the certification tier?")
print(prompt)

# Apply an operator and persist a governance-readable record
result = engine.record(
    "P6",
    "How should we price the certification tier?",
    "Anchor the offer to the compliance officer's risk budget.",
    0.85,  # confidence score
)

# Persist to an append-only ledger
ledger = Ledger("base120-ledger.jsonl")
ledger.append(result.to_tuple())

Engine methods

Operator attributes

CLI

# List all 120 operators
base120 list

# Inspect one operator
base120 get P6

# Generate an operator-specific prompt for a problem
base120 prompt P6 "How should we price the certification tier?"

# List the 6 transformation families
base120 families

CLI examples

$ base120 get IN6
ID:          IN6
Name:        Pre-Mortem
Family:      IN (Inversion)
Description: Imagine the project has failed; work backward to identify causes

$ base120 prompt IN6 "Should we migrate from REST to GraphQL?"
# Generates a pre-mortem prompt: "Assume the migration has shipped and
# failed catastrophically. What went wrong? List the top 5 failure modes
# and their early-warning signals."

MCP Server

Base120 ships with an MCP (Model Context Protocol) server entry point, so any MCP-compatible agent can use the 120 operators directly:

# Run the MCP server
base120-mcp

Learn more about MCP at the Model Context Protocol specification.

Configuration for Claude Code

Add to your Claude Code MCP config:

{
  "mcpServers": {
    "base120": {
      "command": "base120-mcp"
    }
  }
}

Configuration for Cursor

Add to your Cursor MCP config:

{
  "mcpServers": {
    "base120": {
      "command": "base120-mcp"
    }
  }
}

Once configured, your agent can call base120.get, base120.list, base120.prompt, and base120.families as MCP tools.

Ledger

Every operator application can be persisted as a JSONL tuple to an append-only ledger:

from base120 import Engine, Ledger

engine = Engine()
ledger = Ledger("decisions.jsonl")

# Apply an operator and record the result
result = engine.record(
    "DE1",  # operator ID
    "Reduce release risk.",  # problem
    "Split blockers by owner.",  # response
    0.9,  # confidence
)

ledger.append(result.to_tuple())

# Query high-drift records (confidence < threshold)
high_drift = ledger.cut(0.5)
for record in high_drift:
    print(record)

Ledger tuple format

Each ledger entry is a JSONL tuple with:

• operator_id: The operator code (e.g., "DE1")
• problem: The problem statement
• response: The applied response
• confidence: Float 0.0–1.0
• timestamp: ISO 8601 timestamp

The ledger is append-only — records are never modified or deleted, making it suitable for audit trails and governance review.

Examples

Example 1: Structured Decision-Making

Problem: "Should we migrate from REST to GraphQL?"

from base120 import Engine

engine = Engine()

# Step 1 — P1 (First Principles): What are the irreducible requirements?
print(engine.prompt("P1", "Should we migrate from REST to GraphQL?"))
# → "What are the irreducible requirements? Latency, cacheability, client flexibility."

# Step 2 — IN5 (Worst-Case Analysis): What if the migration takes 6 months?
print(engine.prompt("IN5", "Should we migrate from REST to GraphQL?"))
# → "What if the migration takes 6 months and breaks mobile clients?"

# Step 3 — DE5 (Separation of Concerns): Which parts need flexibility?
print(engine.prompt("DE5", "Should we migrate from REST to GraphQL?"))
# → "Which parts of the API actually need flexibility? Read paths vs write paths."

# Step 4 — CO1 (Modularity): Can we support both during transition?
print(engine.prompt("CO1", "Should we migrate from REST to GraphQL?"))
# → "Can we support both during transition? BFF pattern, not big-bang."

# Step 5 — SY13 (Feedback Loops): How do we know it's working?
print(engine.prompt("SY13", "Should we migrate from REST to GraphQL?"))
# → "How do we know it's working? Metrics: latency p99, error rate, client adoption."

Each step names the model, applies it, and passes output to the next. No vague advice — explicit reasoning with receipts.

Example 2: Pre-Mortem for a Launch

from base120 import Engine, Ledger

engine = Engine()
ledger = Ledger("launch-premortem.jsonl")

# Run a pre-mortem on the launch plan
result = engine.record(
    "IN6",  # Pre-Mortem
    "Launch the new pricing tier next Monday.",  # problem
    "Top failure mode: existing customers downgrade to the new tier, cannibalizing revenue.",
    0.8,  # confidence
)

ledger.append(result.to_tuple())
print("Pre-mortem recorded. Review before launch.")

Example 3: Multi-Agent Reasoning

from base120 import Engine

engine = Engine()

# An AI agent applies Perspective operators to gather viewpoints
viewpoints = [engine.prompt(f"P{i}", "Design a rate limiter") for i in [1, 5, 6, 10]]

# Then applies Inversion to stress-test
failure_modes = [engine.prompt(f"IN{i}", "Design a rate limiter") for i in [5, 6, 15]]

# Then applies Systems to understand dynamics
dynamics = [engine.prompt(f"SY{i}", "Design a rate limiter") for i in [1, 12, 13]]

Example 4: Reading the Registry Directly (Any Language)

The canonical registry is a YAML file — you can read it from any language without installing Base120:

import yaml  # any YAML parser

with open("Base120_Canonical_Model_Registry.yaml") as f:
    registry = yaml.safe_load(f)

models = {m["id"]: m for m in registry["models"]}
print(models["P1"]["name"])  # → First Principles Framing
print(models["IN6"]["name"])  # → Inverse/Proof by Contradiction
print(models["SY13"]["name"])  # → Incentive Architecture

// Node.js
import yaml from 'js-yaml';
import { readFileSync } from 'fs';

const registry = yaml.load(readFileSync('Base120_Canonical_Model_Registry.yaml', 'utf8'));
const models = Object.fromEntries(registry.models.map(m => [m.id, m]));
console.log(models.P1.name);   // → First Principles Framing

// Rust (using serde_yaml)
let registry: serde_yaml::Value = serde_yaml::from_str(&std::fs::read_to_string("Base120_Canonical_Model_Registry.yaml")?)?;
let models = registry["models"].as_sequence().unwrap();

Why Base120?

The problem with existing mental-models resources

Most mental-models resources fall into one of three categories:

Base120 fills the structural hole: a general-purpose Python library with a structured taxonomy, stdlib-only design, and multi-surface delivery (Python SDK + CLI + MCP + REST).

What you get

• 120 operators — the largest catalog among general-purpose mental-models libraries
• 6-family taxonomy — structured navigation, not a flat list
• Zero dependencies — installs in seconds, runs anywhere Python 3.11+ runs
• Deterministic — same input, same output, every time
• Agent-native — MCP server built in, works with Claude Code, Cursor, Codex, Copilot
• Human-native — CLI and Python API equally usable
• Ledger-native — every application persists a governance-readable record
• Frozen canon — the registry is versioned and frozen; other-language implementations conform to it

Step 1 — P1 (First Principles Framing):
  What are the irreducible requirements? Latency, cacheability, client flexibility.

Step 2 — IN5 (Negative Space Framing):
  What is absent from the current architecture? What gaps does REST leave unaddressed?

Step 3 — DE5 (Dimensional Reduction):
  Which dimensions actually matter? Read paths vs write paths, client types, payload size.

Step 4 — CO1 (Synergy Principle):
  Can we support both during transition? BFF pattern, not big-bang.

Step 5 — SY13 (Incentive Architecture):
  How do we know it's working? Metrics: latency p99, error rate, client adoption.

Implementing in another language

The registry is language-agnostic. To implement Base120 in Rust, Go, TypeScript, etc.:

1. Parse Base120_Canonical_Model_Registry.yaml with any YAML parser
2. Implement the 4 Engine methods: get, list, families, prompt
3. Implement the Ledger for append-only JSONL persistence
4. Validate against the test corpus in tests/

Domain P — Perspective (P1–P20)

P1 First Principles Framing | P2 Stakeholder Mapping | P3 Identity Stack | P4 Lens Shifting | P5 Empathy Mapping | P6 Point-of-View Anchoring | P7 Perspective Switching | P8 Narrative Framing | P9 Cultural Lens Shifting | P10 Context Windowing | P11 Role Perspective-Taking | P12 Temporal Framing | P13 Spatial Framing | P14 Reference Class Framing | P15 Assumption Surfacing | P16 Identity-Context Reciprocity | P17 Frame Control & Reframing | P18 Boundary Object Selection | P19 Sensemaking Canvases | P20 Worldview Articulation

Domain IN — Inversion (IN1–IN20)

IN1 Subtractive Thinking | IN2 Premortem Analysis | IN3 Problem Reversal | IN4 Contra-Logic | IN5 Negative Space Framing | IN6 Inverse/Proof by Contradiction | IN7 Boundary Testing | IN8 Contrapositive Reasoning | IN9 Backward Induction | IN10 Red Teaming | IN11 Devil's Advocate Protocol | IN12 Failure First Design | IN13 Opportunity Cost Focus | IN14 Second-Order Effects (Inverted) | IN15 Constraint Reversal | IN16 Inverse Optimization | IN17 Counterfactual Negation | IN18 Kill-Criteria & Stop Rules | IN19 Harm Minimization (Via Negativa) | IN20 Antigoals & Anti-Patterns Catalog

Domain CO — Composition (CO1–CO20)

CO1 Synergy Principle | CO2 Chunking | CO3 Functional Composition | CO4 Interdisciplinary Synthesis | CO5 Emergence | CO6 Gestalt Integration | CO7 Network Effects | CO8 Layered Abstraction | CO9 Interface Contracts | CO10 Pipeline Orchestration | CO11 Pattern Composition (Tiling) | CO12 Modular Interoperability | CO13 Cross-Domain Analogy | CO14 Platformization | CO15 Combinatorial Design | CO16 System Integration Testing | CO17 Orchestration vs Choreography | CO18 Knowledge Graphing | CO19 Multi-Modal Integration | CO20 Holistic Integration

Domain DE — Decomposition (DE1–DE20)

DE1 Root Cause Analysis (5 Whys) | DE2 Factorization | DE3 Modularization | DE4 Layered Breakdown | DE5 Dimensional Reduction | DE6 Taxonomy/Classification | DE7 Pareto Decomposition (80/20) | DE8 Work Breakdown Structure | DE9 Signal Separation | DE10 Abstraction Laddering | DE11 Scope Delimitation | DE12 Constraint Isolation | DE13 Failure Mode Analysis (FMEA) | DE14 Variable Control & Isolation | DE15 Decision Tree Expansion | DE16 Hypothesis Disaggregation | DE17 Orthogonalization | DE18 Scenario Decomposition | DE19 Critical Path Unwinding | DE20 Partition-and-Conquer

Domain RE — Recursion (RE1–RE20)

RE1 Recursive Improvement (Kaizen) | RE2 Feedback Loops | RE3 Meta-Learning (Learn-to-Learn) | RE4 Nested Narratives | RE5 Fractal Reasoning | RE6 Recursive Framing | RE7 Self-Referential Logic | RE8 Bootstrapping | RE9 Iterative Prototyping | RE10 Compounding Cycles | RE11 Calibration Loops | RE12 Bayesian Updating in Practice | RE13 Gradient Descent Heuristic | RE14 Spiral Learning | RE15 Convergence-Divergence Cycling | RE16 Retrospective -> Prospective Loop | RE17 Versioning & Diff | RE18 Anti-Catastrophic Forgetting | RE19 Auto-Refactor | RE20 Recursive Governance (Guardrails that Learn)

Domain SY — Systems (SY1–SY20)

SY1 Leverage Points | SY2 System Boundaries | SY3 Stocks & Flows | SY4 Requisite Variety | SY5 Systems Archetypes | SY6 Feedback Structure Mapping | SY7 Path Dependence | SY8 Homeostasis/Dynamic Equilibrium | SY9 Phase Transitions & Tipping Points | SY10 Causal Loop Diagrams | SY11 Governance Patterns | SY12 Protocol/Interface Standards | SY13 Incentive Architecture | SY14 Risk & Resilience Engineering | SY15 Multi-Scale Alignment | SY16 Ecosystem Strategy | SY17 Policy Feedbacks | SY18 Measurement & Telemetry | SY19 Meta-Model Selection | SY20 Systems-of-Systems Coordination