Highlights The Large Cancer Assistant (LCA): A Model-Agnostic Orchestration Framework for Scalable Clinical Decision Support in Oncology Ghassen MARRAKCHI, Basarab MATEI • LCA orchestrates multimodal oncology data without model coupling. • Algorithmic impermeability strictly isolates AI from data routing. • Entry Theory algebraically standardizes diverse clinical formats. • A Standardized Intermediate Payload (SIP) ensures EMR isolation.
arXiv:2607.06531v1 [cs.AI] 7 Jul 2026
• Proof of concept proves 100% failure safety and zero AI overhead.
The Large Cancer Assistant (LCA): A Model-Agnostic Orchestration Framework for Scalable Clinical Decision Support in Oncology Ghassen MARRAKCHIa,∗ , Basarab MATEIa a LIPN, CNRS, UMR 7030 — Université Sorbonne Paris Nord, 99 Av. Jean Baptiste Clément, Villetaneuse, F-93430, France
ARTICLE INFO
ABSTRACT
Keywords: clinical decision support multimodal orchestration algorithmic impermeability oncology informatics interoperability model-agnostic architecture
Objective: Multimodal deep learning models in oncology are currently limited by monolithic designs that rigidly couple data ingestion, clinical routing, and artificial intelligence (AI) inference. To address this inflexibility, we propose the Large Cancer Assistant (LCA), a model-agnostic, post-hoc orchestration framework designed for scalable clinical decision support. Methods: The LCA is mathematically formalized as a 7-tuple architecture grounded in the principle of Algorithmic Impermeability, ensuring the orchestration logic remains strictly independent of underlying black-box AI models. We introduce the Entry Theory, leveraging Geometric Deep Learning (GDL) to standardize multimodal patient data along distinct structural and medical axes. The system dynamically orchestrates data via a Cancer Switching Module and intentionally isolates the core AI execution from volatile hospital IT infrastructures by outputting a Standardized Intermediate Payload (SIP). Results: A Proof of Concept (PoC) validated the orchestration logic across four technical scenarios. The framework executed a nominal flow with negligible orchestration overhead. It empirically demonstrated algorithmic impermeability by maintaining an invariant routing projection during AI model swaps, and it validated strict failure-safety by achieving a 100% recall rate in generating targeted Supplementary Data Requests (SDR) under injected data anomalies. Multi-protocol execution capability was also successfully verified. Conclusion: By structurally decoupling multimodal ingestion from feature inference, the LCA provides a highly adaptable and modular orchestration foundation. The SIP establishes a clear architectural boundary, natively setting the stage for downstream Electronic Medical Record (EMR) interoperability as an independent future paradigm.
1. Introduction The landscape of clinical oncology is inherently multimodal. A comprehensive patient diagnosis rarely relies on a single data source; rather, it requires the continuous synthesis of high-dimensional spatial imaging (e.g., computed tomography, magnetic resonance imaging), unstructured semantic histories (e.g., clinical notes, pathology reports), and tabular biological metrics (e.g., blood panels). Consequently, the integration of Artificial Intelligence (AI) into oncology has largely focused on developing multimodal deep learning models capable of processing these diverse data streams to improve diagnostic and prognostic accuracy. However, the clinical translation of these advanced models is currently constrained by systemic architectural flaws. Many existing multimodal systems remain tightly coupled to specific modality combinations and task definitions, limiting their flexibility across heterogeneous clinical workflows. They tightly couple the ingestion of data, the routing logic, and the core neural network inference into a single, rigid, monolithic pipeline. This monolithic design prevents dynamic adaptability: a model trained specifically ∗ Corresponding author
[email protected] (G. MARRAKCHI); [email protected] (B. MATEI) https://marrakchighassen.github.io/ (G. MARRAKCHI); https://lipn.univ-paris13.fr/~matei/ (B. MATEI) ORCID (s): 0009-0006-2538-783X (G. MARRAKCHI); 0000-0001-7946-530X (B. MATEI)
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
for lung nodule segmentation cannot easily re-route an abdominal profile, nor can it dynamically adjust to missing data modalities without catastrophic failure. Furthermore, previous paradigms often conceptualized these systems for synchronous or concurrent execution. However, clinical realities demand a post-hoc, offline orchestration approach capable of asynchronously synthesizing highly fragmented patient histories without forcing artificial real-time constraints. Within the domain of biomedical informatics, the focus must fundamentally shift from the internal mechanics of individual predictive models to the overarching systems engineering that governs their clinical deployment. This paper explicitly addresses this gap by framing the challenge not as a computer vision or signal processing problem, but as an advanced informatics orchestration problem. By explicitly treating the underlying diagnostic AI networks as impermeable "black boxes," we isolate the computational inference from the clinical data flow. This perspective is vital for modern Clinical Decision Support Systems (CDSS), where the primary technical bottleneck is managing data heterogeneity and modular routing, rather than simply optimizing isolated algorithmic performance. To address these structural limitations, this work presents a framework specification for the Large Cancer Assistant (LCA). Rather than proposing a singular diagnostic neural network, the LCA is conceptualized as an advanced systemsengineering orchestration architecture. It is designed to autonomously ingest, route, and synchronize multi-format
Page 1 of 21
patient data across specialized pathological pipelines without rigid coupling to the underlying computational models. A foundational pillar of the LCA is the principle of Algorithmic Impermeability. By establishing strict structural boundaries between data preprocessing, clinical routing, and AI inference, the framework ensures that its orchestration logic remains entirely independent of specific, transient machine-learning models. To formally establish these architectural boundaries, the main contributions of this work are defined as follows: • The LCA Framework and Algorithmic Impermeability: We formally define the LCA as a 7-tuple orchestration architecture that rigorously enforces Algorithmic Impermeability, mathematically guaranteeing that system-level orchestration projections remain invariant under AI model substitutions. • Input Data Formalization (Entry Theory): We introduce a novel Entry Theory leveraging Geometric Deep Learning (GDL) to systematically standardize multimodal clinical inputs across distinct structural and medical axes, ensuring the mathematical independence of data topology from clinical provenance. • Dual-Variant Pathology Routing: We define a modular Cancer Switching Module capable of dynamic pipeline activation via either explicit deterministic parameterization (V1) or an autonomous, calibrated multi-protocol learned router (V2). • The Standardized Intermediate Payload (SIP): We establish a deliberate architectural boundary by culminating the system’s output in a decoupled, proprietary JSON payload (SIP) accompanied by a structured Supplementary Data Request (SDR) feedback loop. This explicitly isolates the core AI framework from downstream Electronic Medical Record (EMR) interoperability dependencies. The remainder of this paper is organized as follows: Section 2 reviews the related literature regarding multimodal oncology and clinical decision support. Section 3 details the methodological foundations, including the formal Entry Theory, the LCA framework, its internal modules, and the SIP specification boundary. Section 4 presents the empirical Proof of Concept (PoC) results, demonstrating the framework’s nominal flow, algorithmic impermeability, and failure safety. Section 5 outlines the principal findings, framework limitations, and ethical considerations as a CDSS. Finally, Section 6 concludes the paper with a defined roadmap for future interoperability translation.
2. Related Work This section surveys prior work relevant to the Large Cancer Assistant (LCA) framework across two primary axes: multimodal deep learning in oncology and orchestrationstyle clinical decision support systems (CDSS). Together, G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
these strands demonstrate that while powerful AI models exist in isolation, the combination of strict algorithmic impermeability and modular, multi-pathology switching remains underexplored.
2.1. Multimodal Deep Learning in Oncology A substantial literature has emerged focusing on the joint modeling of clinical modalities to improve diagnostic and prognostic accuracy. Early frameworks established the value of combining multi-omics inputs (mRNA, miRNA, DNA methylation) using deep learning and graph-based feature selection to outperform single-modality baselines Lin, Deng, Wei, Zheng, Chen, Chai, Zeng and Tang (2024). Broader multi-omics models leverage deep neural networks to fuse genomics and epigenetics with clinical covariates for survival analysis and risk stratification Zhang, Wan, Luo, Zhao, Samayoa, Zhao and Wu (2025). Recent advancements have extended this integration to include spatial imaging and unstructured clinical variables. For example, systems have been developed to integrate pre-treatment histopathology images, molecular biomarkers, and clinical data using CNN-based image encoders alongside dense layers for tabular features, demonstrating the necessity of explicit cross-modal representation learning Wang, Lin, Li, Zeng, Chen, Ouyang, Li, Jia, Lai, Yu, Yao and Su (2024). Similarly, multimodal state-space models combine endoscopic images, radiomic features, and clinical variables within unified probabilistic frameworks to capture temporal disease trajectories Wang, Lin, Li, Lyu, Jiang, Ni, Huang, Chen, Yan and Huang (2025). At the scale of foundation models, large-scale multimodal transformers have been trained on millions of pathology images and freetext clinical reports to predict prognosis and immunotherapy response across multiple tumor types Xiang, Wang, Zhang, Xi, Eweje, Chen, Li, Bergstrom, Gopaulchan, Kim, Yu, Willens, Olguin, Nirschl, Neal, Diehn, Yang and Li (2025). However, a persistent limitation across these architectures is their monolithic design Waqas, Tripathi, Ramachandran, Stewart and Rasool (2024). These systems typically operate as rigidly coupled prediction models, tightly bound to their training cohorts and specific data modality combinations Yang, Yang, Chen, Yao, Zou and Jia (2025). Because their data orchestration is permanently fused to their underlying feature extractors, they prevent modular updates or adaptable clinical routing. Consequently, the field currently lacks a mechanism to structurally decouple multimodal data ingestion from deep learning inference—a critical void that the LCA resolves through its foundational principle of Algorithmic Impermeability.
2.2. Multimodal Clinical Decision Support Systems Parallel to model-centric advancements, several systems target end-to-end decision support, embedding AI directly into clinical workflows. Task-focused CDSS architectures frequently fuse radiological imaging, dosimetric parameters, and clinical covariates to support personalized radiotherapy Niecikowski, Gupta, Suarez, Kim, Chen, Page 2 of 21
Patient data
Patient data
Large Cancer Assistant (LCA)
Diagnosis
Diagnosis
Medical Assistance
Medical Assistance
Supplementary Data Request Figure 1: Macroscopic ecosystem of the LCA framework, showing the central black box "LCA" with an incoming "Multimodal patient data" stream and three distinct outputs: Diagnosis, Medical Assistance, and a Supplementary Data Request feedback loop.
Guo, Long and Deng (2022) or predict post-operative recurrence Wang et al. (2025). Beyond these task-specific tools, several CDSS architectures have been implemented as workflow-engine–driven systems that encode clinical guidelines via integrated workflow and rule engines, yet they remain tightly bound to local institutional pathways and lack a cancer-agnostic orchestration layer Lee, Kim, Cho and Kim (2010); Huser, Rasmussen, Oberg and Starren (2011). While these systems demonstrate the clinical necessity of AI empowerment, their logic remains closely tied to specific institutional contexts or isolated anatomical targets (e.g., exclusively addressing non-small-cell lung cancer or colorectal tumors). Because they lack a universal, canceragnostic ingestion framework, translating these siloed CDSS tools to generalized hospital environments is fundamentally restricted. They require an overarching, model-agnostic orchestration layer—which the LCA introduces via its dynamic Cancer Switching Module— to autonomously align highly diverse patient profiles with the appropriate specialized clinical protocols.
2.3. Positioning of the Large Cancer Assistant (LCA) The proposed LCA framework deliberately departs from existing multimodal oncology paradigms along three strategic dimensions: • Algorithmic Impermeability vs. Monolithic Fusion: Unlike existing multimodal transformers or deep-fusion networks that directly consume diverse inputs to generate a unified probability score Lin et al. (2024); Xiang et al. (2025), the LCA enforces strict modular boundaries. It separates multimodal data preprocessing from the core diagnostic inference, ensuring the orchestration logic remains fully independent of the underlying neural networks. • Dynamic Switching vs. Task-Specific CDSS: Rather than operating as a siloed tool for a single cancer type Niecikowski et al. (2022), the LCA utilizes a distinct Cancer Switching Module. This allows the G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
framework to act as a universal orchestrator, dynamically detecting the anatomical target and activating the appropriate, specialized downstream pathological pipeline. • Standardized Output Boundary vs. Direct EMR Integration: Unlike systems that directly commit results to hospital databases, the LCA produces a Standardized Intermediate Payload (SIP) as its sole external output. This boundary strictly decouples the AI orchestration core from volatile EMR infrastructure: changes to HL7 FHIR versions, database schemas, or institutional IT systems require no modification of any upstream LCA module. Downstream FHIR translation is scoped as an independent subsequent work. This design is consistent with interoperability-driven CDSS architectures that leverage standards such as HL7 FHIR, while deliberately keeping the orchestration layer model-agnostic and EMR-decoupled Carbonaro, Giorgetti, Ridolfi, Pasolini, Pagliarani, Cavallucci, Andalò, Del Gaudio, De Angelis, Vespignani et al. (2025); Jung, Bae, Seong, Oh, Kim and Yi (2022).
3. Overview & Design Principle A critical limitation of existing automated diagnostic tools is their inability to process the full spectrum of patient data, often isolating radiological imaging from the broader clinical context. To address this, the Large Cancer Assistant (LCA) orchestration framework is explicitly designed to encapsulate the entire decision assistance schema in a posthoc (offline) manner. It ingests and aggregates a multimodal triad of patient data: high-dimensional spatial imaging (e.g., CT, MRI), unstructured textual data (e.g., clinical notes), tabular biological metrics (e.g., blood biomarkers), etc., after acquisition is complete. The LCA does not operate concurrently with an ongoing examination (e.g., it does not process a live ultrasound stream during the exam); no realtime processing is intended.
Page 3 of 21
Parameters Large Cancer Assistant (LCA)
V2: Auto-Detecting Baseline Real Data V1: Parameterized Additions
Patient data
Supplementary Data Request Meta Data
Preprocessed Data Data Preprocessing Module (DPM)
Preprocessed Data
Detected Cancer
Cancer Switching Module (CSM)
Large Cancer Diagnostic Module (LCDM)
Diagnosis Data (Decision/Structured)
Detected Cancer
Diagnosis Data (Decision/Structured) Large Cancer Remedy Module (LCRM)
Detected Cancer
Medical Assistance Remedy Data
Large Cancer Wordings Module (LCWM)
Diagnosis
Figure 2: Internal orchestration graph (unidirectional DAG) showing the pipeline sequence: DPM → CSM → {LCDM, LCRM} → LCWM → SIP. The CSM includes V1 (parameterized) / V2 (auto-detection) annotations. An SDR branch originates from the LCWM. The shared routing context 𝑃̂ is propagated throughout the modules.
A foundational design principle of the LCA is Algorithmic Impermeability. The framework imposes strict modular boundaries between its clinical routing logic and the underlying neural networks. By decoupling data orchestration from feature inference, the LCA ensures that its internal logic remains invariant under machine-learning model swaps, provided the interface contracts are satisfied. This impermeability ensures that the system is highly scalable, capable of integrating future interoperability standards natively, and strictly independent of specific, transient machine-learning models. The internal orchestration is structured as a unidirectional pipeline governed by a directed acyclic graph (DAG), propagating a shared routing context denoted as 𝑃̂ through the successive modules (See Figure 2).
3.1. Input Data Formalization (Entry Theory) To orchestrate heterogeneous clinical data comprehensively, the LCA framework employs a formal Entry Theory (depicted in Figure 3) that decouples the structural properties of an input from its clinical semantics.
3.1.1. CS Axis (Structural) Following the principles of Geometric Deep Learning, input data is formalized structurally. A Domain (Definition 1) is defined as a pair (Ω, 𝔊), where Ω is a set of positions and 𝔊 is a symmetry group acting on Ω. An Entry (Definition 2) is a geometric signal 𝑥 ∈ Ω defined on this domain, with being the feature space. This definition elegantly unifies spatial modalities (e.g., CT volumes, Whole-Slide Images) and non-spatial ones (e.g., textual clinical notes, tabular biological metrics) under a common mathematical representation 3.1.2. Medical Axis Independently of its structure, each entry is augmented with a clinical context, defined by three categorical attributes: • Provenance (𝜌): The acquisition process (e.g., imaging/CT, pathology/WSI). • Usage (𝑢): The functional role in the decision process (e.g., observation, diagnosis). • Epistemic Certainty (𝜅): The evidential grounding of the information (e.g., confirmed, suspected, inferred). G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
Together, these form the Medical Signature 𝜎 = (𝜌, 𝑢, 𝜅) (Definitions 5-8), capturing the clinical essence of the data.
3.1.3. Characterized Entry & Independence A Characterized Entry 𝑥̃ = (𝑥, Ω, 𝔊, , 𝜎) (Definition 9) merges these two axes. Crucially, the CS structural axis and the medical axis are mutually independent (Proposition 1). The geometric structure of an entry does not dictate its medical signature, and vice versa. For instance, two structurally identical CT volumes can have different certainty levels depending on their conclusiveness, while two entries with identical signatures (e.g., biological observations) might have entirely different tabular geometries. Finally, an LCA Input (Definitions 3-4) is formalized as a clinical history: a finite, ordered sequence of characterized entries (𝑥̃ 𝑗 )𝑇𝑗=1 associated with a patient identifier, fully supporting multi-modal heterogeneity and arbitrarily short histories (𝑇 ≥ 1); the degenerate case 𝑇 = 1 – a single new-patient visit or single-modality input – requires no separate treatment.(see Appendix A for detailed entry theory explanation).
3.2. The LCA Framework Formally, the Large Cancer Assistant (LCA) framework is structured as a 7-tuple. This architecture comprises the input space (), a shared protocol catalog = {𝑝1 , … , 𝑝𝐾 } (a finite, non-empty set of 𝑘 clinical protocols ; Definition 13), and a unidirectional orchestration pipeline consisting of five specific modules: the Data Preprocessing Module (𝑓𝐷𝑃 ), the Cancer Switching Module (𝑓𝐶𝑆 ), the Large Cancer Diagnostic Module (𝑓𝐿𝐶𝐷 ), the Large Cancer Remedy Module (𝑓𝐿𝐶𝑅 ), and the Large Cancer Wordings Module (𝑓𝐿𝐶𝑊 ) ; where the global LCA function is depicted as : LCA =
( ) , , 𝑓𝐷𝑃 , 𝑓𝐶𝑆 , 𝑓𝐿𝐶𝐷 , 𝑓𝐿𝐶𝑅 , 𝑓𝐿𝐶𝑊 (1)
3.2.1. System-Level Algorithmic Impermeability The core guarantee of this mathematical formulation is defined by Proposition 2 (System Impermeability). It states that if two different machine-learning models satisfy the same diagnostic or therapeutic interface contract, swapping them will leave the orchestration-structural projection of the system entirely invariant. Specifically, the module activation sequence, the routing decisions, the failure handling mechanisms, and the final structural schema of the Standardized Intermediate Payload (SIP) remain identical. The clinical Page 4 of 21
Inset — Proposition 1: Independence of Axes Identical σ · differing CS structure
Identical CS structure · differing σ
σ = (bio/panel, {obs}, confirmed) · Ω = {1,...,d}
(Ω_CT, 𝔊_CT, ℝ) · κ = confirmed
same σ — distinct CS
same CS — distinct σ
σ = (bio/panel, {obs}, confirmed) · Ω = {1,...,d'}
(Ω_CT, 𝔊_CT, ℝ) · κ = suspected
CS Axis structural component
(Ω, 𝔊, 𝒞)
𝔊 · symmetry group
Ω · position set
𝒞 · feature space
⊥ mutually independent
Medical Axis
(Prop. 1)
x̃ = (x, Ω, 𝔊, 𝒞, σ) —
Characterized Entry
clinical component
σ = (ρ, u, κ)
ρ · provenance
u · usage κ · epistemic certainty
Figure 3: Structure of the characterized entry and orthogonality of axes, decomposing an entry into the CS axis (Ω, 𝔊, ) and the medical axis 𝜎 = (𝜌, 𝑢, 𝜅). The inset illustrates Proposition 1 (identical CS structure with differing signatures, and identical signatures with differing CS structures).
inference content will naturally differ between the two models, but the orchestration layer remains impermeable to this change. As a direct corollary (Corollary 1), downstream modules like the Data Preprocessing Module (DPM), Cancer Switching Module (CSM), and Large Cancer Wordings Module (LCWM) require no updates when underlying AI models are retrained or replaced.
3.2.2. Key Framework Properties This formalization guarantees four essential properties across the entire framework: (Q1) Defined on : The framework processes all valid inputs, including partial clinical histories, without silent failures. More details in Appendix B. (Q2) Protocol generality. The framework is not specialized to any cancer type 𝑐 ∗ . The protocol catalog is a parameter; adding or removing a protocol 𝑝𝑘 requires updating the catalog and the corresponding module instances, not the orchestration. (Q3) Unidirectionality. The pipeline graph is a DAG with a single source (𝑒) and a single sink (SIP). There are no feedback loops and no bidirectional dependencies between modules. (Q4) Failure safety. Every module that fails to process its input emits ⊥ rather than a spurious output. The LCWM translates each ⊥ into a Supplementary Data Request. No failure is silent.
3.2.3. Data Preprocessing Module (DPM) The Data Preprocessing Module (𝑓𝐷𝑃 ) maps raw heterogeneous clinical inputs to canonical, standardized representations. Structural preprocessing is parameterized exclusively by the provenance 𝜌 of each entry, which selects the appropriate canonical form; the clinical attributes 𝑢 and 𝜅 are not accessed and pass through unmodified. The full medical signature 𝜎 = (𝜌, 𝑢, 𝜅) is never modified by the DPM. Formally, 𝑓𝐷𝑃 is the sequential composition of five stages G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
𝑓0 , … , 𝑓4 : history sequencing, signature extraction and preprocessing routing, structural preprocessing via provenancespecific operators 𝜙𝜌 , axis reconstruction, and history recomposition. The associated properties—symmetry group preservation (P1.1), medical transparency (P1.2), metadata invariance (P1.3), and identity as degenerate case (P1.4)— and the complete formal definitions are detailed in Appendix C.
3.2.4. Cancer Switching Module (CSM) The Cancer Switching Module (𝑓𝐶𝑆 ) is the central routing engine of the LCA framework. Rather than enforcing a single definitive cancer diagnosis, the CSM receives the preprocessed clinical history from the DPM and outputs an activation set denoted 𝑃̂ . This set identifies the specific cancer protocols (from the a priori catalog ; Definition 13) that warrant downstream investigation. The framework supports two distinct routing variants: • Variant V1 (Deterministic Activation): Activation is governed by an explicit, a priori declaration parameter (𝑃𝜆 ). V1 bypasses the content of the clinical history entirely, routing the data strictly according to prior clinical or systemic instruction. • Variant V2 (Probabilistic Auto-Detection): A learned, multi-protocol routing function that evaluates both the CS structural axis and the medical axis to infer clinical relevance. V2 activates protocols independently based on a calibrated confidence score exceeding a declared threshold 𝜏 ∈ (0, 1). (Note: While fully specified theoretically within the framework, V2 is excluded from the current Proof of Concept). Crucially, if evidence is insufficient in V2, or if the parameter is missing in V1, the CSM emits a null token (⊥), safely terminating the pipeline before inference and triggering a top-level Supplementary Data Request. (See Appendix D for details) Page 5 of 21
3.2.5. Abstract AI Module The Large Cancer Diagnostic Module (LCDM) and the Large Cancer Remedy Module (LCRM) share an identical foundational architecture defined by the Abstract AI Module. This abstraction enforces a strict interface contract (𝜏(𝑘) ) that mandates predefined input types, failure precondition sets, and explicit output space typologies. Output types are categorized globally as either structural (geometric signals defined on an output domain) or decisional (probability distributions over a class catalog). To guarantee algorithmic impermeability at the module level, a crucial distinction is made regarding failure handling: if an input lacks required modalities or fails predefined quality checks, the module emits a null token (⊥) to halt the pipeline securely. Conversely, if the underlying machine learning model fails internally during inference on valid data, the module must output a declared 𝙲𝙾𝙳𝙴_𝙵𝙰𝙸𝙻 rather than ⊥, preserving the integrity of the framework’s failure-safety mechanics. 3.2.6. Large Cancer Diagnostic and Remedy Modules (LCDM & LCRM) The LCDM and LCRM instantiate the abstract interface to perform active cancer diagnostics and treatment generation, respectively. Executing strictly downstream of the CSM, the LCDM consumes the preprocessed clinical history and the activation set, producing novel characterized diagnostic entries. During this operation, the medical axis of the historical data is not discarded; instead, its epistemic certainty is renewed and synthesized into the output’s medical signature. Operating subsequently, the LCRM receives the complete diagnostic outputs alongside the untouched historical data. Both modules ensure per-protocol independence, operating on parallel isolated instances for each activated protocol. In specific clinical configurations where a protocol requires only a remedy phase (e.g., when the diagnosis is already definitively confirmed in the patient’s history), the framework executes a canonical lifting operation. This mechanism bypasses the LCDM and maps the historically confirmed diagnosis directly into the requisite input format for the LCRM, strictly preserving the unidirectional flow of the pipeline (See Appendix E for details). 3.2.7. Large Cancer Wordings Module (LCWM) The Large Cancer Wordings Module (𝑓𝐿𝐶𝑊 ) functions as the terminal node of the unidirectional pipeline and constitutes the exclusive external interface of the LCA framework. Like the DPM and the CSM, 𝑓𝐿𝐶𝑊 is 𝜃-free (Corollary 1): it is not subject to the interface-contract substitution of Definition 25, which applies only to 𝜏 ∈ {LCD, LCR}. This fixed module aggregates the activation set, the structural and decisional outputs from the LCDM and LCRM, and the bypassed preprocessed clinical history. From these inputs, the LCWM produces a unified Standardized Intermediate Payload (SIP). The SIP acts as a strict architectural boundary between the internal orchestration
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
logic and external healthcare IT infrastructure. It is composed of two distinct elements: • Text output: A natural language narrative generated by an internal Natural Language Generation (NLG) model. • Structured bypass: The unmodified structured AI outputs and historical data, passed through identically for downstream clinical archiving and auditing. A critical feature of the LCWM is its enforcement of failure-safety via the Supplementary Data Request (SDR) track. If any upstream module emits a null token (⊥), the LCWM translates this precise failure into a targeted SDR. These requests are either top-level (when the CSM fails to activate any protocol) or protocol-level (when a specific LCDM or LCRM instance encounters a precondition failure). This mechanism guarantees that missing clinical evidence systematically halts the pipeline for the affected protocol and triggers human-in-the-loop intervention, precluding silent failures or uninformative outputs (See Appendix F for details).
3.3. Implementation Boundary: SIP/SDR Specification As the exclusive architectural boundary of the LCA framework, the Standardized Intermediate Payload (SIP) must strictly adhere to specific design principles to ensure interoperability and algorithmic impermeability (see Figure 4). Several key principles explicitly govern its implementation: (D1) (SIP as the sole output type): The LCWM invariably produces a SIP. Regardless of success or failure, the top-level payload structure remains a SIP. If a module failure occurs (⊥), the resulting Supplementary Data Request (SDR) is not a standalone payload type but is structurally embedded within the SIP’s narrative and protocol outputs. (D2) (𝐷𝑜𝑢𝑡 by reference): To prevent unacceptable latency and redundancy, the structured bypass does not embed heavy input content (e.g., full CT volumes or text tokens). Instead, the SIP logs input provenance via entry_refs, mapping each entry to its acquisition index, its medical signature (𝜎), and its external identifier in the upstream healthcare system (e.g., FHIR, PACS). (D8) (Impermeability to serialization): Machine-learning model identities (e.g., specific neural network versions like "monai_unet_v1_lung") are strictly excluded from the SIP. Exposing such identities would create downstream dependencies, violating the algorithmic impermeability guarantee (Proposition 2). These details are reserved exclusively for internal audit logs. (D12) (⊥ vs CODE_FAIL distinction): The SIP structure explicitly distinguishes between orchestration halting and inferential failure. The ⊥ token, which halts the pipeline and triggers an SDR, is reserved solely for Page 6 of 21
} | null
{ protocol_outputs [k]
header
repeated ∀ pk ∈ P̂
"protocol_outputs" : [{
"protocol_id" : string, "support" : [LCD,LCR] | [LCD] | [LCR]
"sip_version" : string , "run_id" : uuid , "timestamp_utc" :
Def. 27
ISO 8601
lcdm_output input_provenance
"input_provenance" : {
"status" : SUCCESS | HALTED | LIFTED D9, D11
D2 — Dout by reference
"characterized_entry" : {
"patient_ref" : string , "T" : int ≥ 1 , "dpm_profile_id" :
"y_LCD" : { output_type, structural?, decisional? }
string Def. 3–4
Def. 24
"entry_refs" : [
"sigma_LCD" : { rho, u, kappa } D3, D6
σ — per entry j
"lifting_note" ?: string
"j" : int , "external_id" : string Def. 3
} | null
"sigma" : { "rho" : Prov Def. 5 , "u" : [ Usg ] Def. 6 , "kappa" : Cert Def. 7
lcrm_output
}
"status" : SUCCESS | HALTED ] }
"characterized_entry" : { y_LCR, sigma_LCR } | null
csm_execution
} | null if support(pk) = {LCD}
"csm_execution" : {
Def. 23
"variant" : V1 | V2 , "status" : ACTIVATED | HALTED
sdr ⚠ only if ⊥ raised for this pk
"activation_set_P_hat" : [protocol_id] | null
"source" : LCDM | LCRM , "request"
← P̂ — effective routing output (Def. 23)
: { description, requested_data } Def. 34, P5.3
V1 only
V2 only
"v1_param_P_lambda"
"v2_per_protocol_scores"
: [protocol_id] ← Pλ, Def. 16
: { id: float }
} | null }]
"v2_threshold_tau" : τ
lcwm_narrative
"lcwm_narrative" : string
Def. 33(i) — terminal output
Def. 22
} }
csm_sdr
"csm_sdr" : {
⚠ only if csm_execution.status = HALTED — Def. 34
"source" : "CSM" , "request" : { "description" : string,
Legend:
SUCCESS / ACTIVATED
HALTED
LIFTED
conditional (| null)
Def. N formal definition reference
"requested_data" : {…} }
Figure 4: Condensed SIP/SDR schema (annotated pseudo-JSON representation) showing the block layout: header; input_provenance (entry_refs + 𝜎); csm_execution (variant, 𝑃̂ , V1/V2 settings); csm_sdr; protocol_outputs[𝑘] containing individual lcdm_output, lcrm_output, or protocol-level sdr; and finally the lcwm_narrative block.
missing or invalid inputs (precondition failures, (𝑘) ). ⊥ Conversely, if an AI model fails internally during inference on a valid input, it outputs a protocol-specific CODE_FAIL class rather than ⊥, ensuring downstream consumers can precisely audit the failure’s true origin without halting the orchestration logic erroneously. The complete set of design principles D1–D12, along with the full annotated JSON schema, are detailed in Appendix G. The comprehensive coverage of the eight canonical orchestration cases, demonstrating the SIP behavior under various module states, is provided in Appendix H.
4. Results & Proof of Concept Setup The proof of concept (PoC) is governed by a single axiom: it evaluates the orchestration behaviour of the framework— routing, failure handling, and output structuring —not the clinical performance of the underlying models. Accordingly, classifier-level metrics such as AUC or the Dice coefficient are deliberately excluded. All scenarios target the deterministic variant V1 on a single lung protocol; the diagnostic module is instantiated with interchangeable G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
open reference bundles and the remedy module with a declared rule-based stub, as summarised in Fig. 5. Full environment, metric definitions, and sample sizes are given in Appendix I.
4.1. Scenario 1: Nominal Flow Over 𝑁 = 10 runs the pipeline completed end-to-end without emitting ⊥ (completion rate 100%). Every payload was schema-valid and carried the expected diagnostic signature 𝜎𝐿𝐶𝐷 = (inference/AI, {diagnosis}, inferred) (Table 2). We do not claim the orchestration cost dominates inference: the reference components used here are lightweight. Rather, the orchestration layer itself (DPM, CSM, LCWM; ≈ 0.04 ms) adds a sub-millisecond cost that is negligible relative to the 102 –103 ms typical of production 3D inference, confirming that orchestration introduces no material overhead in deployment.
4.2. Scenario 2: Algorithmic Impermeability We substituted the diagnostic module’s output stub (Stub A, emitting a 3D U-Net-style output schema) with an architecturally distinct stub (Stub B, emitting a SegResNet-style output schema), both satisfying the same interface contract Page 7 of 21
Table 1 Coverage of Orchestration Situations (T1 Source) Case CSM Variant Support 1 2 3 4 5 6 7 8
LCDM
LCRM
SDR
V1 {LCD, LCR} SUCCESS SUCCESS — V2 multi-proto {LCD, LCR} + {LCD} SUCCESS SUCCESS / null — V2 — not invoked not invoked CSM top-level V1 {LCD, LCR} HALTED null (not invoked) LCDM level V1 {LCD, LCR} SUCCESS HALTED LCRM level V1 {LCR} only LIFTED SUCCESS — V1 multi-proto {LCD, LCR} + {LCD, LCR} SUCCESS / HALTED SUCCESS / null LCDM level (partial) V1 {LCD, LCR} SUCCESS (CODE_FAIL) HALTED LCRM level Reference rule stubs — adapters/{lcd_model,lcr_model}/printing.py no clinical content, fixed distributions
PrintingRemedyModelA toy remedy stub
RemedyModelPort binding
PrintingModelA nominal, confident {A:.9 B:.08 CODE_FAIL:.02}
DiagnosticModelPort binding
PrintingModelB impermeability comparator (S2) {A:.6 B:.35 CODE_FAIL:.05}
DiagnosticModelPort binding (S2 swap)
Active LCA modules — ∀ protocol_id ∈ activation_set P̂ (independent, P12)
SDRRequest yes
LCD ∈ support
Data pipeline
support(protocol_id) LCD ∉ support
Synthetic input generation — poc/config.py
make_history() / make_multi_history() toy CharacterizedEntry(j, ρ, u, κ, payload)
CharacterizedHistory T ≥ 1 entries · σ = (ρ, u, κ)
DPM
φ_ρ preprocessors, param. by ρ only θ-free — no failure path
LCDM.infer(protocol_id, history) diagnostic inference
Canonical lifting ι (D9/Remark 4) LCR-only protocol — total, cannot fail
LCRM.infer(protocol_id, y_lcd, history) remedy inference
LCDM HALTED SDR(source = LCDM, protocol_id) LCRM cascade-skipped → lcrm_output = None
SUCCESS
LCR ∈ support? LIFTED
no
SDRRequest SUCCESS
LCRM HALTED SDR(source = LCRM, protocol_id)
ProtocolOutput (lcdm_output, lcrm_output, sdr)
activation(P̂ ) CSM — route(history, μ) V1: a-priori P_λ · V2: τthreshold scorer
SDRRequest
LCWM.generate(...) assembles narrative + SDR rendering never leaks upstream implementation detail
⊥ HALTED (top-level)
SDR(source = CSM)
SIP (Def. 35/36) poc_outputs/sip_raw/sip_<run_id>.json
Figure 5: PoC architecture diagram showing the data pipeline, active LCA modules, synthetic input generation, and reference rule stubs.
(lung)
𝐿𝐶𝐷 , on 𝑁 = 10 identical inputs. The orchestrationstructural projection was invariant in every pair (𝜋-equality 100%) while the diagnostic content differed in every pair (100%; Table 3). This is a direct empirical instantiation of Proposition 2: the routing projection is impermeable to the model swap even though the inference content is not.
4.3. Scenario 3: Failure Safety We separate two structurally different guarantees (Table 3). Module-level failure safety concerns inputs that reach a module and violate its declared precondition set (𝑘) . ⊥ For both a corrupted CT and a missing required modality (𝑁 = 10 each), the diagnostic module raised ⊥ and the LCWM emitted a protocol-level SDR with the correct source (LCDM) and a non-generic request, yielding 100% SDR recall—where recall is the conjunction of (i) ⊥ raised, (ii) correct source, (iii) SDR emitted, and (iv) non-generic request. Type safety is a distinct property: an empty history (𝑇 = 0) lies outside the input space (Def. 4, 𝑇 ≥ 1) and is rejected at construction, before any module executes. This produces no SDR—it is a violation of the type invariant, not a module failure—and was correctly rejected in 100% of cases (𝑁 = 10).
4.4. Scenario 4: Multi-Protocol Execution (𝐾 = 2) With 𝑃𝜆 = {𝑝lung , 𝑝mock }, both diagnostic instances executed as independent per-protocol branches in every run (𝑁 = 10): branch independence, composite payload schema validity, and a protocol-output cardinality of exactly two each held at 100% (Table 3). This confirms that the framework composes multiple protocols without cross-contamination, addressing concerns specific to singleprotocol (𝐾 = 1) evaluation. G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
Table 2 S1 (nominal flow, 𝑁 = 10): per-module latency and payload validation. Module
Latency (mean ± std, ms)
𝑡𝐷𝑃 𝑀 𝑡𝐶𝑆𝑀 𝑡𝐿𝐶𝐷𝑀 𝑡𝐿𝐶𝑅𝑀 𝑡𝐿𝐶𝑊 𝑀 𝑡total
0.025 ± 0.004 0.009 ± 0.004 0.032 ± 0.007 0.022 ± 0.003 0.008 ± 0.004 0.096 ± 0.016
Completion rate SIP schema valid 𝜎𝐿𝐶𝐷 correct
100% 100% 100%
5. Discussion The PoC validates the framework at the level it is designed to operate: orchestration, not classification. Across the four scenarios the system exhibited (i) end-to-end completion with structurally valid payloads; (ii) empirical algorithmic impermeability—the routing projection was invariant under a labeled stub substitution with differing simulated content, an experimental instantiation of Proposition 2; (iii) failure safety with 100% SDR recall and correctly attributed, non-generic requests, complemented by construction-time enforcement of the input type invariant; and (iv) per-protocol independence under multi-protocol activation. These are properties of the orchestration layer: they hold irrespective of the diagnostic model and therefore generalise beyond the particular components used here.
Page 8 of 21
Table 3 Orchestration-property outcomes for S2–S4 (𝑁 = 10 each; all targets 100%). The empty-history row is a type-system invariant (Def. 4), not a module-level failure, and emits no SDR. Sc.
Property
Rate
S2 S2
𝜋-equality (projection invariant) Content difference (𝑦̃𝐿𝐶𝐷 )
100% 100%
S3 S3 S3
SDR recall — corrupted data𝑎 SDR recall — missing modality𝑎 Type-invariant rejection — empty history𝑏
100% 100% 100%
S4 S4 S4
Branch independence Composite SIP schema valid Protocol-output cardinality = 2
100% 100% 100%
𝑎 Recall = (⊥ raised) ∧ (correct source) ∧ (SDR emitted) ∧ (¬ generic);
source = LCDM (protocol-level). 𝑏 Rejected at construction (𝑇 < 1); no SDR is produced.
5.1. Positioning The impermeability result is the practical payoff of the design. Because the orchestration projection is invariant under model swaps, clinical models can be retrained or replaced without revalidating routing, failure handling, or the output contract—an operation that is structurally impossible in monolithic fusion architectures. The SIP further isolates the framework from downstream IT volatility, so that changes to EMR schemas or interoperability standards do not propagate into any upstream module. Combined with cancer-agnostic switching, this positions the LCA as an orchestration layer rather than a competitor to any individual diagnostic model.
5.2. Limitations The evaluation is deliberately scoped. It exercises the deterministic variant V1 only; the probabilistic router V2, although fully specified, is not empirically validated here, and its routing guarantee is conditional on calibration, in line with recent empirical analyses of calibration and selective prediction in multimodal clinical condition classification López, Shamout and Rudner (2026). Inference is provided by declared reference stubs emitting simulated diagnostic content — not executed neural architectures — and the remedy module by a declared rule-based stub: this is appropriate for testing orchestration properties but entails no claim about clinical accuracy or about the behaviour of any specific model class, and the latency argument is made by reference to typical inference magnitudes rather than against a production model. Remedy synthesis policies and SDR request templates are protocol-declared and require maintenance as clinical guidelines evolve, and natural-language generation is presently English-centric. Finally, empirical generality is shown on a single real pathology augmented by a mock protocol; protocol generality at scale is argued formally (Q2) rather than measured across many pathologies.
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
5.3. Ethical & regulatory The LCA is a decision-support layer, not an autonomous diagnostic agent. Its failure-safety mechanism enforces a human-in-the-loop pathway: missing or invalid evidence halts the affected protocol and emits a targeted SDR rather than a silent or speculative output, the behaviour expected of a safe clinical decision support system. A deployed instantiation operating within a diagnostic pathway would fall under software-as-a-medical-device regimes (e.g., FDA SaMD, EU MDR); the architecture supports this through the SIP audit trail and the exclusion of model identities from the external payload, which together aid traceability and governance. Clinical responsibility for any resulting action remains with the supervising clinician. This human-in-the-loop design is consistent with established CDSS design principles that emphasize mitigation of alert fatigue, algorithmic bias, and preservation of clinician judgment Bayor, Li, Yang and Varnfield (2025).
6. Conclusion The integration of artificial intelligence into clinical oncology has historically been constrained by rigid, monolithic models that permanently couple data ingestion with specific neural network inferences. To overcome these systemic bottlenecks, this paper introduced the Large Cancer Assistant (LCA), a model-agnostic orchestration framework designed to asynchronously harmonize multimodal spatial, semantic, and biological patient data. By enforcing the formal principle of Algorithmic Impermeability, the LCA establishes a unidirectional pipeline that structurally decouples raw data routing from black-box deep learning inference, and mathematical predictions from clinical heuristics. Furthermore, the dual-variant routing paradigm—offering both explicit deterministic parameterization (V1) and the formal specification for autonomous probabilistic detection (V2)— ensures the framework remains highly adaptable to varying levels of hospital IT infrastructure fidelity. A defining feature of the LCA architecture is its deliberate boundary constraint: the orchestration systematically outputs a proprietary Standardized Intermediate Payload (SIP). This structural design successfully insulates the core AI systems from the volatile protocols of external hospital databases. Consequently, the framework demonstrates immediate clinical applicability for any multimodal oncological Clinical Decision Support System (CDSS) requiring a scalable, model-agnostic orchestration layer that natively provides a robust, interoperability-ready boundary. To position the LCA framework within a broader clinical translation trajectory, we define an explicit, three-tiered research roadmap. First, the downstream translation of the SIP into strict HL7 FHIR resources is deliberately scoped as an independent architectural challenge, constituting the exclusive subject of a subsequent dedicated paper. Second, parallel informatics efforts will address the factored extraction of deep learning features across distinct modalities. Finally, future work will focus on the rigorous empirical Page 9 of 21
Table 4 Modality Structural Characterization (T) Modality CT / MRI volume Histopathology (WSI) Clinical text Tabular biological metrics
𝔊
Ω {1, … , 𝐷} × {1, … , 𝐻} × {1, … , 𝑊 } {1, … , 𝐻} × {1, … , 𝑊 } {1, … , 𝐿} {1, … , 𝑑}
3
Translations on ℤ Translations on ℤ2 Translations on ℤ {𝑒} (trivial)
ℝ ℝ3 Σ ℝ
validation and calibration of the probabilistic routing variant (V2) across large-scale, multi-pathology clinical cohorts.
Table 5 Default Medical Signature Mappings : 𝜅 values
Appendix A. Entry Theory Complete Formalization
Pathology & direct measurement prov. default to confirmed. Documentation-based prov. default to suspected. Computational inference prov. default to inferred.
Definition 1 (Domain). A domain is a pair (Ω, 𝔊) where Ω is a non-empty set of positions and 𝔊 is a group acting on Ω via a left action 𝔊 × Ω → Ω. Definition 2 (Entry). An entry is a signal 𝑥 ∈ Ω , i.e., a function 𝑥 ∶ Ω → , defined on a domain (Ω, 𝔊) with feature space . The group 𝔊 acts on entries by (𝑔 ⋅ 𝑥)(𝜔) = 𝑥(𝑔 −1 𝜔) for all 𝑔 ∈ 𝔊, 𝜔 ∈ Ω. (See details in Table 4)
Notes: ∙ 𝜌 and 𝜅 are orthogonal. ∙ A histopathology report typically carries 𝜅 = confirmed, but may carry 𝜅 = suspected if tissue is insufficient.
Definition 6 (Usage). The usage of an entry 𝑥 is a nonempty subset 𝑢 ⊆ 𝖴𝗌𝗀. In the oncology domain: 𝖴𝗌𝗀 = {observation, diagnosis, procedure, medication}
Canonical Examples (Entries) • CT volume. A computed tomography scan of 𝐷 × 𝐻 × 𝑊 voxels: 𝑥 ∶ {1, … , 𝐷} × {1, … , 𝐻} × {1, … , 𝑊 } → ℝ where 𝑥(𝑑, ℎ, 𝑤) ∈ ℝ is the Hounsfield Unit value, with 𝔊 = translations on ℤ3 . • Histopathology slide (WSI). A whole-slide image: 𝑥 ∶ {1, … , 𝐻} × {1, … , 𝑊 } → ℝ3 where 𝑥(ℎ, 𝑤) ∈ ℝ3 is the RGB vector, with 𝔊 = translations on ℤ2 . • Clinical note. Tokenized text over vocabulary Σ: 𝑥 ∶ {1, … , 𝐿} → Σ, with 𝔊 = translations on ℤ. • Blood panel. A tabular record of 𝑑 analytes: 𝑥 ∶ {1, … , 𝑑} → ℝ, with 𝔊 = {𝑒} (trivial symmetry group). Scalar values (e.g., PSA level) are represented identically prior to ingestion. Definition 3 (Clinical History). A clinical history associated with patient identifier 𝑠 is an ordered pair = ( ) (𝑥̃ 𝑗 )𝑇𝑗=1 , 𝑠 where (𝑥̃ 𝑗 )𝑇𝑗=1 is a finite ordered sequence of characterized entries, indexed by acquisition order. Definition 4{ (LCA Input). An LCA } input is a clinical history: ∶= ((𝑥̃ 𝑗 )𝑇𝑗=1 , 𝑠) ∶ 𝑇 ≥ 1 . Definition 5 (Provenance). The provenance of an entry 𝑥 is a class 𝜌 ∈ 𝖯𝗋𝗈𝗏. In the oncology domain: 𝖯𝗋𝗈𝗏 = { imaging/CT, imaging/MRI, imaging/PET, pathology/WSI, biology/panel, documentation/note, inference/AI } G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
Definition 7 (Epistemic Certainty). The epistemic certainty of an entry 𝑥 is a class 𝜅 ∈ 𝖢𝖾𝗋𝗍, where 𝖢𝖾𝗋𝗍 = {confirmed, suspected, inferred} See details in Table 5. Definition 8 (Medical Signature). The medical signature of an entry 𝑥 is the triple 𝜎(𝑥) = (𝜌, 𝑢, 𝜅) ∈ 𝖯𝗋𝗈𝗏 × (2𝖴𝗌𝗀 ⧵ {∅}) × 𝖢𝖾𝗋𝗍. Definition 9 (Characterized Entry). A ( ) characterized entry is a tuple 𝑥̃ = 𝑥, Ω, 𝔊, , 𝜎 where (𝑥, Ω, 𝔊, ) constitutes the CS axis and 𝜎 constitutes the medical axis. Proposition 1 (Independence of Axes). The CS axis (Ω, 𝔊, ) and the medical axis 𝜎 are mutually independent. PROOF. Independence in both directions is witnessed by construction: 1. CS does not determine medical. Two entries sharing identical (Ω, 𝔊, ) (e.g., both 3D volumes on ℤ3 translations with = ℝ) may have distinct medical signatures: a conclusive CT carries 𝜅 = confirmed, while an inconclusive CT of identical structural form carries 𝜅 = suspected. 2. Medical does not determine CS. Two entries sharing identical medical signature 𝜎 = (biology/panel, {observation}, confirmed) may have distinct CS structures: a standard blood panel is a tabular entry on domain size 𝑑, while a specialized urine analysis panel has a domain of different size |Ω| ≠ 𝑑 in general. ■ Page 10 of 21
Appendix B. The LCA Framework & Impermeability Definition 10 (Large Cancer Assistant Framework). The Large Cancer Assistant framework is a 7-tuple: ( ) LCA = , , 𝑓𝐷𝑃 , 𝑓𝐶𝑆 , 𝑓𝐿𝐶𝐷 , 𝑓𝐿𝐶𝑅 , 𝑓𝐿𝐶𝑊
• : the input space (Definition 4). • = {𝑝1 , … , 𝑝𝐾 }: the protocol catalog, shared across all modules. • 𝑓𝐷𝑃 : the Data Preprocessing Module (DPM). • 𝑓𝐶𝑆 : the Cancer Switching Module (CSM). • 𝑓𝐿𝐶𝐷 : the Large Cancer Diagnostic Module (LCDM). • 𝑓𝐿𝐶𝑅 : the Large Cancer Remedy Module (LCRM). • 𝑓𝐿𝐶𝑊 : the Large Cancer Wordings Module (LCWM). Proposition 2 (System Impermeability). Let Θ(𝑘) be the space of parameter configurations for protocol 𝑝𝑘 . For any (𝑘) two parameter configurations 𝜃, 𝜃 ′ ∈ Θ(𝑘) such that 𝑓𝐿𝐶𝐷,𝜃 (𝑘) (𝑘) and 𝑓𝐿𝐶𝐷,𝜃 ′ both satisfy the interface contract 𝐿𝐶𝐷 (Defi(𝑘) (𝑘) (𝑘) nition 25), and similarly 𝑓𝐿𝐶𝑅,𝜃 and 𝑓𝐿𝐶𝑅,𝜃 ′ satisfy 𝐿𝐶𝑅 : let 𝜋 denote the projection of the SIP onto its orchestration-structural component — the activation set 𝑃̂ , the perprotocol routing decisions, the set of protocols emitting ⊥, and the SIP schema — discarding the inference content 𝑦̃(𝑘) and the generated text. Then: ( ) ( ) 𝜋 𝑓𝐿𝐶𝐴 [𝜃](𝑒) = 𝜋 𝑓𝐿𝐶𝐴 [𝜃 ′ ](𝑒) ∀𝑒 ∈
i.e., module activation, routing, failure handling, and SIP structure are identical. The inference content 𝑦̃(𝑘) and the generated text may differ between implementations; the orchestration-structural projection does not. This follows : ∀𝑒 ∈
• (𝑜𝑢𝑡 , 𝑃̂ ) ∈ (𝑘) : both emit ⊥; ⊥ (𝑘) • (𝑜𝑢𝑡 , 𝑃̂ ) ∉ (𝑘) : both emit outputs in 𝐿𝐶𝐷 (infer⊥ ence content may differ).
where:
𝜋(𝑓𝐿𝐶𝐴 𝜃) = 𝜋(𝑓𝐿𝐶𝐴 𝜃 ′ )
conforming implementation. Definition 25 requires that a conforming module emits ⊥ if and only if its input belongs to (𝑘) . Since both implementations receive the identical input ⊥ (𝑜𝑢𝑡 , 𝑃̂ ) established in Step 1:
(2)
PROOF. Let 𝑒 ∈ be arbitrary, and fix any pair (𝜃, 𝜃 ′ ) of parameter configurations satisfying the stated interface contracts. We trace the pipeline under both configurations and show that every component retained by 𝜋 is identical. Step 1 — DPM and CSM are 𝜃-free. 𝑓𝐷𝑃 and 𝑓𝐶𝑆 carry no dependence on 𝜃 or 𝜃 ′ . Therefore 𝑜𝑢𝑡 = 𝑓𝐷𝑃 (𝑒) and 𝑃̂ = 𝑓𝐶𝑆 (𝑜𝑢𝑡 , 𝜇) are identical under both configurations. The activation set, the per-protocol routing decisions, and the induced partition (𝑃̂𝐿𝐶𝐷 , 𝑃̂𝐿𝐶𝑅 ) are the same. Step 2 — ⊥-status of LCDM instances. Fix any 𝑝𝑘 ∈ (𝑘) (𝑘) 𝑃̂𝐿𝐶𝐷 . By assumption, 𝑓𝐿𝐶𝐷,𝜃 and 𝑓𝐿𝐶𝐷,𝜃 ′ both satisfy (𝑘) 𝐿𝐶𝐷 (Definition 25). The failure precondition set (𝑘) is ⊥
(𝑘) a declared component of the contract 𝐿𝐶𝐷 , shared by every
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
The ⊥-status of every LCDM instance is therefore identical under 𝜃 and 𝜃 ′ . Step 3 — ⊥-status of LCRM instances. Identical argument (𝑘) (𝑘) (𝑘) for 𝑓𝐿𝐶𝑅,𝜃 and 𝑓𝐿𝐶𝑅,𝜃 ′ with respect to 𝐿𝐶𝑅 . Step 4 — SIP schema. The SIP schema is determined by 𝑃̂ , support(𝑝𝑘 ), and type(𝑝𝑘 ) — all declared a priori as protocol parameters, independent of 𝜃. It is therefore identical under both configurations. Conclusion. The projection 𝜋 retains: (i) the activation set 𝑃̂ , (ii) per-protocol routing decisions, (iii) the set of protocols emitting ⊥, and (iv) the SIP schema; it discards inference content 𝑦̃(𝑘) and generated text. By Steps 1–4, each retained component is identical under 𝜃 and 𝜃 ′ . Hence 𝜋(𝑓𝐿𝐶𝐴 [𝜃](𝑒)) = 𝜋(𝑓𝐿𝐶𝐴 [𝜃 ′ ](𝑒)). Corollary 1. The modules 𝑓𝐷𝑃 , 𝑓𝐶𝑆 , and 𝑓𝐿𝐶𝑊 are un(𝑘) (𝑘) changed by any update to 𝑓𝐿𝐶𝐷 or 𝑓𝐿𝐶𝑅 . Clinical AI models can be retrained, updated, or replaced independently of the orchestration layer.
Definition of the LCA on .
𝑓𝐿𝐶𝐴 is defined for every 𝑒 ∈ , including partialmodality inputs. No input causes a silent failure. Under V2, a degenerate history whose entries carry no clinical signal (all per-protocol scores below 𝜏) causes the CSM to emit ⊥, returning a top-level SDR without invoking any inference module. Under V1, the CSM returns 𝑃𝜆 regardless of signal quality; any ⊥ originates from the LCDM or LCRM at the protocol level, not from the CSM.
Appendix C. Data Preprocessing Module (DPM) Formalization Definition 11 (Modality-Specific Preprocessor). For each 𝜌 ∈ 𝖯𝗋𝗈𝗏, a modality-specific preprocessor is a function ′
𝜙𝜌 ∶ (𝜌 )Ω𝜌 ⟶ (𝜌′ )Ω𝜌 mapping entries on source domain (Ω𝜌 , 𝔊𝜌 , 𝜌 ) to entries on target domain (Ω′𝜌 , 𝔊𝜌 , 𝜌′ ). Each 𝜙𝜌 is defined independently for its provenance class; no preprocessor is shared across distinct classes 𝜌 ≠ 𝜌′ . Remark 1. A preprocessor 𝜙𝜌 may act on the domain Ω𝜌 (e.g., isotropic resampling of CT volumes from anisotropic voxel spacing 𝑠 = (𝑠𝑥 , 𝑠𝑦 , 𝑠𝑧 ) to canonical spacing 𝑠′ = (1, 1, 1) mm), on the feature space 𝜌 (e.g., Hounsfield Unit Page 11 of 21
clipping to [−1000, 400] followed by min-max normalization to [0, 1]), or on both simultaneously. Domain transformation proceeds via interpolation in the continuous embedding of Ω𝜌 ; feature transformation is a pointwise or neighborhood-dependent map on 𝜌 . Definition 12 (Data Preprocessing Module (𝑓𝐷𝑃 )). The DPM function 𝑓𝐷𝑃 is defined over any LCA input (Definition 4): a clinical history of characterized entries ̃ = ((𝑥̃ 𝑗 )𝑇𝑗=1 , 𝑠) with 𝑇 ≥ 1, together with associated metadata 𝜇 ∈ . It is the sequential composition of five functions 𝑓0 , 𝑓1 , 𝑓2 , 𝑓3 , 𝑓4 . 𝑓0 — History sequencing. 𝑓0 decomposes the input history into an index-tagged family and extracts the ordering metadata: ( ) ̃ = (𝑗, 𝑥̃ 𝑗 )𝑇 , = ((𝑗)𝑇 , 𝑠) 𝑓0 () 𝑗=1 𝑗=1 The ordering metadata records the acquisition indices (𝑗)𝑇𝑗=1 and the subject identifier 𝑠. It is carried separately through 𝑓1 , 𝑓2 , 𝑓3 without modification and consumed by 𝑓4 . The index tag 𝑗 preserves the element-to-index association through all stages, so that distinct entries sharing an identical value or signature remain distinguishable. 𝑓1 — Signature extraction and preprocessing routing. ) ) ( ( 𝑓1 (𝑗, 𝑥̃ 𝑗 )𝑇𝑗=1 = 𝑗, 𝑥𝑗 , Ω𝑗 , 𝔊𝑗 , 𝑗 , 𝜌𝑗 )𝑇𝑗=1 , (𝑗, 𝑢𝑗 , 𝜅𝑗 )𝑇𝑗=1 𝑓1 decomposes each characterized entry into two streams. The first stream 𝐶𝑆 = (𝑗, 𝑥𝑗 , Ω𝑗 , 𝔊𝑗 , 𝑗 , 𝜌𝑗 )𝑇𝑗=1 carries the structural CS components together with the provenance 𝜌𝑗 , extracted from 𝜎𝑗 , which serves as the preprocessing routing key. The second stream 𝑚𝑒𝑑 = (𝑗, 𝑢𝑗 , 𝜅𝑗 )𝑇𝑗=1 carries the clinical attributes of the medical signature. The full signature 𝜎𝑗 = (𝜌𝑗 , 𝑢𝑗 , 𝜅𝑗 ) is never modified; it is reassembled by 𝑓3 . 𝑓2 — Structural preprocessing. 𝑓2 (𝐶𝑆 ) =
)𝑇 ( 𝑗, 𝜙𝜌𝑗 (𝑥𝑗 ), Ω′𝜌 , 𝔊𝜌𝑗 , 𝜌′ , 𝜌𝑗 𝑗=1 𝑗
𝑗
𝑓2 applies the modality-specific preprocessor 𝜙𝜌𝑗 , selected via the routing key 𝜌𝑗 ∈ 𝐶𝑆 , to each CS component independently. The functions {𝜙𝜌𝑗 } are applied without defined inter-entry ordering; within each 𝜙𝜌𝑗 , internal suboperations are applied sequentially as specified by the preprocessor for that provenance class. 𝑓3 — Axis reconstruction. ) (( )𝑇 𝑓3 𝑗, 𝑥′𝑗 , Ω′𝑗 , 𝔊𝑗 , 𝑗′ , 𝜌𝑗 𝑗=1 , (𝑗, 𝑢𝑗 , 𝜅𝑗 )𝑇𝑗=1 ( )𝑇 = 𝑗, 𝑥′𝑗 , Ω′𝑗 , 𝔊𝑗 , 𝑗′ , 𝜎𝑗 𝑗=1 where 𝜎𝑗 = (𝜌𝑗 , 𝑢𝑗 , 𝜅𝑗 ) is reconstructed from the routing key 𝜌𝑗 carried in 𝐶𝑆 and the clinical attributes (𝑢𝑗 , 𝜅𝑗 ) carried in 𝑚𝑒𝑑 . 𝑓3 takes as input both the output of 𝑓2 and 𝑚𝑒𝑑 retained from 𝑓1 .
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
𝑓4 — History recomposition. 𝑓4 restores the acquisition ordering and subject identity: ( ) ( ) 𝑓4 (𝑗, 𝑥̃ ′𝑗 )𝑇𝑗=1 , = (𝑥̃ ′𝑗 )𝑇𝑗=1 , 𝑠 𝑓4 reorders the preprocessed entries by their acquisition index 𝑗 and reattaches the subject identifier 𝑠, yielding a preprocessed clinical history. The temporal ordering established by 𝑓0 is exactly preserved. ̃ Full composition. Let (𝐶, ) = 𝑓0 () and (𝐶𝑆 , 𝑚𝑒𝑑 ) = 𝑓1 (𝐶). Then: ( ( ) ) 𝑓𝐷𝑃 (𝑒, 𝜇) = 𝑓4 𝑓3 (𝑓2 (𝐶𝑆 ), 𝑚𝑒𝑑 ), , 𝜇 The ordering metadata produced by 𝑓0 is passed directly to 𝑓4 without being modified by 𝑓1 , 𝑓2 , or 𝑓3 .
Properties of 𝑓𝐷𝑃
(P1.1) Symmetry group preservation. The symmetry group is preserved: 𝔊′𝜌 = 𝔊𝜌𝑖 . A signal defined on a 𝑖 domain with group 𝔊𝜌𝑖 before preprocessing remains defined on a domain with the same group after preprocessing. (P1.2) Medical transparency. The medical signature 𝜎𝑖 = (𝜌𝑖 , 𝑢𝑖 , 𝜅𝑖 ) is never modified during preprocessing. The clinical attributes 𝑢𝑖 and 𝜅𝑖 are not accessed by 𝑓2 . Preprocessing is parameterized exclusively by 𝜌𝑖 , which serves as a routing key selecting the appropriate canonical form. Two arguments motivate this design: (i) Semantic invariance of the medical signature. The signature 𝜎 = (𝜌, 𝑢, 𝜅) characterizes provenance, usage, and epistemic certainty— properties intrinsic to the data item and invariant under changes of representation. A resampled and normalized CT volume retains the same 𝜌, 𝑢, and 𝜅. Preprocessing alters the representation of the signal, not its clinical meaning. (ii) Parameterization by type, not by clinical judgment. Preprocessing depends on the medical axis exclusively through 𝜌𝑖 . It does not depend on 𝑢𝑖 or 𝜅𝑖 , which carry clinical judgment. Proposition 1 is unaffected. (P1.3) Metadata invariance. The metadata 𝜇 passes through 𝑓𝐷𝑃 unmodified. (P1.4) Identity as degenerate case. When Ω𝑖 = Ω′𝜌 and 𝑖 𝑖 = 𝜌′ , the preprocessor 𝜙𝜌𝑖 reduces to the identity 𝑖 map: 𝜙𝜌𝑖 (𝑥𝑖 ) = 𝑥𝑖 .
Canonical Examples (Preprocessing). Natural image. ∙ Source: 𝑥 ∈ {0, … , 255}{1,…,𝐻}×{1,…,𝑊 } . ∙ Target: 𝑥′ ∈ [0, 1]{1,…,224}×{1,…,224} . ∙ 𝜙img applies: (1) bilinear resampling to 224 × 224; (2) normalization 𝑥′ (ℎ, 𝑤) = 𝑥resized (ℎ, 𝑤)∕255. Both Ω and change. CT medical volume. ∙ Source: 𝑥 ∈ ℝ{1,…,𝐷}×{1,…,𝐻}×{1,…,𝑊 } with spacing 𝑠 = Page 12 of 21
(𝑠𝑥 , 𝑠𝑦 , 𝑠𝑧 ) mm. ′ ′ ′ ∙ Target: 𝑥′ ∈ [0, 1]𝐷 ×𝐻 ×𝑊 with isotropic spacing 𝑠′ = ′ (1, 1, 1) mm, where 𝐷 = round(𝐷⋅𝑠𝑧 ), 𝐻 ′ = round(𝐻 ⋅𝑠𝑦 ), 𝑊 ′ = round(𝑊 ⋅ 𝑠𝑥 ). ∙ 𝜙CT applies sequentially: (1) trilinear resampling; (2) HU clipping 𝑣 ↦ max(min(𝑣, 400), −1000); (3) normalization 𝑣 ↦ (𝑣 + 1000)∕1400. Both Ω and change. Clinical note. ∙ Source: 𝑥 ∈ Σ{1,…,𝐿} . By default 𝜙text is the identity. ∙ Classical pipelines may apply a TF-IDF map Σ{1,…,𝐿} → ℝ{1,…,𝑑} , in which case both Ω and change. Blood panel. ∙ Source: 𝑥 ∈ ℝ{1,…,𝑑} in physical units. ∙ Target: 𝑥′ ∈ [0, 1]{1,…,𝑑} . ∙ 𝜙bio normalizes each analyte ) 𝑘 against its reference range: ( 𝑥′ (𝑘) = clip
𝑥(𝑘)−𝑟min 𝑘
𝑟max −𝑟min 𝑘 𝑘
, 0, 1 . Only changes.
Identity case. When Ω𝑖 = Ω′𝜌 and 𝑖 = 𝜌′ : 𝜙𝜌𝑖 (𝑥𝑖 ) = 𝑖 𝑖 𝑥𝑖 . Neither Ω nor changes.
Appendix D. Cancer Switching Module (CSM) Complete Formalization Definition 13 (Protocol Catalog). A protocol catalog is a finite, non-empty set = {𝑝1 , … , 𝑝𝐾 } where each 𝑝𝑘 designates a cancer-specific diagnostic and therapeutic pipeline. is a parameter of the LCA framework, declared a priori from clinical scope; it is not inferred from data.
Remark 2 (Activation parameter vs. safety threshold). The activation parameter 𝑃𝜆 ⊆ (V1) is a content parameter: it determines which modules are activated. The confidence threshold 𝜏 ∈ (0, 1) (V2) is an operational parameter: it determines the minimum per-protocol confidence required before any module is activated.
Variant V2 — Probabilistic Activation Definition 18 (Probability Simplex). For a finite set 𝑆, the probability simplex over 𝑆 is: { } ∑ |𝑆| Δ(𝑆) = 𝑞 ∈ ℝ ∶ 𝑞𝑠 ≥ 0 ∀𝑠, 𝑞𝑠 = 1 𝑠∈𝑆
Definition 19 (V2 Input Space and Hyp. Class). V2 input space is 𝑉 2 , the set of all valid DPM outputs. The hypothesis class is the set of measurable functions ℎ ∶ 𝑉 2 → [0, 1]𝐾 , where ℎ(𝑒)𝑘 ∈ [0, 1] is the per-protocol confidence score that 𝑝𝑘 is relevant to case 𝑒. The framework imposes no invariance or equivariance constraint on ℎ: by algorithmic impermeability, the internal architecture is not part of the V2 contract. Definition 20 (Routing Risk). Let be the unknown joint distribution over 𝑉 2 × 2 . The routing risk of a hypothesis ℎ ∈ is: [ 𝐾 ] ∑ [ ] 𝟏 (𝑝𝑘 ∈ 𝑃̂ (ℎ, 𝑒)) ≠ (𝑝𝑘 ∈ 𝑃 ∗ ) 𝑅(ℎ) = 𝔼(𝑒, 𝑃 ∗ )∼ 𝑘=1
Definition 14 (Activation Set). An activation set is either a non-empty subset 𝑃̂ ⊆ or ⊥, where 𝑃̂ designates the set of cancer-specific modules activated for investigation, and ⊥ designates an activation failure requiring human intervention (Supplementary Data Request). Definition 15 (CSM Input). The CSM receives the output of 𝑓𝐷𝑃 (Definition 12): a preprocessed clinical history ̃ ′ = ((𝑥̃ ′𝑗 )𝑇𝑗=1 , 𝑠) together with associated metadata 𝜇. Each preprocessed entry 𝑥̃ ′𝑗 is a characterized entry in the sense of Definition 9, carrying both CS structure and medical signature. Denote by 𝑒 ∈ 𝑉 2 the full DPM output. The CSM function 𝑓𝐶𝑆 maps (𝑒, 𝜇) to an activation set in 2 ⧵ {∅} or ⊥.
Variant V1 — Deterministic Activation Definition 16 (A Priori Activation Parameter). The V1 activation parameter is a direct protocol set declaration: 𝑃𝜆 ⊆ , 𝑃𝜆 ≠ ∅. 𝑃𝜆 specifies the set of cancer-specific modules to activate unconditionally. It is declared a priori — by the clinician or the upstream system — prior to any signal processing; it is not computed from data. Definition 17 (V1 Activation Function). The V1 activation function is: 𝑅𝑉 1 = 𝑃𝜆 if 𝑃𝜆 is declared and 𝑃𝜆 ⊆ , 𝑃𝜆 ≠ ∅; 𝑅𝑉 1 = ⊥ otherwise. V1 does not access 𝑒, 𝐶𝑆 , 𝑚𝑒𝑑 , or 𝜇. The activation set is determined entirely by the a priori parameter 𝑃𝜆 . G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
where 𝑃 ∗ ⊆ is the ground-truth set of relevant protocols, and 𝑃̂ (ℎ, 𝑒) = {𝑝𝑘 ∶ ℎ(𝑒)𝑘 ≥ 𝜏}. Definition 21 (Calibration). A hypothesis ℎ ∈ is calibrated with respect to if, for all 𝑘 ∈ {1, … , 𝐾} and all 𝑐 ∈ [0, 1]: ( ) 𝑃(𝑒, 𝑃 ∗ )∼ 𝑝𝑘 ∈ 𝑃 ∗ || ℎ(𝑒)𝑘 = 𝑐 ≈ 𝑐 -almost everywhere. Definition 22 (V2 Activation Function). The V2 activation function is defined by a hypothesis ℎ ∈ approximately minimizing 𝑅 subject to calibration, with perprotocol threshold gating at 𝜏 ∈ (0, 1): { } 𝑃̂ (𝑒) = 𝑝𝑘 ∈ ∶ ℎ(𝑒)𝑘 ≥ 𝜏 𝑅𝑉 2 (𝑒) =
{ 𝑃̂ (𝑒)
if 𝑃̂ (𝑒) ≠ ∅
⊥
if 𝑃̂ (𝑒) = ∅
.
Definition 23 (CSM Function). The CSM function 𝑓𝐶𝑆 selects an activation variant and emits an activation set: { 𝑅𝑉 1 = 𝑃𝜆 (V1: parameterized) 𝑓𝐶𝑆 (𝑒, 𝜇) = . 𝑅𝑉 2 (𝑒) (V2: auto-detecting)
Page 13 of 21
Properties of 𝑓𝐶𝑆
(P2.1) Output type. For both variants, 𝑓𝐶𝑆 emits an activation set in 2 ⧵ {∅} or ⊥. (P2.2) Symmetry as optional structural prior. An implementation of ℎ may be designed 𝔊𝑡𝑖 -invariant, but this is an architectural choice, not a framework guarantee. (P2.3) Activation parameter primacy in V1. V1 does not access 𝑒, 𝐶𝑆 , 𝑚𝑒𝑑 , 𝜇, or temporal structure. (P2.4) Dual-axis activation in V2. V2 uses both the CS components and the medical signatures (including 𝜅) from 𝑒. (P2.5) Safety under insufficient evidence. Both variants emit ⊥ when activation cannot be committed, terminating without activating downstream modules and triggering a Supplementary Data Request.
Appendix E. LCDM & LCRM Formalization Definition 24 (Output Space Types). Two classes of output are admitted for AI modules within the LCA framework: (𝑘) Ω(𝑘) 1. Structural output. A signal 𝑦𝑠𝑡𝑟𝑢𝑐𝑡 ∈ (𝑜𝑢𝑡 ) 𝑜𝑢𝑡 defined on (𝑘) ) with output feature space an output domain (Ω(𝑘) , 𝔊 𝑜𝑢𝑡 (𝑘) 𝑜𝑢𝑡 , both declared a priori as part of the protocol 𝑝𝑘
specification. 2. Decisional output. A probability distribution 𝑦𝑑𝑒𝑐 ∈ Δ((𝑘) ) over a finite, protocol-specific class catalog (𝑘) , declared a priori. For each protocol 𝑝𝑘 , the admissible output type is declared a priori: { 𝑚 } 𝑚 ∏ (𝑖) ∏ (𝑖) type(𝑝𝑘 ) ∈ 𝑠𝑡𝑟𝑢𝑐𝑡 , 𝑑𝑒𝑐 , 𝑠𝑡𝑟𝑢𝑐𝑡 × 𝑑𝑒𝑐 , 𝑖=1
𝑖=1
where 𝑚 ≥ 1 Definition 25 (Module Interface Contract). An interface contract 𝜏(𝑘) for a module of type 𝜏 ∈ {LCD, LCR} and protocol 𝑝𝑘 ∈ specifies: • An input type 𝜏(𝑘) . • An output type 𝜏(𝑘) ∈ type(𝑝𝑘 ), declared a priori. • A failure precondition set (𝑘) ⊆ 𝜏(𝑘) , declared a ⊥ priori, enumerating the input-level conditions under which ⊥ is emitted. Remark 3. When internal inference fails on an input not in (𝑘) , a conforming implementation produces a decisional ⊥ output with a protocol-declared failure code 𝙲𝙾𝙳𝙴_𝙵𝙰𝙸𝙻(𝑘) ∈ (𝑘) . ⊥ is reserved exclusively for inputs in (𝑘) . ⊥ Definition 26 (Algorithmic Impermeability). A module 𝑓 (𝑘) is algorithmically impermeable with respect to 𝜏(𝑘) if G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
for any two implementations 𝑓𝜃(𝑘) and 𝑓𝜃(𝑘) ′ both satisfying 𝜏(𝑘) :
[ ] [ ] Orch 𝑓𝜃(𝑘) (𝑒) = Orch 𝑓𝜃(𝑘) ′ (𝑒)
∀ 𝑒 ∈ 𝑉 2
where Orch[ ⋅ ] denotes the global orchestration function.
Protocol Catalog Completeness Definition 27 (Protocol Support). For each protocol 𝑝𝑘 ∈ , its support is a non-empty subset support(𝑝𝑘 ) ⊆ {LCD, LCR} declaring which AI modules are required to handle 𝑝𝑘 . The three configurations are {LCD, LCR}, {LCD}, and {LCR}. Proposition 3 (Catalog Completeness). The protocol catalog is complete if and only if ∀ 𝑝𝑘 ∈ ,
support(𝑝𝑘 ) ≠ ∅
Large Cancer Diagnostic Module (LCDM) Definition 28 (LCDM Input and Activated Subset). Let 𝑃̂ be the activation set emitted by 𝑓𝐶𝑆 . Define 𝑃̂𝐿𝐶𝐷 = {𝑝𝑘 ∈ 𝑃̂ ∶ LCD ∈ support(𝑝𝑘 )}. The LCDM interface for protocol 𝑝𝑘 is: (𝑘) (𝑘) (𝑘) 𝐿𝐶𝐷 ∶ 𝐿𝐶𝐷 = 𝑉 2 × 2 ⟶ ̃ 𝐿𝐶𝐷 ∪ {⊥}
Definition 29 (LCDM Output as Characterized Entry). (𝑘) For each 𝑝𝑘 ∈ 𝑃̂𝐿𝐶𝐷 , 𝑓𝐿𝐶𝐷 produces (𝑘) 𝑦̃(𝑘) = (𝑦(𝑘) , 𝜎𝐿𝐶𝐷 ) 𝐿𝐶𝐷 𝐿𝐶𝐷 (𝑘) (𝑘) where 𝜎𝐿𝐶𝐷 = (𝜌𝐿𝐶𝐷 , 𝑢(𝑘) , 𝜅𝐿𝐶𝐷 ). The epistemic 𝐿𝐶𝐷
(𝑘) certainty 𝜅𝐿𝐶𝐷 = synth𝑘 ((𝜅𝑖 )𝑖 ) is derived via a declared synthesis policy, defaulting to inferred. The LCDM function is thus : ( {( ) )} 𝑓𝐿𝐶𝐷 (𝑜𝑢𝑡 , 𝑃̂ ) = 𝑦̃(𝑘) , 𝑝 , 𝑘 𝑜𝑢𝑡 ̂ 𝐿𝐶𝐷 𝑝 ∈𝑃 𝑘
𝐿𝐶𝐷
Properties of 𝑓𝐿𝐶𝐷 (P3.1) Algorithmic impermeability: Implementations sat(𝑘) isfying 𝐿𝐶𝐷 are interchangeable. (P3.2) Per-protocol independence: Instances (𝑘) {𝑓𝐿𝐶𝐷 }𝑝 ∈𝑃̂ are independent at the framework 𝑘 𝐿𝐶𝐷 level. (P3.3) SDR trigger: Inputs in (𝑘) emit ⊥ mapped to an ⊥ SDR.
Large Cancer Remedy Module (LCRM) Definition 30 (LCRM Input and Activated Set). Define 𝑃̂𝐿𝐶𝑅 = {𝑝𝑘 ∈ 𝑃̂ ∶ LCR ∈ support(𝑝𝑘 )} The LCRM interface is: ( (𝑘) ) (𝑘) (𝑘) 𝐿𝐶𝑅 ∶ 𝐿𝐶𝑅 = ̃ 𝐿𝐶𝐷 × 𝑉 2 × 2 (𝑘) ⟶ 𝐿𝐶𝑅 ∪ {⊥}
Page 14 of 21
Definition 31 (LCRM Function). The LCRM function is: (( ) ) ̂ 𝑓𝐿𝐶𝑅 {(𝑦̃(𝑘) , 𝑝 )}, 𝑜𝑢𝑡 , 𝑃 𝐿𝐶𝐷 𝑘 ( {( ) )} = 𝑦̃(𝑘) , 𝑝 , 𝑘 𝑜𝑢𝑡 ̂ 𝐿𝐶𝑅 𝑝 ∈𝑃 𝑘
𝐿𝐶𝑅
Remark 4 (Conditional activation). The LCRM is activated only for protocols where LCR ∈ support(𝑝𝑘 ). For protocols with support(𝑝𝑘 ) = {LCD}, no LCRM instance is created and the LCWM operates solely on LCDM outputs.
Properties of 𝑓𝐿𝐶𝑅 & Canonical Lifting ∙ Properties (P4.1 - P4.3): Identical impermeability, independence, and SDR triggers as the LCDM. (P4.4) Conditional activation: For protocols where support(𝑝𝑘 ) = {LCR}, a canonical lifting 𝜄 maps relevant confirmed historical entries (with 𝑢 ∋ diagnosis and 𝜅 = confirmed) into the LCDM-output type (𝑘) ̃ 𝐿𝐶𝐷 , ensuring the LCRM always receives an input of its declared type. The pipeline remains unidirectional.
Appendix F. LCWM, SDR, and SIP Formalization Definition 32 (LCWM Input). The LCWM receives four inputs: • 𝑃̂ ⊆ : the activation set emitted by 𝑓𝐶𝑆 , identifying which protocols were activated and their support configurations. • LCDM outputs: {(𝑦̃(𝑘) , 𝑝 )} — one char𝐿𝐶𝐷 𝑘 𝑝𝑘 ∈𝑃̂𝐿𝐶𝐷 acterized diagnostic entry per activated diagnostic protocol, or ⊥ per protocol on LCDM failure. • LCRM outputs: {(𝑦̃(𝑘) , 𝑝 )} — one charac𝐿𝐶𝑅 𝑘 𝑝𝑘 ∈𝑃̂𝐿𝐶𝑅 terized remedy entry per activated remedy protocol, or ⊥ per protocol on LCRM failure. • 𝑜𝑢𝑡 : the preprocessed history, bypassed through LCDM and LCRM unchanged. If the CSM itself emitted ⊥ (activation failure), no downstream modules ran; the LCWM receives only 𝑃̂ = ⊥ and generates a top-level SDR. Definition 33 (LCWM Output Components). The LCWM produces two distinct output components: (i) Text output. Generated by the LCWM’s NLG model from the aggregated inputs. For each protocol 𝑝𝑘 ∈ 𝑃̂ : if upstream outputs are valid, the text contains diagnostic and therapeutic narrative; if any upstream module emitted ⊥, the text contains a Supplementary Data Request (Definition 34) for that protocol. A protocol may produce both narrative and SDR text simultaneously (e.g., valid LCDM output and ⊥ from LCRM).
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
(ii) Structured bypass. The LCDM outputs {(𝑦̃(𝑘) , 𝑝 )} 𝐿𝐶𝐷 𝑘 𝑝 ∈𝑃̂ 𝑘
𝐿𝐶𝐷
,
LCRM outputs {(𝑦̃(𝑘) , 𝑝 )} , and the prepro𝐿𝐶𝑅 𝑘 𝑝𝑘 ∈𝑃̂𝐿𝐶𝑅 cessed history 𝑜𝑢𝑡 passed through unchanged. This bypass preserves the full structured AI outputs for clinical archiving, audit, and downstream integration, independently of the text generation. Definition 34 (Supplementary Data Request). Two SDR variants are defined, depending on which module emitted ⊥: (i) Top-level SDR — emitted when the CSM emits ⊥ (no protocol was activated): ( ) SDR𝑡𝑜𝑝 = source = CSM, request No protocol field is present, as no protocol was activated. (ii) Protocol-level SDR — emitted when the LCDM or LCRM emits ⊥ for protocol 𝑝𝑘 : ) ( SDR(𝑘) = protocol(𝑘) , source(𝑘) , request(𝑘) where: • protocol(𝑘) = 𝑝𝑘 : the activated protocol for which a failure occurred. • source(𝑘) ∈ {LCDM, LCRM}: the module that emitted ⊥. • request(𝑘) : a targeted description of the additional data required to resume the pipeline for 𝑝𝑘 . The content of request(𝑘) is determined by source(𝑘) and the activation set 𝑃̂ ; it is not a generic message. The SDR does not terminate the pipeline for other activated protocols. Protocols without failures continue to produce text and structured bypass output independently. Definition 35 (Standardized Intermediate Payload). The Standardized Intermediate Payload (SIP) is the output of the LCWM, comprising the two components of Definition 33: ( ) SIP = text_output, structured_bypass The SIP constitutes the architectural boundary between the LCA framework and downstream systems. Its internal structure is not specified at the framework level; it is the subject of subsequent interoperability work (HL7 FHIR mapping). Downstream systems consume the SIP without interacting with any internal LCA module. Definition 36 (LCWM Function). The LCWM function is: ( ) (𝑘) 𝑓𝐿𝐶𝑊 𝑃̂ , {𝑦̃(𝑘) } , { 𝑦 ̃ } , = SIP 𝑜𝑢𝑡 𝐿𝐶𝐷 𝑝 ∈𝑃̂ 𝐿𝐶𝑅 𝑝 ∈𝑃̂ 𝑘
𝐿𝐶𝐷
𝑘
𝐿𝐶𝑅
(𝑘) (𝑘) Unlike 𝑓𝐿𝐶𝐷 and 𝑓𝐿𝐶𝑅 , the LCWM is not parametrized by an interchangeable implementation under the interfacecontract substitution of Definition 25 (restricted to 𝜏 ∈ {LCD, LCR}): 𝑓𝐿𝐶𝑊 is 𝜃-free, on par with 𝑓𝐷𝑃 and 𝑓𝐶𝑆 (Corollary 1). A change to its internal NLG realization constitutes a new deployment of 𝑓𝐿𝐶𝑊 , not a substitution within a declared interface contract.
Page 15 of 21
Properties of 𝑓𝐿𝐶𝑊
(P5.1) Exclusive external interface. The LCWM is the sole module whose output exits the LCA framework. All other modules communicate exclusively with adjacent modules. (P5.2) Coverage. For every 𝑝𝑘 ∈ 𝑃̂ , the text output of the LCWM contains at least one entry — either narrative content or a Supplementary Data Request. No activated protocol produces a silent empty output. (P5.3) SDR specificity. Each SDR(𝑘) identifies the specific module that failed and the specific data deficiency. Generic or uninformative requests are not admissible. (P5.4) SIP as architectural boundary. The SIP decouples the LCA core from volatile external IT infrastructure. Changes to EMR systems, FHIR versions, or interoperability standards do not require modification of any module upstream of the LCWM.
Appendix G. SIP Design Principles D1 SIP as the LCWM’s sole output type. The LCWM always produces a SIP (Def. 35), regardless of the situation. The top-level JSON is invariantly a SIP. When a module emits ⊥, the resulting SDR is (i) a component of lcwm_narrative (Def. 33 ; text (i)) and (ii) a structured object in protocol_outputs[k].sdr — or in csm_sdr if the CSM itself has failed. There is no payload_type: "SDR" as an alternative to payload_type: "SIP"; this pattern conflated the type of the LCWM output with its content. D2 𝐷𝑜𝑢𝑡 : input references rather than content. Def. 35 requires 𝐷𝑜𝑢𝑡 in the bypass but explicitly states: "The framework is agnostic as to persistence: 𝐷𝑜𝑢𝑡 may equal the original history when the DPM acts as the identity (P5), or a preprocessed representation otherwise; which representation(s) a downstream system archives is an implementation decision outside the framework." 𝐷𝑜𝑢𝑡 contains normalized CT volumes, clinical note tokens — including them in full within the JSON introduces unacceptable latency and redundancy: the source data already exists in the upstream Healthcare system (FHIR/PACS/EMR). Downstream, a FHIR consumer does not consume 𝐷𝑜𝑢𝑡 ; it retrieves the originals via their identifiers. Adopted solution: input_provenance.entry_refs logs for each entry 𝑗 its acquisition index, external identifier in the source system, and medical signature 𝜎𝑗 . The DPM profile is logged separately to enable 𝐷𝑜𝑢𝑡 reconstruction if needed (auditability). The medical signature of input entries is essential: it informs the FHIR translation about the resource types to reference (ImagingStudy vs DocumentReference vs Observation). This is not a violation of theory — it is the explicit instantiation of the persistence choice left open by Def. 35, consistent with the constraints of a FHIR environment. D3 CSM trace: V1 and V2 explicitly distinguished. The CSM has two variants (Def. 23). The JSON trace distinguishes which one is active: G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
• V1: v1_param_P_lambda is the a priori declared parameter (Def. 16) • V2: v2_per_protocol_scores = the scores ℎ(𝑒)𝑘 per protocol and v2_threshold_tau = 𝜏 (Def. 22) • In both cases: activation_set_P_hat is the output 𝑃̂ of the CSM — this is what downstream modules consume. Distinguishing 𝑃𝜆 (V1 input) from 𝑃̂ (CSM output) is conceptually important. In V1, they are equal by construction, but 𝑃𝜆 is the a priori clinical declaration, while 𝑃̂ is the effective routing decision. D4 Naming aligned with theory. See structural correspondences compiled in Table 6. D5 output_type: alignment with type(𝑝𝑘 ) from Def. 24. Exactly three output types (Def. 24) are mapped in Table 7. The decisional output is always a distribution Δ((𝑘) ) with a class_distribution_delta_L_k object. The argmax is a separate derived field — never the primary value. A string like "NSCLC - Suspicion" in place of a distribution erases the formal structure and is inadmissible. D6 Exact cataloged values for 𝜎. The values of 𝜎 = (𝜌, 𝑢, 𝜅) are constrained by Defs. 5–7: • 𝜌 ∈ 𝖯𝗋𝗈𝗏: imaging/CT, imaging/MRI, imaging/PET, pathology/WSI, biology/panel, documentation/note, inference/AI
• 𝑢 ⊆ 𝖴𝗌𝗀 (non-empty): observation, diagnosis, procedure, medication • 𝜅 ∈ 𝖢𝖾𝗋𝗍: confirmed, suspected, inferred D7 SDR: mandatory source, targeted request (P5.3). Def. 34 defines two SDR variants: • Top-level SDR (csm_sdr): source = "CSM", no protocol_id field. Emitted when the CSM itself emits ⊥. • Protocol-level SDR (protocol_outputs[k].sdr): source ∈ {LCDM, LCRM}, protocol_id present. Emitted when a module emits ⊥ for 𝑝𝑘 . Property P5.3 requires that each SDR identifies the failed module and the specific deficiency. Generic requests are inadmissible. source is always present in both variants. D8 Algorithmic impermeability: model identities outside SIP. Property P3.1: implementations satisfying the same interface contract are interchangeable. Exposing "monai_unet_v1_lung" in the SIP creates a downstream dependency forbidden by theory. Model identities belong in the internal audit log, not in the SIP. D9 LCR-only case: lifting 𝜄 and medical signature of the source. When support(𝑝𝑘 ) = {LCR}, the lifting 𝜄 maps the confirmed historical entry to the LCDM-output type (Def. 31, Rmk. 4). Theory (29) states 𝜌𝐿𝐶𝐷 = inference/AI by default, but this default assumes that the AI module produced the entry. Lifting bypasses the AI module by definition: the medical signature of the Page 16 of 21
Table 6 Naming Aligned with Theory JSON Field
Theoretical Correspondence
Definition
activation_set_P_hat v1_param_P_lambda v2_threshold_tau v2_per_protocol_scores sigma
𝑃̂ ⊆ 𝑃𝜆 𝜏 ℎ(𝑒)𝑘 𝜎 = (𝜌, 𝑢, 𝜅) 𝑦̃(𝑘) / 𝑦̃(𝑘) 𝐿𝐶𝐷 𝐿𝐶𝑅 support(𝑝𝑘 ) acquisition index 𝑗 history cardinality canonical lifting 𝜄
Def. 14, 23 Def. 16 Def. 22 Def. 22 Def. 8 Def. 29, 31 Def. 27 Def. 3 Def. 3, 4 Def. 31, Rmk. 4
y_LCD / y_LCR support entry_refs[j].j T lifting_note
Table 7 Alignment with type(𝑝𝑘 ) JSON Value
CorrespondenceComponents
"structural"
𝑠𝑡𝑟𝑢𝑐𝑡
"decisional"
𝑑𝑒𝑐
"structural_x_decisional"𝑠𝑡𝑟𝑢𝑐𝑡 × 𝑑𝑒𝑐
structural N.null decisional null structural null decisional N.null
both N.null
reference is not a component of type(𝑝𝑘 ) and does not appear in the declared type of the protocol—it is a provenance metadata of the output, attached alongside the typed signal. D12 ⊥ vs CODE_FAIL. ⊥ is reserved exclusively for inputs in (𝑘) (Def. 25). An inferential failure on a valid input ⊥
(outside (𝑘) ) does not produce ⊥ and does not generate ⊥ an SDR. It returns: • status: "SUCCESS"
lifted entry inherits from the confirmed source, not from inference/AI. D9 implements the lifting exception already stated in Def. 29 and Def. 31: in the canonical lifting case, 𝜌𝐿𝐶𝐷 is inherited from the confirmed source entry rather than assigned as inference/AI. The JSON makes this explicit: status: "LIFTED" + sigma_LCD inherited from the source + explicit lifting_note field. This pattern is FHIRaligned (the source DiagnosticReport resource can be referenced directly). D10 CSM SDR vs protocol SDR: two structural levels. • CSM failure: protocol_outputs is empty (no module was invoked), top-level csm_sdr field is present. • Module failure (LCDM or LCRM): the SDR is in protocol_outputs[k].sdr. Other protocols continue normally (Def. 34: "The SDR does not terminate the pipeline for other activated protocols.") • lcrm_output: null (absent from support) ≠ lcrm_output.status: "HALTED" (invoked but failed). The distinction is semantically important for FHIR translation. D11 Output lineage: reference from output to 𝐷𝑜𝑢𝑡 input. A structural output component can carry a lineage reference to an entry in input_provenance.entry_refs via its acquisition index 𝑗. This reference identifies the entry that serves as the baseline for the derived component (e.g., temporal derivative relative to the baseline input 𝑗). This mechanism is symmetric to D2: pointer by acquisition index, never content inclusion. The lineage G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
• class_distribution_delta_L_k with total mass on CODE_FAIL(𝑘) — class declared a priori in class_catalog_L_k
• sdr: null A downstream consumer distinguishes CODE_FAIL from a valid output by the membership of argmax_class in the failure codes declared in the specification of protocol 𝑝𝑘 .
Appendix H. SIP Cases The concrete instantiations of these validation rules across the eight canonical execution paths (Case 1 to Case 8) are summarized in Table 8 ; files can be found in the code repository <...> ; scenarios are detailed below. Case 1 Lung, CT + clinical note, comparison with baseline (𝑇 = 3). V1 activated by the clinician. LCDM and LCRM succeed. Output type = structural × decisional for LCDM, decisional for LCRM. Case 2 Thoracic CT with mediastinal adenopathies. V2 activates two protocols above 𝜏 = 0.70. lymphoma_pipeline is support={LCD} (diagnosis only). Case 3 Insufficient data (clinical note only), no V2 protocol exceeds 𝜏. CSM emits ⊥. No downstream module invoked. Case 4 V1 activated, CSM succeeds. LCDM breast_pipeline emits ⊥: 𝑇 = 1, no prior MRI baseline to calculate the temporal derivatives required by the protocol. LCRM not invoked (its precondition — valid LCDM output — is not met). Page 17 of 21
{
" temporal_derivative ": { " baseline_entry_ref_j ": " <int >", " delta_fields ": { /* free fields */ } } | null } | null , " decisional ": { " class_catalog_L_k ": [" < label >"], " class_distribution_delta_L_k ": { " < label >": " < float >" }, " argmax_class ": " < label >", " argmax_code_hint ": " < string >" | null } | null
// --- Header --" sip_version ": " < string >", " run_id ": " <uuid >", " timestamp_utc ": " < ISO8601 >", // --- Input provenance ( D_out by reference , see D2 ) --" input_provenance ": { " patient_ref ": " < string >", "T": " < int >= 1>", " dpm_profile_id ": " < string >", " entry_refs ": [ { "j": " <int >", " external_id ": " < string >", " sigma ": { " rho ": " < Prov value >", "u": [" < Usg value >"], " kappa ": " < Cert value >" } } ] },
}, " sigma_LCD ": { " rho ": " < Prov value >", "u": [" < Usg value >"], " kappa ": " < Cert value >" }, " lifting_note ": " < string >" | null } | null , " interpretability ": { " grad_cam_ref ": " <uri >" | null , " attention_map_ref ": " <uri >" | null } | null } | null ,
// --- CSM execution ( Def . 23) --" csm_execution ": { " variant ": " V1 " | " V2 ", " activation_set_P_hat ": [" < protocol_id >"] | null , " status ": " ACTIVATED " | " HALTED ", " v1_param_P_lambda ": [" < protocol_id >"] | null , " v2_per_protocol_scores ": { " < protocol_id >": " < float [0 ,1] > " } | null , " v2_threshold_tau ": " < float (0 ,1) >" | null },
" lcrm_output ": { " status ": " SUCCESS " | " HALTED ", " characterized_entry ": { " y_LCR ": { " output_type ": " structural " | " decisional " | " structural_x_decisional ", " structural ": { /* same structure as y_LCD . structural */ } | null , " decisional ": { /* same structure as y_LCD . decisional */ } | null }, " sigma_LCR ": { " rho ": " inference / AI ", "u": [" < Usg value >"], " kappa ": " < Cert value >" } } | null } | null ,
// --- CSM - level SDR ( Def . 34) --" csm_sdr ": { " source ": " CSM ", " request ": { " description ": " < string >", " requested_data ": { /* targeted free fields */ } } } | null , // --- Outputs per activated protocol --" protocol_outputs ": [ { " protocol_id ": " < string >", " support ": [" LCD ", " LCR "] | [" LCD "] | [" LCR "], " lcdm_output ": { " status ": " SUCCESS " | " HALTED " | " LIFTED ", " characterized_entry ": { " y_LCD ": { " output_type ": " structural " | " decisional " | " structural_x_decisional ", " structural ": { " domain_type ": " < string >", " content_ref ": " <uri >" | null , " inline_scalar_features ": { /* named fields */ } | null ,
" sdr ": { " protocol_id ": " < string >", " source ": " LCDM " | " LCRM ", " request ": { " description ": " < string >", " requested_data ": { /* targeted free fields (P5.3) */ } } } | null } ], // --- LCWM narrative ( Def . 33( i)) --" lcwm_narrative ": " < string >" }
Figure 6: System JSON Output Representation
The distinction lcrm_output: null (not invoked) vs lcrm_output.status: "HALTED" (invoked but failed) is semantically important for FHIR: in the first case, no LCRM SDR Task is created.
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
Case 5 LCDM succeeds (NSCLC, 𝑃 = 0.61, 𝜅 = inferred). LCRM emits ⊥: the synthesis policy synth_k of the lung_rads_pipeline protocol only allows therapeutic routing if 𝜅 ≥ suspected; the LCDM entry with
Page 18 of 21
Table 8 Summary of Covered Cases (T1 Source Mapping) Case CSM Variant 1 2 3 4 5 6 7 8
Support
LCDM
LCRM
SDR
V1 {LCD, LCR} SUCCESS SUCCESS — V2 multi-proto {LCD, LCR} + {LCD} SUCCESS SUCCESS / null — V2 — not invoked not invoked CSM top-level V1 {LCD, LCR} HALTED null (not invoked) LCDM level V1 {LCD, LCR} SUCCESS HALTED LCRM level V1 {LCR} LIFTED (𝜄) SUCCESS — V1 {LCD, LCR} × 2 proto SUCCESS / HALTED SUCCESS / null LCDM level (proto 2) V1 {LCD, LCR} SUCCESS (CODE_FAIL) HALTED LCRM level
𝜅 = inferred is insufficient. The LCDM output remains valid in the bypass. Case 6 NSCLC confirmed by prior biopsy (𝑗 = 2, pathology/WSI, 𝜅 = confirmed). The clinician activates nsclc_treatment_pipeline (support={LCR}). The LCDM is bypassed; the lifting 𝜄 maps entry 𝑗 = 2 to the LCDM-output type (point-mass distribution, 𝜎 inherited from 𝑗 = 2, see D9). The LCRM produces a first-line recommendation. Case 7 V1 activates two protocols. lung_rads_pipeline: LCDM SUCCESS + LCRM SUCCESS. lymphoma_pipeline: LCDM HALTED (required mediastinal CT absent, 𝑇 = 1, only doc(lymphoma) ), umentation/note available — input in ⊥ LCRM not invoked. Both protocols coexist in protocol_outputs. Demonstrates Def. 34 nontermination clause and P3.2/P4.2. Case 8 V1, single protocol. The LCDM receives a valid input (not in (𝑘) ): the CT is present and well⊥ formed. Internal inference fails (e.g., model convergence failure). Per D12 and Def. 25 remark: no ⊥, no SDR. The LCDM returns status: "SUCCESS" with full probability mass on CODE_FAIL — a class declared a priori in class_catalog_L_k. The LCRM precondition (requires 𝜅 ∈ {confirmed, suspected}) is not met by a CODE_FAIL output (𝜅 = inferred): LCRM emits ⊥ and a protocol-level SDR is generated.
Appendix I. Proof-of-Concept Protocol and Detailed Results Environment. All scenarios use the deterministic variant
V1 on a single lung protocol. The diagnostic module is instantiated with declared reference stubs conforming to (lung) 𝐿𝐶𝐷 ; for S2 these are two independently labeled stub instances (Stub A, Stub B) emitting distinct simulated diagnostic content, without executing any underlying neural architecture. The remedy module follows the same design, declared as a rule-based stub (Lung-RADS-style criteria). Inputs are synthetic entries tagged with lung CT provenance (𝜌 = imaging/CT); the mock protocol 𝑝mock in S4 is a declared baseline diagnostic stub. The configuration isolates G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
orchestration behaviour and reports no classifier-level metric.
Metric definitions. • S1. completion rate: fraction of runs reaching the LCWM without ⊥; SIP schema valid: payload conforms to the schema of Appendix G; 𝜎𝐿𝐶𝐷 correct: emitted signature equals the protocol-declared diagnostic signature. • S2. 𝜋-equality: Boolean equality of the orchestrationstructural projection (activation set, routing, ⊥-set, schema) across the model pair; content difference: 𝑦̃𝐴 ≠ 𝑦̃𝐵 . 𝐿𝐶𝐷 𝐿𝐶𝐷 • S3 (module-level). SDR recall = (⊥ raised) ∧ (source correct) ∧ (SDR emitted) ∧ (¬ generic request). Both the corrupted-CT and missingmodality modes raise ⊥ at the diagnostic module, producing a protocol-level SDR with source = LCDM (consistent with Q1: under V1 the CSM is contentblind and never originates ⊥). • S3 (type invariant). For an empty history (𝑇 = 0) the input violates 𝑇 ≥ 1 (Def. 4) and is rejected at construction before any module runs. Recorded values: bottom_raised = true, bottom_source_correct = null (no module reached HALTED), sdr_emitted = false (a construction error is not a Def. 34 SDR), sdr_request_is_generic = null. This is a type-safety property, reported separately from SDR recall. • S4. branch independence: each activated protocol produces its outputs without reference to the other; composite schema valid: the multi-protocol payload conforms to the schema; cardinality: |protocol_outputs| = 𝐾 = 2.
Sample sizes and latency. 𝑁 = 10 for every scenario and
failure mode (S2: 10 model pairs). Latency is measured per module as wall-clock mean ± std over the 𝑁 = 10 S1 runs (Table 2); the orchestration-only cost (DPM, CSM, LCWM) is ≈ 0.04 ms. The sub-millisecond total is negligible relative to production inference times (102 –103 ms), which the lightweight reference components do not reproduce. Page 19 of 21
Multi-protocol latency projection. For 𝐾 activated pro-
tocols, the reference implementation of the PoC executes the LCDM/LCRM branches sequentially – an engineering choice of the current codebase, not a structural requirement of the framework: 𝑠𝑒𝑞 𝑇𝐿𝐶𝐴 = 𝑇𝐷𝑃 𝑀 + 𝑇𝐶𝑆𝑀 + 𝐾 ( ∑
) (𝑘) (𝑘) 𝑇𝐿𝐶𝐷𝑀 + 𝑇𝐿𝐶𝑅𝑀 + 𝑇𝐿𝐶𝑊 𝑀
(3)
𝑘=1
Because branch independence is established both formally (P3.2, P4.2) and empirically (S4, Table 3: 100% branch independence for 𝐾 = 2), concurrent execution across the 𝐾 branches is architecturally admissible and yields the lower bound: 𝑝𝑎𝑟 𝑇𝐿𝐶𝐴 = 𝑇𝐷𝑃 𝑀 + 𝑇𝐶𝑆𝑀 + ( ) (𝑘) (𝑘) max 𝑇𝐿𝐶𝐷𝑀 + 𝑇𝐿𝐶𝑅𝑀 + 𝑇𝐿𝐶𝑊 𝑀 𝑘=1,…,𝐾
(4)
𝑠𝑒𝑞 as measured for the singleThe present PoC reports 𝑇𝐿𝐶𝐴 𝑝𝑎𝑟 under concurprotocol case (Table 2); benchmarking 𝑇𝐿𝐶𝐴 rent execution across multiple activated protocols is left to future implementation work.
CRediT authorship contribution statement Ghassen MARRAKCHI: Conceptualization, Investigation, Methodology, Project administration, Resources, Software, Visualization, Formal analysis – original draft, Writing – original draft, Writing – review and editing.. Basarab MATEI: Supervision, Validation, Funding acquisition, Formal analysis – review and editing, Writing – review and editing..
Declarations Ethics approval and consent to participate This study used no real patient data. All Proof-ofConcept inputs were synthetically generated to exercise the orchestration pipeline’s structural and control-flow properties. No human subject data was collected, and no interventions were performed on human participants. Therefore, institutional review board (IRB) approval and explicit patient informed consent were not required for this theoretical and computational framework validation.
Data availability No external datasets were used in this study. All Proofof-Concept inputs were synthetically generated; the generation logic is included in the code repository referenced below.
Code availability To ensure complete reproducibility and support the algorithmic impermeability claim, the overarching orchestration code, the declared stubs, and the finalized Standardized Intermediate Payload (SIP) and Supplementary Data Request G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
(SDR) JSON schemas used during the Proof of Concept are publicly accessible. The repository can be found at: https: //github.com/MARRAKCHIGhassen/lca.
Declaration of Competing Interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
Funding This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.
Declaration of generative AI and AI-assisted technologies in the writing process During the preparation of this work the authors used Gemini By Google and Claude by Anthropic, in order to improve language readability, structure, and academic translation. After using this tool/service, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication.
References Bayor, A.A., Li, J., Yang, I.A., Varnfield, M., 2025. Designing clinical decision support systems (cdss)—a user-centered lens of the design characteristics, challenges, and implications: Systematic review. Journal of Medical Internet Research 27, e63733. Carbonaro, A., Giorgetti, L., Ridolfi, L., Pasolini, R., Pagliarani, A., Cavallucci, M., Andalò, A., Del Gaudio, L., De Angelis, P., Vespignani, R., et al., 2025. From raw data to research-ready: A fhir-based transformation pipeline in a real-world oncology setting. Computers in Biology and Medicine 197, 111051. Huser, V., Rasmussen, L.V., Oberg, R., Starren, J.B., 2011. Implementation of workflow engine technology to deliver basic clinical decision support functionality. BMC Medical Research Methodology 11, 43. URL: https://pubmed.ncbi.nlm.nih.gov/21477364/, doi:10.1186/ 1471-2288-11-43. Jung, S., Bae, S., Seong, D., Oh, O., Kim, Y., Yi, B., 2022. Shared interoperable clinical decision support service for drug-allergy interaction checks: Implementation study. JMIR Medical Informatics 10, e40338. URL: https://medinform.jmir.org/2022/11/e40338, doi:10.2196/40338. Lee, J., Kim, J., Cho, I., Kim, Y., 2010. Integration of workflow and rule engines for clinical decision support services. Studies in Health Technology and Informatics 160, 811–815. URL: https://pubmed.ncbi. nlm.nih.gov/20841798/. Lin, J., Deng, W., Wei, J., Zheng, J., Chen, K., Chai, H., Zeng, T., Tang, H., 2024. Gd-net: An integrated multimodal information model based on deep learning for cancer outcome prediction and informative feature selection. Journal of Cellular and Molecular Medicine 28, e70221. URL: https://doi.org/10.1111/jcmm.70221, doi:10.1111/jcmm.70221. López, L., Shamout, F.E., Rudner, T.G., 2026. An empirical analysis of calibration and selective prediction in multimodal clinical condition classification. arXiv preprint arXiv:2603.02719 . Niecikowski, A., Gupta, S., Suarez, G., Kim, J., Chen, H., Guo, F., Long, W., Deng, J., 2022. A multi-modal deep learning-based decision support system for individualized radiotherapy of non-small cell lung cancer. International Journal of Radiation Oncology Biology Physics 114, e100–e101. URL: https://doi.org/10.1016/j.ijrobp.2022.07.894, doi:10.1016/j.ijrobp.2022.07.894. aSTRO Annual 2022 Meeting. Wang, N., Lin, J., Li, W., Lyu, Y., Jiang, Y., Ni, Z., Huang, Q., Chen, H., Yan, Q., Huang, C., 2025. Deep multimodal state-space fusion of endoscopic-radiomic and clinical data for survival prediction in
Page 20 of 21
colorectal cancer. npj Digital Medicine 8, 801. URL: https://doi.org/ 10.1038/s41746-025-02236-3, doi:10.1038/s41746-025-02236-3. Wang, Z., Lin, R., Li, Y., Zeng, J., Chen, Y., Ouyang, W., Li, H., Jia, X., Lai, Z., Yu, Y., Yao, H., Su, W., 2024. Deep learning-based multimodal data integration enhancing breast cancer disease-free survival prediction. Precision Clinical Medicine 7, pbae012. URL: https: //doi.org/10.1093/pcmedi/pbae012, doi:10.1093/pcmedi/pbae012. Waqas, A., Tripathi, A., Ramachandran, R.P., Stewart, P.A., Rasool, G., 2024. Multimodal data integration for oncology in the era of deep neural networks: a review. Frontiers in Artificial Intelligence 7, 1408843. URL: https://doi.org/10.3389/frai.2024.1408843, doi:10. 3389/frai.2024.1408843. Xiang, J., Wang, X., Zhang, X., Xi, Y., Eweje, F., Chen, Y., Li, Y., Bergstrom, C., Gopaulchan, M., Kim, T., Yu, K., Willens, S., Olguin, F.M., Nirschl, J.J., Neal, J., Diehn, M., Yang, S., Li, R., 2025. A vision– language foundation model for precision oncology. Nature 638, 769– 778. URL: https://doi.org/10.1038/s41586-024-08378-w, doi:10.1038/ s41586-024-08378-w. Yang, H., Yang, M., Chen, J., Yao, G., Zou, Q., Jia, L., 2025. Multimodal deep learning approaches for precision oncology: a comprehensive review. Briefings in Bioinformatics 26, bbae699. URL: https://doi. org/10.1093/bib/bbae699, doi:10.1093/bib/bbae699. Zhang, B., Wan, Z., Luo, Y., Zhao, X., Samayoa, J., Zhao, W., Wu, S., 2025. Multimodal integration strategies for clinical application in oncology. Frontiers in Pharmacology 16, 1609079. URL: https://doi.org/10. 3389/fphar.2025.1609079, doi:10.3389/fphar.2025.1609079.
G. MARRAKCHI, B. MATEI.: Preprint submitted to Elsevier
Page 21 of 21