Nota di architettura

Il modello di record di decisione

Una decisione non è un output usa-e-getta. È un record strutturato vincolato a evidenza, policy, provenienza, ciclo di vita, riesaminabilità, contesto regolatorio e packaging di audit.

Questa pagina descrive l’identità architetturale di un record di decisione. Il perimetro operativo è verificato per deployment.

I record di decisione come oggetti durevoli

OmegaOS non tratta una decisione come una voce di log. Ogni decisione è un record. Ogni record conserva gli input che l’hanno prodotto, le regole che li hanno valutati e il contesto in cui è avvenuta la valutazione.

Un record resta vincolato al proprio set di evidenze e alla propria versione di policy. Porta un ciclo di vita. Può essere riesaminato. Si compone in una superficie di audit confezionata. Queste proprietà non sono funzionalità aggiunte a una decisione — definiscono cosa sia una decisione in questa architettura.

Confini di superficie

Attributi del record di decisione

Sei attributi definiscono il record come oggetto. Ciascun attributo è descritto di seguito a livello di modello. Il comportamento operativo di ciascun attributo è verificato per deployment.

Stato

  • Definizione: Un record di decisione porta uno stato di ciclo di vita: attivo, richiede rivalidazione, scaduto, sostituito, revocato o invalidato. Lo stato è calcolato in lettura dalla storia del record. Non è memorizzato sul record stesso.
  • Ciò che il modello richiede: La correttezza alla nascita (l’esito di valutazione del record) e la consumabilità in lettura (lo stato corrente del record) sono architetturalmente separate. Un record corretto al momento della produzione può comunque richiedere una rivalidazione se l’orizzonte di policy o di evidenza cambia.
  • Verificato per deployment: La semantica del ciclo di vita, le superfici di rivalidazione e la gestione dello stato in lettura sono definite per ciascun perimetro di deployment.

Origine

  • Definizione: Un record è vincolato al suo set di evidenze, alla sua versione di policy e al contesto di esecuzione in cui è stato prodotto. L’evidenza è indirizzata per contenuto; la versione di policy è bloccata al momento della valutazione.
  • Ciò che il modello richiede: Evidenza e versione di policy sono input immutabili del record. Un record non può essere staccato dagli input che l’hanno prodotto.
  • Verificato per deployment: La completezza dei metadati di origine e del contesto del record esportato è definita per ciascun perimetro di deployment.

Genealogia

  • Definizione: Un record fa riferimento ai propri predecessori quando viene sostituito. Il lignaggio compone nodi di record, evidenza, policy e supersessione.
  • Ciò che il modello richiede: La provenienza è registrata, non inferita. Ogni anello della catena è indirizzabile in modo indipendente.
  • Verificato per deployment: Le superfici di traversata del lignaggio, i riferimenti ai predecessori e le viste di ricostruzione sono definite per ciascun perimetro di deployment.

Contestabilità

  • Definizione: Un record rimane contestabile. Il suo set di evidenze e la sua versione di policy sono conservati. Il suo lignaggio è auditabile.
  • Ciò che il modello richiede: Il diritto di revisione e di contestazione di un record è una proprietà del modello. Il record non smette di essere una base di revisione quando il suo stato operativo cambia.
  • Verificato per deployment: Le superfici di revisione, i riferimenti conservati e le viste di confronto storico sono definite per ciascun perimetro di deployment.

Orizzonte regolatorio

  • Definizione: Un record porta il proprio contesto regolatorio: i framework valutati e gli obblighi referenziati. Quando abilitate, le superfici di monitoraggio e incidente possono utilizzare i record per supportare flussi di revisione del drift e classificazione degli incidenti.
  • Ciò che il modello richiede: La conformità è una proprietà di esecuzione derivata dai record, non una checklist statica. Il record conosce i framework sotto i quali è stato valutato.
  • Verificato per deployment: Le soglie di monitoraggio, i workflow di incidente e le mappature regolatorie sono definite per ciascun perimetro di deployment.

Busta di prova

  • Definizione: Un record e la sua evidenza sono indirizzati per contenuto. La superficie dell’Audit Pack compone le viste record, lignaggio, spiegazione, monitoraggio, conformità e incidenti.
  • Ciò che il modello richiede: Ciascun componente della busta è identificabile in modo indipendente. L’Audit Pack è la superficie di packaging — non sostituisce alcuno dei record sottostanti.
  • Verificato per deployment: Le superfici di export, packaging e integrità sono definite per ciascun perimetro di deployment. I meccanismi di verifica privati non sono descritti su questa pagina.

Perimetro operativo

Il modello è un’identità strutturale. Il perimetro operativo specifico per deployment — ciò che è implementato, dimostrato, verificato o mantenuto privato — è descritto attraverso i riferimenti sottostanti.

Reality Boundary

Matrice dei claim per ciò che è implementato, dimostrato, benchmarkato, auditabile, privato o non pubblico.

Apri

Verify Offline

Nota di verifica per artefatti esportati e controlli di integrità offline.

Apri

Pilot Scope

Review di deployment delimitata con prerequisiti, deliverable e condizioni di uscita.

Apri

Technical Artifact

Definizioni canoniche di OmegaOS, OmegaOS Kernel, stati terminali, evidenza, replay e ledger.

Apri

Clausola di confine

Questa pagina descrive un modello. Non afferma che ogni attributo sia operativamente completo in ogni deployment.

Il perimetro operativo specifico per deployment, gli artefatti esportati, i runbook, le note di topologia e le procedure di integrazione non sono pubblici. Sono trattati attraverso il percorso di engagement: Pilot Scope, Verify Offline e contatto tecnico diretto nel contesto di review.

Contatta il Team