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 verdict registry is the single authoritative source for the semantic identifiers, display aliases, sides, factive status, and meanings of every verdict in Orthemology. It lives in docs/verdict-registry.yaml and was normalized by Decision 0004 (2026-07-20, registry version 1.0.0). Semantic IDs are authoritative in all schemas, test fixtures, and machine-readable records; display aliases (V1–V6) are reserved for prose and equations. Reordering or renaming the registry immediately propagates to the validators, so the checked semantics can never silently diverge from the file.
This registry is consumed by scripts/validate_verdict_semantics.py and scripts/generate_from_registry.py. The generated alias table at docs/generated/verdict-aliases.md is produced from this source and must not be edited by hand.

Status values

Every verdict slot in an episode record takes exactly one of four values:
StatusMeaning
passThe verdict condition is satisfied
failThe verdict condition is not satisfied
undeterminedInsufficient information to decide
not-applicableThe verdict is governance-excluded for this episode; a recorded reason is required
A missing assessment is never a silent pass. not-applicable requires an explicit reason; “not tested” is never a valid not-applicable reason.

Full verdict table

The fourteen normative verdicts, in canonical display order:
AliasSemantic IDSideFactiveMeaning
V1RESULT_CORRECTresultyesResult/profile correctness against O*(m; A(e)) at the governed level
V2aEVIDENCE_SUPPORTpathwaynoTyped evidence, within declared scopes, meets the declared support standard per placed claim
V2b-PPROCEDURE_RELIABLEpathwaynoConfigured-procedure/reference-class truth-conduciveness under the predeclared RelSpec (non-factive)
V2b-TTOKEN_TRUTH_LINKEDresultyesFactive, claim-wise truth linkage — this claim correct through the truth-relevant mechanism
V2cEVIDENCE_CURRENTpathwaynoLoad-bearing evidence current for (κ, v) with admissible provenance
V3aGOV_CONFIG_ADEQUATEpathwaynoGoverning configuration/type adequacy for the case’s risk class
V3bGOV_POLICY_ADEQUATEpathwaynoMeta-policy/procedure well-formedness for the configuration it runs under
V3cGOV_TOKEN_ADEQUATEpathwaynoMetaorthemma/binding adequacy — every applicable configuration token correctly instantiated, compatible, anchored, scoped, current, provenanced, authorized
V3dEXECUTION_FAITHFULpathwaynoExecutor fidelity — the actor executed the procedure as written
V3eEX_ANTE_JUSTIFIEDpathwaynoDecision-time reasonableness on exactly the evidence then available
V4aROUTE_ADMISSIBLEpathwaynoRoute safety/admissibility under the constraints in force
V4bROUTE_QUALITYadvisorynoNear-optimality/advisory route quality (safe is not best)
V5CLOSURE_TRUTHFULpathwaynoClosure matches the burden ledger — no disposition collapse
V6ROBUST_NEIGHBORHOODpathwaynoRobustness under the declared perturbation family
The V3-block display order matches the conceptual adequacy chain: configuration (V3a) → policy (V3b) → token binding (V3c) → execution (V3d) → decision-time justification (V3e). This ordering was introduced by Decision 0004.

Result axis vs pathway axis

Verdicts divide along two top-level axes.

Result axis

V1 (RESULT_CORRECT) — was the profile/result actually correct?V2b-T (TOKEN_TRUTH_LINKED) — was this specific claim correct through the truth-relevant mechanism (factive, claim-wise)?These are the only two factive verdicts. A correct result does not entail any pathway verdict, and no pathway verdict entails a correct result — with one exception: TOKEN_TRUTH_LINKED entails RESULT_CORRECT claim-wise.

Pathway axis

All remaining non-advisory verdicts: V2a, V2b-P, V2c, V3a–V3e, V4a, V5, V6.Pathway verdicts are non-factive. They assess whether the governed process was correctly configured and faithfully executed — independently of whether the answer happened to be correct.

Result-free pathway core

Decision 0003 established a result-free pathway core: the set of verdicts that constitute PathwayAdequate(e) without including any result-side or advisory verdict. Core pathway verdicts (core_path in the registry): EVIDENCE_SUPPORT, PROCEDURE_RELIABLE, EVIDENCE_CURRENT, GOV_CONFIG_ADEQUATE, GOV_POLICY_ADEQUATE, GOV_TOKEN_ADEQUATE, EXECUTION_FAITHFUL, EX_ANTE_JUSTIFIED, ROUTE_ADMISSIBLE, CLOSURE_TRUTHFUL, ROBUST_NEIGHBORHOOD Excluded from core (with reasons):
VerdictReason for exclusion
RESULT_CORRECTResult-side by construction (Decision 0003)
TOKEN_TRUTH_LINKEDFactive — would re-import result correctness into the pathway core
ROUTE_QUALITYAdvisory quality verdict; recorded separately from safety
The four-cell matrix — correct result × adequate pathway, correct result × defective pathway, incorrect result × adequate pathway (AdequatePathError), incorrect result × defective pathway — is fully representable. AdequatePathError is not a moral or legal blamelessness predicate; it is simply the justified rare miss of a reliable process.

Advisory verdict

ROUTE_QUALITY (V4b) is not part of the core and is recorded separately from the core pathway verdicts. It assesses near-optimality: a route may be safe and admissible (V4a passes) while still not being the best available option (V4b fails).

Declared entailment and non-entailments

The registry declares one entailment:
TOKEN_TRUTH_LINKED (claim-wise) ⟹ RESULT_CORRECT (claim-wise)
All other cross-verdict inferences are explicitly not entailments:
Non-entailment
PROCEDURE_RELIABLE does not entail RESULT_CORRECT
EX_ANTE_JUSTIFIED does not entail RESULT_CORRECT
ROBUST_NEIGHBORHOOD does not entail PROCEDURE_RELIABLE
PROCEDURE_RELIABLE does not entail ROBUST_NEIGHBORHOOD

How to use this registry

  • In machine records (schemas, fixtures, APIs): always use the semantic ID (e.g., RESULT_CORRECT). Aliases are never authoritative in structured data.
  • In prose and equations: use the display alias (e.g., V1, V3c) after first introducing the semantic ID.
  • In code: load docs/verdict-registry.yaml directly. Do not hard-code alias strings; use the semantic ID constants.
  • Applicability: the governance-derived function ReqPath(e) determines which verdicts are required for a given episode. Discretionary exclusion is not permitted; every not-applicable verdict must carry a recorded reason.

Legacy alias migration

Historical documents under archive/ retain the original aliases and are never rewritten. When reading archived material, use the following mapping:
Old labelCurrent label
V3 (configuration adequacy)V3a
V3a (policy adequacy)V3b
V3b (executor fidelity)V3d
V3c (token adequacy)V3c (unchanged)
V3d (ex-ante justification)V3e
V2b^procV2b-P
V2b^tokV2b-T
manuscript bare V4 (route safety)V4a
Registry version 1.0.0 was established by Decision 0004 (2026-07-20). No semantic content of any verdict changed in that normalization; the change was a naming and indexing normalization only.

Build docs developers (and LLMs) love