# LaaP — Language as a Protocol ## White Paper di Fondazione · v0.2 · Luglio 2026 > **Il linguaggio non è soltanto un'interfaccia. Può diventare il piano semantico del protocollo.** **Autore e promotore:** Matteo Masina **Ruolo:** C.T.O. at eFM **Fondatore:** Founder LaaP **Sito:** [https://laap.world](https://laap.world) **LinkedIn:** [www.linkedin.com/in/matteo-masina-06845827](https://www.linkedin.com/in/matteo-masina-06845827) **Email:** [matteo.masina@laap.world](mailto:matteo.masina@laap.world) **Progetto:** LaaP — Language as a Protocol **Reference implementation:** Cortex One **Stato del documento:** Candidate pubblica per revisione tecnica, legale e comunitaria **Lingua:** Italiano **Data:** 22 luglio 2026 --- ## Status del documento Questo white paper descrive una proposta architetturale e una reference implementation in evoluzione. Per evitare di confondere visione, specifica e software, usa tre etichette: - **Normativo** — requisiti che una futura implementazione conforme dovrebbe rispettare. - **Informativo** — motivazioni, esempi e scelte consigliate. - **Implementation-specific** — tecnologie e versioni usate da Cortex One, non obbligatorie per LaaP. Il nome **LaaP Foundation** indica in questo documento il modello di governance proposto per il protocollo. Forma giuridica, statuto, marchi, licenze e processo di standardizzazione devono essere formalizzati e pubblicati separatamente. --- ## Abstract LaaP — Language as a Protocol — propone un piano semantico aperto per la comunicazione tra persone, organizzazioni, agenti AI e sistemi informativi. L'idea centrale è che l'intenzione possa essere espressa in linguaggio naturale, ma debba viaggiare dentro un envelope verificabile che includa identità, contesto, finalità, vincoli, provenienza e requisiti di policy. LaaP non sostituisce HTTP, MQTT, MCP, A2A, OAuth, OpenID Connect, DID o Verifiable Credentials. Li combina e li completa in un modello nel quale: 1. i partecipanti sono identificabili o pseudonimi secondo il contesto; 2. i nodi dichiarano capacità e limiti; 3. la policy resta vicina alla fonte autorevole; 4. i dati grezzi sono minimizzati e il significato viene prodotto localmente quando possibile; 5. ogni risposta conserva provenienza, confidenza, validità e spiegabilità; 6. agenti umani e artificiali operano come principal auditabili; 7. la rete può federarsi senza imporre un unico fornitore o un unico modello AI. **Cortex One** è la prima reference implementation del paradigma: un ambiente nel quale identità YOU, Semantic Node, domini semantici, Knowledge Graph, policy e orchestrazione agentiva vengono sperimentati come un sistema unitario. --- ## Indice 1. Executive Summary 2. Il problema che LaaP affronta 3. Tesi, obiettivi e non-obiettivi 4. Il Manifesto: quattro leggi architetturali 5. Modello del protocollo LaaP 6. YOU: identità, presenza ed evidence graph 7. Semantica come infrastruttura 8. Architettura tecnica di riferimento 9. Cortex One e la Company OS AI-native 10. Security model e threat model 11. Privacy, consenso e allineamento normativo 12. Federazione, discovery e trust 13. Interoperabilità con standard e protocolli esistenti 14. Governance, versioning e conformità 15. Ecosistema e modello economico 16. Percorso per builder e organizzazioni 17. Misurazione, benchmark e agenda di ricerca 18. Stato della reference implementation e roadmap 19. The Signal: ricerca e corpo editoriale 20. Visione: l'era della partecipazione intelligente Appendice A — Vocabolario Appendice B — LaaP Semantic Envelope Appendice C — Capability Card Appendice D — Domain Manifest Appendice E — Matrice delle minacce Appendice F — Riferimenti ## 1. Executive Summary LaaP nasce da una frattura strutturale. I sistemi enterprise comunicano attraverso contratti tecnici rigidi; i modelli AI ragionano invece attraverso intenzioni, contesto e significato. Nel mezzo restano identità frammentate, dati duplicati, policy distribuite in modo incoerente e un'enorme quantità di conoscenza non direttamente utilizzabile. La proposta di LaaP è introdurre un livello sopra il trasporto e sotto l'esperienza applicativa: un **piano semantico di protocollo**. Il partecipante non deve conoscere necessariamente l'endpoint, lo schema o il tool corretto. Esprime ciò che vuole ottenere. L'orchestratore e i nodi negoziano capacità, policy e forma della risposta. Un messaggio LaaP contiene due componenti inseparabili: - una **intenzione semantica**, leggibile da umani e modelli; - un **envelope strutturato**, validabile deterministicamente. Questo permette di conservare la flessibilità del linguaggio senza affidare sicurezza, routing e autorizzazione a interpretazioni probabilistiche. Le quattro leggi di LaaP sono: 1. **Il linguaggio esprime l'intenzione; il protocollo ne rende verificabile il contesto.** 2. **Ogni messaggio ha un principal, un livello di assurance e una finalità.** 3. **Il dato resta alla fonte quando possibile; la disclosure è minima, proporzionata e tracciabile.** 4. **Ogni nodo dichiara capacità, limiti, policy e versione.** Il paradigma introduce inoltre **YOU**, una presenza digitale composta da identificatori, credenziali, account collegati, fonti di evidenza, consensi e rappresentazioni contestuali. YOU non è un mega-profilo centralizzato: è un grafo di attestazioni e fonti mantenute separate, con provenienza e confidenza. Il cuore operativo della rete è il **Semantic Node**. Ogni nodo: - conosce un dominio; - pubblica una Capability Card; - interpreta intenzioni; - applica policy locali; - interroga dati o strumenti autorizzati; - restituisce una risposta semantica con evidence e disclosure controllata. Il protocollo è pensato per coesistere con gli standard attuali. W3C DID e Verifiable Credentials possono fornire identificatori e attestazioni; EUDI Wallet può fornire identità e credenziali regolamentate; OAuth/OIDC e DPoP possono gestire autorizzazione e proof-of-possession; MCP può collegare modelli a risorse e tool; A2A può trasportare collaborazione tra agenti; Solid può offrire personal data stores; LaaP definisce il piano semantico, di policy e di provenienza che orchestra questi elementi. La promessa non è eliminare API, schemi o trasporti. È ridurre l'accoppiamento tra intenzione e implementazione, rendere la conoscenza interrogabile in modo sicuro e restituire centralità al partecipante. --- ## 2. Il problema che LaaP affronta ### 2.1 Il Paradosso dell'Integrazione Enterprise Ogni grande organizzazione oggi possiede decine di sistemi informativi — ERP, CRM, data warehouse, archivi documentali, strumenti operativi. Ognuno parla una lingua diversa: REST API, schemi SQL, tipi GraphQL, formati di messaggi proprietari, SDK incompatibili. L'integrazione non è un problema risolto. È **il problema centrale dell'informatica enterprise**. Una quota rilevante del lavoro di ingegneria enterprise continua a essere assorbita da integrazione, riconciliazione semantica, manutenzione dei contratti e gestione delle eccezioni tra sistemi. Quando l'intelligenza artificiale entra in questo scenario, il problema si amplifica. I modelli LLM sono eccellenti nel ragionare in linguaggio naturale, ma il mondo enterprise è costruito intorno a endpoint, contratti API e schemi rigidi. C'è una frattura fondamentale tra come l'AI ragiona (per significato) e come i sistemi attuali comunicano (per struttura). ### 2.2 Il Problema dell'Identità Digitale Per decenni, l'identità digitale è stata una proprietà delle piattaforme, non delle persone. Il tuo account Google, il tuo profilo LinkedIn, il tuo utente Salesforce — nessuno di questi ti appartiene. Appartengono alle piattaforme che li ospitano. Le conseguenze sono: - **Frammentazione**: una persona media ha decine di identità digitali separate, ognuna con dati diversi e inconsistenti - **Revocabilità arbitraria**: una piattaforma può cancellare il tuo account in qualsiasi momento - **Assenza di portabilità**: non puoi portare la tua identità da un sistema all'altro - **Zero sovranità**: non controlli cosa viene fatto con i tuoi dati identitari - **Nessuna firma**: nessuna certezza crittografica che tu sia chi dici di essere Questo modello — che chiamiamo "identità di piattaforma" — era accettabile nel Web 1.0 e Web 2.0. È fondamentalmente incompatibile con un'era di sistemi intelligenti e agenti AI che devono poter ragionare su *chi sta facendo una richiesta* e *con quale autorità*. ### 2.3 Il Problema della Sovranità dei Dati I sistemi attuali assumono che i dati debbano essere *spostati* per essere utilizzati: esportati, replicati, centralizzati in data lake, inviati ad API esterne. Questo approccio crea: - **Rischio di compliance**: ogni copia dei dati è una potenziale violazione GDPR - **Latenza di trust**: devi fidarti di ogni intermediario che tocca i tuoi dati - **Loss of context**: i dati separati dal loro contesto perdono significato - **Vendor lock-in**: i tuoi dati diventano il capitale del fornitore, non tuo ### 2.4 Il Gap tra AI e Enterprise I modelli AI di nuova generazione ragionano magnificamente su problemi complessi quando hanno accesso al contesto giusto. Ma il contesto nei sistemi enterprise è frammentato, siloed, e protetto da layer di autenticazione e autorizzazione che non parlano con i modelli AI. Il risultato è che la stragrande maggioranza dei progetti AI enterprise fallisce non per limiti del modello, ma per **incapacità di dargli accesso sicuro e contestualizzato alle informazioni dell'organizzazione**. LaaP propone di affrontare questo problema a livello infrastrutturale, separando il piano semantico dal piano di trasporto e portando identità, policy, provenienza e intenzione dentro ogni interazione. --- ## 3. Tesi, obiettivi e non-obiettivi ### 3.1 La tesi Il linguaggio naturale è il mezzo più generale con cui esseri umani esprimono intenzioni, contesto e vincoli. Tuttavia il testo libero, da solo, è ambiguo, non deterministico e inadeguato a trasportare decisioni di sicurezza. LaaP assume quindi una posizione precisa: > **Il linguaggio è il piano dell'intenzione. L'envelope è il piano della verificabilità.** La combinazione dei due forma il messaggio LaaP. ### 3.2 Obiettivi di design LaaP mira a: 1. **Ridurre l'accoppiamento** tra chi esprime un bisogno e l'implementazione che lo soddisfa. 2. **Rendere first-class** identità, finalità, consenso, provenienza e limiti di disclosure. 3. **Favorire l'elaborazione vicino alla fonte**, evitando copie non necessarie. 4. **Permettere la discovery dinamica** di capacità semantiche. 5. **Supportare sistemi multi-modello e multi-vendor**, inclusi modelli locali. 6. **Consentire federazione e delega** tra persone, organizzazioni e agenti. 7. **Mantenere auditabilità** senza trasformare l'audit log in un nuovo data lake invasivo. 8. **Separare il protocollo dalla reference implementation**, così che LaaP possa essere implementato con stack diversi. 9. **Rendere misurabile la qualità semantica**, non soltanto la disponibilità tecnica. 10. **Preservare l'autorità della fonte**, distinguendo fatti, inferenze e sintesi. ### 3.3 Non-obiettivi LaaP non pretende di: - sostituire TCP/IP, HTTP, MQTT o i protocolli di trasporto; - abolire API, database o schemi; - rendere il linguaggio naturale privo di ambiguità; - garantire che una risposta generata da un LLM sia vera per definizione; - creare un'identità universalmente trusted senza governance degli issuer; - centralizzare tutti i dati personali; - rendere automaticamente conforme al GDPR un sistema solo perché usa Semantic Node; - definire un unico modello AI, cloud provider o database; - eliminare la necessità di test, versioning, osservabilità e human oversight. ### 3.4 Il cambio di paradigma: da applicazioni a partecipanti L'architettura software del XX secolo è centrata sull'**applicazione**: un'applicazione possiede i propri utenti, i propri dati, le proprie sessioni. L'utente è un ospite dell'applicazione. LaaP propone un cambio radicale: l'architettura del XXI secolo deve essere centrata sul **partecipante**. Un partecipante — umano, organizzazione o agente AI — ha la propria identità, la propria sovranità sui dati, e interagisce con i nodi della rete su basi di consenso esplicito e policy dichiarata. Le applicazioni diventano **nodi della rete LaaP**: dichiarano cosa sanno, cosa possono fare, sotto quali policy operano. I partecipanti interagiscono con i nodi usando il linguaggio come protocollo. ### 3.5 Apertura e standardizzazione La specifica dovrebbe essere sviluppata pubblicamente attraverso documenti versionati, issue, proposte di modifica e suite di conformità. L'apertura deve includere non solo il codice, ma anche: - vocabolario normativo; - JSON Schema o equivalente; - profili di sicurezza; - casi di test; - esempi interoperabili; - registro delle estensioni; - processo di deprecazione; - governance dei marchi e della certificazione. Una licenza permissiva sul codice non equivale, da sola, a uno standard aperto. La credibilità del protocollo dipenderà dalla possibilità per terze parti di implementarlo senza dipendere da Cortex One. ## 4. Il Manifesto: quattro leggi architetturali Le leggi sono invarianti di design. Le implementazioni possono usare tecnologie differenti, ma non dovrebbero violarne il significato. ### Legge I — Il linguaggio esprime l'intenzione > **Un nodo LaaP non è definito dai suoi endpoint. È definito dalle intenzioni che sa comprendere e soddisfare.** Il trasporto può continuare a usare endpoint, topic, code o sessioni. Ciò che cambia è il contratto percepito dal partecipante: la capacità è descritta semanticamente e non soltanto come funzione tecnica. Requisiti normativi proposti: - ogni intenzione deve essere associata a un `intent_id`; - il messaggio deve dichiarare lingua, finalità e formato di risposta atteso; - il nodo deve poter chiedere chiarimenti o rifiutare intenzioni ambigue; - l'interpretazione deve produrre una rappresentazione strutturata ispezionabile; - la risposta deve distinguere dati, inferenze e raccomandazioni; - la versione del vocabolario o del dominio deve essere dichiarata. ### Legge II — Ogni messaggio ha un principal > **Non esistono azioni senza origine, delega o responsabilità.** Il principal può essere una persona identificata, una persona pseudonima, un'organizzazione, un servizio o un agente AI. Il protocollo deve distinguere: - chi origina l'intenzione; - chi esegue materialmente l'azione; - per conto di chi l'agente opera; - quale issuer attesta l'identità; - quale livello di assurance è disponibile; - quale delega è stata concessa; - quale finalità autorizza l'uso. Un sistema può supportare accesso pubblico o anonimo, ma anche in quel caso deve assegnare un principal tecnico effimero e applicare policy coerenti. “Anonimo” non significa “senza policy” o “senza rate limit”. ### Legge III — Data stays at source, meaning moves with evidence > **L'elaborazione deve avvenire vicino alla fonte autorevole; la disclosure deve essere la minima necessaria.** La frase “i dati non si muovono” è un principio di minimizzazione, non un assoluto fisico. Anche una sintesi può essere dato personale, confidenziale o inferenziale. Pertanto un nodo conforme deve: 1. eseguire localmente query e trasformazioni quando possibile; 2. evitare l'esportazione massiva di dati grezzi; 3. applicare filtri di disclosure prima della generazione; 4. indicare provenienza e livello di aggregazione; 5. prevenire la ricostruzione indiretta di dati sensibili; 6. rispettare purpose limitation e retention; 7. permettere risposte “non posso rispondere” o “serve consenso aggiuntivo”. La risposta semantica non è un modo per aggirare la protezione dei dati. È un artefatto soggetto alle stesse regole di riservatezza, minimizzazione e controllo. ### Legge IV — Ogni nodo dichiara capacità e limiti > **Un nodo non è discoverable se non dichiara cosa sa, cosa può fare, con quali policy e con quale affidabilità.** La Capability Card deve includere: - dominio e versione; - intenzioni supportate; - tipi di output; - policy e prerequisiti di identity assurance; - classi di dati trattate; - limiti e casi esclusi; - modelli o strumenti usati quando rilevanti; - SLA e disponibilità; - meccanismi di audit; - endpoint o binding di trasporto; - firma del publisher; - data di emissione e scadenza. La discovery non implica autorizzazione. Sapere che un nodo possiede una capacità non conferisce il diritto di usarla. ## 5. Modello del protocollo LaaP ### 5.1 Attori Il modello distingue cinque ruoli logici. Una stessa componente può ricoprire più ruoli, ma le responsabilità restano separate. **Participant** Persona, organizzazione o agente che esprime un'intenzione. **Orchestrator** Interpreta l'intenzione, seleziona i nodi, gestisce chiarimenti, deleghe, composizione e failure handling. **Semantic Node** Detiene capacità e accesso a fonti autorevoli. Applica policy e produce risposte semantiche. **Identity and Trust Service** Emette o verifica identificatori, credenziali, token, deleghe e stati di revoca. **Policy Authority** Definisce o distribuisce policy. Il punto decisionale può essere locale al nodo, mentre la governance delle regole può essere federata. ### 5.2 Oggetti del protocollo Il nucleo minimo è composto da: - **Semantic Envelope** - **Intent** - **Capability Card** - **Policy Decision** - **Semantic Response** - **Evidence Reference** - **Audit Event** - **Consent Receipt** - **Delegation Grant** - **Error / Clarification Request** ### 5.3 Semantic Envelope L'envelope è la parte deterministica del messaggio. Deve essere validabile prima di invocare un modello. Campi minimi proposti: ```yaml protocol: laap version: 0.2 message_id: urn:uuid:... timestamp: 2026-07-22T10:30:00Z principal: subject: did:example:123 actor: agent:procurement-assistant on_behalf_of: did:example:123 assurance: L2 intent: text: "Confronta la spesa energetica degli ultimi dodici mesi" language: it purpose: personal-cost-optimization expected_output: summary_with_evidence context: domain: energy locale: it-IT time_range: from: 2025-07-01 to: 2026-06-30 constraints: max_disclosure: aggregate prohibited_data: - payment_card no_external_model: true authorization: consent_receipt: consent:... scopes: - energy.read.aggregate security: audience: laap-node:energy proof_type: dpop nonce: ... trace: correlation_id: urn:uuid:... parent_message_id: null ``` ### 5.4 Lifecycle 1. **Receive** — il gateway valida sintassi, dimensione, timestamp e anti-replay. 2. **Authenticate** — identifica principal, actor, delega e assurance. 3. **Authorize pre-check** — verifica se l'intenzione è ammissibile prima di leggere i dati. 4. **Interpret** — produce una rappresentazione strutturata dell'intenzione. 5. **Clarify** — se l'ambiguità supera la soglia, chiede un chiarimento. 6. **Route** — seleziona uno o più nodi in base a capacità, trust, policy, costo e disponibilità. 7. **Execute** — il nodo usa tool e fonti autorizzate. 8. **Policy post-check** — controlla la risposta e applica redaction o aggregazione. 9. **Compose** — l'orchestratore combina risultati senza perdere provenienza. 10. **Respond** — restituisce contenuto, evidence, confidenza, limiti e policy applicate. 11. **Audit** — registra un evento minimizzato e correlabile. 12. **Learn** — eventuali feedback aggiornano metriche o modelli soltanto secondo policy esplicite. ### 5.5 Chiarimento e fallimento Un protocollo semantico deve trattare l'incertezza come stato normale. Codici logici proposti: - `INTENT_AMBIGUOUS` - `CAPABILITY_NOT_FOUND` - `INSUFFICIENT_ASSURANCE` - `CONSENT_REQUIRED` - `POLICY_DENIED` - `SOURCE_UNAVAILABLE` - `EVIDENCE_INSUFFICIENT` - `DISCLOSURE_TOO_HIGH` - `MODEL_UNCERTAIN` - `HUMAN_REVIEW_REQUIRED` - `DELEGATION_INVALID` - `RESPONSE_CONFLICT` Il nodo non deve inventare una risposta per mascherare l'assenza di capacità o dati. ### 5.6 Composizione multi-nodo Una richiesta complessa può richiedere più domini. L'orchestratore deve mantenere un piano di esecuzione con: - dipendenze; - policy per fase; - dati intermedi consentiti; - provenienza; - timeout; - strategia di fallback; - criteri di conflitto; - necessità di approvazione umana. La composizione non deve creare una “super-policy” più permissiva delle policy dei nodi sorgente. Vale la regola dell'intersezione: l'output finale non può eccedere la disclosure autorizzata da ciascuna fonte. ### 5.7 Semantic Response Una risposta conforme dovrebbe includere: ```yaml status: success answer: text: "La spesa energetica è diminuita del 7,4%..." type: analytical_summary claims: - statement: "La spesa totale è stata 1.842 euro" confidence: 0.99 evidence: - source: provider:utility-a artifact: bill:2026-05 observed_at: 2026-07-22 disclosure: aggregate limitations: - "Manca la bolletta di agosto 2025" policy: decision_id: opa:... purpose: personal-cost-optimization trace: correlation_id: urn:uuid:... ``` La confidenza non deve essere un numero decorativo. Deve riferirsi a un metodo dichiarato: completezza delle fonti, consenso tra evidenze, validità temporale, affidabilità dell'estrattore o verifica deterministica. ## 6. YOU: identità, presenza ed evidence graph ### 6.1 Non un account universale, ma una presenza componibile YOU rappresenta il partecipante senza imporre che tutti i suoi dati confluiscano in un database centrale. Il modello corretto è un **evidence graph**: ```text YOU ├── identifiers ├── credentials ├── linked accounts ├── evidence sources ├── contextual personas ├── permissions and consents ├── delegations ├── semantic claims └── revocation and history ``` Ogni fonte rimane distinta. Un account Microsoft personale, uno corporate, GitHub, LinkedIn, un wallet pubblico e un portale bancario possono riferirsi alla stessa persona, ma mantengono issuer, contesto, validità, policy e confidenza differenti. ### 6.2 Source of evidence, non source of truth universale Una fonte può attestare un fatto soltanto entro il proprio dominio. GitHub può fornire evidenza di attività tecnica; un datore di lavoro può attestare un ruolo; un'università può attestare un titolo. Il sistema non deve trasformare correlazioni in certezze senza dichiararlo. Esempio: ```yaml claim: subject: you:123 predicate: has_competence object: Java confidence: 0.96 evidence: - source: github type: behavioral confidence: 0.88 - source: employer-credential type: verified_credential confidence: 0.99 - source: self-declaration type: asserted confidence: 0.60 ``` ### 6.3 Persona contestuale La stessa YOU può presentare viste differenti: - personale; - professionale; - familiare; - pubblica; - pseudonima; - delegata; - agentica. Una persona contestuale non è una seconda identità scollegata. È una projection governata da policy, con un set limitato di attributi e finalità. ### 6.4 Le 6 Proprietà Fondamentali di YOU YOU garantisce sei proprietà che non sono feature opzionali, ma invarianti architetturali: **01 — PERSISTENT (Persistente)** YOU esiste oltre le sessioni, i dispositivi e le piattaforme. Non scade. Non viene "disconnessa". La tua identità LaaP persiste indipendentemente da quali applicazioni usi o smetti di usare. **02 — CONTEXTUAL (Contestuale)** YOU non ha un'unica rappresentazione fissa. Si adatta al contesto: in un contesto professionale mostra attributi diversi rispetto a un contesto personale, pur rimanendo la stessa identità alla radice. È YOU — variabile nell'espressione, coerente nell'essenza. **03 — SOVEREIGN (Sovrano)** Solo tu controlli cosa riveli e a chi. Il consenso è esplicito, granulare e revocabile. Nessun nodo può accedere agli attributi di YOU senza che tu abbia dato consenso specifico per quel nodo e quel tipo di attributo. **04 — PORTABLE (Portabile)** YOU viaggia con te attraverso tutti i nodi del protocollo LaaP. Non devi "creare un account" su ogni servizio — la tua identità LaaP è già riconosciuta da qualsiasi nodo conforme al protocollo. **05 — VERIFIABLE (Verificabile)** Ogni YOU è firmata crittograficamente con un LaaP JWT emesso dall'Identity Node (Keycloak 26.2). Qualsiasi nodo può verificare l'autenticità di YOU senza interrogare un server centrale — la firma è autosufficiente. **06 — EVOLVING (Evolutiva)** YOU cresce nel tempo. Ogni interazione nel protocollo, ogni competenza acquisita, ogni consenso dato o revocato contribuisce a una rappresentazione più ricca e accurata di chi sei nella rete. Non è un profilo statico: è una presenza viva. ### 6.5 Il Percorso di YOU: da Visitatore a Partecipante Certificato LaaP ha progettato un percorso progressivo che rispetta la gradualità della fiducia digitale: #### Livello 0 — Visitatore Anonimo Arrivi senza nessuna identità. Nessun account, nessun dato personale richiesto. Il sistema non ti chiede nulla. #### Livello 1 — Pre-YOU Identity (Live in v0.13) Il sistema rileva segnali contestuali anonimi — lingua del browser, timezone, tipo di dispositivo, patterns di navigazione — con minimizzazione dei dati e senza richiedere dati anagrafici diretti. Un identificatore persistente o un fingerprint può comunque costituire dato personale o pseudonimo ai sensi del contesto e deve essere trattato come tale. Viene creata una **Pre-YOU Identity** locale: un identificatore pseudonimo e data-minimized che ti permette di interagire con il sistema in modo contestualizzato. Viene emesso una credenziale di sessione a vita limitata. La credenziale attesta il contesto autorizzato; la prova che il singolo messaggio provenga dal mittente richiede un meccanismo separato di proof-of-possession o firma della richiesta. Viene richiesto **consenso GDPR esplicito** prima di memorizzare qualsiasi cosa. Puoi vedere esattamente cosa il sistema sa di te. Puoi revocare e cancellare in qualsiasi momento. #### Livello 2 — YOU Certified (In arrivo in v0.14) Se scegli di certificare la tua identità, il processo è: 1. Fornisci il minimo indispensabile di dati verificabili (a seconda del livello di certificazione) 2. L'Identity Node della reference implementation può emettere token e, quando richiesto, credenziali verificabili. Keycloak 26.2 è una scelta implementativa del prototipo, non un requisito del protocollo 3. Le attestazioni contengono solo gli attributi necessari e indicano issuer, validità, livello di assurance, finalità e stato di revoca. La firma appartiene all'issuer autorizzato, non necessariamente a un'autorità centrale LaaP 4. Da quel momento, YOU può essere presentata a nodi che riconoscono l'issuer, il formato e il trust framework applicabile. Portabilità non significa fiducia automatica: ogni relying node applica le proprie policy. ### 6.6 YOU nel Flusso del Protocollo ``` YOU (LaaP JWT) │ ├──[firma identità]──▶ Cortex One │ │ │ [routing intent] │ │ │ Semantic Node │ │ │ [OPA policy check] │ │ │ Risposta semantica │ (solo significato, │ dati grezzi minimizzati) ▼ Partecipante ``` Il LaaP JWT firmato accompagna ogni richiesta. Il Semantic Node riceve la richiesta, verifica l'identità tramite OPA, decide cosa mostrare in base alla policy configurata, ed emette una risposta semantica. Il partecipante riceve significato — non dati. ### 6.7 Agenti AI come Partecipanti YOU Una delle innovazioni più profonde di LaaP è che **anche gli agenti AI hanno una YOU**. Un agente Cortex Brain che agisce per conto di un'organizzazione ha la propria identità LaaP: - Firmata crittograficamente - Tracciata in ogni interazione - Soggetta alle stesse policy degli umani - Revocabile dal proprietario dell'agente Non esistono azioni anonime nella rete LaaP — né degli umani, né degli agenti. --- ### 6.8 Livelli di assurance Una futura specifica dovrebbe evitare un unico flag `certified: true`. È preferibile un modello a livelli: | Livello | Descrizione | Esempio | |---|---|---| | L0 | Principal tecnico effimero | sessione pubblica rate-limited | | L1 | Identificatore pseudonimo persistente | profilo locale con chiave | | L2 | Identità autenticata da issuer riconosciuto | OIDC con MFA | | L3 | Attributi verificati | credenziale professionale o anagrafica | | L4 | Identità ad alto assurance | wallet o schema regolamentato | Il nodo dichiara il livello minimo richiesto per ciascuna capacità. ### 6.9 Agenti come actor delegati Un agente non “possiede” automaticamente l'identità della persona. Deve operare attraverso una delega esplicita che definisca: - principal delegante; - actor agente; - scopo; - strumenti consentiti; - limiti economici; - durata; - dati accessibili; - azioni che richiedono conferma; - revoca; - audit. La separazione tra `subject`, `actor` e `on_behalf_of` è essenziale per evitare che ogni azione automatica venga attribuita direttamente all'umano. ## 7. Semantica come infrastruttura ### 7.1 Dal dato al significato I sistemi informatici tradizionali operano al livello del **dato**: record in un database, oggetti JSON, file in un filesystem. Il significato di quei dati è implicito — lo sa chi ha scritto il codice, lo sa chi conosce lo schema, lo sa chi ha letto la documentazione. LaaP opera a un livello superiore: il livello del **significato**. I Semantic Node — le unità architetturali fondamentali di LaaP — non espongono dati. Espongono *comprensione dei propri dati*. Questa distinzione non è semantica (nel senso linguistico): è una differenza architetturale fondamentale che cambia come i sistemi si integrano, come l'AI ragiona su di essi, e come viene garantita la sovranità. ### 7.2 Domini semantici Un dominio è un ecosistema governato, non soltanto un modello dati. Deve descrivere: - ontologia; - entità; - relazioni; - fonti autorevoli; - regole di provenienza; - policy; - workflow; - agenti autorizzati; - prompt e tool; - test; - lifecycle; - mapping con domini esterni. La standardizzazione dei domini è il patrimonio strategico di Cortex One e un prerequisito per l'interoperabilità LaaP. I domini non devono duplicare concetti radice: `Identity` può possedere `Person`, mentre `Work`, `Finance` e `Real Estate` la referenziano. ### 7.3 Microdomini vs Microservizi Il confronto con i microservizi aiuta a capire cosa sono i Microdomini LaaP: | Aspetto | Microservizio | Microdomain LaaP | |---------|---------------|-------------------| | Cosa espone | API (endpoint, metodi, schemi) | Significato (capacità dichiarate in linguaggio naturale) | | Come viene consumato | Client conosce l'API a priori | Client esprime un'intenzione | | Contratto | Esplicito (OpenAPI/Swagger) | Semantico (Capability Card) | | Discovery | Registry manuale, Consul, ecc. | Auto-discovery tramite Capability Cards | | Policy | Fuori banda (middleware, gateway) | Integrata nel nodo (OPA sidecar) | | Dati in transito | Dati grezzi | Solo significato estratto | | Evoluzione | Breaking changes richiedono versionamento | Le intenzioni riducono l'accoppiamento, ma Capability Card, schemi semantici e policy restano versionati | Un microservizio risponde alla domanda: *"Cosa posso fare se conosco la tua API?"* Un Microdomain risponde alla domanda: *"Cosa posso capire e cosa posso dirti, se mi dici cosa vuoi sapere?"* ### 7.4 Anatomia di un Semantic Node Ogni nodo nella rete LaaP ha la seguente struttura: ``` ┌─────────────────────────────────────────────────────┐ │ SEMANTIC NODE │ │ │ │ ┌─────────────────┐ ┌──────────────────────┐ │ │ │ Capability Card│ │ Intent Parser │ │ │ │ (chi sono, │ │ (comprende la │ │ │ │ cosa so, policy│ │ richiesta in lang. │ │ │ │ di accesso) │ │ naturale) │ │ │ └─────────────────┘ └──────────────────────┘ │ │ │ │ │ ┌─────────────────────────────────▼──────────────┐ │ │ │ OPA Policy Engine │ │ │ │ (valida identità, applica regole di accesso) │ │ │ └─────────────────────────────────┬──────────────┘ │ │ │ │ │ ┌─────────────────────────────────▼──────────────┐ │ │ │ Data Layer │ │ │ │ (SQLite / CSV / DB — non esce mai dal nodo) │ │ │ └─────────────────────────────────┬──────────────┘ │ │ │ │ │ ┌─────────────────────────────────▼──────────────┐ │ │ │ Semantic Extractor │ │ │ │ (LLM locale o API — estrae significato │ │ │ │ dai dati, compone la risposta semantica) │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘ ``` ### 7.5 Capability Cards — Il Dizionario della Rete Le Capability Cards sono il meccanismo con cui un nodo si presenta alla rete. Una Capability Card descrive: - **Dominio**: cosa sa il nodo ("gestisce dati di vendita per la divisione EMEA") - **Capacità**: cosa può fare ("rispondere a query su performance, trend, previsioni") - **Policy di accesso**: chi può chiedere cosa ("accesso completo per ruolo SALES_MANAGER; accesso aggregato per ruolo ANALYST; nessun accesso per ruoli non certificati") - **Intent patterns**: esempi di richieste che il nodo riconosce - **Limitazioni**: cosa il nodo non sa o non può fare (per evitare confusione nel routing) Un orchestratore LaaP (come Cortex Brain) legge le Capability Cards della rete e usa queste informazioni per instradare le intenzioni degli utenti verso il nodo più appropriato. ### 7.6 Intent Routing — Come Funziona il Routing Semantico Il routing in LaaP è fondamentalmente diverso dal routing tradizionale: **Routing tradizionale**: il client conosce l'indirizzo del servizio a priori → chiama direttamente **Semantic Routing LaaP**: 1. Il partecipante esprime un'intenzione in linguaggio naturale 2. L'orchestratore (Cortex Brain) analizza l'intenzione 3. L'orchestratore cerca nelle Capability Cards quale nodo può rispondere 4. L'orchestratore instrada l'intenzione al nodo (o ai nodi) appropriati 5. I nodi rispondono con significato 6. L'orchestratore compone una risposta coerente al partecipante Questo approccio ha benefici strutturali: - Nessuna configurazione manuale delle route - Resilienza automatica: se un nodo non è disponibile, l'orchestratore cerca alternative - Composizione naturale: più nodi possono rispondere a un'intenzione complessa - Evoluzione governata: quando un nodo aggiunge capacità, queste diventano scopribili dopo pubblicazione, validazione e compatibilità della Capability Card ### 7.7 OPA — Policy at Source Open Policy Agent (OPA) è il motore di policy integrato in ogni Semantic Node LaaP. La sua posizione nell'architettura è deliberata: **la policy vive nel nodo sorgente**, non in un gateway esterno. Questo garantisce: - **Sovranità delle policy**: chi detiene i dati definisce le regole di accesso - **Nessun bypass possibile**: non c'è modo di accedere ai dati aggirando l'OPA del nodo - **Policy-as-code**: le regole sono versionabili, testabili, auditabili - **Contestualità**: l'OPA può usare attributi dell'identità LaaP JWT per prendere decisioni granulari Esempio di policy OPA in un Semantic Node LaaP: ```rego package laap.node.sales allow if { input.identity.role == "SALES_MANAGER" input.intent.type == "query" } allow if { input.identity.role == "ANALYST" input.intent.type == "aggregate_query" not input.intent.includes_pii } deny if { not input.identity.laap_certified } ``` ### 7.8 Knowledge Graph — Come la Rete Scopre la Conoscenza Il Knowledge Graph di LaaP (implementato con NetworkX in Cortex One) è un grafo digitale delle entità e delle loro relazioni nel dominio di conoscenza dell'organizzazione. A differenza dei Knowledge Graph tradizionali (che devono essere costruiti manualmente), il Knowledge Graph LaaP emerge organicamente: - Ogni interazione con un Semantic Node può scoprire nuove entità e relazioni - I nodi trasmettono aggiornamenti sulle entità che conoscono (KG resolution broadcast) - Un Entity Correlator identifica quando entità in nodi diversi si riferiscono alla stessa cosa reale - Il Knowledge Graph guida il routing: sa quali nodi "sanno qualcosa" su quali entità > *"I nodi scoprono entità. Le reti scoprono conoscenza."* — Signal #005 Il Knowledge Graph non deve diventare una copia centralizzata dei dati sorgente. È una **visione emergente e minimizzata** della conoscenza distribuita: conserva identificatori, relazioni, provenienza, livelli di confidenza e riferimenti ai nodi autorevoli. Ogni affermazione deve poter essere ricondotta a una fonte, a un'epoca di validità e a una policy di utilizzo. --- ### 7.9 Provider connection e domain discovery Il primo momento di valore per un partecipante non è “collegare un account”, ma scoprire quali parti della propria identità vivono in quella fonte. ```text Provider Connection → Source Inventory → Domain Discovery → Semantic Extraction → Provenance Registration → Consent and Policy → Personal Memory ``` Un provider manifest deve dichiarare: ```yaml provider: microsoft-365 connection_type: oauth account_context: corporate possible_domains: - identity - work - communication - calendar - documents data_classes: - profile - messages - events - files default_mode: metadata_only requires_explicit_consent: - message_content - file_content ``` Il sistema deve mostrare all'utente prima della connessione quali classi di dati possono essere lette, con quale finalità, per quanto tempo e quali domini potrebbero essere aggiornati. ### 7.10 Semantic Browser Agent Molti dati rilevanti non sono disponibili attraverso API. Un Semantic Browser Agent può, con mandato esplicito dell'utente, accedere a portali autenticati e trasformare le informazioni visibili in entità semantiche. La progressione è: 1. API connector; 2. file import; 3. authenticated navigation; 4. semantic observation; 5. delta detection; 6. living digital twin. Il browser agent deve essere trattato come componente ad alto rischio perché può: - visualizzare dati sensibili; - eseguire azioni irreversibili; - incontrare dark pattern; - violare termini di servizio; - essere ingannato da prompt injection presente nelle pagine; - confondere contenuto informativo e istruzioni operative. Requisiti minimi: - vault credenziali separato; - MFA gestito senza registrare segreti; - modalità read-only predefinita; - allowlist di domini e azioni; - screenshot o evidence hash per audit; - isolamento del browser; - prompt-injection filtering; - conferma umana per azioni dispositive; - rispetto di termini, copyright, robots e limiti legali; - cancellazione selettiva delle evidenze. ### 7.11 Provenienza, temporalità e conflitto Ogni claim semantico deve includere: - fonte; - metodo di estrazione; - timestamp di osservazione; - periodo di validità; - identità dell'estrattore; - confidenza; - stato: asserted, inferred, verified, disputed, expired; - policy di retention; - collegamento all'evidenza quando consentito. In presenza di fonti discordanti, il sistema non deve sovrascrivere silenziosamente. Deve mantenere la pluralità delle attestazioni e applicare una regola di risoluzione dichiarata. ## 8. Architettura tecnica di riferimento Questa sezione descrive Cortex One come reference implementation. Python, FastAPI, LangGraph, Keycloak, NetworkX, MQTT, OPA, AKS e le specifiche versioni non sono requisiti di conformità. ### 8.1 I Nodi del Protocollo LaaP L'implementazione di riferimento (Cortex One) è composta da sette nodi funzionali: #### semantic-node Il nodo semantico è l'unità fondamentale della rete LaaP. Ogni istanza gestisce un dominio di conoscenza specifico. - **Stack**: Python / FastAPI - **Storage**: SQLite o CSV (dati mai esposti direttamente) - **Policy Engine**: OPA sidecar - **LLM Integration**: Multi-LLM (configurabile: OpenAI, Anthropic, Azure OpenAI, modelli locali) - **Funzione**: riceve intenzioni in linguaggio naturale, le interpreta, applica policy, restituisce significato - **Capability Card**: autodichiarata e aggiornabile dinamicamente #### orchestrator-node Il nodo orchestratore coordina le interazioni tra partecipanti e Semantic Node. - **Stack**: Python / FastAPI - **Funzione**: Intent Routing, composizione di risposte multi-nodo, Zero Trust JWT validation - **Routing**: semantico, basato su Capability Cards - **Security**: verifica LaaP JWT su ogni richiesta prima di inoltrarla ai nodi #### knowledge-graph-node Il nodo Knowledge Graph mantiene il grafo delle entità e delle relazioni nel dominio. - **Stack**: Python / NetworkX - **Funzione**: digital twin del dominio di conoscenza; riceve aggiornamenti dai Semantic Node; risponde a query di discovery sulle relazioni tra entità - **KG-guided routing**: suggerisce all'orchestratore quali nodi contattare per entità specifiche #### identity-node Il nodo di identità gestisce il ciclo di vita delle identità YOU. - **Stack**: Keycloak 26.2 - **Protocollo**: PKCE (Proof Key for Code Exchange) + OpenID Connect - **Token**: LaaP JWT — JWT standard esteso con attributi LaaP (ruolo, livello di certificazione, consensi attivi, nodo emittente) - **Funzione**: emissione, validazione e revoca dei token YOU; gestione Pre-YOU Identity; GDPR consent management #### interaction-node Il nodo di interazione è il front-end del protocollo — il punto di contatto tra partecipanti umani e la rete LaaP. - **Frontend**: React / TypeScript - **Backend**: FastAPI (proxy sicuro verso gli altri nodi) - **Componenti chiave**: CockpitPage (interfaccia operativa), LoginPage (autenticazione PKCE), ManifestoPage, LandingPage - **Auth flow**: PKCE → LaaP JWT → sessione sicura #### cortex-brain Il cervello agentivo di Cortex One — il layer di intelligenza artificiale. - **Stack**: LangGraph 1.2.2 (ReAct agent framework) - **Build**: uv (fast Python package manager) - **Pattern**: ReAct (Reason + Act) — l'agente ragiona su un'intenzione, sceglie quale tool usare, agisce, osserva il risultato, itera - **Tool Registry**: custom tool registry con tool builder inline — i tool sono registrabili dinamicamente senza riavvio - **Funzione**: processa intenzioni complesse, orchestra chiamate a Semantic Node multipli, costruisce risposte composite #### mosquitto (Cortex Pulse) Il broker MQTT che gestisce la comunicazione asincrona tra tutti i nodi. - **Stack**: Eclipse Mosquitto - **Pattern**: publish/subscribe — ogni nodo pubblica aggiornamenti sui propri topic, gli altri si iscrivono - **Funzione**: KG resolution broadcast, aggiornamenti di stato dei nodi, sincronizzazione eventi - **Cortex Pulse**: il nome del layer di comunicazione — tutti i messaggi interni al sistema passano per Cortex Pulse ### 8.2 Identità, credenziali e prova del messaggio LaaP separa tre oggetti che non devono essere confusi: 1. **Identificatore del partecipante** — il riferimento stabile o pseudonimo al soggetto. 2. **Credenziale o access token** — un'attestazione emessa da un issuer, con claim, scadenza, audience e condizioni d'uso. 3. **Proof del singolo messaggio** — una prova che la richiesta corrente è stata generata da chi controlla la chiave associata, utile contro replay e furto di bearer token. Un JWT è un formato compatto per trasportare claim; non dimostra, da solo, che ogni richiesta sia stata firmata dal soggetto. Le implementazioni conformi dovrebbero supportare token sender-constrained, DPoP, mTLS o firme applicative equivalenti[R14] quando il livello di assurance lo richiede. Esempio informativo di access token: ```json { "iss": "https://identity.example", "sub": "did:example:123", "aud": "laap-node:sales-emea", "iat": 1784710800, "exp": 1784711700, "jti": "2f71c8d0-...", "scope": "semantic.query aggregate", "cnf": { "jkt": "base64url-thumbprint" }, "laap": { "protocol_version": "0.2", "identity_class": "pseudonymous", "assurance_level": "L1", "consent_receipt": "consent:8c42...", "purpose": "quarterly-business-review" } } ``` Il nodo deve validare almeno issuer, audience, scadenza, algoritmo ammesso, stato di revoca quando previsto, proof-of-possession, purpose e policy locali. Le implementazioni JWT devono seguire le Best Current Practices applicabili[R15] e impedire confusioni di algoritmo, replay e riuso cross-audience. ### 8.3 Deployment — Azure AKS La reference implementation dichiarata dal progetto è distribuita su **Azure Kubernetes Service (AKS)**. Questo snapshot descrive lo stato del prototipo e non costituisce un requisito normativo LaaP: - **12 container** in esecuzione simultanea - **Ingress**: NGINX Ingress Controller con SSL termination - **Secrets management**: Kubernetes Secrets (configurabili con Azure Key Vault) - **Scaling**: Horizontal Pod Autoscaler su tutti i nodi stateless - **Monitoring**: configurabile con Azure Monitor / Prometheus - **CI/CD**: scripts PowerShell per deploy controllato ### 8.4 Zero Trust Semantico LaaP implementa un modello Zero Trust a livello semantico: **nessuna richiesta è trusted per default, nessuna connessione tra nodi è privilegiata**. Ogni richiesta che arriva a un nodo deve: 1. presentare una credenziale o sessione valida per l'audience prevista; 2. fornire una proof del messaggio quando richiesta dal profilo di sicurezza; 3. passare la valutazione della policy del nodo ricevente; 4. rispettare scopo, finalità, consenso, rate limit, retention e limiti di disclosure; 5. produrre un audit event correlabile senza registrare più dati del necessario. Un nodo non si fida di un altro nodo semplicemente perché è "interno alla rete". Ogni interazione deve essere autorizzata. --- ### 8.5 Separazione tra control plane e data plane Una distribuzione matura dovrebbe distinguere: **Control plane** - registry di nodi; - distribuzione delle policy; - trust registry; - governance delle capability; - osservabilità; - lifecycle e revoca; - configurazione del routing. **Data and execution plane** - query locali; - tool execution; - accesso alle fonti; - semantic extraction; - redaction; - evidence generation. Il control plane non deve ricevere automaticamente i dati del data plane. Deve operare su metadata minimizzati. ### 8.6 Modelli locali e model routing L'orchestratore può usare modelli diversi secondo: - sensibilità dei dati; - capacità richiesta; - latenza; - costo; - lingua; - requisiti di residenza; - livello di assurance; - necessità di tool use; - valutazioni di qualità. Il routing del modello deve essere policy-driven. Un vincolo `no_external_model: true` deve impedire l'invio di contenuto a provider esterni, non limitarsi a un suggerimento per il prompt. ### 8.7 Observability semantica Oltre a uptime e latency, LaaP richiede metriche specifiche: - intent routing accuracy; - clarification rate; - policy denial rate; - unsupported intent rate; - evidence coverage; - claim conflict rate; - disclosure violations; - hallucination or unsupported-claim rate; - human override rate; - provenance completeness; - semantic drift tra versioni. ## 9. Cortex One e la Company OS AI-native ### 9.1 Cosa è Cortex One e cosa non è Cortex One è la **prima piattaforma costruita su LaaP Foundation**. Non è LaaP — è l'implementazione del protocollo. La distinzione è fondamentale: - **LaaP Foundation** = il paradigma, le leggi, il protocollo aperto. Come TCP/IP. - **Cortex One** = la prima piattaforma che implementa LaaP. Come un browser è un'implementazione di HTTP. Cortex One dimostra concretamente cosa diventa possibile quando si costruisce su LaaP: - Un'identità YOU che cresce con l'utente - Agenti AI che ragionano su domini di conoscenza reali - Routing semantico senza configurazione manuale - Sovranità dei dati garantita by design ### 9.2 La Simulazione La Simulazione di Cortex One è l'esperienza interattiva del protocollo LaaP. È il luogo dove: - Un partecipante crea la propria Pre-YOU Identity - Interagisce con Semantic Node reali attraverso il linguaggio naturale - Vede in tempo reale come l'orchestratore instrada le sue intenzioni - Sperimenta la sovranità dei dati — vede cosa sa il sistema di lui, può cancellare tutto La Simulazione non è un prodotto finito — è un canvas evolutivo. Ogni versione aggiunge nuovi Semantic Node, nuove capacità dell'agente, nuove funzionalità dell'identità. ### 9.3 LiveCockpit — L'Interfaccia Operativa Il LiveCockpit è l'interfaccia di amministrazione e monitoraggio di Cortex One: - **Infrastructure Graph**: visualizzazione in tempo reale della rete di nodi (quali sono attivi, quali comunicano, quale throughput) - **Agent Editor**: interfaccia tabbata per configurare gli agenti Cortex Brain, includendo tool registry e tool builder inline - **Identity Dashboard**: visione dell'universo YOU — partecipanti, livelli di certificazione, consensi attivi - **Signal Monitor**: traccia dei messaggi Cortex Pulse in tempo reale ### 9.4 Cortex Brain — L'Agente AI Cortex Brain è il layer di intelligenza artificiale di Cortex One. Implementa il pattern ReAct (Reason + Act) tramite LangGraph 1.2.2: **Loop ReAct:** 1. **Reason**: l'agente riceve un'intenzione e ragiona su come rispondervi 2. **Act**: sceglie quale tool usare (es. chiamare un Semantic Node, interrogare il Knowledge Graph, fare un calcolo) 3. **Observe**: riceve il risultato del tool 4. **Iterate**: decide se ha abbastanza informazione per rispondere, o se deve eseguire ulteriori azioni 5. **Respond**: compone una risposta semantica per il partecipante **Tool Registry dinamico:** I tool di Cortex Brain possono essere registrati dinamicamente senza riavvio. Il Tool Builder inline permette di creare nuovi tool direttamente dall'interfaccia del LiveCockpit. ### 9.5 Il Percorso dell'Utente in Cortex One ``` Visitatore anonimo │ ▼ Pre-YOU Identity (identificatore pseudonimo data-minimized, credenziale effimera, consenso e trasparenza) │ ▼ Interazione con Cortex One (linguaggio naturale → Cortex Brain → Semantic Node → risposta semantica) │ ▼ [Opzionale] YOU Certified (dati verificabili minimi → Keycloak 26.2 → LaaP JWT firmato → identità portabile cross-nodo) │ ▼ Partecipante certificato nella rete LaaP ``` --- ### 9.6 Tre stack logici La visione operativa distingue tre stack: ```text Cortex Company OS governa roadmap, agenti, workflow e approvazioni Cortex One Core eroga identità, consenso, registry, marketplace e servizi comuni Identity / Semantic Node Stack rappresenta una persona o un dominio con vault, memoria, policy e agenti ``` Un builder genera stack dedicati a partire da un manifest versionato. L'isolamento può essere logico, dedicato, locale, cloud o ibrido secondo il piano e il livello di sovranità richiesto. ### 9.7 Company OS Cortex One viene concepito anche come prodotto di una organizzazione AI-native. Il CEO o founder interagisce con pochi Domain Executive Agents; gli agenti coordinano sub-agent, tool e workflow. Domini organizzativi proposti: - Product; - ICT / Cloud; - DevOps; - Security & Compliance; - Market & Communication; - Finance & Business Model; - Legal & Trust. Questa organizzazione è una prova interna del paradigma: identità chiare, memoria operativa, deleghe, policy, agenti auditabili e human approval gates. ### 9.8 Human-in-the-loop Richiedono approvazione umana almeno: - deploy di produzione; - variazioni di budget; - modifica di policy privacy o security; - pubblicazioni ufficiali; - pricing e partnership; - azioni su dati reali; - monetizzazione; - cambi architetturali con impatto sul trust; - deleghe ad agenti con poteri dispositivi. L'obiettivo non è automatizzare il governo, ma aumentare la capacità esecutiva mantenendo responsabilità e decisioni critiche in capo agli esseri umani. ## 10. Security model e threat model ### 10.1 Principi LaaP assume un ambiente ostile. Nessun nodo, agente, modello, connettore o messaggio è trusted soltanto perché appartiene alla stessa rete. Principi: - least privilege; - explicit trust; - deny by default; - separation of duties; - sender-constrained credentials; - policy at source; - data minimization; - provenance preservation; - immutable-but-minimized audit; - human approval for irreversible actions; - model isolation; - secure-by-default connector design; - continuous verification. ### 10.2 Asset da proteggere - chiavi e credenziali; - identità e deleghe; - dati sorgente; - semantic memory; - Knowledge Graph; - consensi; - Capability Card; - policy bundle; - prompt e tool registry; - audit log; - modelli locali; - configurazioni di routing; - reputazione e trust score; - supply chain software. ### 10.3 Principali minacce #### Identity spoofing e token replay Un bearer token rubato può essere riutilizzato. Difese: - audience stretta; - TTL breve; - DPoP o mTLS; - nonce; - `jti` e replay cache; - rotazione chiavi; - revoca; - secure storage; - device binding quando proporzionato. #### Prompt injection e tool injection Contenuti letti da web, email o documenti possono contenere istruzioni malevole. Difese: - separazione tra dati e istruzioni; - content provenance; - allowlist dei tool; - policy prima e dopo il modello; - sandbox; - human confirmation; - output encoding; - detector e test avversariali; - nessun segreto nel prompt. #### Capability poisoning Un nodo può pubblicare una Capability Card falsa o troppo permissiva. Difese: - firma; - trust registry; - conformance status; - scadenza; - reputazione; - test di challenge; - allowlist organizzativa; - revoca. #### Semantic exfiltration Una risposta aggregata può rivelare dati sensibili attraverso query ripetute. Difese: - query budget; - k-anonymity o soglie minime dove applicabili; - differential privacy per analisi aggregate; - rate limiting contestuale; - detection di differencing attacks; - policy sullo storico delle query. #### Knowledge Graph poisoning Claim falsi o correlazioni errate possono contaminare il grafo. Difese: - append-only provenance; - livelli di confidenza; - separazione asserted/inferred/verified; - quorum di fonti; - dispute workflow; - expiry; - rollback; - stewardship umano. #### Confused deputy Un agente con privilegi elevati esegue una richiesta per conto di un principal non autorizzato. Difese: - delega esplicita; - scope intersection; - `actor` e `on_behalf_of`; - proof-of-possession; - policy su ogni hop; - no privilege amplification. #### Supply-chain compromise Tool, immagini container, modelli o dipendenze possono essere compromessi. Difese: - SBOM; - firma artefatti; - provenance di build; - vulnerability scanning; - pinning; - isolated runners; - secret scanning; - policy di ammissione; - reproducible builds dove possibile. #### Model substitution e downgrade Un router potrebbe scegliere un modello meno sicuro o esterno. Difese: - model policy; - attestation del runtime; - allowlist; - immutable decision log; - data classification; - no silent fallback. ### 10.4 Security profiles Non tutte le interazioni richiedono lo stesso livello. | Profilo | Caso | Controlli minimi | |---|---|---| | Public | informazioni pubbliche | principal effimero, rate limit | | Standard | dati personali ordinari | OIDC, TLS, consent, audit | | Sensitive | finanza, lavoro confidenziale | MFA, PoP, encryption, local processing | | Regulated | salute, identità legale | assurance elevata, credential validation, strict retention | | Dispositive | pagamento, firma, modifica | step-up auth, human confirmation, non-repudiation | ### 10.5 Audit L'audit event deve permettere di ricostruire: - chi ha chiesto; - quale actor ha agito; - quale delega; - quale finalità; - quali nodi; - quale policy; - quale versione; - quali tool; - quale output class; - quale approvazione. Non deve necessariamente contenere il testo integrale della richiesta o la risposta. Hash, riferimenti e classificazioni possono ridurre l'esposizione. ### 10.6 Incident response Ogni implementazione deve definire: - rilevamento; - contenimento; - revoca credenziali; - sospensione capability; - quarantena nodo; - invalidazione claim; - notifica; - analisi forense; - ripristino; - post-mortem; - aggiornamento del threat model. ## 11. Privacy, consenso e allineamento normativo ### 11.1 Privacy by architecture, non by slogan LaaP può facilitare minimizzazione, purpose limitation e controllo locale, ma la conformità dipende da ruoli, finalità, basi giuridiche, contratti e implementazione. Ogni deployment deve identificare: - titolare del trattamento; - responsabile e sub-responsabili; - categorie di interessati; - finalità; - base giuridica; - categorie di dati; - trasferimenti; - retention; - diritti; - misure tecniche e organizzative; - necessità di DPIA. ### 11.2 Consent Receipt Il consenso non è l'unica base giuridica, ma quando usato deve essere specifico, informato, libero, granulare e revocabile. Un receipt dovrebbe includere: ```yaml consent_id: consent:... subject: did:example:123 controller: org:example purpose: - build_personal_semantic_memory data_categories: - calendar_metadata - document_metadata processing: - extract_entities - infer_relationships recipients: - local-semantic-node valid_from: 2026-07-22 valid_until: 2027-07-22 revocation_endpoint: ... status: active ``` La revoca deve interrompere nuovi trattamenti e attivare il workflow previsto per dati derivati, cache, embedding e backup. ### 11.3 Derivazioni e inferenze Un claim inferito può essere più sensibile del dato di partenza. LaaP deve registrare: - origine dell'inferenza; - metodo; - finalità; - confidenza; - possibilità di contestazione; - diritto alla rettifica; - retention; - soggetti autorizzati. ### 11.4 Portabilità Il diritto GDPR alla portabilità si applica in condizioni specifiche, non a tutti i dati posseduti da una piattaforma.[R1] Cortex One deve distinguere: - dati forniti dall'interessato; - dati osservati; - dati derivati; - dati inferiti; - dati di terzi; - proprietà intellettuale e segreti; - limiti tecnici e giuridici. L'export dovrebbe includere dati, provenance, consensi e schemi in formati interoperabili. ### 11.5 EUDI Wallet, DID e credenziali Il quadro europeo dell'identità digitale richiede wallet interoperabili basati su specifiche comuni e un'Architecture and Reference Framework condivisa.[R2][R3] LaaP dovrebbe trattare EUDI Wallet come possibile fonte ad alto assurance, non come concorrente. W3C Verifiable Credentials 2.0 definisce un modello per attestazioni verificabili nell'ecosistema issuer-holder-verifier; DID definisce identificatori decentralizzati e documenti associati.[R4][R5] YOU può utilizzare questi standard senza coincidere con essi: YOU aggiunge contesto, evidence graph, policy, agenti e memoria semantica. ### 11.6 Data Governance Act e intermediazione Un futuro marketplace di permessi o monetizzazione deve essere valutato rispetto al Data Governance Act, applicabile dal 24 settembre 2023,[R6] e alle regole sui servizi di intermediazione dati. La neutralità, la separazione delle attività e il divieto di sfruttare i dati per finalità proprie possono incidere sul modello societario. Il principio corretto è: > Cortex non vende automaticamente dati personali. Abilita una decisione documentata del partecipante, dentro un quadro giuridico applicabile. ### 11.7 Data Act Il Data Act, applicabile dal 12 settembre 2025, rafforza l'accesso e l'uso dei dati generati da prodotti connessi.[R7] I connettori LaaP possono diventare un layer semantico sopra questi flussi, ma devono rispettare condizioni, segreti commerciali, sicurezza e diritti delle parti. ### 11.8 AI Act Cortex One può integrare modelli general-purpose e costruire sistemi AI verticali. L'AI Act europeo è il quadro generale di riferimento e gli obblighi per provider di GPAI sono entrati in applicazione il 2 agosto 2025.[R8][R9] La classificazione dipenderà dall'uso. Recruiting, accesso a servizi essenziali, credito, salute o biometria possono ricadere in aree ad alto rischio o soggette a obblighi specifici. Il protocollo dovrebbe supportare: - logging; - human oversight; - documentazione; - data governance; - transparency; - risk management; - model and system identification; - incident reporting. ### 11.9 Fingerprinting e Pre-YOU Un fingerprint non è automaticamente anonimo. Persistenza, unicità e combinazione con altre fonti possono renderlo dato personale o pseudonimo. La Pre-YOU deve quindi preferire: - identificatore locale; - rotazione; - TTL; - minimizzazione; - no cross-site tracking; - consenso quando richiesto; - trasparenza; - cancellazione; - separazione tra analytics e identity. ### 11.10 Health e categorie particolari Dati sanitari, biometrici, politici, religiosi e altre categorie particolari richiedono regole rafforzate. Il dominio Health non deve attivare monetizzazione individuale per default. Ricerca e data altruism richiedono governance separata, consenso forte e valutazione legale. ## 12. Federazione, discovery e trust ### 12.1 Perché federare LaaP raggiunge il proprio obiettivo soltanto se nodi costruiti da organizzazioni diverse possono collaborare senza una piattaforma centrale obbligatoria. La federazione deve permettere: - discovery cross-organization; - validazione di issuer e capability; - delega; - routing; - composizione; - policy locale; - revoca; - audit; - portabilità; - isolamento dei fallimenti. ### 12.2 Trust domains Non esiste un trust universale. La rete è composta da trust domain: - personale; - aziendale; - settoriale; - nazionale; - regolamentato; - comunitario. Un nodo può accettare credenziali in un dominio e rifiutarle in un altro. ### 12.3 Registri Registri proposti: - **Node Registry** — identificatori e binding. - **Capability Registry** — Capability Card firmate. - **Issuer Registry** — issuer riconosciuti e assurance. - **Schema Registry** — domini e versioni. - **Policy Profile Registry** — profili condivisi. - **Revocation Registry** — stati di revoca. - **Conformance Registry** — test superati. - **Extension Registry** — estensioni non core. I registri possono essere centralizzati, federati o distribuiti. Il protocollo non impone blockchain. ### 12.4 Discovery Il routing considera: ```text semantic fit × trust × policy compatibility × data locality × availability × latency × cost × conformance × freshness ``` La discovery deve evitare di esporre dettagli sensibili. Una Capability Card può dichiarare “conosco dati payroll” senza rivelare dipendenti o contenuto. ### 12.5 Handshake 1. risoluzione del nodo; 2. recupero Capability Card; 3. verifica firma e scadenza; 4. negoziazione versione; 5. verifica profilo security; 6. exchange di audience e nonce; 7. autorizzazione; 8. invio envelope; 9. receipt e trace. ### 12.6 Cross-node policy Ogni hop applica policy. L'orchestratore non può trasformare un diniego in permesso. La risposta composta conserva: - decision id di ogni nodo; - disclosure applicata; - provenance; - eventuali conflitti; - limiti di riuso. ### 12.7 Delegation chain Una delega può attraversare più agenti, ma la catena deve essere limitata. Ogni grant specifica se è ulteriormente delegabile. Il nodo deve poter imporre `max_delegation_depth`. ### 12.8 Revoca e key rotation La federazione richiede: - key discovery; - rotation; - compromise recovery; - credential status; - capability revocation; - cache invalidation; - grace period; - pinning policy; - transparency log opzionale. ### 12.9 Resilienza Se un nodo è indisponibile, l'orchestratore può usare un'alternativa soltanto se: - l'alternativa è autorizzata; - la fonte è equivalente; - la provenienza è dichiarata; - la qualità minima è rispettata; - la policy consente il fallback. Non deve sostituire silenziosamente una fonte autorevole con una fonte inferita. ## 13. Interoperabilità con standard e protocolli esistenti LaaP non deve posizionarsi come sostituto universale. Il valore è l'orchestrazione semantica e di trust. | Standard / Protocollo | Cosa risolve | Relazione con LaaP | |---|---|---| | HTTP / MQTT | trasporto e messaging | binding possibili | | OpenAPI | descrizione formale di API HTTP | può alimentare tool e Capability Card | | OAuth 2.0 / OIDC | autorizzazione e autenticazione federata | base per accesso e identity | | JWT / JWS / DPoP | claim, firma e proof-of-possession | profilo security | | W3C DID | identificatori decentralizzati | possibile identifier layer | | W3C Verifiable Credentials | attestazioni verificabili | evidence e assurance | | EUDI Wallet | wallet regolamentato UE | issuer/holder ad alto trust | | Solid | personal data store e controllo accessi | possibile data plane personale | | MCP | accesso di modelli a resource, prompt e tool | tool/context binding | | A2A | interoperabilità tra agenti | agent transport e collaboration | | OPA | policy-as-code | decision engine locale | | JSON-LD / RDF / schema.org | semantica e linked data | rappresentazione di domini e claim | ### 13.1 OpenAPI OpenAPI descrive capacità HTTP in modo formale e language-agnostic.[R10] LaaP può generare una Capability Card da OpenAPI o associare un'intenzione a un'operation. Non elimina il contratto tecnico: lo rende discoverable attraverso un contratto semantico. ### 13.2 MCP MCP consente a un client AI di usare resources, prompts e tools attraverso un protocollo con capability negotiation.[R11] LaaP può utilizzare MCP all'interno di un nodo o tra orchestratore e tool provider. La differenza principale è che LaaP rende centrali identity, purpose, consent, provenance, policy at source e risposta semantica. ### 13.3 A2A A2A 1.0 definisce comunicazione e collaborazione tra agenti indipendenti, incluse capability discovery e task.[R12] LaaP può essere un profilo semantico e di trust sopra A2A, oppure usare A2A come binding. ### 13.4 DID e Verifiable Credentials DID e VC non definiscono una memoria personale completa né routing semantico. Forniscono primitive di identità e attestazione. YOU può essere implementata con DID/VC, ma deve anche gestire: - account evidence; - context projection; - consent; - semantic claims; - delegation; - agent identity; - provenance; - policy. ### 13.5 Solid Solid separa dati e applicazioni attraverso Personal Online Data Stores controllati dal soggetto.[R13] LaaP condivide il principio di sovranità, ma aggiunge nodi che elaborano localmente, estraggono significato e restituiscono evidence. Un Solid Pod può essere una fonte di un Semantic Node. ### 13.6 EUDI Wallet EUDI Wallet fornisce identità e documenti digitali interoperabili. Cortex One dovrebbe integrarlo per verificare attributi, evitando di duplicare funzioni regolamentate. YOU è il layer semantico e agentico che usa credenziali, memoria e consensi nel tempo. ### 13.7 Data spaces e ontologie LaaP può collegarsi a data spaces europei e settoriali. Il Domain Standard dovrebbe mappare le proprie ontologie a standard esistenti e documentare le divergenze. L'interoperabilità semantica richiede governance, non solo conversione automatica. ## 14. Governance, versioning e conformità ### 14.1 Artefatti normativi Una release LaaP dovrebbe contenere: - core specification; - security profiles; - semantic envelope schema; - Capability Card schema; - consent and delegation profile; - error registry; - domain governance rules; - conformance tests; - reference examples; - migration guide. ### 14.2 Versioning Il protocollo usa semantic versioning: - major: incompatibilità; - minor: capacità backward-compatible; - patch: chiarimenti e correzioni. Ogni messaggio dichiara versione. Ogni nodo dichiara range supportato. ### 14.3 Estensioni Le estensioni devono usare namespace. Un nodo deve ignorare estensioni non critiche sconosciute e rifiutare quelle marcate `critical`. ### 14.4 Conformance levels **Core Conformant** - envelope; - identity; - capability; - policy; - response; - audit. **Secure Node** - profile security avanzato; - PoP; - key rotation; - threat tests. **Federated Node** - discovery; - trust registry; - delegation; - cross-node trace. **Sovereign Node** - local processing; - export; - policy ownership; - model locality controls. **Domain Certified** - conformità a un dominio specifico. ### 14.5 Test La suite deve includere: - schema validation; - negative tests; - replay; - expired credential; - audience mismatch; - policy denial; - prompt injection; - provenance loss; - conflicting claims; - disclosure attacks; - version negotiation; - failover; - revocation. ### 14.6 Governance process Proposta: 1. issue pubblica; 2. design proposal; 3. security/privacy review; 4. prototype; 5. interoperability test; 6. public comment; 7. decision record; 8. release candidate; 9. stable release; 10. deprecation window. ### 14.7 Fondazione e reference implementation La governance deve prevenire il controllo esclusivo di Cortex One sullo standard. Possibili strumenti: - board multi-stakeholder; - technical steering committee; - public roadmap; - conflict-of-interest policy; - trademark policy; - independent conformance labs; - transparent certification fees; - open source reference implementation; - right to implement. ### 14.8 Licenze Separare: - specifica; - codice; - documentazione; - ontologie; - dataset di test; - marchi; - certificazione. La licenza MIT può essere adatta al codice, ma non risolve automaticamente governance di specifica e marchio. ## 15. Ecosistema e modello economico ### 15.1 Principio Il modello economico deve allinearsi alla promessa di sovranità. Il ricavo non può dipendere dalla vendita opaca dei dati personali. Linee possibili: - subscription B2C; - enterprise licensing; - managed Semantic Node; - conformance e certification; - connector marketplace; - agent marketplace; - domain pack; - support e professional services; - usage-based orchestration; - verified attribute requests; - consented intent marketplace; - revenue share trasparente. ### 15.2 Cortex One La progressione prodotto è: ```text Identity → Memory → Consent → AI → Value ``` Piani possibili: - Free; - Plus; - Pro; - Sovereign; - Enterprise. Il piano Sovereign differisce per isolamento, modello locale, backup, policy e audit, non soltanto per quantità di storage. ### 15.3 Monetizzazione controllata Modelli ammissibili da valutare legalmente: - paid permission; - intent matching; - verified profile access; - aggregated insight; - research participation; - agent negotiation; - personal data dividend. Ogni transazione deve mostrare: - chi paga; - quale informazione; - finalità; - durata; - revoca; - quota utente; - fee piattaforma; - conseguenze. ### 15.4 Foundation economics Una governance sostenibile può finanziarsi tramite: - membership; - certification; - training; - events; - grants; - sponsorship con regole; - conformance services; - donations. Il protocollo core deve restare accessibile senza fee discriminatorie. ### 15.5 Moat Il vantaggio non è il singolo LLM. È la combinazione di: - trust; - domain ontologies; - provenance graph; - consent history; - conformance; - connector ecosystem; - federation; - brand; - operational know-how; - reference implementation. ### 15.6 Confine con il business plan Questo white paper definisce architettura e principi. TAM, pricing, forecast e go-to-market devono essere mantenuti in un Business Plan separato e aggiornato con fonti verificabili. ## 16. Percorso per builder e organizzazioni ### 16.1 Costruire un Semantic Node Passi: 1. identificare dominio e owner; 2. classificare dati; 3. definire fonti autorevoli; 4. creare ontologia; 5. modellare entità e relazioni; 6. definire Capability Card; 7. implementare identity e policy; 8. costruire tool read-only; 9. aggiungere semantic extractor; 10. implementare provenance; 11. testare prompt injection e disclosure; 12. pubblicare capability; 13. eseguire conformance suite; 14. monitorare drift e qualità. ### 16.2 Repository minimo ```text semantic-node/ ├── README.md ├── DOMAIN.yaml ├── CAPABILITY.yaml ├── SECURITY.md ├── PRIVACY.md ├── policies/ ├── ontology/ ├── tools/ ├── prompts/ ├── schemas/ ├── tests/ ├── conformance/ └── deploy/ ``` ### 16.3 Domain Standard Ogni dominio contiene: ```text README DOMAIN.yaml ontology entities relationships workflows policies agents prompts examples tests ``` Lifecycle: ```text Draft → Experimental → Beta → Stable → Deprecated ``` ### 16.4 Capability Card authoring Una buona Capability Card dice anche cosa il nodo non sa. Deve evitare formule marketing come “posso rispondere a tutto”. ### 16.5 Data onboarding Modalità: - database read-only; - API; - event stream; - file; - personal data store; - authenticated browser; - manual evidence; - verified credentials. Ogni fonte ha un adapter, una policy e un provenance profile. ### 16.6 LLM boot del nodo Il boot semantico può: - analizzare schema; - campionare dati minimizzati; - proporre entità; - rilevare relazioni; - generare descrizioni; - suggerire capability; - creare test. Non deve pubblicare automaticamente un'ontologia stabile. Serve human-in-the-loop. ### 16.7 Fine-tuning Il fine-tuning può essere utile per classificazione, mapping o stile, ma non sostituisce: - knowledge base; - retrieval; - policy; - provenance; - test; - aggiornamento dati. Human feedback e informazioni certe possono creare dataset, purché consenso, qualità e licenza siano gestiti. ### 16.8 Checklist di pubblicazione - owner nominato; - threat model; - DPIA se necessaria; - policy testate; - no secret in prompt; - provenance completa; - negative tests; - rate limit; - retention; - revocation; - observability; - fallback; - human escalation; - versioning; - incident contacts. ## 17. Misurazione, benchmark e agenda di ricerca ### 17.1 Perché misurare Una demo convincente non dimostra un protocollo. Servono benchmark riproducibili. ### 17.2 Metriche di routing - top-1 node accuracy; - top-k recall; - clarification precision; - unsupported intent detection; - false route rate; - route stability; - latency; - cost; - fallback success. ### 17.3 Metriche di risposta - factual support; - evidence coverage; - provenance accuracy; - answer completeness; - policy compliance; - disclosure; - calibration; - temporal correctness; - contradiction rate; - human satisfaction. ### 17.4 Metriche di privacy - raw bytes exported; - personal data fields disclosed; - query reconstruction risk; - retention; - deletion completeness; - consent enforcement; - external-model exposure. ### 17.5 Baseline Confrontare: 1. API diretta; 2. RAG centralizzato; 3. tool-calling; 4. MCP; 5. LaaP single-node; 6. LaaP multi-node. ### 17.6 Dataset Creare dataset sintetici e anonimizzati per: - sales; - HR; - real estate; - energy; - personal work identity. I test devono includere ambiguità, conflitti, dati mancanti e attacchi. ### 17.7 Research questions - come misurare semantic fit; - come calibrare confidence; - come federare ontology; - come prevenire inference attacks; - come rappresentare purpose; - come verificare output LLM; - come comporre policy; - come gestire semantic drift; - come valutare deleghe agentiche; - come mantenere il grafo senza centralizzare dati. ### 17.8 Milestone scientifica Prima di v1.0: - protocol schema pubblico; - due implementazioni indipendenti; - interoperability test; - threat model review; - privacy review; - benchmark pubblico; - conformance suite; - governance charter. ## 18. Stato Attuale e Roadmap ### 18.1 Snapshot dichiarato: v0.13 (Giugno 2026) **Infrastruttura dichiarata dal team di progetto (Azure AKS):** - ✅ 12/12 container attivi e healthy - ✅ semantic-node operativo (SQLite + CSV + Multi-LLM) - ✅ orchestrator-node con intent routing - ✅ knowledge-graph-node (NetworkX) - ✅ identity-node (Keycloak 26.2 + PKCE + LaaP JWT) - ✅ interaction-node (React/TS + FastAPI) - ✅ cortex-brain (LangGraph 1.2.2 ReAct) - ✅ mosquitto / Cortex Pulse (MQTT) **Identità:** - ✅ Pre-YOU Identity dichiarata (identificatore pseudonimo data-minimized e credenziale effimera) - ✅ GDPR consent flow - ✅ Trasparenza totale: il partecipante vede cosa sa il sistema, può cancellare tutto - 🔜 YOU Certified Identity (v0.14) **Cortex One:** - ✅ LiveCockpit con infrastructure graph - ✅ Cortex Brain agente (ReAct, LangGraph) - ✅ Custom tool registry + Tool Builder inline - ✅ KG resolution broadcast + Entity Correlator - ✅ KG-guided routing - ✅ Sito pubblico: laap.world + cortex-one.laap.world ### 18.2 Roadmap | Versione | Feature | Stato | |----------|---------|-------| | v0.1–0.3 | Core infrastructure, nodi base | ✅ Done | | v0.4–0.6 | OPA integration, semantic routing | ✅ Done | | v0.7 | Knowledge Graph base | ✅ Done | | v0.8 | Cortex Brain (LangGraph) | ✅ Done | | v0.9 | Sito pubblico, YOU card, framing LaaP/Cortex One | ✅ Done | | v0.10 | LiveCockpit + neural UI | ✅ Done | | v0.11 | Custom tool registry + Agent Editor | ✅ Done | | v0.12 | KG resolution broadcast + KG-guided routing | ✅ Done | | v0.13 | Visitor Identity Flow + Pre-YOU Identity | ✅ **Corrente** | | v0.14 | YOU Certified Identity | 🔜 Prossimo | | v0.15 | Admin panel, YOU post-approval workflow | 🔜 Pianificato | | v1.0 | Federazione: più nodi da più costruttori | 🎯 Target | --- > **Nota di maturità:** le voci di questa sezione descrivono lo stato dichiarato della reference implementation. Prima di una pubblicazione come standard o di una due diligence esterna, devono essere accompagnate da repository, test riproducibili, evidenze di deploy, conformance report e benchmark. ## 19. The Signal — Corpo Editoriale The Signal è la sezione editoriale/ricerca di LaaP Foundation. Pubblica articoli che esplorano le implicazioni del protocollo LaaP sull'industria, sull'architettura software, e sulla società. ### Articoli pubblicati: **#001 — From Authentication to Identity: A New Foundation for Intelligent Systems** *Data: 2026-06-08 · Lingua: EN* L'autenticazione risponde: "hai il permesso?". L'identità risponde: "chi sei?". Per i sistemi intelligence-native, questa distinzione cambia tutto. L'articolo fondativo che introduce la necessità di un layer di identità semantica nei sistemi AI. **#002 — La Potenza di YOU: la Tua Identità Digitale Torna al Centro** *Data: 2026-06-09 · Lingua: IT* YOU non è un altro account. È una rappresentazione personale, evolutiva e controllata dalla persona. L'articolo introduce il concetto di YOU come aggregatore di identità frammentate e come punto di ricomposizione della sovranità digitale. **#003 — Microservices Expose APIs. Microdomains Expose Meaning.** *Data: 2026-06-09 · Lingua: EN* I microservizi sono stati costruiti per applicazioni che parlano con applicazioni. Ma l'AI ragiona per intenti, non per endpoint. Introduce la distinzione fondamentale tra Microdomain e Microservizio e perché l'architettura enterprise deve evolversi. **#004 — The Most Valuable Asset in Your Company Is Invisible** *Data: 2026-06-11 · Lingua: EN* Ogni azienda sa dove sono i propri dati. Quasi nessuna sa dove è la propria conoscenza. La frammentazione della conoscenza è il vero freno all'adozione dell'AI enterprise. Introduce il problema che i Semantic Node risolvono. **#005 — Nodes Discover Entities. Networks Discover Knowledge.** *Data: 2026-06-11 · Lingua: EN* L'intelligenza emerge dalle connessioni, non dai record isolati. Il futuro dei sistemi AI è la rete semantica, non l'integrazione dei dati. Approfondisce il Knowledge Graph LaaP e come la conoscenza emerge dalla rete. **#006 — La Prima Persona in Rete: YOU vs Account** *Data: 2026-07-20 · Lingua: IT* Siamo stati utenti per troppo tempo. Un account appartiene alla piattaforma. Un'identità appartiene alla persona. YOU è la prima vera presenza digitale che non si può toglierti. Il caso LinkedIn: cosa succede quando ti bloccano l'account? Introduce la distinzione tra utente e partecipante nella sua forma più narrativa e accessibile. --- ## 20. Visione — L'Era della Partecipazione Intelligente ### 20.1 Tre Ere della Rete Ogni era di Internet ha connesso qualcosa di diverso: **Web 1.0 — L'Era dei Documenti (1990–2004)** Internet connetteva documenti. Il protocollo fondamentale era l'hyperlink. Le persone leggevano contenuti statici, ma non interagivano. **Web 2.0 — L'Era delle Persone (2004–2020)** Internet connetteva persone. Il protocollo fondamentale era il social graph. Le persone creavano contenuti, ma le piattaforme possedevano le identità e i dati. **L'Era LaaP — L'Era dei Partecipanti (2025–)** Internet connette partecipanti intelligenti. Il protocollo fondamentale è LaaP. Le persone, le organizzazioni e gli agenti AI interagiscono come partecipanti sovrani — con identità proprie, dati propri, conoscenza propria. ### 20.2 Cosa Diventa Possibile con LaaP Quando il linguaggio diventa infrastruttura, quando l'identità appartiene alla persona, e quando la conoscenza è sovrana nel nodo che la detiene, diventano possibili scenari che oggi sembrano fantascienza: **L'assistente che conosce davvero il tuo business** Un agente AI può interrogare, con il tuo consenso, i Semantic Node della tua organizzazione e rispondere a domande complesse sul tuo business — senza che i tuoi dati escano mai dalla tua infrastruttura. **L'identità che ti segue, non la piattaforma** Cambi fornitore di CRM? La tua YOU rimane. Cambi social network? La tua YOU rimane. La tua reputazione digitale, le tue competenze certificate, i tuoi consensi — tutto quello che è te — è tuo e portabile. **La rete di conoscenza federata** Più organizzazioni possono partecipare alla stessa rete LaaP, ognuna con i propri Semantic Node, ognuna con la propria sovereignty. La rete emerge come somma delle loro conoscenze dichiarate — senza data sharing, senza integrazione punto-a-punto. **Agenti AI come colleghi verificabili** Gli agenti AI che agiscono nella tua organizzazione hanno un'identità YOU verificabile. Sai chi ha fatto cosa, ogni agente è auditabile, ogni azione è tracciata. L'AI smette di essere una black box — diventa un partecipante trasparente. ### 20.3 Il Ruolo della LaaP Foundation La LaaP Foundation non costruisce tutte queste applicazioni. Definisce il protocollo su cui altri possono costruirle. Come la IETF definisce TCP/IP ma non costruisce i router, come il W3C definisce HTML ma non costruisce i browser — la LaaP Foundation definisce il protocollo e lascia che l'ecosistema lo implementi. **Cortex One** è la prova di concetto: dimostrazione che il protocollo funziona, piattaforma dove i partecipanti possono sperimentarlo, e punto di riferimento per chi vuole costruire la propria implementazione. Il futuro di LaaP è federato: molte piattaforme, molte organizzazioni, molti agenti AI — tutti partecipanti della stessa rete aperta. ### 20.4 Perché Adesso I modelli di linguaggio di nuova generazione hanno reso possibile ciò che prima era impraticabile: la comprensione del linguaggio naturale a un livello di qualità sufficiente per farne l'infrastruttura di comunicazione tra sistemi. Al contempo, l'adozione enterprise dell'AI ha rivelato con precisione il problema strutturale: i modelli ci sono, ma l'infrastruttura per dargli accesso sicuro, sovrano e contestualizzato alla conoscenza aziendale non esiste. LaaP è quella infrastruttura. Non è una promessa futura — è un protocollo che gira su Azure AKS, con 12 container healthy, con identità Pre-YOU già live, con Cortex Brain che instrada intenzioni reali verso Semantic Node reali. Il linguaggio è sempre stato il protocollo della collaborazione umana. È ora di renderlo il protocollo della rete. --- ## Appendice A — Vocabolario LaaP Glossario dei termini fondamentali del protocollo: **LaaP (Language as a Protocol)** Il paradigma architetturale aperto che definisce il linguaggio naturale come protocollo di comunicazione tra sistemi intelligenti. **LaaP Foundation** Il modello di governance proposto per mantenere specifiche, Manifesto, registri e conformità. Forma giuridica, processo e licenze devono essere formalizzati separatamente. **YOU** Il concetto di identità digitale sovrana di LaaP Foundation. Non un account, ma una presenza nel protocollo: persistente, contestuale, sovrana, portabile, verificabile, evolutiva. **Pre-YOU Identity** Il primo livello di identità LaaP: un principal pseudonimo data-minimized con credenziale effimera. Non richiede dati anagrafici diretti, ma deve essere trattato secondo le regole applicabili ai dati personali o pseudonimi. Dichiarato live nella v0.13. **YOU Certified** Il secondo livello: identità verificata con LaaP JWT firmato crittograficamente, portabile cross-nodo. In arrivo in v0.14. **LaaP JWT** Il JSON Web Token del protocollo LaaP: JWT standard esteso con claim `laap.*` che descrivono il tipo di identità, il livello di certificazione, i consensi attivi e il nodo emittente. **Semantic Node / Microdomain** L'unità architetturale fondamentale di LaaP. Un nodo che espone significato (non API), con OPA integrato e data sovereignty by design. **Capability Card** Il documento di auto-dichiarazione di un Semantic Node: descrive cosa sa, cosa può fare, e sotto quali policy opera. Scritto in linguaggio naturale. **Intent Routing** Il meccanismo di routing basato su intenzioni semantiche (non su URL o endpoint). L'orchestratore usa le Capability Cards per instradare le intenzioni ai nodi appropriati. **Cortex Pulse** Il layer di comunicazione asincrona tra nodi LaaP. Implementato con MQTT (Eclipse Mosquitto). Tutti i messaggi interni al sistema transitano per Cortex Pulse. **Cortex Brain** Il layer di intelligenza artificiale di Cortex One. Agente ReAct basato su LangGraph 1.2.2. Coordina chiamate a Semantic Node multipli per rispondere a intenzioni complesse. **Knowledge Graph** La rappresentazione emergente delle entità e delle relazioni nel dominio di conoscenza. Non è costruito manualmente — emerge dalle interazioni dei nodi. **Partecipante** Chi interagisce nella rete LaaP: umano, organizzazione, o agente AI. Diverso da "utente": un partecipante ha la propria identità YOU e non è ospite di nessuna piattaforma. **OPA (Open Policy Agent)** Il motore di policy integrato in ogni Semantic Node. Garantisce che la policy di accesso viva nel nodo sorgente (sovereignty by design). **Zero Trust Semantico** Il modello di sicurezza di LaaP: nessuna richiesta è trusted per default. Ogni interazione deve portare un LaaP JWT valido e passare la valutazione OPA del nodo ricevente. **Cortex One** La prima piattaforma costruita su LaaP Foundation. Non è LaaP — è la prima implementazione del protocollo. --- ## Appendice B — LaaP Semantic Envelope ### B.1 JSON Schema concettuale ```json { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://laap.world/schema/envelope/0.2", "type": "object", "required": [ "protocol", "version", "message_id", "timestamp", "principal", "intent", "security" ], "properties": { "protocol": { "const": "laap" }, "version": { "type": "string" }, "message_id": { "type": "string", "format": "uri" }, "timestamp": { "type": "string", "format": "date-time" }, "principal": { "type": "object", "required": ["subject", "assurance"], "properties": { "subject": { "type": "string" }, "actor": { "type": "string" }, "on_behalf_of": { "type": "string" }, "assurance": { "type": "string" } } }, "intent": { "type": "object", "required": ["text", "language", "purpose"], "properties": { "text": { "type": "string", "minLength": 1 }, "language": { "type": "string" }, "purpose": { "type": "string" }, "expected_output": { "type": "string" } } }, "context": { "type": "object" }, "constraints": { "type": "object" }, "authorization": { "type": "object" }, "security": { "type": "object", "required": ["audience"], "properties": { "audience": { "type": "string" }, "proof_type": { "type": "string" }, "nonce": { "type": "string" } } }, "trace": { "type": "object" } }, "additionalProperties": true } ``` ### B.2 Regole - `intent.text` non viene interpretato prima dei security pre-check. - `purpose` è obbligatorio. - `audience` è obbligatoria. - l'envelope non contiene segreti; - gli allegati hanno hash, classificazione e policy; - ogni hop mantiene `correlation_id`; - campi critici sconosciuti causano rifiuto. ## Appendice C — Capability Card ```yaml laap_capability: version: 0.2 node_id: did:web:sales.example.com name: EMEA Sales Semantic Node publisher: did:web:example.com issued_at: 2026-07-22T00:00:00Z expires_at: 2026-10-22T00:00:00Z domain: id: sales version: 1.4 description: "Vendite aggregate e performance commerciale EMEA" intents: - id: sales.performance.summary examples: - "Come sono andate le vendite EMEA nel Q2?" output_types: - analytical_summary minimum_assurance: L2 scopes: - sales.read.aggregate disclosure: maximum: aggregate limitations: - "Non fornisce dati individuali dei clienti" data_classes: - commercial_confidential - customer_aggregate bindings: - type: https endpoint: https://sales.example.com/laap - type: a2a endpoint: https://sales.example.com/.well-known/agent-card.json security: proof: - dpop token_issuers: - https://identity.example policy_profile: laap-enterprise-1 conformance: core: 0.2 secure_node: true report: https://example.com/conformance/report.json signature: type: jws value: ... ``` ## Appendice D — Domain Manifest ```yaml id: work name: Work version: 1.0.0 status: beta owner: Cortex Domain Council dependencies: - identity concepts: - ProfessionalProfile - Competence - Experience - Certification - Project - Employer authoritative_sources: Experience: - employer_credential - signed_contract Competence: - certification - project_evidence - self_assertion relationships: - id: HAS_COMPETENCE from: ProfessionalProfile to: Competence - id: WORKED_FOR from: ProfessionalProfile to: Employer policies: default_visibility: private consent_required: true raw_data_sale: prohibited agents: - work_agent - recruiter_agent quality: provenance_required: true temporal_validity_required: true conflict_policy: preserve_all ``` ## Appendice E — Matrice sintetica delle minacce | Minaccia | Asset | Impatto | Controlli principali | |---|---|---|---| | Token replay | identità | accesso illecito | DPoP, nonce, TTL, audience | | Prompt injection | tool e dati | esfiltrazione/azioni | sandbox, policy, allowlist | | Capability poisoning | routing | nodo malevolo | firma, registry, scadenza | | KG poisoning | conoscenza | decisioni errate | provenance, dispute, expiry | | Semantic differencing | privacy | re-identificazione | query budget, aggregation | | Confused deputy | delega | privilege escalation | actor/on-behalf-of, scope | | Model downgrade | dati | esposizione esterna | model policy, no silent fallback | | Supply chain | runtime | compromissione | SBOM, signature, scanning | | Consent drift | privacy | uso non autorizzato | receipt, revocation, purpose | | Audit overcollection | privacy | nuovo silo sensibile | minimization, hash, retention | ## Appendice F — Riferimenti **[R1]** European Commission, *Can individuals ask to have their data transferred to another organisation?* https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/dealing-citizens/can-individuals-ask-have-their-data-transferred-another-organisation_en **[R2]** Regulation (EU) 2024/1183, European Digital Identity Framework. https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng **[R3]** European Commission, *EU Digital Identity Wallet Architecture and Reference Framework*, version 2.0 announced 29 May 2025. https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/900014854/Version+2.0+of+the+Architecture+and+Reference+Framework+now+available **[R4]** W3C, *Verifiable Credentials Data Model v2.0*. https://www.w3.org/TR/vc-data-model-2.0/ **[R5]** W3C, *Decentralized Identifiers (DIDs) v1.0*. https://www.w3.org/TR/did-1.0/ **[R6]** European Commission, *European strategy for data: Data Governance Act becomes applicable*, 24 September 2023. https://digital-strategy.ec.europa.eu/en/news/european-strategy-data-data-governance-act-becomes-applicable **[R7]** European Commission, *Data Act enters into force: what it means for you*; application from 12 September 2025. https://commission.europa.eu/news-and-media/news/data-act-enters-force-what-it-means-you-2024-01-11_en **[R8]** European Commission, *AI Act — Regulatory framework*. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai **[R9]** European Commission, *General-purpose AI obligations under the AI Act*. https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act **[R10]** OpenAPI Initiative, *OpenAPI Specification*. https://spec.openapis.org/oas/ **[R11]** Model Context Protocol, *Specification*. https://modelcontextprotocol.io/specification/ **[R12]** Agent2Agent Project, *A2A Protocol Specification 1.0*. https://a2a-protocol.org/latest/specification/ **[R13]** Solid Project, *Solid Protocol*. https://solidproject.org/ED/protocol **[R14]** IETF, RFC 9449, *OAuth 2.0 Demonstrating Proof of Possession (DPoP)*. https://www.rfc-editor.org/rfc/rfc9449.html **[R15]** IETF, RFC 8725, *JSON Web Token Best Current Practices*. https://www.rfc-editor.org/rfc/rfc8725.html **[R16]** Open Policy Agent, *Documentation*. https://www.openpolicyagent.org/docs **[R17]** OASIS, *MQTT Version 5.0*. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html --- ## Nota editoriale finale La pubblicazione pubblica dovrebbe essere preceduta da: - revisione legale; - revisione privacy; - review crittografica; - verifica indipendente dello stato implementativo; - uniformazione dei termini italiani e inglesi; - rimozione di claim non dimostrati; - definizione della licenza; - indicazione dello status giuridico della Foundation; - repository pubblico della candidate specification; - call for comments. --- *LaaP — Language as a Protocol · White Paper Candidate v0.2 · 22 luglio 2026* *Reference implementation: Cortex One* --- ## Firma dell'autore **Matteo Masina** C.T.O. at eFM Founder LaaP [https://laap.world](https://laap.world) LinkedIn: [www.linkedin.com/in/matteo-masina-06845827](https://www.linkedin.com/in/matteo-masina-06845827) Email: [matteo.masina@laap.world](mailto:matteo.masina@laap.world)