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.

This page provides in-depth coverage of six decisions that are foundational to understanding the architecture of Orthemology. Each section presents the question the decision resolved, the option selected, the rationale, and the artifacts produced. For the complete list of all 19 decisions and their one-line summaries, see the Decisions Overview.

​
Decision 0001 — Analysis-relative ground truth (D1)

Date: 2026-07-19 · Status: implemented and promoted (R1)
How should the fibre of true orthemes be indexed — task-relative O*_T(m), analysis-relative O*_A(m), both at distinct levels, or one primitive with an abbreviation convention?
Option (d): one analysis-relative primitive with a strictly scoped task-relative abbreviation.Inst_A ⊆ M × O is the primitive instantiation relation. The true profile is O*(m; A). The declared analysis A is explicit and versionable, specifying: boundary, task, repertoires, loss, hard constraints, horizon, tolerance, representation family, merger family, and governance boundary where relevant.O*_T(m) and other task-subscripted spaces survive only as local scoped shorthand after one analysis with task(A) = T is explicitly fixed. They are forbidden wherever more than one analysis is live: audits, multi-actor evaluation, cross-version comparison, execution-vs-review.The occurrence and its worldly facts are analysis-independent; only the state-type description is indexed. Episode records carry the analysis identity and version. Result correctness (V1) is judged against O*(m; A(e)). No task-to-analysis bridging law exists.
The corpus previously carried both O*_T and O*_A as apparent primitives. Every downstream object — V1, candidate families, profile spaces — inherited the ambiguity. Definition 7’s merger gap made task-only indexing ill-defined: two analyses can share a task while differing in tolerance or representation, producing incomparable profiles with the same label.
archive/reconciliation/D1-COMPLETE-DIFFS.patch, D1-GROUND-TRUTH-CHANGE-LEDGER.md, D1-VALIDATION-REPORT.md

​
Decision 0002 — Metaorthemma as configuration token (M1)

Date: 2026-07-19 · Status: implemented and promoted (R1)
The word “metaorthemma” remains benchmark-gated. This decision adopts the conceptual object, not the terminology.
Does the theory need a concrete, case-bound token of a governing metaortheme inside an orthing episode — and if so, is it a configuration token (M1), an application-event token (M2), or nothing beyond episode fields (M0)?
M1 — configuration token, tightly interpreted.A metaorthemma μ̄ is the episode-local, case-bound instantiation of a repeatable metaortheme and its policy parameters. It records or references:
  • Its own identity and lineage
  • Metaortheme type and version (MetaInst(μ̄, μ))
  • The episode’s analysis and version (Compatible(μ̄, A(e)))
  • The target occurrence (κ, v)
  • The governed component
  • The case-specific binding map (reference frame, tolerance value, fixture, success surface, and so on)
  • Scope with dependent claims
  • Instrument/calibration provenance
  • The binder with binding warrant kept distinct from the executor
  • Binding time and validity
A metaorthemma is not the whole episode and not the execution event. The application-event view is derived (ApplyEvent(μ̄, e) = ⟨μ̄, Trace_e|_μ̄⟩), never a second primitive.Zero-burden rule: configurations with no material case-specific binding get no token; the associated verdict (GOV_TOKEN_ADEQUATE) is then not-applicable with a recorded reason.
The missing distinction this supplies: correct governing standard + correct policy + faithful execution + defective case-specific binding — wrong reference plane, wrong-role tolerance, expired calibration, wrong test fixture or success surface. Verdict V3c (GOV_TOKEN_ADEQUATE) isolates this failure mode, with per-token statuses preserved. Without M1, that failure mode was invisible to the verdict structure.
archive/reconciliation/METAORTHEMMA-M1-INCREMENTAL-DIFFS.patch, METAORTHEMMA-M1-CHANGE-LEDGER.md

​
Decision 0003 — Result-free pathway adequacy (O2)

Date: 2026-07-19 · Status: implemented, machine-validated, and promoted (R1)
Should PathwayAdequate include result correctness (V1) and a factive truth-connection verdict — or be a result-free core, so that “right answer” and “properly run process” stay independent axes?
Option (a) — result-free pathway core.Three questions are kept strictly distinct:
  1. Was the result correct? — V1 (RESULT_CORRECT), judged against O*(m; A(e)).
  2. Was the configured procedure genuinely truth-conducive? — V2b-P (PROCEDURE_RELIABLE), non-factive; per-claim RelSpec_q with reference class, stratum, metric, threshold, perturbation family, protocol, reliability evidence, version/validity. The reference class is fixed before seeing the outcome; one correct result cannot establish it.
  3. Was this correct claim truth-linked rather than coincidental? — V2b-T (TOKEN_TRUTH_LINKED), factive and claim-wise; entails V1 claim-wise; excluded from the core because of its factivity; reportable for stopped-clock/Gettier diagnoses.
Core path (using Decision 0004 aliases): {V2a, V2b-P, V2c, V3a, V3b, V3c, V3d, V3e, V4a, V5, V6}. V1, V2b-T, and V4b are excluded.Statuses are four-valued: pass / fail / undetermined / not-applicable with PathwayAdequate / PathwayDefective / PathwayUndetermined. A missing assessment is never a silent pass. Applicability is governance-derived (ReqPath(e)), never a discretionary list.
All four result × pathway cells must be representable:
Pathway adequatePathway defective
Correct resultThe ideal caseCorrect by luck or coincidence
Incorrect resultAdequatePathError — the justified rare missThe clearly defective case
AdequatePathError is explicitly not a moral, legal, or theological “blamelessness” predicate. It is the statistical justified rare miss of a genuinely reliable process.
tests/verdict-fixtures.json (fixtures F1–F5), scripts/validate_verdict_semantics.py (29 checks: core exclusions, zero-burden V3c coupling, factivity, non-factivity witness, four-cell satisfiability, undetermined handling, N/A reasons). Archive: O2-PATHWAY-ADEQUACY-INCREMENTAL-DIFFS.patch, O2-PATHWAY-ADEQUACY-CHANGE-LEDGER.md, O2-VALIDATION-REPORT.md

​
Decision 0004 — Verdict registry normalization (D3)

Date: 2026-07-20 · Status: implemented, registry-driven, machine-validated (R2)
The verdict vector carried provisional lettering: the conceptual adequacy chain ran V3 → V3a → V3c → V3b → V3d while the labels stayed alphabetical-by-accident, and the ^proc/^tok superscripts were explicitly provisional. What is the final, machine-stable registry?
Adopt canonical semantic identifiers (authoritative in schemas, tests, fixtures, and machine-readable records) with display aliases in conceptual order (used in prose and equations).The registry lives in docs/verdict-registry.yaml and drives scripts/validate_verdict_semantics.py and the schema validator, so reordering can never silently change semantics.The V3-block display order now matches the conceptual chain: configuration (V3a) → policy (V3b) → token binding (V3c) → execution (V3d) → decision-time justification (V3e).The result-free pathway core (Decision 0003) is unchanged in content; under the new aliases: CorePath = {V2a, V2b-P, V2c, V3a, V3b, V3c, V3d, V3e, V4a, V5, V6}.
Provisional lettering was creating implicit assumptions that the alphabetical order reflected conceptual order. Separating machine-stable semantic IDs from human-readable display aliases allows both stability (IDs never change) and readability (prose uses intuitive aliases).
docs/verdict-registry.yaml (the normative file), docs/generated/verdict-aliases.md (generated, do not edit), scripts/validate_verdict_semantics.py, scripts/generate_from_registry.py

​
Decision 0011 — Claim-relative reasoning paths and strict soundness

Date: 2026-07-20 · Status: adopted; R4 independent review discharged (Decision 0016)
This decision supersedes the strict-soundness formula in Decision 0009. Every other clause of Decision 0009 stands unchanged. The relationship is machine-checked in docs/decision-status.yaml.
Decision 0009 defined StrictlySoundReasoning_q(e) := PathwayAdequate(e) ∧ TOKEN_TRUTH_LINKED_q(e). This names a claim-level predicate but conjoins a whole-episode predicate. A claim soundly reached would be “not strictly sound” because the operator later routed the case poorly. Can a mixed episode — one sound and one unsound claim — be represented?
Two new constructs:
  1. ReqReason_q(e) ⊆ ReqPath(e) — the required verdicts causally or evidentially relevant to claim q. Derived, recorded, and auditable; never chosen after the outcome. Its derivation inputs are: the claim’s declared dependencies; its evidence IDs and their scopes; the metaorthemmata governing those components; the analysis and governance rules; and the procedure/execution portions bearing on the claim. Verdicts required of the episode but irrelevant to q (typically downstream route and closure obligations) are excluded.
  2. ReasoningPathAdequate_q(e) — every verdict in ReqReason_q(e) passes; non-factive (O2 preserved).
  3. Corrected formula: StrictlySoundReasoning_q(e) := ReasoningPathAdequate_q(e) ∧ TOKEN_TRUTH_LINKED_q(e) — factive at the claim level; still a derived profile over existing verdicts. No primitive SOUND_REASON verdict is added; the registry (Decision 0004) is unchanged.
Verdict records carry the projection and its recomputed result in a claim_reasoning_paths block, kept structurally distinct from the episode-level pathway_state.
The whole-episode PathwayAdequate(e) aggregates all of ReqPath(e), including ROUTE_ADMISSIBLE and CLOSURE_TRUTHFUL. A claim soundly reached would therefore become “not strictly sound” because the operator later routed the case poorly or made a false closure claim — and a mixed episode could not carry one sound and one unsound claim. The claim-relative projection resolves this.
tests/claim-reasoning-fixtures.json (fixtures CR-9–CR-15 plus CR-OMIT-1), scripts/validate_claim_reasoning_paths.py, docs/claim-reason-requirements.yaml

​
Decision 0018 — Experiment-packet readiness and registration status

Date: 2026-07-20 · Status: adopted (R6)
OPEN-DECISIONS.md said “Every packet is INSTRUMENT-READY, NOT RUN” while the public experiments/ tree contained only a README. The manuscript called the unbuilt design “preregistered”. How should experiment readiness and registration state be governed?
Two closed vocabularies:Readiness (one status per packet): DRAFT → SPEC_COMPLETE → DETERMINISTICALLY_VALIDATED → READY_FOR_HUMAN_MATCHING_REVIEW → READY_TO_RUN → RUN_IN_PROGRESS → RUN_COMPLETE_UNADJUDICATED → ADJUDICATEDREADY_FOR_HUMAN_MATCHING_REVIEW applies only to packets that declare a required pre-run human review gate (currently the terminology instrument). A packet with no such declared gate may go from DETERMINISTICALLY_VALIDATED to READY_TO_RUN directly. A packet may not be READY_TO_RUN while any declared required review is pending.Registration: NOT_REGISTERED · PREREGISTRATION_READY · LOCALLY_PROTOCOL_FROZEN · EXTERNALLY_PREREGISTEREDA Git freeze is not an external preregistration. No document may say “preregistered” unless it names a real external registry record.Canonical per-packet state lives in experiments/experiment-status.yaml. Freeze discipline: each packet carries FREEZE-HASH.txt (sha256 over sorted file contents); any post-freeze edit is a new packet version.No-run guard: synthetic outputs are labeled and confined to packet tests/ trees; nothing in the repository may present a synthetic traversal as an empirical run.Current status: FCSP-1 (false-closure/selective-prediction benchmark) and ER-1 (episode-reification incremental-value test) are READY_TO_RUN. The terminology pilot-0 v2 instrument is READY_FOR_HUMAN_MATCHING_REVIEW. No run has occurred; nothing is externally preregistered.
The project’s own standard is that false closure — asserting completion of a step that has not been completed — is a V5 (CLOSURE_TRUTHFUL) defect. Calling an unbuilt, unregistered design “preregistered” or “INSTRUMENT-READY” while the experiments/ tree was empty was a false-closure defect under the project’s own framework (independent audit finding B1/B2).
experiments/experiment-status.yaml, experiments/false-closure-selective-prediction/ (packet FCSP-1), experiments/episode-reification/ (packet ER-1), scripts/validate_experiment_readiness.py

Build docs developers (and LLMs) love

Get started for freeTalk to us