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.

A composite episode is a first-class occurrence-centered record that spans multiple sub-episodes, unifying their claim ledgers, evidence items, and verdicts under a single declared analysis. What makes an episode composite is not just that it has multiple claims — a simple episode may also carry several claims — but that those claims were produced by distinct actors or stages across a typed edge graph, and the framework requires that the composition be declared rather than implicit. This example traces sample 77 through an intake pipeline where an auto-classifier initially misidentifies the substance and a bench validator corrects it, producing a composite episode whose final placement is correct while one constituent sub-episode’s placement was not. This is a deterministic illustrative fixture; no empirical claim is made.

​
Why composition matters

Separate auditability

Each sub-episode (ep-classify-1, ep-validate-2) carries its own claim ledger, actor, evidence, and verdict record. Their inadequacies or correctness are each independently recorded.

Non-conjunctive composite verdicts

RESULT_CORRECT(composite) = pass while RESULT_CORRECT(ep-classify-1) = fail. The composite verdict is not the conjunction of sub-episode verdicts, and is audited separately.

Declared boundary

The composite is valid only when three conditions hold: one case, one analysis, a declared boundary, and a declared fusion rule. All three are satisfied here.

Typed edges

Sub-episodes are connected by typed handoff/supersession edges that carry the claim scope and version for which each handoff packet is valid.

​
The scenario

Lab sample 77 arrives and enters the intake pipeline under analysis sample-intake v2.0, whose task is “classify and route incoming samples.” The pipeline has two stages:
  1. ep-classify-1 (auto-classifier): classifies the sample’s substance axis. Placement: substance: "flour (INCORRECT)". The classifier is wrong — sample 77 is cornstarch.
  2. ep-validate-2 (bench-validator): receives the handoff packet from ep-classify-1, performs bench validation, supersedes the classification, corrects the placement to substance: "cornstarch", and routes the sample.
The composite episode ep-composite-intake-77 is the declared composition of these two, covering the full pipeline interval from 09:00 to 10:30 on 2026-07-14. Its placement is substance: "cornstarch" — the correct result.

​
The episode DAG

The edge graph Γ_E connects the two sub-episodes with two typed edges: a handoff edge (ep-classify-1 passes the state claim forward) and a supersession edge (ep-validate-2 supersedes ep-classify-1’s placement). Both edges carry the same subject (sample-77 version received) and the same claim scope. 
{
  "composition_record": {
    "graph": {
      "nodes": ["ep-classify-1", "ep-validate-2"],
      "edges": [
        ["ep-classify-1", "ep-validate-2", "handoff"],
        ["ep-classify-1", "ep-validate-2", "supersession"]
      ]
    },
    "conditions": {
      "one_case_one_analysis": true,
      "declared_boundary": "intake-pipeline named as composite actor by lab governance",
      "declared_fusion_rule": "placement = latest non-superseded sub-placement; per-claim status = weakest along its supporting path; residual ledgers merged with surviving ownership"
    },
    "composite_id": "ep-composite-intake-77",
    "verdict_note": "RESULT_CORRECT(composite)=pass while RESULT_CORRECT(ep-classify-1)=fail — composite verdicts are not conjunctions and the composite level is audited separately"
  }
}

​
The two handoff packets

Each typed edge is carried by a handoff packet that records the sender, the receiver, the claim scope, and the version for which the claim is asserted. 
{
  "packet_id": "pkt-77-1",
  "sender_episode": "ep-classify-1",
  "receiver_episode": "ep-validate-2",
  "edge_label": "handoff",
  "subject": {
    "identity_key": "sample-77",
    "version": "received"
  },
  "state_claims": [
    {
      "claim_id": "claim-substance",
      "scope": "substance axis",
      "valid_for_version": "received",
      "analysis_id": "sample-intake",
      "analysis_version": "2.0"
    }
  ]
}

​
The sub-episodes

1

ep-classify-1: auto-classifier (incorrect)

The auto-classifier places substance: "flour (INCORRECT)" at 09:00. The episode has an empty meta_tokens list (zero-burden) and no route. The successor list is empty at this stage — the sample has not yet been routed.
{
  "episode_id": "ep-classify-1",
  "occurrence": {
    "identity_key": "sample-77",
    "version": "received",
    "kind": "lab-sample"
  },
  "actor": "auto-classifier",
  "analysis": {
    "analysis_id": "sample-intake",
    "version": "2.0",
    "task": "classify and route incoming samples"
  },
  "time": "2026-07-14T09:00:00Z",
  "meta_tokens": [],
  "placement": {
    "substance": "flour (INCORRECT)"
  },
  "action": "forward",
  "successors": []
}
RESULT_CORRECT for this sub-episode: fail. The placement is wrong — the substance is cornstarch, not flour.
2

ep-validate-2: bench-validator (correction)

The bench validator receives the handoff from ep-classify-1, performs bench validation, corrects the placement to substance: "cornstarch", and routes the sample. The action is correct-and-route. The successor is sample-77 version routed.
{
  "episode_id": "ep-validate-2",
  "occurrence": {
    "identity_key": "sample-77",
    "version": "received",
    "kind": "lab-sample"
  },
  "actor": "bench-validator",
  "analysis": {
    "analysis_id": "sample-intake",
    "version": "2.0",
    "task": "classify and route incoming samples"
  },
  "time": "2026-07-14T10:00:00Z",
  "meta_tokens": [],
  "placement": {
    "substance": "cornstarch"
  },
  "action": "correct-and-route",
  "successors": [
    {
      "identity_key": "sample-77",
      "version": "routed",
      "action_label": "route"
    }
  ]
}
RESULT_CORRECT for this sub-episode: pass. The downstream validator caught the upstream error.
3

ep-composite-intake-77: the declared composite

The composite episode spans the full pipeline interval. Its actor is intake-pipeline, declared as the composite actor by lab governance. Its placement is the latest non-superseded sub-placement: substance: "cornstarch". Its action is route; its successor is sample-77 version routed.
{
  "episode_id": "ep-composite-intake-77",
  "actor": "intake-pipeline (declared composite actor)",
  "time": "2026-07-14T09:00:00Z/2026-07-14T10:30:00Z",
  "placement": {
    "substance": "cornstarch"
  },
  "action": "route",
  "successors": [
    {
      "identity_key": "sample-77",
      "version": "routed",
      "action_label": "route"
    }
  ]
}
RESULT_CORRECT(composite) = pass, even though RESULT_CORRECT(ep-classify-1) = fail.

​
Composite verdicts are not conjunctions

This is the central lesson of the fixture. The source record’s verdict_note states it directly:
RESULT_CORRECT(composite)=pass while RESULT_CORRECT(ep-classify-1)=fail — composite verdicts are not conjunctions and the composite level is audited separately.
The fusion rule (“per-claim status = weakest along its supporting path”) applies to pathway verdicts, not to result correctness. Result correctness at the composite level is assessed against the composite placement — which is correct — regardless of what happened at sub-episode level. The audit trail preserves both: the sub-episode error is not erased by the correction; it remains visible in ep-classify-1’s own record.
Treating composite verdicts as conjunctions of sub-episode verdicts is a formal error. The correct-result / defective-pathway and incorrect-result / adequate-pathway cells both demonstrate why: the downstream validator catching an upstream error is exactly the counterexample (counterexample ledger entries #15 and #16 in the source) showing that a sub-episode can be incorrect while the composite is correct.

​
Factorized placement and independent axes

Within a single sub-episode, placement over multiple axes is factorized: each axis is assessed independently under its own evidence and governing token (if any). The substance axis in this example is the only axis declared under sample-intake v2.0 for this occurrence. In episodes with multiple axes — such as the pillar episode, which independently places over perpendicularity and surface-condition — each axis may have its own evidence items, its own token dependencies, and its own per-claim reasoning path.
When governing tokens are present and multiple claims each depend on different tokens, the per-claim verdict adjudication records each claim’s token_truth_linked independently. The per_token_v3c array then lists each token’s GOV_TOKEN_ADEQUATE status and, if failing, its failing_conjunct. This composite fixture has meta_tokens: [] for all sub-episodes, so GOV_TOKEN_ADEQUATE is not-applicable throughout.

​
Residual ledger merging and the reread requirement

The declared fusion rule merges residual ledgers with “surviving ownership” — burdens from sub-episodes that are unresolved at handoff survive into the composite ledger. This matters when resolving one burden invalidates another’s basis. The whole-state-reread.json fixture illustrates this directly: two coupled burdens, B1 (migrate the store) and B2 (rollback rehearsal), start together. B1 lands first — the data is migrated and consumers read from the new store (disposition: "validated-resolved"). The reread triggered by B1’s landing then re-dispositions B2 to unresolved, because B2’s accepted-risk record was written assuming rollback meant “repoint to the old store,” and B1’s completion decommissioned that path. The fixture below is the post-reread state: B1 is resolved and B2 is honestly unresolved. 
{
  "residuals": [
    {
      "burden_id": "B1-migrate-store",
      "description": "move data and switch consumers to the new store",
      "disposition": "validated-resolved",
      "evidence_refs": ["ev-cutover-metrics-1"]
    },
    {
      "burden_id": "B2-rollback-rehearsal",
      "description": "rehearse rollback; the accepted-risk record was written when rollback meant 'repoint to the old store' — B1's completion decommissioned that path, so the acceptance basis is void",
      "disposition": "unresolved",
      "responsible_queue": "platform-reliability backlog",
      "next_review_condition": "when a rollback path for the new store exists and can be rehearsed, or at the next release-readiness review, whichever comes first"
    }
  ],
  "closure_claim": null
}
The post-reread ledger honestly records B2 as unresolved. No closure claim is asserted. The pre-reread variant — which would have asserted a closure claim over an unresolved residual — is negative fixture N11 and must be rejected. In a composite episode, the same principle applies across the merged ledger: resolving a burden in one sub-episode may require re-reading the disposition of burdens in another before any composite closure claim can be asserted.
The composition_record.conditions block records three conditions that must all be satisfied for comp(Γ_E) to be valid:
  1. one_case_one_analysis: all sub-episodes address the same occurrence under the same declared analysis. Here: sample-77 version received under sample-intake v2.0.
  2. declared_boundary: the composite actor must be declared by governance, not inferred. Here: “intake-pipeline named as composite actor by lab governance.”
  3. declared_fusion_rule: the rule for deriving the composite placement and merging claim statuses and residuals must be stated explicitly. Here: “placement = latest non-superseded sub-placement; per-claim status = weakest along its supporting path; residual ledgers merged with surviving ownership.”
Absence of any one condition means the sub-episodes cannot be composed into a single auditable composite — they remain separate records.
The required path ReqPath(e) for the composite episode is derived from the governance configuration of the analysis and the risk class of each claim. Because meta_tokens is empty throughout, GOV_TOKEN_ADEQUATE (V3c) is not-applicable. The path for each claim includes the standard evidence pathway verdicts (V2a, V2b-P, V2c), the governance configuration verdicts (V3a, V3b), execution fidelity (V3d), and ex-ante justification (V3e). Route and closure verdicts apply at the composite level if a route is selected and a closure claim is asserted.

Build docs developers (and LLMs) love

Get started for freeTalk to us