Documentation

# Conceptual Specification of Radiology Transcript Interpretation ## Status This document is a conceptual and normative specification of a system that transforms radiology transcripts into validated structured semantic data. It is not an implementation plan. It does not prescribe a particular parser, graph matcher, programming language, runtime topology, or downstream consumer. It is intentionally written above those mechanisms. The system may use technologies such as Universal Dependencies, UCxn, MoCCA, FrameNet, RadLex, Grew, and Prolog, but those technologies are treated as external bodies of knowledge or implementation resources. They do not define the conceptual architecture of the system. The specification is organized around the concepts that give the system its meaning. The governing principle is: > Preserve source meaning, establish structure incrementally, never invent unsupported instance-level facts, and make every derived interpretation explainable. --- # Table of Contents 1. Vision 2. Conceptual Model 3. System Concepts and Invariants 4. Reference Appendices --- # 1. Vision ## 1.1 Purpose The system interprets a radiology transcript and produces a validated structured representation of what the transcript says. The system is not intended to diagnose disease, infer hidden clinical facts, or construct a complete model of the patient. Its purpose is narrower: > **Understand, structure, and enrich the language of the report without exceeding the evidence provided by the report and the explicitly permitted semantic knowledge of the system.** The source transcript remains authoritative. The system progressively introduces more explicit structure: ```text SOURCE LANGUAGE ───────────────────────────────────── What was actually said. LINGUISTIC STRUCTURE ───────────────────────────────────── How the source is grammatically organized. CONSTRUCTIONAL STRUCTURE ───────────────────────────────────── Which conventional form–meaning patterns occur. DISCOURSE STRUCTURE ───────────────────────────────────── What is being referred to and how mentions relate. SEMANTIC STRUCTURE ───────────────────────────────────── What roles, relations, quantities, states, and assertions are expressed. DOMAIN GROUNDING ───────────────────────────────────── Which external medical concepts the discourse objects correspond to. VALIDATED STRUCTURED OUTPUT ───────────────────────────────────── A source-grounded semantic representation suitable for downstream applications. ``` The validated structured output is the product of this project. A downstream system may later render, search, transform, summarize, or otherwise consume that output, including by a language-model-based application. Such downstream consumers are outside the scope of this specification. ## 1.2 Design Intent The system should have the following qualities. ### 1.2.1 Source fidelity No later representation should obscure what source evidence justified it. ### 1.2.2 Semantic restraint The system should establish only the instance-level facts that are supported by the source or by explicitly permitted derivations. ### 1.2.3 Explicit ambiguity When the source supports multiple interpretations, the representation should preserve those alternatives rather than silently selecting one. ### 1.2.4 Compositionality Larger meanings should be assembled from smaller recognized structures. ### 1.2.5 External grounding The system should reuse established linguistic and medical knowledge where appropriate instead of inventing private substitutes. ### 1.2.6 Explainability Every accepted semantic assertion should retain enough provenance to explain why it exists. ## 1.3 Non-Goals This system does not attempt to: - infer diagnoses that are not stated; - infer hidden patient anatomy merely because ontology knowledge implies it abstractly; - reconstruct a complete clinical world; - eliminate all ambiguity; - define a universal theory of language; - replace established linguistic standards; - replace RadLex or any other external ontology; - generate final report prose; - perform downstream stylistic rendering. ## 1.4 The Fundamental Boundary The most important architectural distinction is between: ```text ABSTRACT KNOWLEDGE ───────────────────────────────────── General linguistic and domain knowledge. Examples: - a construction type; - a semantic frame type; - a RadLex class; - a MoCCA comparative concept; - a grammatical relation. TRANSCRIPT INTERPRETATION ───────────────────────────────────── Concrete structures established while interpreting this specific transcript. Examples: - a mention; - a construct instance; - a discourse referent; - a frame instance; - a grounded concept association; - an explicit ambiguity. ``` Abstract knowledge constrains interpretation. It does not, by itself, populate the transcript model with concrete individuals. --- # 2. Conceptual Model ## 2.1 Overview The system is described using a small set of concepts: ```text Source Mention Construct Construction Element Referent Frame Composition Grounding Ambiguity Provenance Diagnostic Validation ``` These concepts describe what the system means. Implementation mechanisms such as parsers, graph matchers, rule engines, indexes, and serialized formats exist only to realize these concepts. ## 2.2 Representation Flow The system transforms the input through a sequence of increasingly explicit representations. ```text R0 Source Transcript ↓ R1 Linguistically Annotated Source ↓ R2 Construction-Annotated Source ↓ R3 Discourse and Frame Model ↓ R4 Domain-Grounded Semantic Model ↓ R5 Validated Structured Output ``` The transformations are not required to be implemented as five literal runtime stages. The sequence expresses a conceptual ordering: 1. source evidence exists before interpretation; 2. linguistic structure exists before higher-order constructional interpretation; 3. constructional interpretation precedes semantic composition; 4. discourse objects and frames precede domain grounding; 5. validation constrains the final structured output. ## 2.3 Global Transformation Properties Every transformation should satisfy the following properties. ### Source preservation Later representations must retain access to the source evidence from which they were derived. ### No silent contradiction A later representation may enrich an earlier representation but must not silently contradict an established source-backed fact. ### No unsupported instance creation No transformation may create a discourse or application-level entity solely because external ontology knowledge implies that such an entity exists in the abstract. ### Explicit unresolved state A transformation may produce unresolved or ambiguous structure. Failure to resolve is not permission to guess. ### Traceable derivation Every semantic assertion must be derivable from a known combination of: - source evidence; - recognized linguistic/constructional structure; - discourse relationships; - external semantic/domain knowledge; - explicitly specified system rules. --- # 3. System Concepts and Invariants # 3.1 Source ## Purpose The Source preserves the exact evidence supplied to the system. The source is the authoritative record of what was said. ## Operational Principle The system stores the original transcript and stable source locations that can be referenced by later objects. A source location may be represented as: ```text document sentence token character span ``` or another equivalent representation. The essential requirement is stable traceability. ## Model Interpretation ```text SOURCE ───────────────────────────────────── "There is a 6 mm pulmonary nodule in the right upper lobe." ``` Later structures may refer back to: ```text "6 mm" "pulmonary nodule" "right upper lobe" ``` without replacing the original source. ## Concrete Example ```prolog source_span( s1, 11, 17, "6 mm" ). ``` The syntax is illustrative. ## Formal Properties / Invariants For every derived object d: ```text derived(d) → ∃ s : SourceEvidence(s) ∧ supports(s,d) ``` Source evidence is immutable with respect to interpretation. ## Entails A source span establishes that the corresponding text occurred in the transcript. ## Does Not Entail A source span does not establish the medical truth of the words it contains. Mentioning a concept is not equivalent to asserting that the concept is present. --- # 3.2 Mention ## Purpose A Mention represents a linguistically identifiable expression in the source that participates in interpretation. Mentions separate surface language from discourse identity. ## Operational Principle A mention is anchored to source evidence and may carry linguistic, lexical, semantic, or normalization information. Multiple mentions may later refer to the same discourse referent. ## Model Interpretation ```text SOURCE ───────────────────────────────────── "A nodule is present. It measures 6 mm." MENTIONS ───────────────────────────────────── m1 = "A nodule" m2 = "It" m3 = "6 mm" ``` `m1` and `m2` are distinct mentions even if they eventually refer to the same object. ## Concrete Example ```prolog mention(m1, source_span(...)). mention(m2, source_span(...)). ``` Later: ```prolog refers_to(m1, f1). refers_to(m2, f1). ``` ## Formal Properties / Invariants Every mention is source-grounded: ```text Mention(m) → ∃ s : SourceEvidence(s) ∧ anchored_in(m,s) ``` A mention and a referent are distinct concepts: ```text Mention(m) ⇏ Referent(m) ``` ## Entails A mention establishes that an expression occurred and has been identified as relevant to interpretation. ## Does Not Entail A mention does not by itself establish: - discourse identity; - ontology identity; - presence; - absence; - patient-world existence. --- # 3.3 Construct ## Purpose A Construct captures an instance of a conventional meaningful linguistic structure found in the source. The concept exists because individual dependency edges or tokens often do not express the larger semantic organization of an utterance. ## Operational Principle The system recognizes that a region of the linguistic representation instantiates a known construction type. The construct binds construction elements to specific linguistic material. Constructs may overlap. A source region may participate in more than one construct. ## Model Interpretation Source: ```text A pulmonary nodule in the right upper lobe measures 6 mm. ``` Possible constructs: ```text Measurement-Predicate Finding-Location Nominal-Modification ``` Each construct captures a different meaningful organization of the same source. ## Concrete Example ```prolog construct(c1, measurement_predicate). construction_element(c1, entity, m_nodule). construction_element(c1, measurement, m_6mm). ``` ## Formal Properties / Invariants Every construct has exactly one construction type: ```text Construct(c) → ∃! t : ConstructionType(t) ∧ instance_of(c,t) ``` Every construction element must be bound to valid source-backed linguistic material or an explicitly permitted derived element. Constructs may overlap: ```text overlap(c1,c2) ``` is legal. ## Entails A construct establishes that the source instantiates a known linguistic form–meaning pattern. ## Does Not Entail Construct recognition alone does not establish: - ontology grounding; - discourse identity; - patient-world existence; - a final application relation. A location-like construct does not automatically mean that the application should assert `located_in/2`. --- # 3.4 Construction Element ## Purpose A Construction Element identifies the role played by a specific part of the source inside a construct. ## Operational Principle A construct defines named roles. A recognized construct instance binds those roles to source-backed linguistic objects. Examples include: ```text Entity Measurement Figure Ground Predicate ResultState Baseline Degree ``` ## Model Interpretation For: ```text The nodule measures 6 mm. ``` the construct might contain: ```text Measurement-Predicate ───────────────────────────────────── Entity → "The nodule" Predicate → "measures" Measurement → "6 mm" ``` ## Concrete Example ```prolog construction_element(c1, entity, m1). construction_element(c1, predicate, m2). construction_element(c1, measurement, m3). ``` ## Formal Properties / Invariants Every bound element must belong to the construct type's allowed role vocabulary. ```text element(c,r,x) → Construct(c) ∧ allowed_role(type(c),r) ``` ## Entails A construction element establishes a role within a recognized construct. ## Does Not Entail A construction element name is not automatically an application-level semantic relation. For example, `Ground` is a constructional/semantic role, not necessarily a RadLex relation. --- # 3.5 Referent ## Purpose A Referent represents the discourse object that one or more mentions are about. The concept separates linguistic expressions from discourse identity. ## Operational Principle Mentions may introduce or refer to discourse referents. Multiple mentions may resolve to the same referent. A referent exists in the interpretation of the transcript. It is not automatically a metaphysical claim that an independently existing patient-world object has been established. ## Model Interpretation ```text SOURCE ───────────────────────────────────── "There is a nodule. It measures 6 mm." MENTIONS ───────────────────────────────────── m1 = "a nodule" m2 = "it" DISCOURSE ───────────────────────────────────── m1 → f1 m2 → f1 ``` ## Concrete Example ```prolog referent(f1). refers_to(m1, f1). refers_to(m2, f1). ``` ## Formal Properties / Invariants Every referent must be grounded in one or more mentions or in an explicitly specified permitted derivation: ```text Referent(r) → ∃ m : Mention(m) ∧ refers_to(m,r) ``` No external ontology existential creates a referent: ```text OntologyImpliesExistence(c) ⇏ ∃ r : Referent(r) ∧ grounded_as(r,c) ``` ## Entails A referent establishes a discourse-level identity. ## Does Not Entail A referent does not necessarily establish: - physical existence; - clinical truth; - independent ontology instance membership. A negated mention may participate in semantic interpretation without creating a positive finding instance. --- # 3.6 Frame ## Purpose A Frame represents a structured semantic situation with named participant roles. Frames provide an intermediate semantic vocabulary between linguistic constructions and application predicates. ## Operational Principle A recognized construct may evoke one or more frame types. Construction elements and discourse referents fill frame roles. ## Model Interpretation Measurement: ```text MEASUREMENT ───────────────────────────────────── Entity → f1 Value → 6 Unit → mm Dimension → unresolved or inferred if permitted ``` Location: ```text LOCATION ───────────────────────────────────── Figure → f1 Ground → a1 ``` ## Concrete Example ```prolog frame(fr1, measurement). frame_role(fr1, entity, f1). frame_role(fr1, value, 6). frame_role(fr1, unit, mm). ``` ## Formal Properties / Invariants Every frame role must be licensed by the frame type: ```text frame_role(f,r,x) → Frame(f) ∧ allowed_frame_role(type(f),r) ``` Every frame instance must retain evidence linking it to one or more constructs or explicitly specified semantic rules. ## Entails A frame establishes a semantic organization of interpreted source material. ## Does Not Entail A frame is not necessarily a final application assertion. A `LOCATION` frame may still require domain grounding or disambiguation before being projected into a domain relation. --- # 3.7 Composition ## Purpose Composition combines smaller recognized structures into a larger coherent interpretation. ## Operational Principle Constructs, referents, and frames may share participants. When their roles and constraints are compatible, the system composes them. Composition does not erase the components. ## Model Interpretation Source: ```text There is a 6 mm nodule in the right upper lobe. ``` Recognized structures: ```text Existential/Presentation Measured-Nominal Location ``` Composition identifies a common referent: ```text finding f1 ``` and yields: ```text measurement frame → f1 location frame → f1 ``` ## Concrete Example ```prolog refers_to(m_nodule, f1). frame_role(fr_measurement, entity, f1). frame_role(fr_location, figure, f1). ``` ## Formal Properties / Invariants Composition may add relationships among existing objects. It must not erase the provenance of the contributing structures. If two structures are incompatible, composition must not silently choose one. ## Entails Composition establishes that multiple semantic structures participate in one coherent interpretation. ## Does Not Entail Shared source proximity alone does not justify composition. Composition requires explicit structural or semantic evidence. --- # 3.8 Grounding ## Purpose Grounding connects linguistic or discourse objects to established external domain concepts. For this system, the primary medical ontology is RadLex. ## Operational Principle Mentions or discourse referents may be associated with one or more candidate ontology concepts using lexical, constructional, contextual, and semantic evidence. Grounding may remain ambiguous. ## Model Interpretation ```text SOURCE ───────────────────────────────────── "right upper lobe" MENTION ───────────────────────────────────── m7 REFERENT ───────────────────────────────────── a2 ONTOLOGY ───────────────────────────────────── RadLex concept: right upper lobe ``` ## Concrete Example ```prolog grounding( a2, radlex_right_upper_lobe ). ``` ## Formal Properties / Invariants Grounding connects transcript interpretation to ontology classes: ```text grounded_as(r,c) → Referent(r) ∧ OntologyConcept(c) ``` Grounding does not create referents: ```text OntologyConcept(c) ⇏ ∃ r : grounded_as(r,c) ``` Ontology knowledge may constrain interpretation but may not independently populate the transcript model. ## Entails Grounding establishes that a transcript object is being interpreted through the semantics of an external concept. ## Does Not Entail Grounding does not imply that: - the external ontology asserts this transcript referent as an individual; - every existential restriction of the ontology has a corresponding transcript referent; - all ontology relationships become application relationships. --- # 3.9 Ambiguity ## Purpose Ambiguity prevents unsupported certainty from being represented as fact. ## Operational Principle When the available evidence supports multiple interpretations and does not justify selecting one, the system preserves the alternatives explicitly. Ambiguity is a normal structured result. ## Model Interpretation Source: ```text There is a nodule near the fissure measuring 6 mm. ``` Possible interpretations: ```text measurement → nodule measurement → fissure ``` If neither can be eliminated by permitted evidence: ```text AMBIGUOUS ATTACHMENT ───────────────────────────────────── Candidate A → nodule Candidate B → fissure ``` ## Concrete Example ```prolog ambiguous_attachment( measurement_1, [ candidate(f1), candidate(a1) ] ). ``` ## Formal Properties / Invariants If two interpretations are supported and neither dominates under the system's rules: ```text supported(i1) ∧ supported(i2) ∧ ¬ preferred(i1,i2) ∧ ¬ preferred(i2,i1) → preserve({i1,i2}) ``` No transformation may silently collapse explicit ambiguity. ## Entails Ambiguity establishes that the system has identified multiple supported alternatives. ## Does Not Entail Ambiguity is not an error. It does not imply that the transcript is malformed. It does not authorize arbitrary selection. --- # 3.10 Provenance ## Purpose Provenance explains how a derived interpretation arose. ## Operational Principle Derived objects retain references to their relevant source evidence, recognized constructs, semantic rules, external concept alignments, and permitted derivations. ## Model Interpretation A semantic relation might carry: ```text SOURCE "nodule measures 6 mm" LINGUISTIC EVIDENCE subject(measures, nodule) quantity(6 mm) CONSTRUCT Measurement-Predicate FRAME Measurement GROUNDING nodule → pulmonary nodule SEMANTIC RESULT measurement_of(q1,f1) ``` ## Concrete Example ```prolog supports( measurement_of(q1, f1), [ source_span(...), construct(c1), frame(fr1) ] ). ``` ## Formal Properties / Invariants Every accepted semantic assertion must have a derivation path: ```text SemanticAssertion(a) → ∃ p : ProvenancePath(p) ∧ derives(p,a) ``` Later transformations may add provenance but must not destroy the ability to trace the assertion back to source evidence. ## Entails Provenance establishes why the system believes a representation is justified. ## Does Not Entail Provenance does not itself guarantee correctness. It makes correctness auditable. --- # 3.11 Diagnostic ## Purpose A Diagnostic represents a limitation, unsupported form, conflict, or incomplete interpretation without forcing the system to fabricate meaning. ## Operational Principle When a representation cannot be completed under the system's rules, the system emits a structured diagnostic attached to relevant source evidence. Examples: ```text unknown construction ambiguous attachment unresolved referent ambiguous grounding unsupported semantic projection malformed measurement ``` ## Model Interpretation ```text SOURCE ───────────────────────────────────── "RUL noduel 6 mm" DIAGNOSTIC ───────────────────────────────────── unknown lexical normalization: "noduel" possible spelling candidate: "nodule" ``` ## Concrete Example ```prolog diagnostic( d1, ambiguous_grounding, mention(m7), candidates([...]) ). ``` ## Formal Properties / Invariants Diagnostics must not silently become semantic assertions. A diagnostic must identify the relevant object or source region. ## Entails A diagnostic establishes that some part of the interpretation is incomplete, uncertain, unsupported, or inconsistent. ## Does Not Entail A diagnostic does not necessarily invalidate the entire transcript interpretation. Partial success is permitted. --- # 3.12 Validation ## Purpose Validation ensures that the structured output satisfies the semantic contract of the system. ## Operational Principle Validation checks structural, referential, semantic, ontological, and provenance constraints. Validation may accept representations containing explicit ambiguity or diagnostics when those are valid outcomes. ## Model Interpretation Validation may check: ```text every mention has source evidence every construct has a valid construction type every construction element fills an allowed role every referent is source-licensed every frame role is valid every grounding target exists in the external ontology every semantic assertion has provenance no ontology-only existential creates a transcript referent explicit ambiguity has not been silently collapsed ``` ## Concrete Example Invalid: ```prolog measurement_of(q1, f99). ``` if `f99` is not a valid discourse referent. Valid: ```prolog ambiguous_attachment( q1, [candidate(f1), candidate(f2)] ). ``` if both candidates are well-formed and source-supported. ## Formal Properties / Invariants Let `Valid(R)` mean that representation `R` satisfies all applicable system invariants. The final output must satisfy: ```text Output(R) → Valid(R) ``` Validation is semantic, not merely syntactic. ## Entails A validated output conforms to the system's explicit model and invariants. ## Does Not Entail Validation does not mean that: - every ambiguity has been resolved; - every source phrase has a perfect interpretation; - the representation constitutes a clinical diagnosis; - the external ontology is itself infallible. --- # 3.13 Cross-Cutting Invariants The following invariants apply throughout the system. ## I1. Source Preservation Every derived object is traceable to source evidence. ## I2. No Instance Invention No discourse or application-level individual is introduced solely because external ontology knowledge implies that some individual exists abstractly. ## I3. Abstract Knowledge / Transcript Separation General ontology and linguistic knowledge remain semantically distinct from concrete transcript interpretation. ## I4. Mention / Referent Separation A linguistic mention is not identical to the discourse referent it denotes. ## I5. Construct Accountability Every recognized construct must be justified by a known construction definition or rule. ## I6. Role Integrity Every construction or frame role is filled by a valid object of the appropriate kind or is explicitly unresolved. ## I7. Ambiguity Preservation Supported alternatives remain explicit until additional permitted evidence resolves them. ## I8. Compositional Provenance Composed semantic structures preserve the provenance of their constituent structures. ## I9. No Silent Semantic Rewrite Later representations may refine or enrich earlier ones but may not silently contradict source-backed established facts. ## I10. Explicit Diagnostics Unsupported or unresolved interpretation is represented explicitly rather than silently discarded. ## I11. Validated Output The final structured representation satisfies all applicable structural, referential, ontology, ambiguity, and provenance constraints. --- # 3.14 Acceptance Criteria This specification is ready to support implementation when: - every core concept has a stable purpose and operational principle; - global invariants are mutually consistent; - the project boundary is clear; - the distinction between source, mention, referent, construct, frame, and ontology concept is unambiguous; - ambiguity and diagnostics are accepted as legitimate outputs; - the external authorities used by each concept are identified; - representative transcript examples can be described entirely using the conceptual vocabulary; - no core semantic requirement depends on a specific implementation technology; - the final structured output can be validated against the invariants in this document. --- # 4. Reference Appendices # Appendix A. Universal Dependencies ## Role in the System Universal Dependencies supplies a standardized morphosyntactic representation. The system may use UD for: - tokenization; - lemmas; - universal part-of-speech tags; - morphology; - dependency relations; - language-specific dependency subtypes; - enhanced dependency information where useful. UD is treated as linguistic evidence. It is not the semantic model of the application. ## Conceptual Boundary ```text UD ───────────────────────────────────── What grammatical relationships are present? THIS SYSTEM ───────────────────────────────────── What larger constructions, discourse structures, frames, and domain meanings are established? ``` ## Important Property A later semantic interpretation should not silently rewrite the imported linguistic analysis. If the implementation permits alternative UD analyses, those alternatives should be represented explicitly. --- # Appendix B. Construction Grammar ## Role in the System Construction Grammar supplies the conceptual basis for recognizing conventional form–meaning pairings as first-class objects. The system does not claim to implement a complete theoretical Construction Grammar formalism. The relevant principle is: > A recurrent linguistic configuration may contribute meaning that is not reducible to individual lexical items or dependency edges. This motivates the concepts `Construct` and `Construction Element`. --- # Appendix C. UCxn ## Role in the System UCxn supplies a practical model for annotating construction instances on top of Universal Dependencies. Relevant ideas include: ```text Cxn construction instance annotation CxnElt construction element annotation ``` UCxn also establishes that: - constructions may overlap; - construction elements may correspond to nodes, spans, full subtrees, or partial subtrees; - construction recognition can be expressed over UD graphs. The system should reuse UCxn-compatible conventions where practical. --- # Appendix D. MoCCA ## Role in the System MoCCA supplies a comparative-concept network for aligning language-specific constructions with cross-linguistic analytical concepts. The most important distinction is: ```text L-CONSTRUCTION ───────────────────────────────────── A language-specific construction. COMPARATIVE CONCEPT ───────────────────────────────────── A language-neutral analytical category. ``` MoCCA also distinguishes construction concepts, strategies, semantic content, information packaging, and FrameNet frames. The system should use MoCCA as the default reference model for classifying construction types where suitable. A radiology-specific construction remains local when no appropriate comparative concept exists. --- # Appendix E. Frame Semantics and FrameNet ## Role in the System Frame Semantics provides a model for representing semantic situations through named participant roles. FrameNet supplies an existing inventory of semantic frames. The system may reuse suitable FrameNet frames rather than inventing private equivalents. The frame model does not replace RadLex. FrameNet describes general semantic situations. RadLex describes radiological and medical domain concepts. --- # Appendix F. RadLex ## Role in the System RadLex supplies the principal domain ontology for medical and radiological grounding. Relevant knowledge includes: - classes; - labels; - synonyms; - subclass relationships; - object properties; - class restrictions; - relation specializations; - ontology metadata required by the application. ## Critical Boundary RadLex is abstract domain knowledge. The transcript interpretation is a concrete discourse model. For example: ```text RADLEX ───────────────────────────────────── right_kidney ⊆ ∃ contained_in.right_retroperitoneal_compartment TRANSCRIPT MODEL ───────────────────────────────────── mention("right kidney") referent(k1) grounded_as(k1, right_kidney) ``` If no compartment is established by the source or by an explicitly permitted application derivation, no compartment referent is introduced. Ontology existential meaning remains ontology-level knowledge. --- # Appendix G. Compiler Concepts The system intentionally borrows several concepts from compiler design. ## Source The immutable input to interpretation. ## Intermediate Representation A structured language used between transformation stages. ## Pass A transformation from one representation into a richer or more normalized representation. ## Semantic Analysis The stage in which syntactic or constructional structures are related to discourse identity, semantic roles, and domain meaning. ## Validation / Static Semantics Rules that determine whether a structured representation is semantically well formed. ## Diagnostic A structured account of unsupported, ambiguous, or invalid input or interpretation. ## Provenance The derivation path explaining how later representation elements arose. The compiler analogy is conceptual. Natural language is not treated as if it were a conventional deterministic programming language. --- # Appendix H. External Knowledge and Versioning A concrete implementation should record the versions of external resources that materially influence interpretation. Candidate metadata includes: ```text UD specification version UD parser/model version UCxn schema/rule version MoCCA comparative-concept database version FrameNet version RadLex version local constructicon version system semantic-rule version ``` Versioning supports reproducibility and provenance. --- # Appendix I. Representative Examples ## I.1 Happy Path Measurement Source: ```text A pulmonary nodule in the right upper lobe measures 6 mm. ``` Conceptual interpretation: ```text SOURCE ───────────────────────────────────── original sentence and spans MENTIONS ───────────────────────────────────── pulmonary nodule right upper lobe 6 mm CONSTRUCTS ───────────────────────────────────── Measurement-Predicate Location REFERENTS ───────────────────────────────────── f1 = finding discourse referent a1 = anatomical discourse referent FRAMES ───────────────────────────────────── Measurement(Entity=f1, Value=6, Unit=mm) Location(Figure=f1, Ground=a1) GROUNDING ───────────────────────────────────── f1 → pulmonary nodule a1 → right upper lobe OUTPUT RELATIONS ───────────────────────────────────── measurement_of(q1, f1) located_in(f1, a1) ``` No token-distance heuristic is required. ## I.2 Cross-Sentence Reference Source: ```text There is a nodule in the right upper lobe. It measures 6 mm. ``` Conceptual interpretation: ```text MENTIONS ───────────────────────────────────── m1 = "a nodule" m2 = "right upper lobe" m3 = "It" m4 = "6 mm" REFERENTS ───────────────────────────────────── m1 → f1 m3 → f1 m2 → a1 FRAMES ───────────────────────────────────── Location(Figure=f1, Ground=a1) Measurement(Entity=f1, Value=6, Unit=mm) ``` The pronoun is a mention. It is not a second finding referent. ## I.3 Negated Coordination Source: ```text No pleural effusion or pneumothorax. ``` Conceptual interpretation: ```text CONSTRUCTS ───────────────────────────────────── Negation Coordination Medical nominal mentions SEMANTIC STRUCTURE ───────────────────────────────────── negative scope applies to: - pleural effusion - pneumothorax ``` The system may represent absence assertions. It should not create positive finding individuals merely because the concepts were mentioned. ## I.4 Ambiguous Attachment Source: ```text There is a nodule near the fissure measuring 6 mm. ``` Conceptual interpretation: ```text KNOWN ───────────────────────────────────── nodule mention fissure mention measurement mention proximity/location construct measurement construct UNRESOLVED ───────────────────────────────────── measurement target: - nodule - fissure ``` Unless permitted structural or domain evidence resolves the ambiguity, both candidates remain represented. ## I.5 Telegraphic Radiology Source: ```text Stable 6 mm RUL nodule. ``` Conceptual interpretation: ```text CONSTRUCT ───────────────────────────────────── Telegraphic-Finding-Assertion ELEMENTS ───────────────────────────────────── Status → stable Measurement → 6 mm Location → RUL Finding → nodule ``` The construction is a property of the radiology reporting sublanguage. It may be aligned to more general constructional concepts, but its report-specific character remains explicit. --- # Appendix J. Open Design Questions The following questions remain intentionally open. ╔════════════════════════════════════════════════════════╗ ║ ⚠ OPEN DECISION ║ ║ ║ ║ Define the exact boundary between Mention grounding ║ ║ and Referent grounding. ║ ╚════════════════════════════════════════════════════════╝ Known possibilities include: ```text mention → ontology concept referent → ontology concept both, with distinct semantics ``` The decision affects provenance and ambiguity representation. --- ╔════════════════════════════════════════════════════════╗ ║ ⚠ OPEN DECISION ║ ║ ║ ║ Define the exact frame vocabulary used internally. ║ ╚════════════════════════════════════════════════════════╝ Possible approaches include: ```text reuse FrameNet where possible define application-specific frames use a hybrid ``` The decision should be driven by empirical radiology cases. --- ╔════════════════════════════════════════════════════════╗ ║ ⚠ OPEN DECISION ║ ║ ║ ║ Define which semantic projections are canonical ║ ║ output relations and which remain frame structures. ║ ╚════════════════════════════════════════════════════════╝ For example: ```text LOCATION frame ``` may or may not always project to: ```prolog located_in(Figure, Ground). ``` The decision should preserve distinctions among linguistic meaning, frame semantics, and domain ontology relations. --- # Appendix K. Design Conversation Provenance This appendix is non-normative. It records selected conceptual pivots that materially shaped the specification. ## K.1 Structured Interpretation Rather Than Clinical Inference **Design issue** Scope of the application. **Context summary** The system was initially being discussed alongside ontology enrichment and report interpretation, creating a risk that ontology knowledge could be mistaken for case-level clinical inference. **Design contribution** Human-led direction. The project scope was explicitly restricted to understanding what the doctor said. Ontology knowledge may enrich meaning, but the system should not infer unstated facts about the patient. **Resulting specification rule** No ontology fact alone introduces a discourse or application-level individual. **Why the interaction was useful** The correction changed the system boundary rather than merely changing implementation details. ## K.2 Grammar Rather Than Token Distance **Design issue** Attachment of measurements and other modifiers. **Original input** > “The grammatical attachment is what I was expecting.” **Design contribution** Human-led correction. Bounded token windows were rejected in favor of following grammatical relationships. **Resulting specification rule** Composition requires structural or semantic evidence. Source proximity alone is insufficient. **Why the interaction was useful** A local measurement example became a global architectural principle. ## K.3 Universal Dependencies as Linguistic Authority **Design issue** Whether the application should implement English syntax directly. **Context summary** APE demonstrated how a Prolog grammar could produce rich linguistic and discourse structure, but building a full English parser would create substantial unnecessary work. **Design contribution** Joint refinement. Universal Dependencies was adopted as the standardized morphosyntactic representation, allowing later system logic to operate above raw syntax. **Resulting specification rule** Linguistic analysis is an external evidence layer. Later semantic stages interpret rather than reinvent it. ## K.4 Construction Recognition Above UD **Design issue** How to obtain larger meaningful grammatical structures. **Context summary** Individual dependency relations were useful but too local to express recurring semantic patterns such as measurement, result, location, and comparison. **Design contribution** Human-led direction refined through Construction Grammar research. Larger form–meaning pairings should be recognized compositionally over the linguistic representation. **Resulting specification rule** Constructs are first-class runtime objects with typed construction elements. ## K.5 UCxn Instead of a Private Construction Annotation System **Design issue** How construction instances should be represented. **Context summary** A custom Prolog representation was initially considered. **Design contribution** Research-led refinement. UCxn was identified as existing prior art specifically for construction annotation atop Universal Dependencies. **Resulting specification rule** The conceptual model distinguishes Construction Types, Constructs, and Construction Elements in a way compatible with UCxn. ## K.6 MoCCA and the Separation of Universal Meaning from Language Strategy **Design issue** Avoiding accidental English-specific semantics. **Context summary** An English dependency pattern such as `X measures Y` could easily be mistaken for the universal definition of a measurement construction. **Design contribution** Human-led concern followed by research into MoCCA. The design now distinguishes language-specific constructions from comparative construction concepts and realization strategies. **Resulting specification rule** Language-specific realization and language-neutral semantic classification remain distinct. ## K.7 Ambiguity as a Structured Output **Design issue** What the deterministic system should do when multiple interpretations remain plausible. **Original input** > “Ambiguous structures [are] 100% of the point.” **Design contribution** Human-led direction. Correctness was prioritized over forced coverage. **Resulting specification rule** Explicit ambiguity is a valid structured result and may not be silently collapsed. **Why the interaction was useful** The design objective shifted from maximizing deterministic interpretation to safely reducing ambiguity. ## K.8 The Project Ends at Structured Output **Design issue** Whether downstream language-model completion or report generation belonged inside the interpreter. **Design contribution** Human-led scope correction. Those activities were removed from the project boundary. **Resulting specification rule** The system ends at validated structured semantic output. Downstream consumers are separate systems. --- # Appendix L. One-Sentence Summary > **The radiology transcript interpreter progressively transforms source language into a validated semantic representation by identifying mentions, recognizing constructs, forming discourse referents and frames, grounding those objects in established domain concepts, composing compatible interpretations, preserving ambiguity and diagnostics explicitly, and retaining provenance for every derived result.**