Una rappresentazione deterministica dell'impresa.

Connettori firmati conformi ai protocolli pubblicati dei sistemi origine (OAuth2 per Microsoft 365 / Google Workspace, API REST per Zucchetti TeamSystem SAP B1, WhatsApp Business Cloud API, IMAP IDLE per posta). Ogni connettore eredita le ACL del sistema d'origine: Lemnia non vede mai dati che l'utente sorgente non vedrebbe.

Le credenziali sono custodite in keychain di sistema (Keychain Access su macOS, Credential Manager su Windows). Mai persistite in chiaro su disco applicativo. Refresh token ruotati ogni 24h. CST.375

Ingestione streaming per i sistemi che supportano webhook + IMAP IDLE; batch polling per gli altri (intervallo configurabile, default 5 min). Sub-5min p95 dal segnale alla visibilità nel dossier. CST.269

Cifratura at-rest AES-256-GCM con DEK per-tenant, KEK custodito da Keychain. Pseudonimizzazione opzionale dei PII durante l'ingestione per categorie configurate dal DPO.

NER + RE addestrati su corpus italiano (medico + business + tributario). Backbone Qwen3.5-4B Q4 per intent comprehension, mDeBERTa-v3-base-italian-NLI per consistency check. CST.333

Disambiguazione via embedding Qwen3-Embedding-0.6B su contesto locale, con fallback su HITL (human-in-the-loop) modal per i casi con confidence < 0.7. Le decisioni di disambiguazione diventano dati di training continuo per il tenant.

Riferimenti SOTA: LightRAG (HKU EMNLP 2025) per estrazione duale entità+relazione su KG locale; HippoRAG 2 per ranking via PageRank personalizzato sul grafo.

Schema dual-node: Entity (cliente, fornitore, prodotto, pratica) + Source (documento, email, riga di registro). Ogni arco di tipo SUPPORTS collega un fact a una source con range char-level (offset_start, offset_end) e hash BLAKE3 del contenuto sorgente. CST.30

Storage backend: SQLite con sqlite-vec 0.1.9 per embeddings, rusqlite per tabelle relazionali, RocksDB per il blob store dei documenti originali. Append-only log con sigillo BLAKE3 per ogni transazione, esportabile come prova per audit Art. 30 GDPR.

Community detection: algoritmo Leiden per cluster analysis su entità frequentemente co-occorrenti. Refresh PageRank batched, configurabile per dimensione del grafo. CST.129

Pipeline ibrida BM25 + densi: query parsing → seed nodes via embedding similarity → multi-hop traversal con PPR weighting → cross-encoder reranking (mDeBERTa). Cap di profondità: 3 hop default biz, 2 medico. Cap di tempo: 8s totali, fallback a top-3 evidence se timeout.CST.389

Multi-entity seed weighting: ogni seed pesato per (confidence, PageRank_prior, freshness). La query passa per un classifier deterministico di route (FetchTimeline | FetchMultiHopChain | FetchAggregate | FetchSummary). Nessuna agentic loop sul modello locale.

Riferimento SOTA: PathRAG (AAAI 2026, arXiv 2502.14902) per path-pruning relazionale. Lemnia adotta il prune-flow ma mantiene la generazione deterministica vincolata al cite-or-refuse.

Cite-or-refuse pipeline a 5 step: (1) decomposizione della risposta in claim atomici; (2) substring match contro evidence set; (3) mDeBERTa-NLI per entailment verification; (4) KG-consistency check via traversal; (5) strip-and-replace per i claim non entailed. CST.82

Whitelist hedging per pack: verosimilmente, presumibilmente, si stima, pare — esenti dalla verifica entailment ma comunque limitati a paragrafi marcati come dossier hedged. Sezioni strict (dunning, preventivo, supplier-risk) non ammettono hedging.

Registro di elaborazione firmato BLAKE3 per ogni risposta. Esportabile come prova in giudizio o per il DPO. Ancoraggio normativo: Trib. Siracusa 338/2026 Art. 96 c.p.c.