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 Orthemology experimental program consists of two fully designed, frozen, and deterministically validated study packets. Both packets were built to test a single core question: does the framework’s occurrence-centered machinery provide measurable incremental value over matched ordinary baselines? Neither packet has been executed. No result, finding, or empirical claim exists for either study.
No experiment has been run. Both packets below are ready-to-run instruments only. The canonical machine-readable state of every packet is experiments/experiment-status.yaml. No result, adoption, or empirical claim is licensed from anything in this program.

​
What these experiments are designed to test

Both experiments operationalize the utility hypothesis: that the framework’s explicit occurrence-anchored structure — maintained candidate families, typed and scoped evidence, route composition, per-burden closure ledgers, and episode/verdict records — provides incremental value over matched ordinary audit records carrying the same underlying facts. This is not a test of whether the framework’s structures can be written (the repository’s schemas already demonstrate that). The question is whether auditors equipped with those structures do measurably better at defect detection, false-closure prevention, and correct remedy selection than auditors working from an ordinary chronological record.
The utility hypothesis is tested separately from the terminology hypothesis. A favorable result from either experiment licenses only a claim about the structure or machinery tested in that study. It transfers nothing to the other experiment, and neither can adopt or retire coined terms — that is reserved for the terminology benchmark program.

​
The two packets

ER-1: Episode Reification

Tests whether the joint verdict vector and episode reification structure provide incremental value over a baseline audit log. Five synthetic cases (E1–E5), two arms, and a frozen analysis script. Status: READY TO RUN, NOT RUN.

FCSP-1: False-Closure Selective Prediction

Tests whether the framework’s handling machinery reduces false-closure and improves selective-prediction behaviour. Forty synthetic items across nine scenario families, two arms, and a power simulation. Status: READY TO RUN, NOT RUN.

​
Current status

Both packets reached READY_TO_RUN through the closed readiness ladder defined by Decision 0018. The vocabulary has two dimensions — readiness state and registration state — and both are tracked separately in experiment-status.yaml.
PacketReadiness stateRegistration stateRun exists
ER-1READY_TO_RUNPREREGISTRATION_READYfalse
FCSP-1READY_TO_RUNPREREGISTRATION_READYfalse
The canonical and authoritative source for all packet states is experiments/experiment-status.yaml, validated in CI by scripts/validate_experiment_readiness.py. Any summary here defers to that file.

​
Preregistration requirement

PREREGISTRATION_READY means the packet has been locally frozen with a verified SHA-256 hash, but a Git freeze is not an external preregistration. External registry submission is an owner/external act, distinct from any repository artifact. No document in this project may describe a packet as “preregistered” without naming a real external registry record with a URL or identifier. Both packets carry the required remaining gates before any run may proceed:
  1. Owner authorization of execution (model spend and run responsibility)
  2. External preregistration (owner/external act; optional but strongly recommended before any run)
Decision 0018 introduced the closed readiness vocabulary, the separation of readiness from registration state, the canonical experiment-status.yaml file, and the no-run guard enforced in CI. Consult that decision before interpreting any status value.

​
Decision 0018

Decision 0018 resolved a structural problem: the project had described unbuilt, unregistered designs as “preregistered” and had conflated packet preparation (a project-side task) with execution (an owner-only act requiring spend and human-subjects responsibility). Decision 0018:
  • Defined the closed eight-state readiness vocabulary
  • Defined the separate four-state registration vocabulary
  • Made experiment-status.yaml the canonical machine-readable state index
  • Established freeze discipline (per-packet FREEZE-HASH.txt)
  • Enforced the no-run guard: deterministic smoke tests are never empirical outcomes
The freeze hashes for both current packets are: 
# From experiments/experiment-status.yaml
ER-1:
  freeze_hash: fd3194406f42afa8602c0a704b088154c498100c1aff4b81d1d1c9da80a9fc78

FCSP-1:
  freeze_hash: 59c5427b2551a1446e10e5aadb24ed2fcb749e7d072335ff14fe1dfec939737b

​
What is licensed now

Neither packet licenses any result, finding, adoption, or empirical claim. Deterministic smoke tests under each packet’s tests/ directory are engineering validation of the instruments — they measure nothing empirical and produce no scientific outcome.

Build docs developers (and LLMs) love

Get started for freeTalk to us