Closed Truth-Distillation Cycle

The closed truth-distillation cycle is a formal methodology for creating, validating, compiling, and deploying clinical knowledge in a deterministic decision-support system. It provides a reproducible, auditable, and publication-ready framework for converting clinical expertise into a versioned decision artifact — the compiled bundle — and for feeding evidence from its deployment back into the knowledge creation process.

The methodology is designed to satisfy three simultaneous requirements: regulatory traceability (full provenance chain), scientific reproducibility (identical inputs → identical outputs, at any future time), and clinical governance (every knowledge change requires expert review and formal approval).

1. The distillation problem

Clinical knowledge exists in an unstructured continuum — literature, guidelines, expert judgment, case history. Converting this into executable decision logic introduces failure modes at each step: knowledge may be misrepresented during encoding, inconsistencies may be introduced between rules, implementation may deviate from intent, and runtime behavior may drift from the compiled artifact.

The closed truth-distillation cycle addresses all four failure modes through structural constraints at each stage:

  1. Encoding — knowledge is represented in a formal graph with explicit ontological commitments
  2. Consistency — SHACL constraints validate the graph before compilation
  3. Implementation fidelity — the knowledge compiler produces a deterministic artifact from the approved graph; human review of the compiled artifact is optional but supported
  4. Runtime fidelity — the evidence-of-fact receipt chains the compiled artifact to the runtime output, making drift detectable

2. Roles and responsibilities

Role Responsibility Sign-off scope
Knowledge author Drafts and edits rules in the graph Individual rule changes
Knowledge approver Clinical validation and formal approval Rule set for compilation
Knowledge compiler Toolchain: graph → signed bundle Bundle integrity
Release operator Deploys approved bundle to runtime Deployment record

No single role can complete the cycle alone. This four-eyes-minimum structure is a deliberate constraint against unilateral knowledge changes.

3. The distillation stages

Seven stages of distillation Seven nodes: evidence gathering, knowledge encoding, validation, compilation, deployment, runtime — arranged in a row; evidence extraction sits below the "runtime" stage; an arrow returns from evidence extraction to evidence gathering, closing the cycle. STAGES OF DISTILLATION 1. Evidencegathering 2. Knowledgeencoding 3. Validation 4. Compilation 5. Deployment 6. Runtime 7. Evidenceextraction refinement candidates — back to evidence gathering
Seven stages of distillation: from evidence gathering to evidence extraction, closing the cycle.

Stage 1 — Evidence gathering. Relevant clinical literature, guidelines, and expert judgment are assembled. Sources are cited in the medical knowledge graph store as evidence references.

Stage 2 — Knowledge encoding. Clinical knowledge is encoded as formal graph triples with explicit ontological commitments. Each rule is a named, versioned entity in the graph. The knowledge author is responsible for encoding fidelity.

Stage 3 — Validation. SHACL constraints are applied to the graph snapshot. Constraint failures are blocking: a graph that fails SHACL validation cannot be compiled. The knowledge approver reviews the validated snapshot and provides formal sign-off.

Stage 4 — Compilation. The knowledge compiler transforms the approved snapshot into a compiled bundle. The compilation digest is recorded in the evidence-of-fact receipt.

Stage 5 — Deployment. The release operator deploys the bundle to the edge runtime via the governed write surface. The deployment event is logged with bundle digest, operator ID, and timestamp.

Stage 6 — Runtime. The Compute core executes the bundle. All inputs and outputs are recorded in the audit event log.

Stage 7 — Evidence extraction. The audit event log is processed to extract runtime evidence reports. Patterns suggesting knowledge gaps or errors are formalised as refinement candidates, which feed back to stage 1.

4. The evidence-of-fact receipt as a scientific citation

The evidence-of-fact receipt enables reproducible citation of a decision-support intervention in a peer-reviewed publication. A complete citation contains:

  • Platform version
  • Bundle version (digest)
  • Knowledge graph commit (digest)
  • Deployment timestamp
  • Evidence-of-fact receipt hash

This is equivalent in precision to citing a specific version of a software library in a computational methods section. Reviewers can verify that the same intervention can be replicated at another institution by deploying the same compiled bundle.

5. Multicenter reproducibility

Because the Compute core produces identical outputs from identical inputs regardless of deployment site, a multicenter study using HealthOS ICU can guarantee intervention consistency without site-specific AI tuning or calibration. The compiled bundle version is the intervention definition; its digest is the intervention identifier.

6. Limitations

  • The methodology does not eliminate the possibility of knowledge encoding errors — it makes such errors detectable and traceable
  • Evidence extraction (stage 7) is a governed process; the loop closes through human review, not automatic rule updates
  • SHACL validation catches structural inconsistencies but not clinical errors of omission
  • The methodology assumes a disciplined governance culture; technical constraints alone cannot substitute for clinical expertise

Documents

Glossary → · Full Concept → · Conformance →

Discuss scientific co-authorship or multicenter validation. Contact for co-authorship →