Architettura di yeah.wiki
yeah.wiki è costruito come monolite modulare attorno a un unico canvas scientifico, con un solo modello di autenticazione, controlli di accesso lato server e riferimenti espliciti alle fonti quando sono disponibili. La copertura effettiva richiede verifiche del runtime.
1. Superficie unica e capacità modulari
L’esperienza utente converge su un’unica superficie di lavoro (Domanda → Fonti → Analisi → Evidenze → Ipotesi concorrenti → Risultato → Esportazione). Le capacità di calcolo, recupero documentale, orchestrazione e verifica operano come infrastruttura interna senza frammentare il prodotto.
2. Scientific Truth Layer
Ogni elaborazione separa lo stato epistemico del contenuto (da VERIFIED DATA aUNKNOWN) dallo stato operativo del runtime (LIVE, VERIFIED,CACHED, ESTIMATED, PARTIAL, UNKNOWN, UNAVAILABLE).
3. Componenti del Core
Intent & Cost-Hierarchy Router
Instradamento deterministico: DETERMINISTIC → CACHE → RETRIEVAL → LOCAL MODEL → SPECIALIZED MODEL → FRONTIER MODEL.
Scientific Knowledge & Provenance
Gestione di documenti autorizzati, metadati DOI (Crossref/OpenAlex), versioning, citazioni e stato di ritrattazione.
Research & Falsification Engine
Progetti di ricerca, teorie, osservazioni, esperimenti, dataset, letteratura e matrici delle evidenze.
Truth Layer
Distinzione rigorosa tra VERIFIED DATA, OBSERVATION, MEASUREMENT, DERIVED METRIC, MODEL, INFERENCE, HYPOTHESIS, REJECTED e UNKNOWN.
Infrastructure & Material Governance
Controllo delle policy operative, tracciabilità delle distinte materiali (BOM) e audit trail con isolamento per utente e tenant.
4. Sicurezza e Isolamento Dati
L’architettura prevede Row-Level Security (RLS), controllo delle autorizzazioni e isolamento dei dati. L’efficacia di ciascun percorso dipende da verifiche runtime e test di isolamento effettivamente eseguiti. Le bozze guest restano confinate nello storage locale del browser e nessun dato privato viene pubblicato o indicizzato automaticamente.
yeah.wiki · Scientific Canvas Architecture · Contatti