English · Español
A framework for learning and reasoning under accelerated technological change.
Invariant Thinking is an open conceptual framework for separating transferable structure from implementation-specific novelty. Its purpose is practical: when a new technology appears, do not relearn the entire surface. Identify what remains structurally true, test the limits of that mapping, and invest deep learning effort in the actual delta.
Learn what survives the change.
Draft 0.1 — open proposal.
Invariant Thinking is not presented as a scientifically validated theory of cognition. It is a structured framework, vocabulary, and repeatable method intended for use, criticism, case studies, and future empirical evaluation.
English is the canonical language of the framework. The Spanish translation is available in README.es.md, with translated core documents under docs/es/. Translations improve accessibility but do not replace the canonical English specification.
In fast-moving technical domains, tools, frameworks, APIs, interfaces, and product categories change faster than a practitioner can study each manifestation independently. A purely implementation-centered learning strategy creates recurring cognitive rework.
Invariant Thinking proposes a different unit of learning:
product -> implementation -> mechanism -> pattern -> constraint -> invariant
The deeper the reusable structure, the more future systems it may help explain. The framework does not assume that everything new is merely old technology with new branding. Its method explicitly searches for where analogies fail and where genuine novelty begins.
| Layer | Question | Typical volatility |
|---|---|---|
| L5 — Product / Interface | What do users or developers interact with? | High |
| L4 — Implementation | How is the capability concretely built? | High |
| L3 — Mechanism | By what mechanism does it work? | Medium-high |
| L2 — Pattern | What recurring organization solves this class of problem? | Medium |
| L1 — Constraint | What limits the solution space? | Low-medium |
| L0 — Invariant | What relevant property must remain true across the defined transformation? | Context-dependent, often low |
An invariant is never claimed in isolation. A valid Invariant Thinking statement identifies:
- the property claimed to remain relevant;
- the transformation set across which it is being compared; and
- the boundary within which the claim is intended to hold.
The operational method is DELTA:
- Decompose — break the system into actors, state, inputs, outputs, boundaries, resources, transformations, and dependencies.
- Extract — identify constraints and candidate invariants.
- Link — map those structures to prior knowledge and known patterns.
- Test — actively search for where the analogy, invariant, or prior model breaks.
- Acquire — learn the irreducible delta that remains.
The conceptual relation is:
new system
- correctly transferable prior knowledge
= learning delta
This is a reasoning aid, not a quantitative equation.
Every Invariant Thinking analysis should be able to answer:
- What changed?
- What remained true?
- Under which transformation and boundary?
- Where does the analogy break?
If the fourth question is missing, the analysis is incomplete.
SPEC.md— normative definition of the framework.DELTA-PROTOCOL.md— operational procedure.PRINCIPLES.md— design principles.GLOSSARY.md— controlled terminology.NON-CLAIMS.md— explicit statements the framework does not make.LIMITATIONS.md— known weaknesses and failure modes.PRIOR-ART.md— intellectual context and related work.RESEARCH.md— testable hypotheses and research agenda.examples/— worked analyses.maps/template.yaml— reusable Invariant Map format.rfcs/— proposed changes to the framework.README.es.mdanddocs/es/— Spanish translation.
A new framework introduces server-side function invocation directly from UI code.
A shallow reading says: "this replaces APIs."
An Invariant Thinking analysis asks:
- Changed: invocation ergonomics, routing abstraction, framework integration.
- Candidate invariants: trust boundaries, authorization, validation, serialization, failure, latency.
- Boundary: multi-user network applications invoking privileged server behavior.
- Analogy break: framework-mediated actions are not semantically identical to public REST endpoints.
- Learning delta: framework-specific execution, serialization, caching/revalidation, lifecycle, and security semantics.
The goal is not to deny novelty. The goal is to locate it accurately.
A contribution must do more than assert that two technologies are "basically the same." It should identify the transformation, state the invariant boundary, provide evidence or reasoning, and include at least one plausible analogy break or counterexample.
See CONTRIBUTING.md.
Invariant Thinking builds on long-standing ideas around invariance, abstraction, structural reasoning, analogy, schema formation, and transfer. The claim of this project is not that the word invariant or the general value of abstraction is new.
The proposed contribution is the specific combination of:
- the Invariant Stack;
- Transformation + Boundary as required context for invariant claims;
- the Learning Delta as the target of deep learning effort;
- the DELTA Protocol;
- Invariant Maps as a reusable analysis artifact; and
- explicit analogy-break testing as a guard against reductionism.
See PRIOR-ART.md.
If you use or discuss this framework, see CITATION.cff.
The conceptual and written material in this repository is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). See LICENSE.md.