Governing a classification system requires more than a list of state-types and a procedure. The system must also declare which higher-order distinctions govern its evidence procedure, its versioning discipline, its closure standard, and its authorization rules. Orthemology formalizes this with two related objects: the metaorthemeDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/theislampill/orthemology/llms.txt
Use this file to discover all available pages before exploring further.
μ (the repeatable governing configuration and its paired meta-policy) and the metaorthemma μ̄ (the concrete, case-bound configuration token inside a specific episode). These two objects stand in a type–token relation of their own — the metaortheme is the type, the metaorthemma is the token.
The term “metaorthemma” is benchmark-gated candidate vocabulary. The word is a candidate pending the terminology benchmark described in the manuscript’s Section 13.3. The object it refers to — the case-bound configuration token — is adopted and implemented; the word’s utility over ordinary language is undecided. Every coined term in Orthemology is governed by the same rule.
The Metaortheme Type μ
A metaortheme is a metaorthemic configurationμ paired with a separable meta-policy π_μ:
The stable identifier for this metaortheme type.
ver(μ) — recorded per episode so audits can scope which placements ran under which edition of the rule.g — which part of the handling machinery this distinction governs. Must be one of O, I, E, D, R, V, or W. See the governed-component table below.S_μ — the set of declared competing higher-order states the governing context may occupy. Must be declared in advance, not read off a single incident. Requires at least two members.select_μ — the state-selecting evidence procedure that determines which state in S_μ actually obtains for a given episode. A typed object with kind and description required; a bare string is not a valid selector.π_μ — the conduct rule conditional on the obtaining state, including what the rule prescribes on undetermined selection. Either meta_policy or policy_ref is required; a metaortheme without a paired meta-policy is not a metaortheme.prov(μ) = ⟨authority, warrant, scope⟩ — the rule’s own provenance. A rule of unknown provenance is a stale-evidence problem one level up.Governed Components
The governed componentg must be drawn from the following declared set. Objectives, loss functions, the task itself, and the governance meta-level are excluded.
| Code | Component | Governs |
|---|---|---|
O | Repertoire | Which state-types exist and may be posited or retired |
I | Individuation | What counts as the same case; identity keys, versioning, lineage |
E | Evidence | What evidence counts, of which property class, at what grade |
D | Disclosure | What may be left open, and how open questions must be declared |
R | Routing | Where cases are sent; what happens when the correct route is unavailable |
V | Validation/closure | What may be called done, at what standard, when a completion claim must be reopened |
W | Warrant-classification | Which warrant states exist (authorized vs established) and what each licenses |
The Selector: A Typed Object
The selectorselect_μ is not a bare description — it is a typed object with declared fields:
Full metaortheme schema example
Full metaortheme schema example
Anti-Vacuity Conditions
A candidateμ is admitted as a metaortheme only if all four conditions hold:
gis named — the governed component is explicitly declaredS_μis declared in advance — the competing higher-order states are specified before any episode runs, not read off a single incident- The distinction is consequential — switching the obtaining state changes validated placement, risk, or constraints in at least one episode class
- It is not a disguised first-order ortheme or policy parameter — a good policy that consults no in-advance-declared competing higher-order states is just a good policy
The Metaorthemma Token μ̄
The metaorthemmaμ̄ is the concrete, case-bound configuration token of a metaortheme type inside a specific episode. It is not the episode; it is not the execution event. It references the episode’s evidence and trace; it never absorbs them.
Metaorthemma Schema Fields
Required fields
Required fields
The token’s own identity and lineage. Each metaorthemma is individually identified.
MetaInst(μ̄, μ) — exactly one metaortheme type reference (mu_id + mu_version). Single-typing is the current rule; a case governed by several types uses several separate tokens.Compatible(μ̄, A(e)) — the analysis this token is compatible with (analysis_id + version). The token binds case-specific values within the declared analysis; it never overrides A without a new analysis version.The target occurrence
(κ, v) — identity_key + version. The token is occurrence-anchored.Must match the governed component of the parent metaortheme type.
The case-specific binding map
B — reference frame, tolerance value, fixture, success surface, instrument, calibration, etc. Must be non-empty: a metaorthemma exists only where material case-specific binding exists (the zero-burden rule).Who or what made the binding —
actor, binding_warrant (w_bind), and binding_time. Kept distinct from the designated executor.The temporal window:
effective_from, expiry, superseded_by. A binding with no declared start is undated governance; effective_from or a declared validity_unbounded_reason is required.The claims in
𝒬(e) that depend on this token. Must carry the dependent claims, an explicit reason why no claim depends on this token, or a declared external scope model.Full metaorthemma schema example
Full metaorthemma schema example
The Four Layers
The split-model formalization keeps four layers explicitly separate:Type μ — the repeatable governing configuration
The metaortheme type: which component it governs, which states it declares, which evidence selects among them. Adequacy verdict: V3a (GOV_CONFIG_ADEQUATE).
Policy π_μ — the repeatable conduct rule
The meta-policy paired with the type: what the system must do conditional on the obtaining state. Adequacy verdict: V3b (GOV_POLICY_ADEQUATE).
Token μ̄ — the case-bound configuration binding
The metaorthemma: the concrete token that applies the type’s binding to a specific occurrence under a specific analysis, with declared scope, calibration, and binder warrant. Adequacy verdict: V3c (GOV_TOKEN_ADEQUATE).
The adequacy questions at each layer are independent. A correct standard (V3a pass) can carry an ill-formed policy (V3b fail). A correct standard and sound policy can have a defective case-binding (V3c fail) — wrong reference plane, wrong-role tolerance, expired calibration, wrong fixture or success surface. And a correctly bound token can be faithfully executed by an executor who still makes an error at the procedure level. Each layer routes to a different remedy.
V3c: GOV_TOKEN_ADEQUATE
The verdictV3c (GOV_TOKEN_ADEQUATE) judges every concrete metaorthemma applied in an episode:
TokenAdequate(μ̄, e) holds iff:
| Conjunct | What it checks |
|---|---|
MetaInst(μ̄, μ) | The token is an instance of a declared metaortheme type |
Compatible(μ̄, A(e)) | The token is compatible with the episode’s declared analysis |
Anchored(μ̄, κ(e), v(e)) | The token is anchored to the correct occurrence identity and version |
ScopeCorrect(μ̄, 𝒬(e)) | The token is scoped to exactly the claims that depend on it |
Current(μ̄, t(e)) | The token’s validity window covers the episode time |
Provenanced(μ̄) | The token has declared and traceable provenance |
AuthorizedBinding(μ̄) | The binding was made under authority |
μ̄_2: stale calibration; μ̄_3: wrong claim scope.
Zero-burden rule: when MetaTok(e) = ∅ (no material case-specific binding exists), V3c ∉ ReqPath(e) and the status is recorded not-applicable with a reason. The absence of metaorthemmata is an explicit recorded fact, not silence.
Plurality, Conflict, and Precedence
A typical episode runs under several metaorthemes at once:≼. An unresolved conflict is an ANDON condition — stop or escalate. Silent override is itself a metaorthemic error.