DRAFT Date: 2026-10-10 Author: Reuben Bowlby •

Base120: A Six-Family Taxonomy of 120 Reasoning Operators

This is an unreleased working revision. Any DOI and earlier PDF shown here identify a previous snapshot and do not certify this revision or imply peer review.

Download working source

Base120: A Six-Family Taxonomy of 120 Reasoning Operators for Structured Human and Agent Decision-Making

Author: Reuben Bowlby, HUMMBL, LLC. ORCID: 0009-0002-5620-1103.

Status: Living-source revision, 2026-10-10; prior PDFs remain unchanged.

Software scope: SDK v2.0.0, commit f27d603f401751a772fcade069038b45c248fe42; canonical registry labeled v1.0.0.

Software license: Apache 2.0.

Abstract

Base120 organizes 120 named reasoning prompts into six families: Perspective, Inversion, Composition, Decomposition, Recursion, and Systems. It combines a versioned catalog with a Python lookup and prompt-generation SDK, a command-line interface, and a JSONL record format. We describe the taxonomy as a design framework for selecting and documenting reasoning strategies, and audit its correspondence to a pinned software release. That release contains 20 operators per family and no third-party runtime dependencies. Its engine constructs prompts and records externally supplied recommendations; it does not execute or validate the reasoning itself. We distinguish catalog coverage from cognitive completeness, prompt composition from a typed program calculus, and append-mode storage from tamper-evident audit infrastructure. The contribution is a reproducible vocabulary and interface design. Improvements in decision quality, completeness of the taxonomy, and production safety remain empirical questions.

1. Problem and contribution

A decision-maker may want to ask whose perspective is missing, how a plan might fail, which components can be separated, and how feedback changes a proposed solution. A flat list of techniques makes these questions available but does not prescribe how to select among them. Base120 groups techniques by their intended transformation, assigning stable identifiers that can be included in prompts and decision records.

The term mental model has a specific representational role in cognitive science [1]. Here, reasoning operator is a software catalog term: a named technique and natural-language instruction, not a mathematical function with proven semantic properties. Base120 includes heuristics, representational devices, and procedural suggestions. Sharing a catalog interface does not make their evidentiary status or logical strength equivalent.

The paper makes three bounded contributions:

1. A six-family organizing framework and an explicit account of how it can guide selection.
2. A source-verified description of the v2.0.0 software and its information-loss boundaries.
3. A reproducible release audit and a proposed evaluation separating catalog usability from decision quality.

This is not a systematic review of all mental-model software. Earlier unpinned feature and star-count comparisons do not establish that Base120 is the first or only resource with these features. There is no controlled decision-quality study or released production trace in this paper.

2. Taxonomy and operational definitions

Counts are computed from both the canonical YAML and packaged JSON in the pinned release [2]. They correct the earlier table's 18/18/20/20/20/20 counts. The canonical YAML labels SY “Systems”; the v2 SDK's FAMILY_NAMES labels it “Synthesis.” This paper follows the canonical domain heading and records the naming mismatch rather than treating both files as identical.

2.1 Design rationale and boundary cases

Perspective/Inversion, Composition/Decomposition, and Recursion/Systems are useful organizing pairs. They are not three orthogonal axes from which all possible reasoning transformations are derived. In particular, feedback can be described at both the Recursion and Systems levels, and decomposition often changes perspective. One primary family per identifier is an editorial assignment; it is not proof of semantic disjointness.

Examples verified against the release include P6 (Point-of-View Anchoring), P18 (Boundary Object Selection), IN2 (Premortem Analysis), IN6 (Inverse/Proof by Contradiction), CO1 (Synergy Principle), CO4 (Interdisciplinary Synthesis), DE1 (Root Cause Analysis (5 Whys)), DE2 (Factorization), RE1 (Recursive Improvement (Kaizen)), RE2 (Feedback Loops), SY1 (Leverage Points), SY6 (Feedback Structure Mapping), and SY13 (Incentive Architecture). These names are catalog labels; for example, prompting IN6 does not ensure that the response is a valid proof by contradiction.

The equal family sizes are a catalog design choice. The release does not establish that 20 is an optimal number per family, that additional operators would be redundant, or that a human population would independently recover these six categories. Those claims would require documented item-selection criteria and classification studies.

2.2 Sequencing operators

An illustrative workflow is:

P2 Stakeholder Mapping
  -> IN2 Premortem Analysis
  -> DE1 Root Cause Analysis (5 Whys)
  -> CO4 Interdisciplinary Synthesis
  -> RE2 Feedback Loops
  -> SY13 Incentive Architecture

For a service migration, this could identify affected users, imagine failure, isolate causes, combine proposed remedies, specify feedback, and inspect incentives. A caller passes the relevant output or a summary to the next prompt. The SDK does not implement a type checker, precondition calculus, or correctness-preserving composition rule for this sequence. Its “composition grammar” is therefore a workflow convention.

Define family coverage for a sequence $O$ as $C(O)=|\{family(o):o\in O\}|/6$. This measures only how many catalog families were selected. A sequence with $C=1$ can still miss critical facts, misuse every operator, or produce a wrong recommendation. A sequence with lower coverage may be entirely appropriate for a narrow task. Coverage must not be reported as a proxy for decision accuracy without validation.

3. Versioned software artifacts

The canonical YAML provides identifiers, names, and definitions. Its version is stated in a comment; it contains schema_version: base120.schema.v1 and canonical: true, but does not contain the per-item family or top-level version fields shown in the earlier manuscript's example. Family membership is recoverable from the identifier prefix. The following excerpt wraps the original one-line definition using equivalent YAML folding:

schema_version: base120.schema.v1
canonical: true
models:
  - id: P1
    name: First Principles Framing
    definition: >-
      Reduce complex problems to foundational truths
      that cannot be further simplified

The SDK loads base120/data/operators.json, whose fields are code, name, transformation, and definition. It does not parse the YAML at runtime. The companion audit checks identifier and family coverage in both representations; it does not establish full text equality or the psychological validity of a definition. Third-party YAML parsers are needed for general-purpose YAML consumers but are not SDK runtime dependencies.

The release's pyproject.toml requires Python 3.11 or later, declares an empty runtime dependency list, and registers base120 = base120.cli:main. It does not register a base120-mcp console script. MCP is an available integration protocol [3], but an MCP server claim needs a separately identified implementation/version and conformance checks. This paper makes no such implementation claim for v2.0.0.

4. SDK semantics

The release exposes lookup (get), filtered listing (list), family codes (families), prompt construction (prompt), keyword selection (select), and recording (record).

from base120 import Engine, Ledger

engine = Engine()
operator = engine.get("P6")
assert operator is not None
assert operator.name == "Point-of-View Anchoring"
prompt = engine.prompt("P6", "How should we price a service?")

# The recommendation and confidence come from the caller.
result = engine.record(
    "P6",
    "How should we price a service?",
    "Assess affordability from the purchasing team's perspective.",
    0.85,
    actor="example-agent",
)
ledger = Ledger("decisions.jsonl")
ledger.append(result.to_tuple())

prompt() includes the catalog definition and requests a recommendation, confidence, and reasoning. It does not call a model. record() validates the operator and confidence range and constructs an ApplyResult; it does not apply the technique or check the supplied answer. select(problem, n) ranks name/definition token overlap, so it is a lexical heuristic rather than a validated semantic recommendation model.

Lookup and prompt generation are deterministic for fixed release data and inputs. The full recording path is not byte-for-byte deterministic: ApplyResult creates a random UUID, and to_tuple() creates a UTC timestamp. Calling to_tuple() twice may create two timestamps for the same result. Reproducibility tests should compare deterministic fields separately from event identifiers and time.

The CLI supports:

base120 list
base120 list --family DE
base120 get P6
base120 prompt P6 "How should we price a service?"
base120 families

5. Ledger representation and assurance boundary

ApplyResult stores the problem, recommendation, confidence, evidence UUID, and caller metadata. Its ledger projection is smaller:

The projection drops the original problem, evidence UUID, and metadata, including the example actor. Thus this ledger alone cannot reconstruct which agent acted, the full prompt chain, or the identity of an application event. Applications needing those fields must retain the complete result in a separate, documented envelope. Such an extension is outside the audited v2 ledger format.

Ledger.append() opens a JSONL file in append mode; project() reads records, and cut(d) returns records whose stored drift is strictly greater than d. The API does not modify earlier entries. Another process with filesystem write permission can still modify, truncate, or replace the file. There is no signature, hash chain, external checkpoint, or identity verification in this implementation. Append-mode storage supports later inspection, but does not establish immutability, deletion detection, truthful reasoning, or non-repudiation.

Reported confidence is uncalibrated. Consequently drift is not a measured distribution shift, error probability, or distance from a validated behavioral target. Calibration would require predictions paired with scored outcomes; selecting low-confidence records is a review heuristic.

6. Reproduction and evidence status

Run the release audit against any local clone containing the pinned commit:

python papers/base120-reasoning-taxonomy/audit_release.py /path/to/base120

The script uses Git object reads without changing the clone or installing the package. It verifies the two identifier sets, expected 1–20 ranges for six families, and packaged family prefixes; it prints the release commit, registry SHA-256, counts, dependencies, and console scripts as JSON. Expected counts are 120/120 and 20 per family. The release pin prevents unrelated later features from silently changing these results.

The audit establishes catalog structure and package declarations. Direct source inspection establishes the SDK and ledger semantics described above. Neither method measures successful reasoning, model behavior, deployment adoption, or resistance to adversarial modification. The historical claim “120 tests, all passing” lacks a version-bound transcript in this paper and is not carried forward as a reproduced result.

7. Proposed empirical evaluation

Three questions should be studied separately:

1. Classification reliability: Give independent raters operator definitions with names and codes hidden. Ask them to assign primary and secondary families using a fixed codebook. Report confusion matrices, agreement, disagreement resolution, and uncertainty across raters and items. Predefine how multi-family assignments count.
2. Selection utility: Compare a flat catalog, the six-family catalog, and a size-matched alternative grouping on held-out tasks. Measure selection time and appropriateness against expert criteria; hold descriptions, search access, and display information constant except the grouping.
3. Decision quality: Randomly assign tasks to unstructured reasoning, family-guided reasoning, and an equal-budget checklist control. Hold model/version or participant expertise, time/token budget, and access to evidence constant. Blind evaluators to condition, preregister scoring and primary contrasts, report all exclusions, and account for repeated tasks and raters.

An ablation should distinguish the effect of explicit questions from the effect of this particular family assignment. Self-reported confidence and family coverage are secondary process measures, not the primary quality endpoint. No results from these proposed studies are reported here.

8. Limitations and conclusion

The catalog is curated in English, contains overlapping techniques, and has not been established as an exhaustive or minimal basis for cognition. Category boundaries and equal group sizes need empirical justification. The SDK structures prompts and records supplied text; correctness depends on the user or agent and its evidence. The compact ledger omits important provenance and has no independent integrity mechanism.

Base120's supported contribution is a versioned vocabulary, navigation framework, and lightweight software interface. Its pinned artifacts make implementation claims inspectable. Whether the taxonomy improves decision-making is a testable hypothesis rather than a consequence of having 120 names or six families.

References

[1] Johnson-Laird, P. N. (1983). Mental Models: Towards a Cognitive Science of Language, Inference, and Consciousness. Harvard University Press. Author laboratory bibliography.

[2] HUMMBL. Base120, SDK v2.0.0, commit f27d603f401751a772fcade069038b45c248fe42. Pinned source. Source audit performed 2026-10-10; see audit_release.py and the associated research notebook.

[3] Model Context Protocol. Specification, 2025-06-18: Overview. Versioned specification. Cited as an integration protocol, not evidence that the audited release implements it.