È la policy completa?
Verificare identità del documento, sezioni richieste, lingua e passaggio finale rispetto a un contratto di fonte revisionato.
Programma sperimentale
Quaderno di progetto / 01
Engine 6Preview
Un percorso più chiaro dalla fonte alle prove.
Engine 6 Preview è in sviluppo e sperimentazione per rendere più tracciabili recupero, confronto e validazione delle policy. Questa pagina rende il progetto consultabile.
ArchitetturaTre domande guidano la sperimentazione.
Quali prove sostengono la conclusione?
Collegare catture congelate, citazioni esatte e una verifica separata a ogni cambiamento proposto.
Il lavoro può riprendere in sicurezza?
Salvare attività, tentativi e checkpoint affinché un’interruzione non cancelli i progressi né pubblichi due volte la stessa modifica.
01 / Architettura
Le prove attraversano confini espliciti.
Le fonti ufficiali entrano in un’area di lavoro privata. Un record pubblico nasce solo dopo il superamento dei controlli richiesti. Recupero, analisi AI e invio hanno responsabilità separate.
Leggi il diagramma in forma testuale
- Fonte ufficiale
HTTP diretto, HTTP/2 e un renderer browser configurato offrono percorsi di recupero con limiti. Le catture d’archivio non attestano la disponibilità live attuale.
- Lavoro e prove private
Attività persistenti, attese per origine, artefatti congelati e checkpoint conservano il percorso di recupero e analisi. Osservazione e pubblicazione mantengono stati distinti.
- Confine di pubblicazione
Le modifiche complete e supportate possono essere registrate automaticamente a impatto contenuto. L’alto impatto richiede revisione; prove mancanti o incerte restano sospese.
- Record pubblico e invio
Baseline, versione, modifica ed evento di notifica vengono registrati insieme. L’invio avviene dopo e ricontrolla consenso e preferenze.
02 / Flusso decisionale
Una risposta HTTP riuscita avvia i controlli.
Il percorso di modifica richiede due catture nuove in run distinti, distanti almeno un’ora e al massimo sette giorni. Una risposta 304 può riconvalidare una rappresentazione conservata; non conferma un nuovo cambiamento.
- 1
Verificare la fonte
Contratto mancante, deviazione della fonte, contenuto incompleto o lingua incerta → sospendere e registrare il motivo.
- 2
Confrontare la baseline
Contenuto invariato → registrare un controllo verificato. Baseline mancante o incompatibile → revisione prima del confronto.
- 3
Confermare il candidato
Una nuova cattura corrispondente, in un altro run, conferma il candidato. Un retry o una risposta condizionale 304 non valgono come seconda cattura.
- 4
Spiegare ogni blocco modificato
L’analista deve coprire tutti i delta con citazioni esatte prima/dopo. Un verificatore separato controlla ogni affermazione e le due versioni linguistiche.
- 5
Applicare il controllo di pubblicazione
Affermazioni incerte o non supportate → sospensione. Alto impatto verificato → revisione umana. Modifiche complete, supportate e a impatto contenuto → commit atomico se la pubblicazione è abilitata.
L’approvazione umana non sostituisce le prove mancanti. Le riparazioni di fonte o baseline hanno un percorso di revisione dedicato. Una differenza di sola presentazione nell’estrazione non diventa un avviso di modifica della policy del provider.
03 / Entità e relazioni
Le relazioni dietro una modifica registrata.
Mappa concettuale dello schema implementato nella preview. La linea continua indica una chiave esterna esplicita nel database; le linee tratteggiate sono riferimenti gestiti dall’applicazione, inclusi gli identificatori nei checkpoint e nelle prove.
Scorri in orizzontale per leggere tutte le colonne. Da tastiera: seleziona l’area della tabella e usa le frecce.
| Entità | Che cosa registra | Relazione / identità |
|---|---|---|
| EngineRun → EngineTask | Una scansione richiesta e le sue attività riprendibili. | Chiave esterna esplicita runId; un run contiene più attività. |
| EngineAttempt | Ogni assegnazione di una fase e il suo esito. | taskId logico; lo storico dei tentativi è separato dall’attività corrente. |
| EngineArtifact | Prove acquisite o derivate, congelate e controllate per integrità. | ID basato sul contenuto; riferimenti logici nei checkpoint e nelle prove. |
| EngineSourceContract | Aspettative revisionate per uno specifico documento. | Identità policyId; relazione logica con Policy. |
| EnginePolicyState | Scadenza, ultima verifica e conferma del candidato. | Identità composta (policyId, mode); observe e publish sono separati. |
| EngineOrigin · EngineHttpCache | Attese per origine e rappresentazioni condizionali idonee. | Identità per origine / chiave cache; riferimento logico della cache a un artefatto. |
| EngineReview | Prove congelate, motivo, decisione e storico delle revisioni. | taskId/evidenceKey univoci; riferimenti logici a policy, artefatti e modifica. |
| Policy · PolicyChange · EngineOutbox | Baseline pubblica, modifica registrata e invio differito. | PolicyChange → Policy è una FK esistente; changeId dell’outbox è un riferimento applicativo. |
04 / Validazione
Che cosa dimostrano oggi le verifiche.
Verifiche locali registrate il 31 ottobre 2026. Questi risultati sono una base per la qualificazione, non un punteggio di accuratezza in produzione.
Suite automatica di regressione
1.369 superati · 14 esclusi
Le fixture sintetiche non misurano la qualità del recupero sul catalogo reale.
Test specifici del motore
43 superati, inclusi nella suite completa
Un test di pianificazione con 500 record non equivale a 500 recuperi Internet riusciti.
Build e controlli statici
Build di produzione e TypeScript superati; lint senza errori
Restano 15 warning web preesistenti; nessun audit dinamico indipendente di sicurezza è attestato.
Flusso amministrativo
Approvazione e annullamento verificati su DB isolato
Una policy sintetica esplicitamente indicata; nessun invio agli iscritti.
Revisione del codice con modelli
Gemini 4 High e GLM-5.3 Max hanno revisionato candidati congelati
La revisione non è esecuzione né certificazione. Le correzioni successive sono state testate localmente.
Da qualificare
La prossima prova è il catalogo reale.
Prima dell’attivazione live servono un corpus annotato e almeno tre finestre giornaliere complete. L’obiettivo è fino a 500 policy al giorno, con affidabilità e copertura prioritarie.
- Identità e completezza delle fonti
- Falsi cambiamenti e affermazioni non supportate
- Copertura, retry e latenza del recupero
- Token e costo per documento modificato
- Crescita delle prove, backup e ripristino
OCR dei PDF scansiti, ricostruzione generale della struttura PDF, configurazione automatica dei contratti di fonte e cancellazione automatica delle prove sono fuori da questa preview. I documenti ambigui restano in revisione.