Skip to main content

Documentation 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 two foundational objects of Orthemology are the concrete occurrence and the repeatable state-type that describes it. An orthemma is any concrete situated occurrence — this utterance, this word-token, this patient presentation, this build report for this commit — taken as something to be apprehended and handled. An ortheme is the repeatable, consequence-bearing operational state-type that an orthemma may instantiate relative to a declared, versioned analysis. The relation between them — instantiation — is the primitive from which every downstream concept is derived.

​
The Orthemma: Concrete Situated Occurrence

An orthemma is not an abstract description; it is the concrete case itself, with two formal attributes that track its identity through time:

Identity Key κ

κ = id(m) — which thing this is. The identity key survives change: the same file before and after an edit shares one κ. It is conceptually distinct from location (a storage slot is not an identity key) and from ordinal position (sequence position in a list is not an identity key).

Version v

v = ver(m) — which state or edition of that thing. Two orthemmata can share an identity key and differ in version (the same file at two different commits). Two can share an observation and differ in identity (a reused slot occupied by a new file).
The orthemma schema formalizes this structure. The two required fields are identity_key and version; everything else is optional but typed: 
{
  "identity_key": "repo/src/main.py",
  "version": "commit-abc123",
  "kind": "artifact",
  "lineage": [
    {
      "from_identity": "repo/src/main.py",
      "from_version": "commit-ab0000",
      "action_label": "edit",
      "producing_episode": "ep-build-0042"
    }
  ],
  "reified_from_episode": null
}
​
identity_key
string
required
κ — which thing this is, surviving change. Must be non-empty. Used as the anchor target by metaorthemmata and handoffs.
​
version
string
required
v — which state or edition of that thing. Must be non-empty.
​
kind
string
Domain kind of the occurrence. Examples: artifact, batch, position, directive, reified-episode. Guides the interpretation of the lineage structure.
​
lineage
array
Labeled successor edges into this occurrence (Definition 6 of the manuscript). Each item records which action on which predecessor produced this occurrence — from_identity, from_version, action_label, and optionally producing_episode. This is the formal object behind the transport principle: placements valid for (κ, v) do not transport to (κ, v′) across a successor edge without a lineage argument.
​
reified_from_episode
string | null
The ι_n embedding: set when this occurrence is an episode cast as a higher-audit case. Enables level-indexed audits without conflating the base and audit domains.
Placement validity is bound to (κ, v). A placement or validation established for (κ, v) does not transport across a successor edge to (κ, v′) — or to a different κ behind the same observation — without a lineage argument and, where the edge could have changed the placed property, fresh evidence. “Right finding, wrong copy” is a well-formed, detectable error in this framework; it is invisible to systems that have no formal version on the occurrence object.

​
The Ortheme: Repeatable Operational State-Type

An ortheme is a repeatable, consequence-bearing operational state-type that an orthemma may instantiate. “Consequence-bearing” is part of the definition: an ortheme is a type whose confusion with another type would change a warranted classification, prediction, investigation, route, validation condition, closure condition, or evaluation. An ortheme is not:
  • An actor’s local belief or judgment token
  • A single episode’s output
  • An objective or loss function
  • A metaortheme (a governing distinction over the machinery)
One orthemma typically instantiates several orthemes at once and at different descriptive levels. A build report can simultaneously instantiate a test-outcome type, an evidence-scope type, and a provenance-currency type. An Arabic word-token can simultaneously instantiate a lexeme, a lemma, a morphological pattern, and a syntactic role. An orthemma is not assigned to one mutually exclusive box.

​
The Analysis A: The Declared Ground-Truth Index

Ground truth is only defined relative to a declared analysis A. The analysis is explicit and versionable, carrying:
​
task
string
required
The task T = task(A) — the governing operation. Rules are task-indexed, never task-governing. A change to the task yields a new analysis version.
​
boundary
string
required
The system and governance boundary — what is inside the analysis scope and what is outside.
​
repertoire_ref
string
required
The active ortheme repertoire O_A ⊆ 𝓞 — the state-types in play for this analysis.
​
tolerance
number
The accepted tolerance ε_A for the merger gap — how different two state-types must be before their conflation incurs excess risk above the declared threshold.
​
axes
array
Where declared, the factorized axes of the profile space — each with an exclusivity marking (alternatives vs co-holding) and an applicability condition.
​
loss
string
The loss or evaluation function over outcomes. Objectives and losses are components of the analysis; they are not orthemes and are not metaorthemes.
​
hard_constraints
string
Hard constraints — conditions that no admissible placement may violate, regardless of the loss. Distinct from tolerance, which sets a soft threshold on the merger gap.
​
horizon
string
The declared temporal or causal horizon — how far forward (in time or in the causal graph) the analysis’s verdict obligations extend.
​
representation_family
string
The declared family of representations Rep_A — the set of ways the system may encode orthemic placements. The merger gap is computed relative to this family.
​
merger_family
string
The declared family of permitted mergers Rep_A^{i=j} — pairs of state-types the analysis declares admissibly collapsible.
​
governance_boundary
string
Where the governance authority stops — the declared scope of the analysis’s rule set. The regress terminates here.

​
The Instantiation Relation and True Profile

The primitive relation is: 
Inst_A ⊆ M_A × O_A
where (m, o) ∈ Inst_A reads: the orthemma m instantiates the ortheme o, relative to the declared analysis A. The orthemic profile of m under A is its fibre: 
O*(m; A) = { o ∈ O_A : (m, o) ∈ Inst_A }
This is the ground truth — the set of orthemes the occurrence actually instantiates, fixed by the occurrence and the analysis, independent of anyone’s evidence or belief. It is:
  • Not the observation of m
  • Not the inferred profile p̂ (the system’s belief)
  • Not the candidate set Ĉ (the open alternatives)
  • Not actor-relative (once A is fixed, O*(m; A) is an objective matter every actor can be wrong about)

​
Why Ground Truth Is Analysis-Relative

Two analyses A and A′ can share the same task T = task(A) = task(A′) while differing in tolerance, representation family, or governance boundary. Under A the orthemma may instantiate {compliant, evidence-grade-structural} while under A′ — with a stricter tolerance — it instantiates {non-compliant, evidence-grade-structural}. Both verdicts are objective relative to their declared analysis.This is not relativism. Analysis-relative means: the analysis is a declared, versioned, public index — not anyone’s private belief state. Once A is fixed, O*(m; A) is a fact that every actor can be right or wrong about.

​
The Instantiation Relation: Inst_A ⊆ M × O

The relation Inst_A is the primitive. Everything else — profiles, candidate families, placement, verdicts — is derived from it. Three facts about the relation are worth stating explicitly:
  1. It is not a function. One orthemma maps to many orthemes (the profile is generally not a singleton).
  2. It is analysis-indexed. There is no single task-only primitive; O*_T(m) is abbreviation, not a second ground.
  3. It is objective. The occurrence and its worldly facts are not created by the analysis; what is analysis-relative is which consequence-bearing state-type description truly applies.

​
The Profile Space

The profile space Π_A is the set of admissible complete profiles under the constraints declared by A: 
Π_A ⊆ 𝒫(O_A)
A partial profile p̂ ∈ Π_A^∂ leaves some axes undetermined. The inferred placement is always a partial profile — never a set of complete profiles (the candidate set Ĉ ⊆ Π_A is a distinct object that must not be collapsed into a single partial profile).
Five states that a factorized profile representation must never conflate: objective absence (the axis applies; nothing on it obtains), objective inapplicability (the axis does not apply — the not-applicable value), epistemic openness (the actor has not resolved the axis — a property of p̂, never of O*), evidence absence (no evidence bears on the axis), and candidate plurality (several complete profiles remain live). The first two live in profiles; the last three never do.

​
Summary

orthemma m  →  has  →  identity key κ, version v
                         ↓
              observed as  →  x = Ω(m)   [distinct from m]
                         ↓
      actual profile  →  O*(m; A)        [ground truth, analysis-relative]
                         ↓
    inferred profile  →  p̂(m)           [belief; judged by V1 vs O*(m; A)]
The occurrence m and its worldly facts are analysis-independent. What is analysis-relative is which profile of consequence-bearing operational state-types truly describes m in the declared repertoire O_A.

Build docs developers (and LLMs) love

Get started for freeTalk to us