End-to-end Codified-term Traceability for Debugging and Auditing Compiler and Executable Modules

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
2. Bakhvalov I.M., General Director, RTLAB Oncology; ibakhvalov@rtlab.ru;

Abstract

Objective: This article describes how codified-term traces make a governed semantic snapshot reviewable across knowledge compilation, release evidence, runtime diagnostics, and operator triage. The central claim is that the IR Term Registry and IR Term Trace provide a digest-bound join surface between authorized semantics, compiler products, runtime evidence, Plane diagnostics, and the Diagnostic Triage Workbench, while preserving a single semantic authority.

Materials and methods: The article is methodological and is grounded in bounded implementation evidence from the Plane authorization, compilation, runtime-evidence, and diagnostic-triage surfaces. External standards are used to position the method relative to ontology-based semantics, RDF graph modeling, graph-shape validation, provenance, audit-event modeling, canonical JSON digesting, schema-constrained artifacts, and software-lifecycle traceability. Internal repository specifications are used only as authoring basis and are not cited as public references.

Results: The resulting method separates three levels of trace use: design-time authorization of a snapshot, runtime joining of observed evidence to authorized term traces, and operator-facing triage of gaps without direct mutation of the semantic authority. The implementation evidence supports strict live authorization from the governed store’s named graphs into an authorized graph model, derived registry and trace artifacts, Rust binary export, digest equality checks, atomic publication, and a runtime evidence report that normalizes debug, audit, result, alert, metric, and load-test captures into safe references. A worked example uses flag_sinus_rhythm to show how deployment evidence selects a compiled bundle, how registry and trace rows bind the term path inside that bundle, and how Workbench exposes the resulting join.

Conclusion: Term traces form a reviewable hinge between authorized semantics and runtime behavior. They do not replace semantic authority, audit records, or clinical validation; they give reviewers a bounded, digest-bound way to ask whether observed executable behavior still joins to the exact authorized terms from which it was compiled.

Keywords: executable knowledge; term traceability; IR term registry; IR term trace; runtime evidence; provenance; auditability; knowledge compiler; diagnostic contour

Abbreviations and Terminological Conventions

Authorized snapshot: A governed semantic snapshot admitted as compile input after validation and authorization. In this article, an authorized snapshot is the semantic basis from which Plane derives compiler artifacts; it is not a runtime observation and it is not a UX object.

IR Term Registry: A compiler-owned registry of significant control and data terms derived from the authorized snapshot and admitted into the compiled intermediate representation. It records the stable key, kind, owner surface, source reference set, IR reference set, and authority chain for each term that needs to remain inspectable across the lifecycle.

IR Term Trace: A term-level lineage artifact that records how registry terms travel through compiler steps, where they are used, and whether trace coverage is complete, partial, unsupported, evidence-only, or absent.

Authority Refs: Safe, digest-bound references that let compiler, runtime, and triage artifacts point back to authorized terms and lineage artifacts without copying or becoming semantic authority.

Lineage Receipt: A reproducible receipt that binds the snapshot, derived registry, trace, compiled bundle, and publication evidence by digest. The receipt makes the authorization and compilation path reviewable without turning downstream artifacts into separate sources of meaning.

Runtime Evidence Report: A safe-reference report that normalizes runtime observations into a schema-constrained evidence artifact suitable for diagnostic joining. It is not a Kafka message, not a second semantic authority, and not a substitute for audit records.

Diagnostic Triage Workbench: An operator-facing UX over Plane diagnostic artifacts and commands. It persists review workspaces, groups evidence and candidates, opens safe-reference details, and records decisions while governed semantic changes remain outside the UX surface.

Operator: In this article, an unqualified “operator” means the engineer who works with the Diagnostic Triage Workbench: reviewing evidence, inspecting safe references, and making diagnostic decisions. This is a human in a review role; the term does not denote a Kubernetes Operator or any deployment or runtime automation. Operators in other roles are always named explicitly — for example, a release operator (who runs strict authorization and publication) or a runtime operator (who works with the deployed system during operation).

trace_status: The compiler-side trace coverage status for a term or term-use path. Typical statuses distinguish traced, partial, evidence-only, unsupported, and untraced cases.

join_status: The runtime-evidence join status that classifies how an observed evidence item relates to authorized term traces, for example matched, missing_authorized_term, or capture_gap.

1. Introduction

Knowledge-intensive clinical software can make runtime behavior visible in logs, metrics, audit events, results, and runtime operator screens, but visibility alone does not answer a harder governance question: does this observed behavior still join back to the exact authorized semantic terms that were admitted to compilation? The traceability gap appears when a deployed executable module emits evidence that looks operationally plausible while the reviewer cannot determine whether the observed term, threshold, prerequisite, dependency, or policy path came from governed semantics, service-local code, stale release input, or incomplete capture.

This article focuses on that gap. It treats codified terms as reviewable lifecycle objects rather than as passive labels. A term that affects compilation or runtime behavior must be traceable from the authorized snapshot into compiler products, then joinable from runtime evidence back to the same authorized basis. The goal is not to make every runtime event semantically authoritative. The goal is to make the reviewer able to distinguish authorized behavior, missing semantic coverage, implementation defects, stale releases, ambiguous references, and evidence-capture gaps.

The method is deliberately bounded. It documents an implementation-backed contract around Plane authorization, compiled bundles, runtime evidence, diagnostic contour artifacts, and Workbench UX. Its central invariant is simple: downstream artifacts can carry safe references and evidence about authorized semantics, but they do not become independent semantic authority.

2. Materials and Methods

The paper is a methodological article with bounded implementation evidence. The evidence basis consists of the Plane live-authorization path, the compiled-bundle export path, the registry and trace artifacts, the runtime evidence report model, the diagnostic contour commands, and the Diagnostic Triage Workbench surfaces that consume these artifacts. These sources define what the current implementation can prove: strict live snapshot authorization, derived registry and trace materialization, digest equality checks between Go and Rust surfaces, atomic publication of the authorized output set, and evidence-first triage over safe references.

External references provide conceptual grounding rather than product validation. OWL 2 is used for the ontology-based framing of authorized semantics [1], RDF 1.1 for the graph data model and named-graph basis [2], SHACL for fail-closed graph-shape validation [3], PROV-O for provenance and lineage vocabulary [4], FHIR Provenance and AuditEvent for healthcare analogies to provenance-bearing operational records and structured audit context [5,6], RFC 8785 for canonical JSON digesting [7], JSON Schema 2020-12 for schema-constrained evidence artifacts [8], IEC 62304 for software lifecycle discipline [9], and ISO 13485 for quality-system traceability governance context [10]. SLSA is not cited here because this article does not make a substantive release-artifact supply-chain integrity claim.

The analysis proceeds by separating the lifecycle into design-time, runtime, and operator-facing levels. Design-time analysis asks whether the snapshot authorization and compilation path produced complete, digest-bound trace artifacts. Runtime analysis asks whether observed evidence can be normalized into safe references and joined to the authorized registry and trace. Operator-facing analysis asks whether triage can expose the join status and candidate explanations without letting UX become an authority surface.

3. Trace Artifacts and Responsibility Boundaries

Term traceability works only if each artifact has a narrow responsibility. The registry identifies the significant terms admitted from the authorized snapshot. The trace records how those terms move through compilation and where coverage is incomplete. Authority Refs carry safe pointers into authorized and compiled evidence. The Lineage Receipt binds the authorization and publication path. None of these artifacts is allowed to silently invent semantics.

Table 1. Trace artifact purposes, composition, join roles, and responsibility boundaries

Artifact	Purpose	Composition	Join role	Responsibility boundary
Authorized snapshot	Admit governed semantic content to compilation	Named-graph basis, graph model, validation state, snapshot digest	Provides the semantic basis and digest context against which later artifacts join	Owns semantic authority only after authorization; runtime observations remain outside it
IR Term Registry	Enumerate significant terms that need lifecycle traceability	Term key, term kind, plane, owner surface, source refs, IR refs, authority chain	Gives runtime and UX artifacts a stable term identity for joins	Records admitted term identity and references; clinical correctness remains a separate validation question
IR Term Trace	Record compiler use and coverage of registry terms	Registry key, compiler step, trace status, gap class, diagnostic hints, safe refs	Exposes whether the term path is traced, partial, unsupported, evidence-only, or absent	Makes coverage state reviewable; semantic repair belongs to governed remediation
Authority Refs	Carry joinable references across artifacts	Safe reference identifiers, digest-bound artifact refs, line or object refs where permitted	Links compiler, runtime evidence, diagnostic contour, and UX detail panes without copying authority	Cannot become semantic authority and cannot carry unsafe runtime payloads
Lineage Receipt	Bind authorization, derivation, compilation, and publication evidence	Snapshot digest, registry digest, trace digest, bundle digest, publication receipt metadata	Lets reviewers reproduce the artifact chain that a join claims to use	Records evidence of the chain; approval of semantic changes is separate
Runtime Evidence Report	Normalize observed behavior into joinable safe references	Source surface, observed refs, evidence refs, join status, candidate kind, alternative explanations	Converts runtime observations into schema-constrained join inputs	Complements audit/debug/result/alert/metric surfaces without replacing them
Diagnostic Triage Workbench	Present artifact-first review and decision workflow	Workspace state, grouped candidates, detail drawer, decision records, remediation drafts	Makes join state inspectable for operators and reviewers	Does not write directly to the graph store, repair traces in place, or auto-remediate

4. Design-Time Use: Snapshot Authorization

Design-time trace use begins before runtime exists. A governed graph basis, modeled with ontology and RDF concepts and validated through fail-closed shape constraints [1-3], is admitted as an authorized snapshot. That snapshot is materialized as semantic_graph_model.v1, then used to derive the IR Term Registry and IR Term Trace. The derived artifacts are compiled into a bundle and bound by a lineage receipt. The important property is not merely that files are produced; it is that the registry, trace, and bundle are all tied to the same authorized graph model and to reproducible digests.

Figure 1. Lifecycle position of term traces. The registry and trace sit after snapshot authorization and before compiled release, then serve as the join surface for runtime evidence and diagnostic review.

Figure 2. Plane design-time trace integration. Strict authorization from the governed live graph state derives registry and trace artifacts from the graph model and binds them to bundle publication through equality checks and a receipt.

Completeness gates are fail-closed. A strict design-time path requires that registry and trace entries can be derived from the authorized model, that projection equality holds across the Go and Rust surfaces, and that publication is atomic. A trace may still carry a status indicating partial coverage, unsupported coverage, evidence-only handling, or an untraced path in non-strict or diagnostic contexts, but strict release authorization cannot treat unexplained gaps as complete coverage. Where current evidence is bounded, this article states the limitation explicitly: the present proof covers the strict graph-store-to-registry/trace authority path and governed descriptor metadata authority, not full product-wide clinical compiler coverage.

5. Plane Integration

Plane integration supplies the bounded implementation evidence for the design-time lifecycle. The command identifier authorize-snapshot --strict-live-graph is retained in the public manuscript as the machine-checkable name of the stage that performs strict snapshot authorization from the current governed graph-store state and rejects prebuilt authority inputs. That rejection prevents a release operator or pipeline from substituting a prebuilt registry, trace, or graph model for the governed source during strict authorization. Plane then invokes the Rust export-bin path, the stage that exports the compiled JSON/BIN bundle carrying registry and trace projections plus verifiable digests. It checks digest equality between the Go authorization surface and the Rust export surface and publishes the manifest, bundle, registry, trace, and receipt as an atomic output set.

The compiled bundle is tracked as a digest-bound evidence object, not as a second semantic source. Its bundleDigest identifies the exact executable materialization, while embedded ir_term_registry.entries[] and ir_term_trace.entries[] preserve the term keys and trace rows derived from the authorized snapshot. Release and deployment evidence identifies which bundle was published or observed; the join then asks whether a runtime term reference belongs to the registry and trace projections inside that same bundle.

The bundle-side lookup is deliberately mechanical. Plane selects the bundle by bundleDigest or release-manifest evidence, locates registry entries by term_key or ir_refs, and requires trace entries with matching term keys plus explicit trace_status and gap_class. A runtime label alone is never enough.

The strict-mode design is intentionally asymmetric. The governed named graphs and the resulting authorized snapshot are semantic authority. The registry and trace are derived review artifacts. The compiled bundle is executable materialization. Runtime evidence is post-release observation. Workbench UX is a review surface. If these responsibilities blur, a missing term can be misclassified as a runtime bug, a stale runtime reference can be treated as valid authority, or an operator screen can appear to authorize a semantic repair that never passed governance. This separation is also consistent with lifecycle and quality-system traceability expectations rather than a claim of product validation [9,10].

The clinical coverage boundary remains important. Plane can currently prove that the authorization and trace derivation surfaces obey the strict live-authority contract for the implemented paths. This does not prove that every possible clinical algorithm body, signal, threshold, or deployment mode has complete registry and trace coverage.

6. Runtime Use: Evidence Join

Runtime trace use begins when deployed behavior produces observations. The Runtime Evidence Report normalizes evidence from several runtime surfaces into safe references: the debug telemetry stream of the ECG executable module (ecg.debug), the audit ledger of the same module (ecg.audit), result surfaces, alert surfaces, metrics, and load-test captures. The report records where the observation came from, which runtime object or safe reference it points to, what authorized snapshot or bundle it appears to relate to, and how the join to registry and trace artifacts should be classified. Its schema-constrained shape and receipt-friendly digesting follow the same reproducibility discipline used for other evidence artifacts [7,8].

Figure 3. Runtime evidence join through registry and trace. Runtime surfaces are normalized into a schema-constrained report before the join engine classifies their relationship to authorized term traces.

This distinction protects audit semantics. Debug telemetry (ecg.debug) can be valuable for diagnosis, but it is not an audit ledger and does not replace the audit ledger (ecg.audit). Debug evidence may explain why an implementation path behaved as it did; audit evidence may record durable operational facts; results and alerts may expose user-visible consequences; metrics and load-test captures may expose aggregate or scenario-specific behavior. The Runtime Evidence Report brings these into one diagnostic artifact without granting any of them semantic authority.

7. Worked Example: E2E Trace of a Sinus-rhythm Flag

The bounded example below traces one concrete feature — the sinus-rhythm flag — along the full trace path. It is included to demonstrate the trace mechanics, not to validate the clinical interpretation of sinus rhythm. The same feature exists in three representations, and each one has its own stable identifier. At the authorized-semantics level it is the descriptor term — an entry in the governed rhythm-descriptor vocabulary that defines the feature as a semantic unit (identifier cardio.rhythm.descriptor.sinus_node_rhythms.flagref.flag_sinus_rhythm). At the compiler level it is the projection term — the same feature derived for the internal intermediate layer (identifier cardio.rhythm.projection.flag_sinus_rhythm). At the runtime side it is the canonical flag — the form in which the feature is emitted by the executable module during operation (identifier cardio.flag.sinus_rhythm).

The generated terminology surface links these three representations through two explicit relations. The “canonical flag for term” relation (canonicalFlagTermFor in the material) states which runtime flag corresponds to the descriptor term; the feature-registry reference (featureRegistryRef in the material) holds the correspondence between the term and its feature-registry entry. The three identifiers therefore do not denote three different features, but one semantic unit in three roles — authorized, compiled, and observed at runtime.

The split into three representations is needed because the feature has different owners and different guarantees at different lifecycle stages. The descriptor term belongs to the authorized semantics: its meaning is set and changed only through governance. The projection term belongs to the compiler and confirms that the authorized feature actually reached the internal representation from which the bundle is assembled. The canonical flag belongs to the runtime side: it is what the deployed module actually emits. Each representation can be verified independently, and the explicit relations between them turn the “authorization → compilation → runtime” transition into a checkable chain rather than an implicit match of names.

For the reviewer, this means that when an observed flag diverges from expectation, the gap can be located precisely. A missing projection term points to a gap in compilation; a missing descriptor term points to a gap in the authorized semantics; a runtime flag not bound to a projection points to a gap on the implementation or deployment side. The distinct identifiers and the relations binding them also guard against silent desynchronization on renames: a change at one level surfaces as a broken link rather than going unnoticed.

If the representations were not separated and a single flat string flag_sinus_rhythm were used everywhere, these distinctions would disappear. A text match in a log would give false confidence: the reviewer could not distinguish a feature that came from authorized semantics from a string invented by service-local code, from a stale release, or from an incomplete-capture artifact. Join statuses such as missing_authorized_term, stale_snapshot, and missing_runtime_ref would become indistinguishable, and the observed runtime flag would in effect turn into a second source of semantic authority — exactly what the method forbids.

Deployment evidence tracks the term in the compiled bundle by joining two coordinates. The first coordinate is the deployment or release reference to the exact bundle, typically represented by bundleDigest or a release-manifest digest that resolves to that bundle. The second coordinate is the term identity inside the bundle’s embedded registry and trace projections. For cardio.flag.sinus_rhythm, the join does not scan the bundle for the text flag_sinus_rhythm. It opens the selected bundle, locates a registry row whose term_key or ir_refs identifies the runtime flag, follows the registry/trace path to cardio.rhythm.projection.flag_sinus_rhythm, and then follows the descriptor-side key cardio.rhythm.descriptor.sinus_node_rhythms.flagref.flag_sinus_rhythm. The corresponding trace rows must report trace_status=traced and gap_class=none under the same bundle digest.

In bundle terms, the example is a small join table inside one compiled artifact. bundleDigest selects the artifact. ir_term_registry.entries[] gives stable rows for the runtime flag, projection term, and descriptor term. ir_term_trace.entries[] records that those rows were produced by the compiler path and are traced rather than partial, unsupported, evidence-only, or untraced. authority_chain and source_refs retain authorized graph lineage. ir_refs carry runtime and projection handles that diagnostic tools can match without reading the graph store at runtime. A matched join therefore means that the observed deployment context and the term-level path point to the same digest-bound compiled bundle, not merely that the string flag_sinus_rhythm appeared somewhere in runtime evidence.

Table 2. E2E trace of flag_sinus_rhythm across authority, compilation, runtime evidence, and UX review

Trace position	Concrete example	Join contribution	Review meaning
Authorized term	cardio.rhythm.descriptor.sinus_node_rhythms.flagref.flag_sinus_rhythm	Provides the governed descriptor-side term identity	Reviewer can see the term comes from the authorized rhythm descriptor vocabulary
Registry row	term_key=cardio.rhythm.descriptor.sinus_node_rhythms.flagref.flag_sinus_rhythm, term_kind=flag	Gives the compiler and diagnostics a stable key for this term	The term can be grouped, searched, and compared without relying on display text
Trace row	trace_status=traced, relation to cardio.rhythm.projection.flag_sinus_rhythm	Shows that the descriptor flag is projected into a compiler-visible representation	A missing or partial status here would be a compiler trace gap before runtime analysis begins
Compiled bundle	The selected bundleDigest contains registry rows for cardio.flag.sinus_rhythm, cardio.rhythm.projection.flag_sinus_rhythm, and the descriptor term, plus trace rows with matching keys, trace_status=traced, and gap_class=none	Deployment evidence supplies the observed bundle or release-manifest digest; the join gates on that digest, resolves the runtime flag through registry term_key or ir_refs, and checks trace rows in the same bundle	A stale bundle, missing registry row, missing trace row, or mismatched digest classifies as release/deployment or trace-coverage mismatch, not as semantic proof
Runtime evidence	Evidence item references cardio.flag.sinus_rhythm under compatible snapshot, bundle, and release evidence refs	Produces join_status=matched when the runtime ref joins to the authorized trace path inside the observed bundle context	The observation is trace-joined; it is still not a clinical efficacy claim
Workbench drawer	Row for cardio.flag.sinus_rhythm is grouped by trace_status=traced and join_status=matched; selecting it opens the safe-reference drawer	Drawer resolves the runtime flag to the descriptor term, projection term, bundle digest, registry/trace refs, and release evidence refs already carried by Plane artifacts	Reviewer can confirm that the observed flag is joined to the deployed bundle context or route a mismatch without editing authority from the UI

The drawer view is the operator-facing end of the trace, not a new authority artifact. For cardio.flag.sinus_rhythm, the selected row begins with the normalized runtime evidence item: a runtime ref to cardio.flag.sinus_rhythm, join_status=matched, and the available request, result, alert, audit, debug, metric, or load-test refs. The drawer then separates authority and lineage refs: authorized snapshot digest, bundleDigest or release-manifest digest, registry digest, trace digest, and safe refs to the descriptor and projection terms. The operator sees the exact path cardio.flag.sinus_rhythm -> cardio.rhythm.projection.flag_sinus_rhythm -> cardio.rhythm.descriptor.sinus_node_rhythms.flagref.flag_sinus_rhythm in the deployed-bundle context. Because the drawer is populated from safe refs and governed artifact JSON, it can explain the join and preserve review notes, but it cannot rewrite the registry, repair the trace row, or make the observed flag semantically authoritative.

The same example also illustrates failure modes. If runtime evidence emitted flag_sinus_rhythm without a safe authority reference, the drawer would show the runtime ref but lack the authority and lineage refs needed for a confident join; the status would move toward missing_runtime_ref or unbound_runtime_evidence. If a service emitted a new flag-like object with no registry row in the bundle selected by deployment evidence, the drawer would expose an affected runtime object without a matching registry/trace path, and the likely status would be missing_authorized_term. If cardio.flag.sinus_rhythm appears in generated terminology material but not in the selected bundle’s registry and trace projections, the join must not infer a match from display text, source JSON, or UX labels. If deployment evidence points to a prior bundle digest or release manifest, the term may exist in a historical bundle but not in the deployed context expected for the observation; the likely status would be stale_snapshot. The value of the trace is that these cases are not collapsed into a generic runtime error.

8. Join Status Semantics

The join result must be more precise than a binary success or failure. A matched join means the observed runtime evidence can be tied to an authorized term trace and compatible snapshot or bundle context. Other statuses distinguish absent terms, missing runtime references, ambiguous mappings, stale snapshots, unbound runtime evidence, and capture gaps. These statuses support triage without prematurely deciding whether the root cause belongs in semantic authority, implementation, deployment, or evidence capture.

Table 3. Join status semantics and diagnostic candidate mapping

join_status	Meaning	Typical candidate_kind	Alternative explanations
matched	Runtime evidence joins to an authorized term trace under the expected snapshot or bundle context	None, or review-only confirmation	Behavior may still be clinically wrong, but the trace join itself is present
missing_authorized_term	Runtime evidence points to behavior or a term-like object that has no authorized registry entry	missing_term, terminology_binding_gap, descriptor_metadata_gap	Semantic authority gap; service-local semantic invention; evidence label drift
missing_runtime_ref	Authorized trace exists, but runtime evidence lacks a safe reference needed for the join	missing_mapping, evidence_capture_gap	Runtime implementation bug; instrumentation omission; event schema omission
ambiguous_ref	Runtime evidence can join to more than one plausible authorized term or trace path	missing_mapping, wrong_applicability, terminology_binding_gap	Overloaded labels; insufficient runtime context; incomplete applicability constraints
stale_snapshot	Runtime evidence refers to a snapshot, bundle, or release context that is not the expected current basis	wrong_dependency, wrong_policy, missing_mapping	Deployment-release mismatch; delayed rollout; mixed capture window
unbound_runtime_evidence	Evidence is observable but has no safe authority ref or recognized join path	evidence_capture_gap, missing_mapping	Capture gap; non-governed diagnostic emission; implementation path outside current trace coverage
capture_gap	The diagnostic path cannot determine whether evidence is absent because behavior did not occur or because capture failed	evidence_capture_gap	Observability defect; sampling window issue; source-surface outage

Join status is therefore a diagnostic classification input, not a remediation decision. A missing_authorized_term may become a semantic-authority refinement candidate, but it may also expose a service-local bug. A stale_snapshot may require deployment investigation rather than ontology work. An ambiguous_ref may be resolved by better runtime safe references rather than new semantic content. The trace system is useful precisely because it keeps these alternatives visible.

9. Plane Diagnostic Contour and UX Use

The Plane diagnostic contour turns runtime evidence into reviewable candidate artifacts through a conceptual sequence: normalize runtime evidence, propose authority refinement, classify the candidate, correlate related evidence, classify the decision, and draft remediation. In a target-journal implementation account, the command identifiers remain as machine-checkable stage names, while their descriptive prose is carried from compiled JSON/BIN module artifacts into Workbench screens as the human-readable layer for review. This article stops at that diagnostic lifecycle. Graph mutation, governed update payloads, approval, write evidence, closure evidence, and closure decisions belong to the companion article on authorization and diagnostic contour infrastructure.

The Diagnostic Triage Workbench is an artifact-first UX over these Plane commands and outputs. It persists review workspaces, imports Runtime Evidence Reports, shows proposed authority refinement candidates, groups rows by trace_status, gap_class, candidate_kind, affected object, source surface, and release wave, and opens safe-reference detail drawers. The drawer is structured rather than decorative: runtime/debug refs, durable audit refs, artifact and lineage refs, release-wave refs, affected objects, governed artifact JSON, and artifact-supplied command/status prose are shown as separate sections. For a matched cardio.flag.sinus_rhythm row, this lets the reviewer inspect the runtime flag, trace and join status, snapshot and bundle context, descriptor/projection term path, and the descriptive meaning of the relevant Plane stages without opening raw runtime payloads. The Authority Refinement tab helps reviewers inspect whether a runtime observation suggests a missing term, mapping gap, wrong applicability, wrong prerequisite, wrong dependency, wrong policy, terminology-binding gap, descriptor-metadata gap, or evidence-capture gap.

Figure 4. Workbench operator flow. Workbench makes Plane diagnostic artifacts reviewable, but semantic changes are handed off to governed graph-update and closure workflows rather than being applied directly in the UI.

The UX contract is intentionally narrow. Workbench may help an operator choose a candidate, inspect refs, read artifact-supplied command/status prose, record a decision, and draft remediation. This matters because UX convenience can otherwise create an implicit second authority. In this method, the Workbench is allowed to make trace gaps visible and reviewable while governed closure remains outside the UI. The manuscript therefore uses schematic figures rather than screenshots; screenshots would illustrate a presentation surface, not change the traceability contract.

10. Operator Review Flow

A reviewer begins the flag_sinus_rhythm review by importing a Runtime Evidence Report into a Workbench workspace. The report may have been built from debug, audit, result, alert, metric, or load-test evidence, but the reviewer sees safe references and normalized join fields rather than unsafe raw payloads. Grouping by trace_status=traced and join_status=matched keeps the cardio.flag.sinus_rhythm row out of the semantic-gap queue while still allowing drawer inspection. In that drawer, the runtime section identifies the observed cardio.flag.sinus_rhythm reference; the authority section shows descriptor and projection term refs; the artifact/lineage section shows snapshot, registry, trace, bundle, and release evidence digests; and the affected-object section anchors the row to the term or descriptor under review.

If the same workspace contains a similar rhythm flag with missing_authorized_term, the reviewer opens the Authority Refinement view, inspects registry and trace refs, checks snapshot and bundle digests, and compares the proposed candidate kind with implementation, deployment, and capture explanations. The reviewer can classify the decision and draft a remediation packet. If the decision calls for semantic work, the item is handed off to the governed graph-update and closure workflow. If the evidence points to runtime implementation, stale deployment, or capture failure, the remediation path stays outside semantic authority.

This flow protects both sides of the lifecycle. Semantic authors do not have to infer runtime failures from unstructured logs, and runtime operators do not have to guess whether a missing reference is a missing ontology term, a release mismatch, or an instrumentation failure. The trace and join artifacts provide a shared review vocabulary while preserving separation between observation, diagnosis, authorization, and mutation.

11. Boundary With Companion Articles

This article is positioned between the compiler-language article and the diagnostic-contour article. It assumes the compiler-language article’s separation of authorized input, internal representation, and compiled output. It provides the term-level join method needed by runtime and triage papers. It deliberately avoids owning the graph-update and closure workflow, which belongs to the authorization and diagnostic-contour article.

Companion article	Boundary
Formal knowledge representation as the input and internal languages of the knowledge compiler	Owns compiler language layers, representation split, and fail-closed lowering. This article uses those layers as the basis for term traceability.
Closed-loop governance of formalizable knowledge	Owns the generic closed governance method and semantic-authority invariant. This article specializes that method for term traces and runtime joins.
Authorization and diagnostic contour as universal infrastructure for executable-knowledge development and governance	Owns remediation, graph-update requests, governed mutation, write evidence, and closure. This article stops at diagnostic classification and handoff.
Implementing executable knowledge as compute core and safety kernel	Owns runtime hosting, safety-kernel separation, and execution architecture. This article only discusses runtime evidence as a join input.
Instant health assessment through an ECG example: interpreting mixed named terms and ECG oscillograms	Owns ECG-specific instantiation and domain evidence. This article uses ECG runtime surfaces as bounded implementation evidence rather than as a clinical validation claim.

12. Limitations and Non-claims

This article does not claim clinical efficacy, clinical safety, registration-grade validation, full clinical compiler coverage, or complete ECG-domain coverage. It does not claim that all runtime behavior is already trace-covered. It does not claim that ecg.debug replaces ecg.audit, that metrics replace event evidence, or that a Runtime Evidence Report is a medical record.

The article also does not claim UX authority. Workbench is a review surface over artifacts and Plane commands. It can persist a workspace, expose grouped evidence, open safe-reference details, support classification, and draft remediation. It cannot directly write the graph store, repair trace artifacts in place, approve semantic mutation, or auto-remediate a missing authority term. These restrictions are part of the method rather than temporary omissions.

Finally, the article does not claim that digest-bound lineage proves semantic correctness. Digest equality and canonical receipts show that artifacts correspond to the same basis and were reproduced through the expected path. They do not prove that the authorized semantics were clinically adequate or that the deployed interpretation was clinically beneficial.

13. Conclusion

Codified-term traceability gives reviewers a way to connect authorized semantics, compiler products, runtime evidence, Plane diagnostics, and Workbench triage without fragmenting semantic authority. The IR Term Registry identifies the significant terms admitted to compilation. The IR Term Trace records their compiler coverage and gap state. Deployment evidence selects the compiled-bundle context in which those registry and trace projections must be found. Runtime evidence reports join observations back to those artifacts through safe references and explicit status semantics. Workbench makes the resulting evidence inspectable for operators while handing semantic mutation to governed closure workflows.

The result is a bounded but important infrastructure claim: term traces are the reviewable hinge between authorized semantics and runtime evidence. They make the lifecycle easier to debug and audit precisely because they preserve the distinction between authority, derivation, observation, diagnosis, and remediation.

Authoring Basis

The article draws on the internal documentation of the HealthOS project: the specifications, schemas, and registries that define authorized semantics and its compiled form, the runtime and tooling that produce execution evidence, and the companion manuscripts of the series, bound together by a shared terminology canon. These are working sources that ground the engineering decisions and keep terminology consistent across the series. They remain internal authoring basis rather than public references and are not cited as repository links in the text.

Conflict of Interest

The manuscript describes the implementation of a specific aspect of the HealthOS platform, namely: end-to-end codified-term traceability for debugging and auditing the knowledge compiler and executable modules.

Funding

The work was funded by RTLAB.

References

1. W3C OWL Working Group. OWL 2 Web Ontology Language Document Overview (Second Edition). W3C Recommendation; 2012. https://www.w3.org/TR/owl2-overview/
2. Cyganiak R, Wood D, Lanthaler M, editors. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation; 2014. https://www.w3.org/TR/rdf11-concepts/
3. Knublauch H, Kontokostas D, editors. Shapes Constraint Language (SHACL). W3C Recommendation; 2017. https://www.w3.org/TR/shacl/
4. Lebo T, Sahoo S, McGuinness D, editors. PROV-O: The PROV Ontology. W3C Recommendation; 2013. https://www.w3.org/TR/prov-o/
5. HL7 International. FHIR Resource Provenance (R4). https://hl7.org/fhir/R4/provenance.html
6. HL7 International. FHIR Resource AuditEvent (R4). https://hl7.org/fhir/R4/auditevent.html
7. Rundgren A, Jordan B, Erdtman S. JSON Canonicalization Scheme (JCS). RFC 8785; 2020. https://www.rfc-editor.org/rfc/rfc8785
8. JSON Schema authors. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
9. International Electrotechnical Commission. IEC 62304:2006/AMD 1:2015 Medical device software - Software life cycle processes. https://www.iso.org/standard/64686.html
10. International Organization for Standardization. ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes. https://www.iso.org/standard/59752.html