Orthing Episodes: The Auditable Handling Record Schema

An orthing episode is the concrete token of the orthing process — one dated, situated run with an actor, a time, an input occurrence, and a result. It is the object on which all verdicts are defined. Two episodes are distinct occurrences even when their inputs and outputs agree: one may have a stale governing token where the other does not; one may have followed the procedure faithfully where the other deviated. The episode exists precisely so these differences are statable on a single auditable record, separately from whether the answer happened to be correct.

An episode is not its output. out(e) = ⟨p̂, r, estatus, 𝒬, δ, a⟩ is a projection. An episode is not the policy either: the policy π is repeatable and undated; reliability claims attach to the policy; correctness and pathway adequacy claims attach to the episode. A placement inside an episode is not the episode: the convenient notation e ⊨_μ (m : ô) is derived, not definitional.

The Episode Signature

An orthing episode is a record with the following components, each applicable where relevant:

e = ⟨ id;  m, κ, v;  x, H;  α, w, A, T, t;
      μ⃗, MetaTok, π;  C⃗, p̂;  r;  estatus;  𝒬;  δ;
      hand_in, hand_out;  a, Succ ⟩

Component	Type	Gloss
`id`	episode identifier	Which run this is — referenced by handoffs and audits
`m`	orthemma `∈ M`	The concrete case handled
`κ = id(m)`	identity key	Which thing this is (survives change)
`v = ver(m)`	version	Which state or edition of that thing
`x = Ω_e(m)`	observation	What the episode actually saw
`H`	ordered typed evidence sequence	Evidence gathered in order; each item typed, scoped, provenanced, and expiring
`α`	actor	Who or what executed — populated even for mechanical executors
`w`	episode warrant	Who or what authorized acting, with scope; distinct from evidence and from executor identity
`A`	declared analysis (id + version)	The analysis the placement is relative to; `O*(m; A)` is the ground truth against which V1 is judged
`T = task(A)`	task	The task component of `A`, retained as a separate readable component
`t`	time interval	When the episode ran
`μ⃗ = (μ₁,…,μ_k; ≼)`	metaorthemic configuration	The governing rules in force with precedence order `≼`
`MetaTok(e)`	concrete metaorthemmata	The case-bound configuration tokens of governing types actually applied
`π`	policy	The concrete procedure executed under `μ⃗`
`C⃗`	typed candidate families	Open alternatives per uncertainty axis
`p̂ ∈ Π_A^∂`	inferred placement	Exactly one partial profile — never a set of complete profiles
`r`	route	The operation or owner the case was sent to
`estatus`	evidence status map	Per placed claim: validated / provisional / stale / absent
`𝒬`	claim ledger	Per claim: proposition, target `(κ, v)`, property class, required success surface, evidence IDs, warrant, verification status, explicit non-claims
`δ`	residual disposition map	Per obligation: one of six disposition values
`hand_in, hand_out`	handoff records	Incoming and outgoing inter-episode state claims
`a`	action	What was done to or with the case
`Succ ⊆ M`	successor set	Occurrences the action created or affected, as labeled lineage edges

Record Mode: Audit-Ready vs Minimal

The schema requires an explicit record_mode declaration:

audit-ready
minimal

The record claims to carry everything an auditor needs to re-derive the verdict. It is held to the full conditional contract:

actor, time, analysis, occurrence, observation must be non-empty
claim_ledger_ref and verdict_record_ref must be declared
Evidence must be present, or evidence_absent_reason must be declared
Placement or a candidate set must be present

An audit-ready episode with unresolved external references is schema-invalid.

An honest label for a record that does not support audit. It is not a license to omit base fields. A minimal record still requires episode_id, record_mode, occurrence, actor, analysis, time, placement, observation, evidence, warrant, policy, and verdict_record_ref — it simply does not claim audit completeness.“Minimal” is not a weaker form of “audit-ready.” It is a different posture that makes no audit claim.

Evidence Channels H

Evidence is an ordered typed sequence — not a single observation and not an untyped list. Each item in H is a record:

Evidence item fields

evidence_id

string

required

Stable identifier for this evidence item. Referenced by claim ledger entries and handoffs.

channel

string

required

The evidence channel kind. Examples: behavioral-test, structural-parse, provenance-lineage, instrument-reading.

property_class

string

required

The core cross-domain class. The three core classes are structural (form: does the file parse, does the schema match), behavioral (exercised behaviour: the test ran this code path on this input), and provenance (origin and currency: this artifact was produced by that process from that version). Domain-specific subclasses are declared inside A. Authorization is not an evidence property class — it is a warrant gate W.

scope

string

required

The claims, occurrence versions, and levels this item can bear on at all. A validator can pass while supporting nothing: a mis-scoped pass (pass ∧ scope ∩ claim = ∅) is no evidence for that claim.

provenance

string

required

Which process produced the item, from which (κ, v).

validity

string

required

The conditions under which the item remains current. Evidence expires when the occurrence it attests to acquires a successor along an edge that could have changed the attested property.

A green validator whose scope does not intersect the claim being closed is a mis-scoped pass — it is no evidence for that claim, not weak evidence. Stale evidence (valid in its day, expired by lineage) is evidence about a different occurrence, not weak evidence for the current version. Both defects are representable in the episode record; both fail V2c (EVIDENCE_CURRENT) or leave V2a (EVIDENCE_SUPPORT) undetermined.

Placement and Candidate Families

The typed candidate families C⃗ hold open alternatives per uncertainty axis:

Family	Ranges over	Open question
`C^id`	`M` (occurrence domain)	Which occurrence (identity or version) is actually in hand
`C^profile`	`Π_A` (complete profiles)	Which profile the case instantiates
`C^cause`	`𝒦_A` (cause repertoire)	Which cause produced the state
`C^route`	`ℛ_A` (route repertoire)	Which operation or owner should receive the case
`C^warrant`	`𝒲_A` (warrant states: authorized, established, both, neither)	Which warrant state obtains

The inferred placement p̂ ∈ Π_A^∂ is exactly one partial profile — determined on resolved axes, open on the rest. It is never a set of complete profiles: live alternatives belong in Ĉ ⊆ Π_A. Collapsing the candidate set into a single vague partial profile loses the alternatives structure that routes and discriminating tests act on.

Residual Dispositions

The six residual disposition values

Every burden of an episode carries exactly one disposition at closure time. The six values are mutually exclusive:

Disposition	Meaning
`unresolved`	Still open with no plan
`deferred`	Open with a declared later trigger
`transferred`	Moved to another party with traceable ownership
`owner-assigned`	Waiting on a named owner’s decision
`risk-accepted`	Consciously left open under an accepted, recorded risk
`validated-resolved`	Closed on in-scope, current, sufficient evidence

False closure is a type error: a completion claim that collapses unresolved, deferred, transferred, owner-assigned, or risk-accepted into validated-resolved. The completion claim is well-formed only when every burden’s disposition admits it. “Done” uttered over a ledger containing a deferred burden is a claim whose type its own ledger refutes.Claims (𝒬) and residuals (δ) are never merged: claims are assertions about what the case instantiates; residuals are obligations that have not been discharged. They live in separate ledger slots.

A closure_claim is ill-formed while any residual carries disposition: unresolved. A release with a deferred flake-investigation burden is closed with a deferred residual, not “done.” The per-burden ledger makes this a well-formedness check, not a subjective judgment.

Handoffs

A handoff record is an inter-episode state claim — the structured packet that one episode passes to the next in a distributed handling graph:

Handoff record fields

packet_id

string

required

Stable identifier for the handoff packet.

sender_episode_id

string

required

The episode that produced this handoff.

receiver_episode_id

string

The episode that consumes this handoff (populated in hand_in of the receiving episode).

subject_identity

object

required

The (κ, v) of the occurrence this handoff concerns.

state_claims

array

required

The claims being passed: each with its proposition, evidence references, scope, and validity. A verdict crossing an edge without its scope and version is how stale evidence propagates.

valid_for_version

string

required

The version for which these state claims are valid. A handoff state claim without valid_for_version is schema-invalid — it is an error to pass a claim without declaring which occurrence version it covers.

authority_claims

array

Any authorization context the sender passes to the receiver.

Handoffs are the loci of transport error in a distributed episode graph. When a partial profile, evidence item, or route crosses a handoff edge without its scope and version declaration, stale evidence can enter the next episode’s H as if it were current. The valid_for_version field is the formal guard against this.

Successors

The successor set Succ ⊆ M records the occurrences an action created or affected, as labeled lineage edges:

"successors": [
  {
    "identity_key": "repo/src/main.py",
    "version": "commit-def456",
    "action_label": "edit"
  },
  {
    "identity_key": "repo/tests/test_main.py",
    "version": "commit-def456",
    "action_label": "test-run"
  }
]

The successor set can be zero (read-only classification), one, or many (a split, broadcast, or build). The earlier formalization forced a single successor m′ = succ(m, a); this is corrected to a labeled set. The labels enable the transport principle: a placement valid for (κ, v) is not automatically valid for any (κ, v′) in the successor set.

The Endpoint and the Bounded Trace

The episode signature above is the required endpoint. Where pathway verdicts involving the truth-conduciveness of the procedure (V2b-P), executor fidelity (V3d), or robustness (V6) must be adjudicated from the episode’s own record, an ordered trace is also required:

Trace_e = (s_0, u_1, s_1, …, u_k, s_k)

Each state s_i snapshots the current evidence, candidate families, inferred placement, route, and open residuals. Each update u_i records an evidence acquisition, selection, routing, action, or revision step, with the rule edition ver(μ) in force. Governance declares the trace granularity. Trivial cases carry no trace; maximal per-event logging is never a blanket requirement. A minimal record carries the endpoint; an audit-ready record carries enough of the trace for the governance-derived required verdicts to be adjudicated.

Partial Applicability

Not every episode has a route, a mutation, a closure claim, or open residuals:

A read-only classification episode has a = ⊥, Succ = ∅, possibly r = ⊥, and an empty δ.
Where a component is ⊥, the verdicts that quantify over it (V4a for route, V5 for closure) are not asserted of that episode — they receive not-applicable status with a recorded reason.

“Deliberately none, with reason” is distinguished from “omitted as a defect.” “Not tested” is never “not applicable.” Every verdict excluded from ReqPath(e) carries a recorded applicability reason on the episode record.

Introduction

Core Concepts

Worked Examples

Schemas & Validation

Experiments & Terminology

Orthing Episodes: The Auditable Handling Record Schema

The Episode Signature

Record Mode: Audit-Ready vs Minimal

Evidence Channels H

Placement and Candidate Families

Residual Dispositions

Handoffs

Successors

The Endpoint and the Bounded Trace

Partial Applicability

Build docs developers (and LLMs) love

Introduction

Core Concepts

Worked Examples

Schemas & Validation

Experiments & Terminology

Documentation Index

​The Episode Signature

​Record Mode: Audit-Ready vs Minimal

​Evidence Channels H

​Placement and Candidate Families

​Residual Dispositions

​Handoffs

​Successors

​The Endpoint and the Bounded Trace

​Partial Applicability

Build docs developers (and LLMs) love

The Episode Signature

Record Mode: Audit-Ready vs Minimal

Evidence Channels H

Placement and Candidate Families

Residual Dispositions

Handoffs

Successors

The Endpoint and the Bounded Trace

Partial Applicability