Every durable claim in Orthemology rests on a single architectural separation: the type pole and the token pole. An ortheme is a repeatable operational state-type — a stable, consequence-bearing description that many occurrences may share. An orthemma is a concrete situated occurrence, this thing here and now, with its own identity key and version. The entire placement lifecycle, the evidence machinery, the verdict layer, and the episode reification embedding are all downstream consequences of keeping these two poles cleanly distinct.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 Poles
Ortheme — Type Pole
A repeatable operational state-type that a concrete occurrence may instantiate, relative to a declared analysis
A. Orthemes are stable descriptions: compliant, stale-version, route-sufficient, evidence-grade-provenance. They are never occurrences themselves, never actor-relative belief states, and never the output of a single episode.Orthemma — Token Pole
A concrete situated occurrence — this utterance, this build report for this commit, this patient presentation — with an identity key
κ (which thing it is) and a version v (which state or edition of that thing). Two orthemmata can share every observable property and still be numerically distinct.The token pole is primary in the Orthemology workflow. The system first encounters a concrete occurrence, then asks which repeatable state-types it instantiates — not the other way around. Types do not hover independently of occurrences; what is unresolved is always the placement of a present, concrete case.
Why the Distinction Matters
The sharpest consequence of the type–token separation is this: two episodes that are identical in every input and output are still distinct auditable occurrences. Consider a build validator that passes two successive runs on the same commit. Even if both runs receive the same evidence, produce the same placement, and select the same route, they are different tokens: different actors (or the same actor at different times), different evidence-gathering moments, and different pathway histories. The verdict layer can yield different results — one run may have a stale governing token (V3c fail) while the other does not.- Compilation Analogy
- Classification Analogy
Orthing (the rule-governed, evidence-updating process of handling a concrete case) is a process type: the operation kind by which an orthemma is individuated, observed, profiled, routed, validated, and dispositioned. It stands to its runs as compilation stands to the 14:32 build of commit
abc123.- “Compilation” → the type: repeatable, undated, shared by all instances of the operation.
- “The 14:32 build of commit
abc123” → the token: dated, situated, with a specific actor, inputs, trace, and result.
PathwayAdequate and PathwayDefective are predicates on episodes (tokens), not on procedures (types). Reliability claims attach to the procedure type; correctness and pathway adequacy claims attach to the concrete episode token.
The Orthing Process Type vs the Orthing Episode Token
| Dimension | Process Type (Orthing) | Episode Token (e) |
|---|---|---|
| Identity | Shared by all instances | Unique (id) |
| Datedness | Undated | Dated (t = time interval) |
| Actor | Unspecified | α — populated even for mechanical executors |
| Reliability claims | Yes — V2b-P evaluated over declared reference class | No — one correct result does not establish the procedure |
| Correctness claims | No | Yes — V1 judged against O*(m; A(e)) |
| Pathway adequacy | No | Yes — PathwayAdequate(e), PathwayDefective(e) |
Level-Indexing: Episodes Reified as Higher-Audit Occurrences
The type–token architecture is recursive. When a higher audit asks “was this placement made correctly, on adequate evidence, under an adequate rule?”, the episode being audited must itself become a concrete case — a token — in the higher-level domain. This is formalized as the reification embedding:E^(n)= the class of episodes at leveln(tokens handling base orthemmata)M^(n+1)= the domain of orthemmata at leveln+1(concrete cases for the higher audit)- The arrow is an injective modeling step — it records that a classification act has been cast as a case to be audited, not that episodes are literally members of the base occurrence domain
The orthemes at level
n+1 are pathway state-types: evidence-sufficient placement, stale-rule placement, false closure. These are precisely the verdicts of the pathway layer, applied one level up. The regress stops at the declared governance boundary.⊇ (literal set inclusion) would falsely assert that episodes are already members of the base domain.
Concrete Examples
"Compilation" (type) vs "the 14:32 build of commit abc123" (token)
"Compilation" (type) vs "the 14:32 build of commit abc123" (token)
This is the canonical analogy from the formalization. Compilation is the operation kind — defined by its inputs, rules, and outputs. “The 14:32 build of commit
abc123” is a concrete token: it happened at a specific time, was performed by a specific executor, produced specific artifacts, and can be audited for whether the correct build configuration was in force, whether the evidence of passing tests was current for that exact commit, and whether the closure claim (“build succeeded”) matched the actual burden ledger.Two builds of the same commit at different times are distinct tokens. Even if both produce identical binaries, they differ in actor, governing token (which version of the build policy was in force), and pathway history. One may be pathway-adequate; the other may not.A scan validator — correct result, defective pathway
A scan validator — correct result, defective pathway
A scan validator’s rule is: pass if the output log contains the marker string
SCAN-CLEAN. On today’s artifact it passes. The artifact is genuinely compliant.- V1 (RESULT_CORRECT): pass — the placed claim (“compliant”) is true of the occurrence.
- V2b-P (PROCEDURE_RELIABLE): fail — over its declared reference class, a non-compliant artifact with the marker present would also pass; the configured procedure is not truth-conducive.
- V6 (ROBUST_NEIGHBORHOOD): fail — the perturbation neighborhood exposes it: compliant-without-marker is rejected; non-compliant-with-marker is passed.
- V3a (GOV_CONFIG_ADEQUATE): fail — the governing evidence configuration cannot discriminate the states it is supposed to separate.
Two episodes, identical inputs and outputs, distinct verdicts
Two episodes, identical inputs and outputs, distinct verdicts
Suppose two episodes
e₁ and e₂ both handle the same build report, both place the same profile, and both route identically. They differ only in one detail: e₁’s governing token μ̄ has a current calibration; e₂’s has an expired calibration.e₁: V3c (GOV_TOKEN_ADEQUATE) = pass → PathwayAdequatee₂: V3c (GOV_TOKEN_ADEQUATE) = fail (token notCurrent) → PathwayDefective
The Abbreviation Convention
Because the analysisA is the ground-truth index, the full form O*(m; A) is always authoritative. The task-subscripted shorthand O*_T(m) is permitted only as local scoped shorthand after a single analysis A with task(A) = T has been explicitly fixed in the current context.