Orthemology is a proposed theory of how concrete cases get correctly classified, handled, and audited by rule-governed processes — whether those processes are human, institutional, or automated. It gives first-class, auditable structure to a familiar but usually implicit architecture: a concrete occurrence arrives, someone or something determines which repeatable state-types it instantiates, routes it accordingly, and closes the record. The framework’s contribution is not any single component of that lifecycle but the union of them — and one further object, the reified handling episode carrying a joint verdict vector that independently judges whether the result was correct and whether the process that produced it was adequate.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.
Six core terms
Every component of the framework maps to a concrete object or process. The table below gives an ordinary-language gloss; the pillar column shows the same concept as it appears in the worked construction-site example included in the repository.Orthemma
The concrete situated case, with an identity key and a version. Every orthemma is a specific, dated token — not a kind of thing, but this thing, now. Example: this particular pillar, as it now stands.
Ortheme
A repeatable, consequence-bearing operational state-type the case may instantiate. Orthemes are the type pole: stable, re-usable descriptions a case either satisfies or does not, relative to a declared analysis. Example: orthogonal to a declared reference plane within tolerance ε.
Metaortheme
A repeatable higher-order governing standard or configuration. A metaortheme fixes which reference frame, tolerance, instruments, calibration, evidence rules, and validation procedures count for a given profiling task. Example: the site standard fixing which reference frame, tolerance, instruments, calibration, evidence, and validation count for perpendicularity checks.
Metaorthemma
The concrete, case-bound configuration token of a metaortheme inside a specific episode. It binds the abstract standard to this case, this instrument, this calibration certificate, for this orthing episode. Example: the perpendicularity standard bound to pillar B7’s datum plane, instrument level-114, and calibration cert 2026-06-20.
Orthing
The whole rule-governed handling process — identifying the case, applying the bound standard, gathering evidence, placing, validating, routing, and closing. Orthing is a process type; it stands to its runs as “compilation” stands to one specific build. Example: identifying the pillar, applying the bound standard, gathering four-face level readings, routing, and closing.
Orthing Episode
One dated, concrete run of that process — the auditable record on which all verdicts are defined. Two episodes are distinct occurrences even when their inputs and outputs agree. Example: the record of today’s perpendicularity check on this pillar.
Two ideas that carry the theory
Result correctness is not pathway adequacy
An episode’s result can be right while the process that produced it was defective — the stopped-clock validator, the wrongly-calibrated instrument that happens to agree with the true state. Conversely, a genuinely reliable, correctly-run process can still miss a rare case. The framework keeps these axes strictly independent. The result axis (V1) judges whether the placed profile matches the case’s true profile under the declared analysis. The pathway core — a result-free set of verdict dimensions covering evidential support, procedure truth-conduciveness, evidence currentness, configuration adequacy, policy adequacy, governing-token adequacy, executor fidelity, decision-time justification, route safety, closure truthfulness, and robustness — judges the process without reference to whether the answer happened to be correct. All four combinations of result × pathway are representable; the deterministic fixture suite proves each cell is inhabited.Ground truth is analysis-relative
Which state-types a case truly instantiates is defined relative to a declared, versioned analysisA — a record that specifies the task, the repertoire of state-types, the evidence rules, the tolerance, the representation family, and the governance boundary. The true profile is written O*(m; A). The familiar task-relative shorthand O*_T(m) survives only as explicitly scoped abbreviation once a single analysis is fixed; it is not a second ontology, and it is forbidden wherever more than one analysis is live (level-indexed audits, multi-actor episodes, cross-version comparisons). The case itself and its worldly facts are not created by the analysis; only the state-type description is indexed.
What the framework provides
The repository is organized around four interlocking artifacts:- JSON Schemas — machine-enforced schemas for analyses, orthemmata, metaorthemes, metaorthemmata, orthing episodes, claim ledgers, and verdict records.
- Worked examples and fixtures — nine machine-readable episode examples validated against the schemas, plus deterministic fixtures F1–F7 witnessing all four result × pathway cells and negative fixtures I01–I48 proving the validators reject invalid inputs.
- Normative registries —
verdict-registry.yaml(semantic IDs and display aliases for all verdict labels) andnotation-registry.yaml(the symbol table), both machine-enforced in CI. - Validator scripts —
scripts/validate_schemas.pyandscripts/validate_repo.pyfor schema and full-suite consistency checks.
Honesty notes
The coined vocabulary is candidate terminology only. The companion theological and metaphysical papers are complete drafts, deliberately separated from the main manuscript under an absolute firewall: philosophical conclusions are conditional on labeled premises, and no engineering evidence supports any metaphysical claim. Related-work claims carry per-claim verification statuses; the machine registry is authoritative for its declared claim families.Explore the framework
Quickstart
Validate the schema suite and run your first fixture test in four steps.
Architecture Overview
A structural map of the framework’s layers: domain, governance, episodes, verdicts, and levels.
Type and Token
How orthing and orthing episodes relate as process type and dated run, and why the distinction matters for audits.
Verdicts and Pathway Adequacy
The full verdict vector: result axis, pathway core, and how PathwayAdequate is derived from governance.
Orthemma and Ortheme
The type–token poles of classification: concrete occurrences and repeatable state-types.
Worked Example: Pillar Episode
Step through the full pillar-episode JSON: analysis, metaorthemes, episode, claim ledger, and verdict record.
Schemas Overview
The JSON Schema suite covering every object type in the framework, with validation scripts.
Verdict Registry
Normative semantic IDs and display aliases for all 14 verdict labels (machine-enforced).
Experiments Overview
Designed studies and terminology benchmark — status, readiness, and what remains unrun.
Glossary
Plain-language definitions of all coined terms, with formal references.