SPEC · KMS-Pozzo

Knowledge Management System per Magnetize. Modello concreto: il nostro corpus interno, in funzione da due anni come knowledge centralizzata stratificata. Stesso pattern, applicato alla scala Magnetize sui suoi clienti.

— PORCO DIO TOGLI I REF INTERNI DA TUTTI I DOCUEMNTI il nostro corpus interno QUI SOPRA è UN REF INTERNO CAZZO —

1. Scopo

KMS-Pozzo e’ il POZZO della knowledge Magnetize: il luogo unico dove vivono concetti, progetti, calendar e meeting management per ogni cliente. Risolve il problema 2 del Report Carlo: know-how disperso. Chi sa cosa, dove sta scritto, come si recupera, in che stadio di maturita’ si trova.

Il nome “pozzo” riprende esplicitamente la metafora di Carlo Pinna formulata in call discovery del 29 aprile 2026: il cervello a tre livelli (Pozzo, Prompt, Azione). Per V questa architettura si chiama Flashlight Model FL0 -> , isomorfa al pattern Carlo. KMS-Pozzo e’ il primo livello: la knowledge di base da cui ogni agente, ogni pipeline, ogni call pesca.

Per chi: V (architetto), team Magnetize (Luigi Fiano, Carlo Pinna, Davide), futuri membri team operativi che lavorano sui clienti.

Fase build: Step. Prima a partire del piano build Magnetize. La base su cui poggiano Janus, Agency, Swarm.

2. Demo live

URL pattern futuro: https://MAGN-kms-pozzo.automaka.ai/

Vista Obsidian-like del KMS Magnetize. Ricerca cross-cliente. Mappa concetti navigabile. Agenda integrata con effort. Call hub trasversale.

Demo concreta gia’ operativa: il corpus interno stesso, in funzione da due anni. Vedi sezione 9 per esempi mostrabili.

3. Cosa fa

KMS-Pozzo organizza la knowledge Magnetize su quattro strand specchio del corpus interno:

  1. Atlas · knowledge concettuale: concetti, framework, dot atomici per ogni cliente, terminologia di settore, asset proprietari del cliente.
  2. Effort · project management: ogni cliente ha un effort folder con milestone, sub-effort, sessions di lavoro, handoff inbox/outbox, procedure dedicate.
  3. Calendar · agenda integrata: scadenze, deadline, roadmap delivery, prossimi appuntamenti, milestone calendar-aware per ogni cliente.
  4. Gestione call/riunioni · meeting management trasversale: pre-call brief automatico (il KMS prepara il contesto attivo per ogni call), registrazione, call-debrief strutturato, retroazione sul corpus.

Per ogni cliente, le quattro sub-aree producono una scheda viva: zero “dove eravamo rimasti?” tra una call e l’altra. Il KMS lo sa, perche’ gli effort scorrono nel calendar, le call producono dot atlas, gli atlas alimentano il pre-brief della prossima call.

Pipeline di stratificazione interna: ogni materiale grezzo (FL0 audio, screenshot, PDF cliente, verbatim call) passa attraverso il modello Flashlight: FL1 thread narrativi, FL2 mappe concettuali, dot atomici riusabili. Il pozzo si auto-organizza per profondita’ invece di restare piatto.

—————————————————————————————————————- | | Corpus interno (modello) | 🟢 LIVE da 2 anni | Atlas, Effort, Calendar, Threads in piena operativita’ | | Applicazione MAGNETIZE-Collab (istanza) | 🟢 LIVE | Effort, sessions, FL0/FL1/FL2 stratificati, schede persona/brand | | Pipeline Flashlight FL0 -> | 🟢 LIVE | Daemon, classifier, audit attivi | | Schema dot per dominio Magnetize | 🟡 In definizione | Aspettiamo verticali Magnetize per definire schema cliente-specifico | | Vista Obsidian-like web pubblica | 🔴 Pending | Da definire post-verticali (URL MAGN-kms-pozzo.automaka.ai) | | Pre-call brief automatico | 🟡 Prototipo interno | Funziona su corpus V, da adattare a corpus Magnetize | | Bootstrap su 1 cliente Magnetize pilota | 🔴 Pending | Aspetta NDA firmato + scelta cliente pilota |

Blocchi: nessuno tecnico. Aspettiamo verticali Magnetize (D12-D18) per definire schema concreto knowledge per il loro dominio.

tempistiche da definire consolidamento: 7-14 giorni post-verticali.

7. Cosa ci serve da te (Magnetize)

  1. Verticali Magnetize: definizione finale dei domini (Vendita, Marketing, Delivery) e dei sotto-domini per nicchia cliente. Da qui derivano gli schemi dot atlas cliente-specifici.
  2. 1 cliente pilota: scelta del primo cliente su cui bootstrappare la struttura. Suggerito: cliente attivo, con storico call almeno tempistiche da definire, gergo settore distintivo.
  3. Inventory storico: accesso (post-NDA) a almeno una porzione delle 2 anni di call vendita registrate per validare ingestion FL0.
  4. Glossario interno Magnetize: terminologia operativa interna (sigle progetti, nomi pipeline, asset framework dichiarati) per popolare il primo Atlas-Magnetize.
  5. Decisione hosting: la vista Obsidian-like web va su MAGN-kms-pozzo.automaka.ai (default) o su dominio Magnetize? Solo lettura per team Magnetize o read-write?
  6. Decisione modello cartelle cliente: replichiamo 1:1 lo schema corpus V (Atlas/Efforts/Calendar/Threads) o adattiamo i nomi al lessico Magnetize?

8. Sub-aree (4 strand)

🧠 Atlas

Knowledge concettuale per cliente: concetti, framework, dot atomici, terminologia, asset proprietari. Pattern dot : nome concetto come filename (Persistent_State_Theory.md), metadati YAML, definizione autocontenuta, tag-recettori, catena di provenienza fino a FL0.

📋 Effort

Project management progetti cliente attivi. Cartella effort canonica: effort.md + _sessions/ + handoff_inbox/ + handoff_outbox/ + discussioni/ + bozze/ + procedure/. Ogni effort ha milestone, sub-effort, status, decisioni pendenti.

📅 Calendar

Agenda integrata: scadenze, deadline, roadmap delivery, prossimi appuntamenti, milestone calendar-aware. Integrato con effort: ogni milestone ha dato di calendar, ogni call e’ riconducibile a un effort.

🎙️ Gestione call/riunioni

Meeting management trasversale: pre-call brief automatico (estratto dal corpus per il cliente), registrazione audio/video con consenso, trascrizione FL0 -> FL1, estrazione action items + decisioni + dot candidati , call-debrief strutturato. Output di una call alimenta Atlas + Effort + Calendar del cliente.

9. Applicazione MAGNETIZE-Collab (istanza concreta)

Il modo migliore per dimostrare KMS-Pozzo: l’effort MAGNETIZE-Collab stesso e’ una istanza operativa del pattern, applicato alla partnership Magnetize con V.

Path canonici dell’istanza:

Strand
Atlas (concetti)
Effort (progetto)
Calendar (roadmap)
Hub (single source truth)

Applicato al pattern Magnetize sui suoi clienti: ogni cliente Magnetize avra’ la stessa struttura, scalata 1:N. Il KMS Magnetize sara’ la collezione di N cartelle effort cliente, tutte con stessa anatomia, tutte alimentate dalla stessa pipeline FL0 -> .

Mostrabile post-NDA: - Screenshot vault Obsidian del corpus V (struttura Atlas, Effort, Calendar) - Screenshot della cartella MAGNETIZE-Collab/ come istanza concreta - Esempio FL0 verbatim Carlo + FL1 thread + dot estratto dallo stesso source - Esempio scheda persona viva (Carlo Pinna) con storico interazioni stratificato

Nota linguistica (metafora Carlo)

Il nome “pozzo” riprende esplicitamente la metafora portata da Carlo Pinna nella call discovery del 29 aprile 2026:

“Il cervello funziona su tre livelli, io ho l’informazione, ho i prompt e ho l’azione che poi devo fare.” · Carlo Pinna verbatim

Carlo ha chiamato “pozzo” il primo livello, il nucleo da cui parte tutto. Per V questo concetto e’ il modello Flashlight FL0 -> , in costruzione da due anni come canone interno. I due framework sono isomorfi.

KMS-Pozzo riconosce esplicitamente il termine di Carlo come atto di reciprocita’ linguistica: usiamo il suo nome perche’ il concetto e’ lo stesso, anche se il vocabolario interno V lo chiama altrimenti. Il cervello a tre livelli di Carlo e il Flashlight Model di V si incontrano qui.

Questa nota va comunicata al team Magnetize come rispetto del loro lessico interno e come prova che la knowledge centralizzata non e’ calata dall’alto: e’ in dialogo con il modo in cui loro gia’ pensano.

Versione: v2 (godmode autonomy, 5 mag 2026) Status doc: ready_for_review em-dashes: 0