Orthemology is organized around a small number of interlocking layers. The bottom layer is the object layer: the domain of concrete occurrences and the repertoire of state-types that describe them. Above it sits the governance layer: metaorthemes and their case-bound tokens, which fix how any particular profiling task is to be conducted. Episodes sit on top of both: each episode is a dated, concrete run of a governed handling process, and it is the unit on which all audits are defined. The verdict layer spans the episode and produces an independent judgment on the result and on the process. Finally, the level structure allows episodes themselves to be cast as occurrences for higher-order audit. This page maps each layer in turn.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.
Objects: occurrence domain and state-type repertoire
A declared, versioned analysisA activates two sets:
- A domain
Mof concrete occurrences — orthemmata — each identified by an identity keyκand a versionv. Two observations of the same physical object at different times are different orthemmata if the version differs; this makes “right finding, wrong copy” a statable error rather than a silent assumption. - A repertoire
Oof repeatable operational state-types — orthemes. These are not created by the analysis; the analysis declares which ones are in scope.
Inst_A ⊆ M × O: analysis-indexed instantiation. The true profile of an occurrence m under analysis A is the fibre
x = Ω(m) is separate from the occurrence; the inferred profile p̂ is separate from both. The candidate set Ĉ(m) collects the complete profiles still compatible with the evidence at a given time.
Abbreviation convention. Once a single analysis
A with task T = task(A) is fixed by explicit declaration, the task-subscripted shorthands Inst_T, O*_T(m), Π_T and the unsubscripted M, O are permitted abbreviations. This shorthand is forbidden wherever more than one analysis is live — level-indexed audits, multi-actor episodes, cross-version comparisons, and execution-vs-review comparisons all require the full O*(m; A) form. The task-relative notation is an abbreviation, not a second ontology.Π_A collects all axis-consistent complete placements; the partial-profile space Π_A^∂ collects placements with some axes left open. The inferred profile p̂_t(m) ∈ Π_A^∂ is a belief state that may leave axes undetermined until evidence justifies closing them.
Governance: metaorthemes and metaorthemmata
Metaortheme structure
A metaorthemeμ is a repeatable higher-order governing standard or configuration. Formally:
g is the governed component (repertoire, individuation, evidence, disclosure, routing, validation, or warrant), S_μ is the set of admissible member states, select_μ is the selector procedure, prov(μ) is the provenance record (authority, warrant, scope), and ver(μ) is the version. Metaorthemes carry a meta-policy specifying how each member state is to be acted upon.
Metaorthemma structure
A metaorthemmaμ̄ is the concrete, case-bound configuration token of a metaortheme inside a specific episode. It is not the episode and not the execution event; it is the binding that makes the abstract standard operative for this case:
binding map fills in the abstract parameters of μ with concrete values (datum plane, instrument ID, tolerance value). The validity record tracks when the token is effective, when it expires, and whether it has been superseded.
MetaTok
The setMetaTok(e) collects all metaorthemmata active in episode e. The governing configuration in the episode record declares the metaortheme references and their precedence order; MetaTok(e) is the realized collection of their case-bound tokens.
Episodes: the auditable record
An orthing episodee is one dated, concrete run of a governed handling process. Its full signature is:
| Component | Notation | Description |
|---|---|---|
| Episode identifier | id | Unique, stable identifier for this episode record |
| Occurrence | m, κ, v | The orthemma being handled, with its identity key and version |
| Observation and evidence | x, H | The observation map output and the typed, scoped, expiring evidence set |
| Actor, warrant, analysis, task, time | α, w, A, T, t | Who ran the episode, under what warrant, under which declared analysis, for which task, and when |
| Governing configuration | μ⃗, MetaTok, π | The ordered metaortheme references, the realized metaorthemma tokens, and the precedence relation |
| Candidates and inferred profile | C⃗, p̂ | The candidate family (factorized over axes) and the episode’s inferred placement |
| Route | r | The action taken, drawn from the analysis’s declared action repertoire |
| Evidence status | estatus | Per-claim evidence validation status |
| Claim ledger | 𝒬 | The set of placement claims, each with its evidence references, success surface, and verification status |
| Residual dispositions | δ | Open burdens and their closure states |
| Handoffs | hand_in, hand_out | Incoming and outgoing handoff records, preserving provenance across actor boundaries |
| Action and successors | a, Succ | The executed action and labeled successor edges to next-version orthemmata |
v is applied to version v', the episode must carry a lineage record; “right finding, wrong copy” is a statable, detectable error in this structure.
Verdicts: result axis and pathway core
The verdict vector has two independent parts. Every verdict label is a semantic ID defined indocs/verdict-registry.yaml; the registry is authoritative in machine records.
Result axis
| Verdict ID | Name | What it judges |
|---|---|---|
RESULT_CORRECT (V1) | Placement correctness | Whether the placed profile matches O*(m; A(e)) |
TOKEN_TRUTH_LINKED (V2b-T) | Factive claim annotation | Whether each placement claim’s token is truth-linked to the case’s actual state |
Pathway core (result-free)
The pathway core is a set of verdict dimensions that judge the process without reference to whether the result happened to be correct.ReqPath(e) is the governance-derived subset of pathway dimensions that apply to episode e; statuses are four-valued (pass, fail, not-applicable, undetermined).
| Verdict ID | Name | What it judges |
|---|---|---|
EVIDENCE_SUPPORT (V2a) | Evidential support | Whether the evidence actually supports the placed profile |
PROCEDURE_RELIABLE (V2b-P) | Configured-procedure truth-conduciveness | Whether the configured selector procedure is truth-conducive |
EVIDENCE_CURRENT (V2c) | Evidence currentness | Whether the evidence is not stale relative to the case version |
GOV_CONFIG_ADEQUATE (V3a) | Configuration adequacy | Whether the governing configuration as a whole is adequate |
GOV_POLICY_ADEQUATE (V3b) | Policy adequacy | Whether the meta-policy is adequate for the task |
GOV_TOKEN_ADEQUATE (V3c) | Governing-token adequacy | Whether each metaorthemma token is well-formed and in force |
EXECUTION_FAITHFUL (V3d) | Executor fidelity | Whether the episode actor faithfully followed the configured procedure |
EX_ANTE_JUSTIFIED (V3e) | Decision-time justification | Whether the placement was justified given the information available at decision time |
ROUTE_ADMISSIBLE (V4a) | Route safety | Whether the route taken was admissible under the governing configuration |
ROUTE_QUALITY (V4b) | Near-optimality | Whether the route was near-optimal (advisory; not required for PathwayAdequate) |
CLOSURE_TRUTHFUL (V5) | Closure truthfulness | Whether the closure claim accurately represents the episode’s state |
ROBUST_NEIGHBORHOOD (V6) | Robustness | Whether the placement is stable under small perturbations of the evidence |
PathwayAdequate / PathwayDefective / PathwayUndetermined labels follow from the statuses of the required pathway dimensions. V4b is advisory: a safe-but-suboptimal route does not render the pathway defective, though it is recorded. The pillar episode’s verdict record has ROBUST_NEIGHBORHOOD: not-applicable with an explicit reason — “no predeclared robustness obligation for this risk class” — illustrating how governance-derived scope controls which dimensions are required.
The deterministic fixture suite proves every architecturally distinct cell is inhabited: F1 (correct + adequate), F2 (correct + defective — the stopped-clock case), F3 (incorrect + adequate — the rare-case miss), F4 (incorrect + defective), F5 (undetermined), F6 (stale-directive), and F7 (safe but sub-optimal routing). The negative fixtures I01–I48 prove the validators reject every invalid configuration.
Levels: episode reification for higher-order audit
Episodes can themselves become objects of audit. If yesterday’s classification act is audited today — “Was that placement made on adequate evidence, under an adequate governing configuration?” — then the episode must be cast as a base occurrence for the higher audit. This is an explicit reification embedding, not a claim that episodes are already members of the base domain:E^(n) is the class of episodes at level n and M^(n+1) is the occurrence domain at the next level. The embedding ι_n is injective; ι_n(e) is “episode e, considered as a case to be audited.” Writing ⊆ here would falsely assert that episodes are already members of the base domain; the embedding records that a modeling step is required to turn one into the other.
Level indexing. At level
n+1, the orthemes are pathway state-types — evidence-sufficient placement, stale-rule placement, false closure — precisely the verdict dimensions from the previous section. The regress stops at a declared governance boundary; no infinite regress is implied. Multi-actor settings index every object per actor (α, β) under per-actor analyses A_α, so disputes between actors are representable at the same level without conflating their evidence states or their placement claims.