Skip to content

Latest commit

 

History

History
163 lines (89 loc) · 2.93 KB

File metadata and controls

163 lines (89 loc) · 2.93 KB

RUN_ADMISSIBILITY.md

Purpose

This document defines the admissibility conditions for Matrix runs.

A run is any structured instantiation of the Matrix/MMS framework that attempts to produce, relate, or evaluate artifacts (claims, problems, relations, sources, etc.).

No run is valid by default. Admissibility must be explicitly established.


Definition of a Run

A run is an ordered, finite process that:

  1. declares a purpose
  2. specifies admissible artifact types
  3. assigns roles
  4. operates under explicit constraints
  5. produces traceable artifacts
  6. terminates under defined stop conditions

Any process lacking one of these properties is not a run.


Preconditions for Admissibility

A run is admissible only if all of the following are satisfied:

1. Declared Purpose

The run MUST declare:

  • its intended function (e.g. comparison, construction, exploration)
  • its scope boundaries
  • what it explicitly does not attempt to do

Implicit purposes are invalid.


2. Role Assignment

All roles involved in the run MUST be declared explicitly, including:

  • authoring roles
  • evaluation roles
  • arbitration or governance roles (if any)

Undeclared roles invalidate the run.


3. Artifact Scope

The run MUST specify:

  • which artifact types may be produced
  • which relations are admissible
  • which schemas are binding

Producing undeclared artifact types is invalid.


4. Constraint Awareness

The run MUST acknowledge:

  • applicable admissibility rules
  • applicable stop rules
  • applicable contracts

A run that does not explicitly bind itself to constraints is inadmissible.


5. Non-Transfer Condition

A run MUST NOT:

  • assert truth, correctness, or validity beyond its declared scope
  • transfer structural properties into claims about the world
  • imply epistemic authority

Violations trigger immediate stop conditions.


Termination Conditions

Every admissible run MUST define:

  • normal termination conditions
  • explicit stop triggers
  • rejection criteria

Runs that cannot terminate are invalid.


Evaluation of Runs

Admissibility evaluation is binary:

  • admissible
  • inadmissible

There is no partial admissibility.

Admissibility does not imply usefulness, correctness, or relevance.


Public vs. Private Runs

Public runs MUST satisfy additional constraints:

  • minimality
  • schematic character
  • absence of empirical claims
  • absence of domain authority

Private runs MAY relax these constraints but remain bound by all stop rules.


Consequences of Inadmissibility

If a run is inadmissible:

  • its artifacts are non-binding
  • its results must not be cited
  • it may not be extended
  • it must not be retroactively justified

Inadmissibility is a valid and expected outcome.


Summary

A run is not a result.

A run is a test of admissibility under constraint.

Only runs that survive constraint checking are allowed to exist within the Matrix system.