Skip to content

finkeissen/matrix

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

21 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Matrix Repository

Public, curated showcase of the Matrix within the Matrix/MMS research program.


Status

This document defines the scope of validity of this repository. It defines structural boundaries and admissibility conditions. It is not a working log and does not function as a development notebook.


Scope of Validity

This repository implements the Matrix as an instantiated component within a formally bounded research program architecture (Matrix / MMS).

It does not constitute:

  • a theory of the world,
  • an epistemology,
  • a truth theory,
  • a normative framework,
  • or an ontology.

It demonstrates how bounded formal coordination can be implemented.

Status of Claims

All artifacts in Matrix are treated as hypotheses.

Matrix does not decide correctness, truth, or validity. It does not confirm. It does not endorse.

Its function is diagnostic: to expose hidden assumptions, illegitimate transfers of authority, and structural tensions.

Whether a hypothesis is correct is not determined here.

Correction, validation, or rejection occurs only through:

  • explicit formalization,
  • application within a concrete world model,
  • and ultimately through use in practice.

Matrix may show that a hypothesis cannot work as stated. It never shows that it must be correct.

Practical use is the only non-hypothetical filter in this system. Everything else remains provisional.

Use and Utility of Knowledge

Within this system, knowledge is not treated as truth, representation, or explanation of the world.

All knowledge artifacts remain hypothetical.

The utility of knowledge is therefore defined pragmatically.

Knowledge is considered useful if it:

  • improves decision-making under explicit constraints,
  • reduces unexamined assumptions,
  • clarifies what can and cannot be done next,
  • makes trade-offs visible,
  • or enables justified STOP decisions.

Knowledge does not need to be true to be useful. It needs to be operable without hidden authority.

The primary function of knowledge in this system is not to eliminate uncertainty, but to structure action in the presence of uncertainty.

Practical use is the only context in which utility is tested. Outside of use, all knowledge remains provisional.

The goal of this system is not to produce correct knowledge, but to enable responsible action under uncertainty.

Knowledge Navigation

The system supports knowledge navigation.

Navigation does not guarantee correctness. It structures orientation under uncertainty.

Navigation consists of:

  1. Positioning (Where are we?)

    • Explicit articulation of current assumptions, constraints, and world context.
  2. Goal Clarification (Where do we intend to go?)

    • Explicit declaration of aims.
    • Goals are not derived by the system. They are provided by context or practice.
  3. Routing (How can we move?)

    • Exploration of admissible transitions.
    • Identification of constraints, trade-offs, and STOP conditions.
    • Selection of next executable steps.

The system does not decide the destination. It clarifies the map.


Scope Limits and Misuse

This system is not a worldview, a moral framework, or a substitute for existential meaning.

It is an operational instrument for structuring reasoned action under uncertainty.

Misuse occurs when the system is treated as:

  • a source of ultimate truth,
  • a moral authority,
  • a replacement for responsibility,
  • or a total framework for life.

The system does not generate motivation. It does not define values. It does not determine goals.

All motivation, value commitments, and responsibility remain external inputs.

The system may clarify constraints and consequences. It cannot relieve agents from decision-making.

Attempting to live inside the system instead of using it as a tool leads to distortion.

This scope constrains what can be addressed inside the system. It does not determine what matters, what is valuable, or what should be done.

This system does not aim to be immune to criticism.

Criticism is valid when it addresses:

  • internal inconsistency,
  • hidden transfers of authority,
  • unjustified exclusions,
  • or practical failure in concrete runs.

Criticism that presupposes a different paradigm must explicitly declare that shift.

Refusing undeclared paradigm shifts is not avoidance of critique, but enforcement of scope discipline.


Position of the Matrix

The Matrix is an instantiated component within a layered architecture. It is not the research program itself, and it does not define the scope of validity.

This document defines the boundary within which the Matrix operates. All Matrix-specific behavior is specified separately under 1.system/.


0.legacy/

Contents under 0.legacy/ are part of the repository but not part of the system architecture.

They document inherited bodies of knowledge and serve exclusively as raw material for later structural decomposition.

Their presence implies no recognition of truth, validity, or structural authority.


Language Architecture

The formal prerequisites of the system are treated under the field Language Architecture.

Language Architecture defines:

  • structural conditions of formal articulation,
  • admissible forms of symbolic operation,
  • and limits of formal systems.

It makes no claims about meaning, truth, or reality.


Boundary Topics

Topics such as logic, mathematics, truth, incompleteness, reality, or knowledge are handled strictly within their formal scope.

Any implicit transfer:

  • from formal properties to the world,
  • from provability to truth,
  • from structure to normativity,

is considered inadmissible and triggers refusal or STOP.


Architecture Progression

The research program follows a strictly layered construction. Later components do not ground earlier ones.

The intended build-up is:

  1. Language Architecture (Luftschloss)
    Formal preconditions for symbolic systems, models, and interpretation.
    No ontology, no semantics, no truth claims.

  2. Model Toolkit
    A construction kit for building explicit models:
    states, parameters, relations, observation layers, and purposes.
    Models are artifacts, not explanations.

  3. DBMS Layer
    Storage, versioning, provenance, and audit of artifacts and runs.
    The DBMS is intentionally blind to meaning and truth.

  4. MMS (Meta-Model System)
    Coordination, constraint enforcement, comparison, and composition
    of models within the admissible system scope.

  5. Matrix Instantiations
    Concrete, task-bound model configurations for analysis,
    experimentation, or application.

No layer licenses an ontological or epistemic upgrade of earlier layers. Pragmatic success at higher layers does not retroactively ground lower layers in reality.

Note: Files like stress_test.md are generated and stored per run under 2.runs/..., not as a single global document in the root.


Repository Character

This repository is intentionally curated.

It demonstrates:

  • structural layering,
  • admissibility constraints,
  • formal artifact schemas,
  • and a small number of representative example runs.

It does not aim to provide:

  • exhaustive domain coverage,
  • a comprehensive dataset,
  • or a complete knowledge archive.

Architecture Overview

The architecture consists of four strictly separated layers:

  1. Legacy
    Preserves prior assumptions, unresolved contradictions, structural patterns, and contextual material that exist before admissibility, governance, or instantiation. ↓
  2. Research Program (RP)
    Defines ontological primitives and admissible structural forms. ↓
  3. Meta-Management System (MMS)
    Enforces admissibility rules without structural or epistemic authority. ↓
  4. Matrix
    Records concrete instantiations, conflicts, STOPs, and explicit absences.

The Matrix contains only what remains after RP definition and MMS enforcement.

No layer may absorb the role of another.

Work Status

Open tasks, development order, and working notes are not part of this document and are maintained separately from the scope definition.

Governance (Binding)

This repository is governed by:

  • foundation/README.md (Foundation gate; includes operational STOP + Occam)
  • 2.runs/README.md (Run semantics; runs are diagnostic, terminate by STOP)
  • Gaps/README.md (Non-knowledge as first-class terminal outcomes)

Runs may produce Absence, Gap, or Silence. No canonical artefact may enter 3.commit without traceable run provenance.

Paradigms and Illegitimate Transitions

Many reasoning systems implicitly assume a paradigm: a set of rules that determines which kinds of questions, operations, and justifications are considered admissible.

Examples include:

  • probabilistic reasoning
  • optimization frameworks
  • decision-theoretic models

Within such paradigms, certain transitions (e.g. quantification, aggregation, comparison) are treated as legitimate by default.

This system does not assume any such paradigm.

Paradigm shifts are treated as explicit structural changes, not as implicit improvements or refinements.

Introducing probabilistic, statistical, or optimization-based reasoning constitutes a paradigm change that must be explicitly declared and scoped.

Undeclared paradigm shifts are treated as illegitimate transfers of authority.

In this sense, the system is compatible with historical and methodological accounts that treat paradigms as constraints on admissible operations, rather than as progressively truer representations of reality.

Paradigms of Operation

FP, MMS, and Matrix are paradigms in the strict sense: they impose constraints on admissible operations.

They are not paradigms of explanation, prediction, or truth. They are paradigms of disciplined reasoning under uncertainty.

Paradigms of Operation

FP, MMS, and Matrix are paradigms in the strict sense: they impose constraints on admissible operations.

They are not paradigms of explanation, prediction, or truth. They are paradigms of disciplined reasoning under uncertainty.

Verification

  • Status: VERIFICATION_STATUS.md
  • Index: VERIFICATION_INDEX.md

Repository Structure

0.legacy/ – Historical / raw source material (non-canonical) 1.system/ – Canonical system specification (normative core) 1.handbook/ – Explanatory documentation (non-normative guidance) 2.work/ – Active drafts and experimental development 2.runs/ – Append-only diagnostic runs 3.commit/ – Publication-ready artifacts / curated exports foundation/ – Shared conceptual or structural base layer


Structured Claim Records (Addendum)

To support mechanical auditability under MMS enforcement, claims may be stored in structured form.

This does not change their status as hypotheses.

A machine-validatable schema may be defined under:

1.system/matrix/schemas/

Structured storage does not introduce authority. It only enables:

  • deterministic provenance tracking
  • admissibility validation
  • trace reconstruction
  • audit consistency under scaling

All claims remain hypothetical and non-authoritative.

Role in the epistemic flow

The Matrix records the epistemic states that remain after Research Program definition and MMS enforcement.

It does not produce knowledge. It records admissible structure.

Possible states include:

  • instantiated artifact
  • explicit absence
  • STOP
  • Gap or Silence

Artifact lifecycle

Artifacts may:

  • enter the Matrix when admissible,
  • remain provisional,
  • regress via STOP,
  • or be preserved as unresolved structure in Legacy.

The Matrix therefore represents states, not conclusions.

Interface to MMS

MMS determines admissible transitions. The Matrix records their outcomes.

MMS enforces constraints. The Matrix preserves resulting epistemic states.

External orientation

The Matrix is where the effects of the architecture become visible: structure, conflict, STOP, and absence.

Engine / Step Separation

The pipeline is now structured as a chain of locally executable steps. Each step can be treated as a separate work unit with an explicit Input -> Step -> Output contract.

Static step work packages live under engine/steps/. Runtime step artifacts are written under data/runs/<run-id>/steps/<step>/run/.

See ENGINE.md for the step-oriented engine layout.

About

The Matrix ist the knowledge structure connecting information about a large number of problems from 80 domains and respective solutions including their history. Based on research-program (theory, audit) and mms (roles, governance).

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors