Render architecture diagrams as SVG (hub-visible); refresh EN/ES/IT

README.md

@@ -1,10 +1,6 @@
 ---
 license: other
-tags:
-- molly-os
-- whitepaper
-- preprint
-- orchestration
+tags: [molly-os, whitepaper, preprint, orchestration]
 ---
 
 # Molly OS — Whitepaper / Preprint
@@ -14,17 +10,15 @@ tags:
 *Molly OS: A Model-Agnostic Inference Orchestration Layer for On-Device and Federated Inference.*
 
 A sovereign orchestration layer that routes each request across heterogeneous execution
-targets (on-device, LAN, cloud, external API), serves many domain-specialist LoRA adapters
-over a shared quantized base, enforces on-device-first data sovereignty, and continuously
-specializes via distillation. Evaluation across ~100 domains (neutral LLM judge, 115-panel
-probe) shows orchestration improves output quality over the unspecialized base.
+targets, serves many domain-specialist LoRA adapters over a shared quantized base,
+enforces on-device-first data sovereignty, and continuously specializes via distillation.
 
 ## Documents
-- English: `molly_os_whitepaper_en.md` / `molly_os_whitepaper_en.html`
-- Español: `molly_os_whitepaper_es.md` / `molly_os_whitepaper_es.html`
-- Italiano: `molly_os_whitepaper_it.md` / `molly_os_whitepaper_it.html`
+- English: `molly_os_whitepaper_en.md` / `.html`
+- Espanol: `molly_os_whitepaper_es.md` / `.html`
+- Italiano: `molly_os_whitepaper_it.md` / `.html`
 
-References (69) are verified against the arXiv API, with official venue links for the
-two non-arXiv works.
+Architecture figures are rendered as SVG (`fig_1.svg` ... `fig_5.svg`). References (69) are
+verified against the arXiv API, with official venue links for the two non-arXiv works.
 
-(c) 2026 Core Labs R&D. Private preprint — please do not redistribute.
+(c) 2026 Core Labs R&D. Private preprint - please do not redistribute.

molly_os_whitepaper_en.md

@@ -60,28 +60,7 @@ Molly OS sits between applications and a heterogeneous pool of execution targets
 
 Supporting subsystems include the adapter registry (Section 7), the policy engine (Section 8), the trace store and specialization pipeline (Section 9), and multimodal backends (Section 10). Retrieval [38, 40] and tool execution [43, 44] are mediated by the same layer so that retrieval corpora and tool I/O obey the same residency rules as model inputs.
 
-```mermaid
-flowchart TD
-    APP[Applications / Clients] --> GW[Unified Inference Interface]
-    GW --> CLS[Capability + Sensitivity Classifier]
-    CLS --> RT[Router]
-    POL[Sovereignty Policy Engine] --> RT
-    REG[Adapter Registry] --> RT
-    RT --> T0[T0: On-Device Model + Adapters]
-    RT --> T1[T1: LAN Model Server]
-    RT --> T2[T2: Self-Hosted Remote Model]
-    RT --> T3[T3: External API - policy gated]
-    T0 --> AGG[Response Aggregator / Verifier]
-    T1 --> AGG
-    T2 --> AGG
-    T3 --> AGG
-    AGG --> GW
-    AGG --> TRC[Trace Store]
-    TRC --> SPC[Specialization Pipeline]
-    SPC --> REG
-    RAGS[Retrieval Store] --- RT
-    TOOLS[Tool Executor] --- RT
-```
+![Figure 1](fig_1.svg)
 
 **Figure 1.** Molly OS architecture. All requests pass through a single interface; the router selects among four target tiers under sovereignty policy; traces feed a specialization pipeline that produces new adapters.
 
@@ -97,26 +76,7 @@ The router solves, per request, a constrained selection problem: choose the targ
 
 **Speculative cooperation.** When a request lands on T1, the T0 model can serve as a draft model for speculative decoding [30, 31, 33], so the placement hierarchy doubles as an acceleration hierarchy.
 
-```mermaid
-flowchart TD
-    REQ[Incoming Request] --> SENS{Sensitivity class?}
-    SENS -->|Private| LOCK[Tier set = T0, T1]
-    SENS -->|Standard| OPEN[Tier set = T0..T3]
-    LOCK --> CAP[Capability + Difficulty Estimate]
-    OPEN --> CAP
-    CAP --> AD{Specialist adapter available?}
-    AD -->|Yes| LOCAL[Attempt T0 with adapter]
-    AD -->|No| EST[Score permitted targets]
-    EST --> PICK[Select max expected quality s.t. latency and cost]
-    LOCAL --> CONF{Confidence above threshold?}
-    PICK --> EXEC[Execute on selected target]
-    EXEC --> CONF
-    CONF -->|Yes| OUT[Return response]
-    CONF -->|No| ESC{Higher tier permitted?}
-    ESC -->|Yes| UP[Escalate to next tier]
-    UP --> EXEC
-    ESC -->|No| BEST[Return best local response with caveat]
-```
+![Figure 2](fig_2.svg)
 
 **Figure 2.** Routing and cascade flow. Sensitivity classification restricts the permitted tier set before capability-based selection; low-confidence outputs escalate only within the permitted set.
 
@@ -132,31 +92,7 @@ A central design choice is that *specialization is cheaper than scale at the edg
 
 **Adapter portability.** Adapters are versioned against base-model checkpoints and quantization configurations, so an adapter trained on a T1 host can be redistributed to T0 devices sharing the same base — this portability underpins the federated mechanism of Section 8.
 
-```mermaid
-flowchart LR
-    subgraph SRV[Adapter-Augmented Serving Engine]
-        BASE[Shared Quantized Base Model]
-        SCHED[Iteration-Level Scheduler]
-        POOL[Unified Paged Memory: KV cache + adapter pages]
-        K[Batched LoRA Kernels]
-        SCHED --> BASE
-        BASE --> K
-        POOL --- BASE
-        POOL --- K
-    end
-    R1[Request A: legal adapter] --> SCHED
-    R2[Request B: medical adapter] --> SCHED
-    R3[Request C: code adapter] --> SCHED
-    subgraph REG[Adapter Registry]
-        HOT[Hot: device memory]
-        WARM[Warm: host memory]
-        COLD[Cold: storage]
-        COLD -->|on-demand load| WARM
-        WARM -->|promote| HOT
-        HOT -->|evict| WARM
-    end
-    HOT --> POOL
-```
+![Figure 3](fig_3.svg)
 
 **Figure 3.** Concurrent specialist serving. One shared base model serves heterogeneous adapter requests in the same batch; adapters migrate between hot, warm, and cold states under a cost-aware policy.
 
@@ -176,20 +112,7 @@ Many requests presented to the orchestration layer are not single-shot completio
 
 We evaluate orchestration on standard agent benchmarks and harnesses, including general agentic evaluation [62], realistic web environments [63], repository-level software tasks [64], and tool-augmented API use [65], quantifying the quality gain over the single-specialist baseline and the added latency overhead is part of ongoing measurement.
 
-```mermaid
-flowchart TD
-    R[Request] --> C[Controller: triage + delegation plan]
-    G[Policy / Budget Gate] --> C
-    C --> S1[Specialist A: base + domain adapter]
-    C --> S2[Specialist B: base + domain adapter]
-    C --> S3[Specialist C: base + domain adapter]
-    S1 --> F[Fusion: confidence-weighted ranking]
-    S2 --> F
-    S3 --> F
-    F --> M[Meta-cognition: consistency check]
-    M -- refine --> C
-    M -- accept --> O[Response]
-```
+![Figure 4](fig_4.svg)
 
 **Figure 5.** Agent orchestration. The controller emits a delegation plan under an explicit policy/budget gate; domain specialists execute in parallel on the least-exposed permitted tier; fusion ranks and integrates outputs; meta-cognition validates consistency and may trigger bounded refinement.
 
@@ -203,30 +126,7 @@ Self-custody holds across the entire heterogeneous-OS cluster: data, adapters, a
 
 **Federated improvement.** Devices improve collectively without centralizing raw data, following federated principles [23, 24]. The unit of exchange is the *adapter delta*: a participant trains or refines a specialist adapter locally (Section 9), and only the low-rank parameters — optionally with privacy-preserving noise consistent with established federated practice [24] — are shared with an aggregation point, which may itself be a LAN host. Because adapters are orders of magnitude smaller than base models, communication cost is modest, echoing the communication-efficiency motivation of federated averaging [23]. Aggregated adapters are redistributed through the registry with version pinning.
 
-```mermaid
-flowchart TD
-    subgraph DEV[On-Device Tier T0]
-        P1[Phone: SLM + adapters]
-        P2[Laptop: SLM + adapters]
-        DATA[(Raw user data - never leaves tier)]
-        P1 --- DATA
-        P2 --- DATA
-    end
-    subgraph LAN[Local Network Tier T1]
-        HUB[LAN Model Server + Adapter Aggregator]
-    end
-    subgraph REM[Remote Tiers]
-        T2N[T2: Self-Hosted Model]
-        T3N[T3: External API]
-    end
-    P1 -->|adapter deltas only| HUB
-    P2 -->|adapter deltas only| HUB
-    HUB -->|aggregated adapters| P1
-    HUB -->|aggregated adapters| P2
-    P1 -.->|policy-gated, redacted requests| T3N
-    HUB -->|escalated inference| T2N
-    HUB -.->|policy-gated, redacted| T3N
-```
+![Figure 5](fig_5.svg)
 
 **Figure 4.** Federated topology. Raw data remains in the on-device tier; only adapter deltas cross tiers for improvement, and only redacted, policy-gated requests reach external APIs.
 

molly_os_whitepaper_es.md

@@ -60,28 +60,7 @@ Molly OS se sitúa entre las aplicaciones y un conjunto heterogéneo de objetivo
 
 Los subsistemas de soporte incluyen el registro de adaptadores (Sección 7), el motor de políticas (Sección 8), el almacén de trazas y el pipeline de especialización (Sección 9), y los backends multimodales (Sección 10). La recuperación [38, 40] y la ejecución de herramientas [43, 44] están mediadas por la misma capa, de modo que los corpus de recuperación y la E/S de herramientas obedecen las mismas reglas de residencia que las entradas de los modelos.
 
-```mermaid
-flowchart TD
-    APP[Applications / Clients] --> GW[Unified Inference Interface]
-    GW --> CLS[Capability + Sensitivity Classifier]
-    CLS --> RT[Router]
-    POL[Sovereignty Policy Engine] --> RT
-    REG[Adapter Registry] --> RT
-    RT --> T0[T0: On-Device Model + Adapters]
-    RT --> T1[T1: LAN Model Server]
-    RT --> T2[T2: Self-Hosted Remote Model]
-    RT --> T3[T3: External API - policy gated]
-    T0 --> AGG[Response Aggregator / Verifier]
-    T1 --> AGG
-    T2 --> AGG
-    T3 --> AGG
-    AGG --> GW
-    AGG --> TRC[Trace Store]
-    TRC --> SPC[Specialization Pipeline]
-    SPC --> REG
-    RAGS[Retrieval Store] --- RT
-    TOOLS[Tool Executor] --- RT
-```
+![Figure 1](fig_1.svg)
 
 **Figura 1.** Arquitectura de Molly OS. Todas las solicitudes pasan por una única interfaz; el enrutador selecciona entre cuatro niveles de objetivo bajo la política de soberanía; las trazas alimentan un pipeline de especialización que produce nuevos adaptadores.
 
@@ -97,26 +76,7 @@ El enrutador resuelve, por solicitud, un problema de selección con restriccione
 
 **Cooperación especulativa.** Cuando una solicitud aterriza en T1, el modelo T0 puede servir como modelo de borrador para decodificación especulativa [30, 31, 33], de modo que la jerarquía de ubicación funciona también como jerarquía de aceleración.
 
-```mermaid
-flowchart TD
-    REQ[Incoming Request] --> SENS{Sensitivity class?}
-    SENS -->|Private| LOCK[Tier set = T0, T1]
-    SENS -->|Standard| OPEN[Tier set = T0..T3]
-    LOCK --> CAP[Capability + Difficulty Estimate]
-    OPEN --> CAP
-    CAP --> AD{Specialist adapter available?}
-    AD -->|Yes| LOCAL[Attempt T0 with adapter]
-    AD -->|No| EST[Score permitted targets]
-    EST --> PICK[Select max expected quality s.t. latency and cost]
-    LOCAL --> CONF{Confidence above threshold?}
-    PICK --> EXEC[Execute on selected target]
-    EXEC --> CONF
-    CONF -->|Yes| OUT[Return response]
-    CONF -->|No| ESC{Higher tier permitted?}
-    ESC -->|Yes| UP[Escalate to next tier]
-    UP --> EXEC
-    ESC -->|No| BEST[Return best local response with caveat]
-```
+![Figure 2](fig_2.svg)
 
 **Figura 2.** Flujo de enrutamiento y cascada. La clasificación de sensibilidad restringe el conjunto de niveles permitido antes de la selección basada en capacidades; las salidas de baja confianza escalan solo dentro del conjunto permitido.
 
@@ -132,31 +92,7 @@ Una decisión de diseño central es que *la especialización es más barata que
 
 **Portabilidad de adaptadores.** Los adaptadores se versionan contra checkpoints del modelo base y configuraciones de cuantización, de modo que un adaptador entrenado en un host T1 puede redistribuirse a dispositivos T0 que compartan la misma base — esta portabilidad sustenta el mecanismo federado de la Sección 8.
 
-```mermaid
-flowchart LR
-    subgraph SRV[Adapter-Augmented Serving Engine]
-        BASE[Shared Quantized Base Model]
-        SCHED[Iteration-Level Scheduler]
-        POOL[Unified Paged Memory: KV cache + adapter pages]
-        K[Batched LoRA Kernels]
-        SCHED --> BASE
-        BASE --> K
-        POOL --- BASE
-        POOL --- K
-    end
-    R1[Request A: legal adapter] --> SCHED
-    R2[Request B: medical adapter] --> SCHED
-    R3[Request C: code adapter] --> SCHED
-    subgraph REG[Adapter Registry]
-        HOT[Hot: device memory]
-        WARM[Warm: host memory]
-        COLD[Cold: storage]
-        COLD -->|on-demand load| WARM
-        WARM -->|promote| HOT
-        HOT -->|evict| WARM
-    end
-    HOT --> POOL
-```
+![Figure 3](fig_3.svg)
 
 **Figura 3.** Servicio concurrente de especialistas. Un modelo base compartido sirve solicitudes heterogéneas de adaptadores en el mismo lote; los adaptadores migran entre los estados caliente, templado y frío bajo una política consciente del costo.
 
@@ -176,20 +112,7 @@ Muchas solicitudes presentadas a la capa de orquestación no son completaciones
 
 Evaluamos la orquestación en benchmarks y harnesses estándar de agentes, incluyendo evaluación agéntica general [62], entornos web realistas [63], tareas de software a nivel de repositorio [64] y uso de APIs aumentado con herramientas [65]; cuantificar la ganancia de calidad sobre la línea base de especialista único y la sobrecarga de latencia añadida es parte de la medición en curso.
 
-```mermaid
-flowchart TD
-    R[Request] --> C[Controller: triage + delegation plan]
-    G[Policy / Budget Gate] --> C
-    C --> S1[Specialist A: base + domain adapter]
-    C --> S2[Specialist B: base + domain adapter]
-    C --> S3[Specialist C: base + domain adapter]
-    S1 --> F[Fusion: confidence-weighted ranking]
-    S2 --> F
-    S3 --> F
-    F --> M[Meta-cognition: consistency check]
-    M -- refine --> C
-    M -- accept --> O[Response]
-```
+![Figure 4](fig_4.svg)
 
 **Figura 5.** Orquestación de agentes. El controlador emite un plan de delegación bajo una puerta explícita de política/presupuesto; los especialistas de dominio se ejecutan en paralelo en el nivel menos expuesto permitido; la fusión clasifica e integra las salidas; la metacognición valida la consistencia y puede desencadenar un refinamiento acotado.
 
@@ -203,30 +126,7 @@ La autocustodia se mantiene en todo el clúster de SO heterogéneo: los datos, l
 
 **Mejora federada.** Los dispositivos mejoran colectivamente sin centralizar datos en bruto, siguiendo principios federados [23, 24]. La unidad de intercambio es el *delta de adaptador*: un participante entrena o refina un adaptador especialista localmente (Sección 9), y solo los parámetros de bajo rango — opcionalmente con ruido para preservación de privacidad consistente con la práctica federada establecida [24] — se comparten con un punto de agregación, que puede ser él mismo un host LAN. Dado que los adaptadores son órdenes de magnitud más pequeños que los modelos base, el costo de comunicación es modesto, haciendo eco de la motivación de eficiencia de comunicación del promediado federado [23]. Los adaptadores agregados se redistribuyen a través del registro con fijación de versiones.
 
-```mermaid
-flowchart TD
-    subgraph DEV[On-Device Tier T0]
-        P1[Phone: SLM + adapters]
-        P2[Laptop: SLM + adapters]
-        DATA[(Raw user data - never leaves tier)]
-        P1 --- DATA
-        P2 --- DATA
-    end
-    subgraph LAN[Local Network Tier T1]
-        HUB[LAN Model Server + Adapter Aggregator]
-    end
-    subgraph REM[Remote Tiers]
-        T2N[T2: Self-Hosted Model]
-        T3N[T3: External API]
-    end
-    P1 -->|adapter deltas only| HUB
-    P2 -->|adapter deltas only| HUB
-    HUB -->|aggregated adapters| P1
-    HUB -->|aggregated adapters| P2
-    P1 -.->|policy-gated, redacted requests| T3N
-    HUB -->|escalated inference| T2N
-    HUB -.->|policy-gated, redacted| T3N
-```
+![Figure 5](fig_5.svg)
 
 **Figura 4.** Topología federada. Los datos en bruto permanecen en el nivel en dispositivo; solo los deltas de adaptadores cruzan los niveles para la mejora, y solo las solicitudes redactadas y autorizadas por la política alcanzan las APIs externas.
 

molly_os_whitepaper_it.md

@@ -60,28 +60,7 @@ Molly OS si colloca tra le applicazioni e un pool eterogeneo di target di esecuz
 
 I sottosistemi di supporto includono il registro degli adapter (Sezione 7), il motore delle politiche (Sezione 8), l'archivio delle tracce e la pipeline di specializzazione (Sezione 9) e i backend multimodali (Sezione 10). Il retrieval [38, 40] e l'esecuzione degli strumenti [43, 44] sono mediati dallo stesso livello, in modo che i corpora di retrieval e l'I/O degli strumenti rispettino le stesse regole di residenza degli input dei modelli.
 
-```mermaid
-flowchart TD
-    APP[Applications / Clients] --> GW[Unified Inference Interface]
-    GW --> CLS[Capability + Sensitivity Classifier]
-    CLS --> RT[Router]
-    POL[Sovereignty Policy Engine] --> RT
-    REG[Adapter Registry] --> RT
-    RT --> T0[T0: On-Device Model + Adapters]
-    RT --> T1[T1: LAN Model Server]
-    RT --> T2[T2: Self-Hosted Remote Model]
-    RT --> T3[T3: External API - policy gated]
-    T0 --> AGG[Response Aggregator / Verifier]
-    T1 --> AGG
-    T2 --> AGG
-    T3 --> AGG
-    AGG --> GW
-    AGG --> TRC[Trace Store]
-    TRC --> SPC[Specialization Pipeline]
-    SPC --> REG
-    RAGS[Retrieval Store] --- RT
-    TOOLS[Tool Executor] --- RT
-```
+![Figure 1](fig_1.svg)
 
 **Figura 1.** Architettura di Molly OS. Tutte le richieste passano attraverso un'unica interfaccia; il router seleziona tra quattro livelli di target secondo la politica di sovranità; le tracce alimentano una pipeline di specializzazione che produce nuovi adapter.
 
@@ -97,26 +76,7 @@ Il router risolve, per ogni richiesta, un problema di selezione vincolata: scegl
 
 **Cooperazione speculativa.** Quando una richiesta approda su T1, il modello T0 può fungere da modello di bozza per la decodifica speculativa [30, 31, 33], cosicché la gerarchia di posizionamento funge anche da gerarchia di accelerazione.
 
-```mermaid
-flowchart TD
-    REQ[Incoming Request] --> SENS{Sensitivity class?}
-    SENS -->|Private| LOCK[Tier set = T0, T1]
-    SENS -->|Standard| OPEN[Tier set = T0..T3]
-    LOCK --> CAP[Capability + Difficulty Estimate]
-    OPEN --> CAP
-    CAP --> AD{Specialist adapter available?}
-    AD -->|Yes| LOCAL[Attempt T0 with adapter]
-    AD -->|No| EST[Score permitted targets]
-    EST --> PICK[Select max expected quality s.t. latency and cost]
-    LOCAL --> CONF{Confidence above threshold?}
-    PICK --> EXEC[Execute on selected target]
-    EXEC --> CONF
-    CONF -->|Yes| OUT[Return response]
-    CONF -->|No| ESC{Higher tier permitted?}
-    ESC -->|Yes| UP[Escalate to next tier]
-    UP --> EXEC
-    ESC -->|No| BEST[Return best local response with caveat]
-```
+![Figure 2](fig_2.svg)
 
 **Figura 2.** Flusso di instradamento e cascata. La classificazione della sensibilità restringe l'insieme di livelli consentito prima della selezione basata sulle capacità; gli output a bassa confidenza fanno escalation solo all'interno dell'insieme consentito.
 
@@ -132,31 +92,7 @@ Una scelta progettuale centrale è che *la specializzazione è più economica de
 
 **Portabilità degli adapter.** Gli adapter sono versionati rispetto ai checkpoint del modello base e alle configurazioni di quantizzazione, cosicché un adapter addestrato su un host T1 può essere ridistribuito a dispositivi T0 che condividono la stessa base — questa portabilità è alla base del meccanismo federato della Sezione 8.
 
-```mermaid
-flowchart LR
-    subgraph SRV[Adapter-Augmented Serving Engine]
-        BASE[Shared Quantized Base Model]
-        SCHED[Iteration-Level Scheduler]
-        POOL[Unified Paged Memory: KV cache + adapter pages]
-        K[Batched LoRA Kernels]
-        SCHED --> BASE
-        BASE --> K
-        POOL --- BASE
-        POOL --- K
-    end
-    R1[Request A: legal adapter] --> SCHED
-    R2[Request B: medical adapter] --> SCHED
-    R3[Request C: code adapter] --> SCHED
-    subgraph REG[Adapter Registry]
-        HOT[Hot: device memory]
-        WARM[Warm: host memory]
-        COLD[Cold: storage]
-        COLD -->|on-demand load| WARM
-        WARM -->|promote| HOT
-        HOT -->|evict| WARM
-    end
-    HOT --> POOL
-```
+![Figure 3](fig_3.svg)
 
 **Figura 3.** Serving specialistico concorrente. Un unico modello base condiviso serve richieste di adapter eterogenee nello stesso batch; gli adapter migrano tra stati hot, warm e cold secondo una politica consapevole dei costi.
 
@@ -176,20 +112,7 @@ Molte richieste presentate al livello di orchestrazione non sono completamenti s
 
 Valutiamo l'orchestrazione su benchmark e harness agentici standard, inclusa la valutazione agentica generale [62], ambienti web realistici [63], compiti software a livello di repository [64] e l'uso di API aumentato da strumenti [65]; la quantificazione del guadagno di qualità rispetto al baseline a singolo specialista e dell'overhead di latenza aggiunto fa parte delle misurazioni in corso.
 
-```mermaid
-flowchart TD
-    R[Request] --> C[Controller: triage + delegation plan]
-    G[Policy / Budget Gate] --> C
-    C --> S1[Specialist A: base + domain adapter]
-    C --> S2[Specialist B: base + domain adapter]
-    C --> S3[Specialist C: base + domain adapter]
-    S1 --> F[Fusion: confidence-weighted ranking]
-    S2 --> F
-    S3 --> F
-    F --> M[Meta-cognition: consistency check]
-    M -- refine --> C
-    M -- accept --> O[Response]
-```
+![Figure 4](fig_4.svg)
 
 **Figura 5.** Orchestrazione di agenti. Il controller emette un piano di delega sotto un gate esplicito di politica/budget; gli specialisti di dominio vengono eseguiti in parallelo sul livello consentito meno esposto; la fusione classifica e integra gli output; la meta-cognizione valida la coerenza e può innescare un raffinamento limitato.
 
@@ -203,30 +126,7 @@ La self-custody vale sull'intero cluster a OS eterogeneo: dati, adapter ed embed
 
 **Miglioramento federato.** I dispositivi migliorano collettivamente senza centralizzare i dati grezzi, seguendo i principi federati [23, 24]. L'unità di scambio è il *delta dell'adapter*: un partecipante addestra o raffina localmente un adapter specialistico (Sezione 9), e solo i parametri a basso rango — opzionalmente con rumore a tutela della privacy coerente con la pratica federata consolidata [24] — sono condivisi con un punto di aggregazione, che può a sua volta essere un host LAN. Poiché gli adapter sono di ordini di grandezza più piccoli dei modelli base, il costo di comunicazione è modesto, riecheggiando la motivazione di efficienza comunicativa del federated averaging [23]. Gli adapter aggregati sono ridistribuiti tramite il registro con il pinning della versione.
 
-```mermaid
-flowchart TD
-    subgraph DEV[On-Device Tier T0]
-        P1[Phone: SLM + adapters]
-        P2[Laptop: SLM + adapters]
-        DATA[(Raw user data - never leaves tier)]
-        P1 --- DATA
-        P2 --- DATA
-    end
-    subgraph LAN[Local Network Tier T1]
-        HUB[LAN Model Server + Adapter Aggregator]
-    end
-    subgraph REM[Remote Tiers]
-        T2N[T2: Self-Hosted Model]
-        T3N[T3: External API]
-    end
-    P1 -->|adapter deltas only| HUB
-    P2 -->|adapter deltas only| HUB
-    HUB -->|aggregated adapters| P1
-    HUB -->|aggregated adapters| P2
-    P1 -.->|policy-gated, redacted requests| T3N
-    HUB -->|escalated inference| T2N
-    HUB -.->|policy-gated, redacted| T3N
-```
+![Figure 5](fig_5.svg)
 
 **Figura 4.** Topologia federata. I dati grezzi rimangono nel livello on-device; solo i delta degli adapter attraversano i livelli per il miglioramento, e solo richieste redatte e soggette a politica raggiungono le API esterne.