Technology / Knowledge Architecture
Diamo una struttura alla conoscenza aziendale.
Lo strato fra i documenti di un'azienda e ciò che la sua AI può davvero usare.
Le aziende hanno un problema di infrastruttura epistemica.
Decisioni, ragionamenti degli esperti, contraddizioni, ipotesi abbandonate, deriva delle versioni: niente di tutto questo è tipizzato in un CRM, in una wiki o in un database vettoriale. Ingerito come testo indifferenziato, viene recuperato per somiglianza — attuale o obsoleto, verificato o assunto, tutto con lo stesso peso.
La knowledge architecture è lo strato che decide come quelle informazioni diventano calcolabili: come vengono tipizzate, tracciate, versionate, fatte decadere, contraddette e recuperate.
RESEARCH
Collaborazione attiva con il MIT sull'ingestione della conoscenza e sull'ottimizzazione dell'inferenza
Non esiste una pipeline pronta all'uso.
La forma giusta dipende da quale conoscenza l'organizzazione produce davvero, da chi la crea, da dove vivono le decisioni e da che cosa deve fare l'AI sottostante. Due aziende dello stesso settore raramente hanno bisogno della stessa pipeline.
KVA conduce l'ingaggio — superficie della conoscenza, pipeline, OBS — sulla tecnologia e sulla ricerca di Project OIDA, la venture accelerata da KVA che lavora sull'infrastruttura della conoscenza epistemica. Le sette fasi qui sotto sono i componenti di riferimento: li calibriamo sul contesto.
Ingestione delle fonti
Documenti, email, riunioni, CRM, codice, database strutturati, interviste agli esperti. Tutto ciò che l'organizzazione produce davvero, non solo ciò che giace in SharePoint.
Segmentazione semantica
Scomposta per affermazione, non per numero di token. L'unità di conoscenza è l'unità di significato, non ciò che entra in un chunk.
Risoluzione di entità e attori
Chi ha detto cosa, in quale ruolo, con quale autorità. La stessa frase detta da un analista junior e da un membro del consiglio non è la stessa frase.
Classificazione epistemica
Ogni unità tipizzata per ruolo epistemico prima dell'archiviazione. Un'ipotesi e una decisione hanno peso nel retrieval, tasso di decadimento e sensibilità alle contraddizioni diversi: confonderle degrada tutto ciò che sta a valle.
Tracciamento della provenienza
Ogni Knowledge Object ancorato allo span della fonte e alle sue catene di dipendenza. Ogni affermazione ricostruibile fino al documento da cui viene.
Confidenza e decadimento
Calcolati con una formula, non da un LLM che ha letto la frase e ne è rimasto convinto. Stesso input, stesso punteggio, ogni volta. I tassi di decadimento sono assegnati in ingestione per tipo di contenuto e dominio, così la conoscenza obsoleta viene segnalata prima del retrieval, non dopo una risposta sbagliata.
Ciclo di vita e contraddizioni
Le affermazioni in conflitto emergono come segnale di prima classe invece di essere mediate in silenzio. Versionamento, superamento, archiviazione: la conoscenza invecchia, e il sistema deve invecchiare con lei.
Nove tipi epistemici
Ogni unità di conoscenza viene classificata in ingestione. Il tipo governa peso nel retrieval, tasso di decadimento e sensibilità alle contraddizioni: è il campo che tutto il resto della pipeline legge.
Decisione
Una scelta risolta con una motivazione documentata
Evidenza
Dati verificati che supportano o confutano un'affermazione
Ipotesi
Una proposizione non testata, in fase di indagine
Osservazione
Un fatto registrato senza interpretazione causale
Domanda aperta
Un problema senza una risposta attuale
Contraddizione
Due informazioni in conflitto
Assunzione
Una premessa accettata senza verifica
Affermazione
Un'asserzione in attesa di validazione
Segnale
Un indicatore debole che richiede accumulo prima di agire
Gli LLM leggono gli schemi, il sistema li definisce.
Il modello mappa il linguaggio naturale su schemi epistemici pre-validati, senza inventare parametri ODE o proporre nuove classi epistemiche.
Le violazioni dello schema falliscono in modo netto, senza fallback.
È l'unico modo per mantenere gli schemi uniformi tra le istanze e l'integrità del grafo intatta nel tempo.
OIDA — conoscenza epistemica per l'era dell'AI.
OIDA è la tech company accelerata da KVA e dedicata all'infrastruttura della conoscenza epistemica; Project OIDA ne è il braccio di ricerca, dove il framework viene formalizzato prima di entrare nei clienti.
Il framework modella la conoscenza organizzativa come quattro strati interconnessi. Lavora al livello epistemologico — cosa si sa, con quanta confidenza, cosa sta decadendo — distinto dalle piattaforme ontologiche (pensa a Palantir) che modellano quali entità esistono e come si relazionano. I due livelli sono complementari.
Knowledge Objects (KOs)
L'unità atomica: tipizzata, tracciata, valutata, con il proprio stato epistemico e gli archi verso ciò che supporta, contraddice e da cui deriva.
Knowledge Gravity Engine (KGE)
Importanza e decadimento calcolati con ODE, non in base all'umore di un LLM. Stabili tra le query, stabili nei mesi.
Hybrid Retrieval
Retrieval denso, sparso e strutturale, pesato in base a ciò che viene effettivamente chiesto. Nessuno dei tre da solo è sufficiente.
Organisational Belief System (OBS)
L'aggregato: in che cosa crede l'organizzazione, con quale confidenza, e come quelle convinzioni si muovono di fronte a nuove evidenze.
Position paper di Project OIDA in preparazione per H2 2026.
Che aspetto ha davvero un Knowledge Object.
La dataclass da un lato, dall'altro l'API con cui lo strato agentico interroga l'OBS. Gli schemi sono calibrati per dominio.
knowledge_object.py
from dataclasses import dataclass
from datetime import datetime
from typing import Literal
EpistemicType = Literal[
"decision", "evidence", "hypothesis",
"observation", "open_question", "contradiction",
"assumption", "claim", "signal",
]
@dataclass(frozen=True)
class KnowledgeObject:
id: str
claim: str
type: EpistemicType
# provenance
source_id: str
source_span: tuple[int, int]
actor: Actor # who, role, authority
# epistemic state — deterministic
confidence: float # [0, 1]
decay_half_life_days: float
created_at: datetime
# graph relationships
supports: list[str]
contradicts: list[str]
derived_from: list[str]obs_query.py
# What does the org currently believe about X,
# and how has that belief evolved?
belief = obs.query(topic="pricing strategy")
belief.consensus
# weighted by confidence and decay state
belief.contradictions
# explicit conflicts among KOs, with sources
belief.evolution(window="18m")
# trajectory over time, decision points marked
belief.decisions_made_under(
snapshot=obs.snapshot_at("2025-Q4"),
)
# which decisions stood on now-decayed beliefs?OBS — ciò in cui l'organizzazione crede, messo per iscritto.
L'Organisational Belief System aggrega i Knowledge Object in uno stato di credenza interrogabile, pesato per confidenza e decadimento. KVA lo istanzia per ogni cliente durante l'ingaggio.
Risponde a domande a cui nessun sistema aziendale attuale sa rispondere:
- 01
In che cosa crede oggi questa organizzazione riguardo a X — e con quanta confidenza?
- 02
Come è cambiata quella convinzione negli ultimi diciotto mesi?
- 03
Quali decisioni sono state prese sotto quali convinzioni, e quelle convinzioni sono nel frattempo decadute?
- 04
Dove gli esperti interni non sono d'accordo — e quali evidenze ha in mano ciascuno?
Che cosa produce un ingaggio.
Audit della knowledge architecture — stato epistemico attuale
Schema dei Knowledge Object, calibrato sul tuo dominio
Pipeline di ingestione con governance epistemica
Validation Gate — fallimento netto, nessun fallback
Istanziazione dell'OBS — la tua organizzazione, modellata
Interfacce di retrieval e di ragionamento
Passaggio di consegne allo strato agentico
Vediamo cosa sa davvero la tua organizzazione.
La maggior parte degli ingaggi parte da un audit mirato della superficie della conoscenza. Da lì progettiamo la pipeline, istanziamo l'OBS e passiamo il testimone allo strato agentico.