Perché è importante

Le architetture di governance per i sistemi ad alta conseguenza si stanno sviluppando rapidamente. Molteplici layer indipendenti stanno convergendo intorno a preoccupazioni istituzionali simili: evidenza a runtime, ammissibilità, continuità, chiusura evidenziaria e sufficienza della revisione. Senza un meccanismo standard di dichiarazione, si ripresentano tre modalità di fallimento strutturale:

• Revisione del boundary senza semantica dichiarata: le architetture adiacenti vengono revisionate o confrontate rispetto a standard di riferimento esterni senza che il layer revisionato abbia dichiarato la propria semantica di interoperabilità, creando ambiguità di posizionamento che avrebbero potuto essere evitate.
• Sovrapposizione semantica non dichiarata: i sistemi adiacenti sviluppano vocabolario o descrizioni funzionali sovrapposti senza un meccanismo canonico per distinguere l’ambito dichiarato dalla convergenza incidentale.
• Ambiguità nel procurement: acquirenti, auditor e regolatori non possono determinare in modo sicuro o coerente che cosa un governance layer dichiara o esclude senza leggere documentazione estesa del vendor, soggetta a interpretazione.

GLM affronta questo problema pubblicando una dichiarazione strutturata, versionata e hashabile a un URL well-known prevedibile – rendendo la semantica dei governance layer individuabile dalle macchine senza richiedere la sostituzione della documentazione human-readable.

Struttura del Manifest

Un entry point conforme a GLM è un file JSON pubblicato a /.well-known/governance-layer-manifest.json sul dominio canonico. A partire dallo schema 1.3, questo entry point può essere un manifest a layer singolo oppure un organization index che punta a manifest di layer pubblicati in modo indipendente in posizioni well-known separate (vedi manifest_kind più sotto). Un manifest a layer singolo contiene le seguenti sezioni principali:

• schema_version – versione della specifica di schema GLM (es. “1.4”)
• manifest_kind – dichiara se questo file è un singolo governance layer ("layer", il valore predefinito) o un artefatto di discovery a livello di organizzazione ("organization_index"), introdotto nello schema 1.3
• manifest_version – versione di questo specifico documento manifest, distinta dalla versione dello schema GLM (es. “7.0” per il manifest EVIDE)
• valid_from – data a partire dalla quale questa versione del manifest è in vigore (ISO 8601)
• valid_until – data in cui questa versione del manifest è stata sostituita, oppure null se attualmente attiva
• layer – nome del prodotto, proprietario, layer_type (vocabolario controllato), descrittore del vendor
• timing_axis – posizione sull’asse bind-time (pre-bind / at-bind / post-bind / cross-cutting)
• operational_scope – che cosa il layer fa e che cosa non fa
• claims_boundary – claim autoritativo del layer, non-claim espliciti, vincolo di boundary per il consumer, forbidden_interpretations
• controlling_test – principio normativo di primo livello per valutare i claim di interoperabilità
• interoperability_doctrine – il principio fondativo della componibilità GLM
• composition – tipi di layer componibili e URL dei manifest dichiarati
• machine_readable_status – boundary_readiness, authority_dependency, execution_capability
• public_anchors – riferimenti documentali verificabili in modo indipendente
• glm_compatibility – famiglia di schema, intervallo di versioni supportate, policy di modifica
• manifest_digest – verifica di integrità del contenuto SHA-256 con metodo di canonicalizzazione e, a partire dallo schema 1.4, un canonicalization_id facoltativo machine-dispatchable
• vendor_framework_constructs – blocco facoltativo per dichiarare costrutti concettuali definiti dal vendor con URI canonici, senza importarli nel vocabolario controllato GLM

Vocabolario dei Layer Type (controllato, estensibile)

Il campo layer_type utilizza un vocabolario controllato per consentire il confronto automatico tra implementazioni. Il vocabolario è estensibile attraverso future revisioni dello schema. I nomi specifici del vendor sono dichiarati separatamente in vendor_layer_name e vendor_layer_descriptor.

Definizioni dei Campi Chiave

responsibility-bearing closure state (stato di chiusura portatore di responsabilità): la configurazione responsabile che esiste nel momento in cui una decisione finalizzata e attribuibile attraversa un boundary evidenziario – incluse le condizioni di autorità dichiarate, le condizioni di supervisione e lo stato di qualità osservazionale. Questo stato è specifico del momento dell’attraversamento e non può essere ricostruito da artefatti a valle senza perdere il proprio valore evidenziario.

externally verifiable artifact (artefatto verificabile esternamente): un artefatto strutturato in modo che un revisore indipendente possa interpretarlo e verificarlo senza accesso al sistema di origine, ai suoi operatori o al suo contesto di runtime. La verifica non deve dipendere dalla spiegazione del produttore.

authoritative_layer_claim: una singola frase che dichiara che cosa fa questo layer che nessun layer adiacente dichiara di fare. Utilizzato dai sistemi di procurement e di composizione per determinare la non sovrapposizione senza richiedere una revisione bilaterale.

consumer_boundary_constraint: una dichiarazione di ciò che i consumer a valle non devono inferire dagli output di questo layer. Distinto dai non-claim – il vincolo di boundary per il consumer riguarda come gli output possono e non possono essere usati dopo la ricezione.

forbidden_interpretations: un array machine-readable di usi semantici esplicitamente proibiti per gli output di questo layer. Distinto da explicit_non_claims (che dichiara che cosa il layer non fa) – forbidden_interpretations dichiara che cosa i sistemi a valle non devono concludere o inferire dagli output del layer. Consente la validazione automatizzata contro il collasso semantico.

controlling_test: un principio normativo di primo livello per valutare i claim di interoperabilità. Dichiarato alla radice del manifest (non all’interno di claims_boundary) perché si applica come postura generale di governance a tutte le sezioni del manifest, non solo al claims boundary. Nella v1.0 è un principio human-readable, non un vincolo eseguibile da una macchina.

interoperability_doctrine: il principio filosofico fondativo della componibilità GLM, dichiarato come campo di primo livello. GLM non stabilisce interoperabilità tra sistemi. Rende il boundary, i claim, i non-claim e le condizioni di componibilità di un governance layer machine-readable e leggibili in modo indipendente, così che la potenziale interoperabilità tra layer diventi valutabile attraverso l’ispezione e il confronto dei rispettivi manifest – non attraverso accordi bilaterali di integrazione tra vendor.

glm_compatibility: dichiara la famiglia di schema e l’intervallo di versioni supportate per questo manifest. Consente agli ecosistemi multi-attore di verificare la compatibilità dichiarata con lo schema GLM senza richiedere comunicazione diretta tra gli implementatori. Il campo schema_family identifica esplicitamente il framework GLM (non la versione del layer del vendor) come riferimento per le dichiarazioni di compatibilità.

supersedes / supersedes_digest: campi di chain of custody per il versionamento del manifest. A partire dallo schema 1.2, supersedes è un oggetto strutturato che dichiara il digest SHA-256 della versione precedente e l’url pubblico di archivio. Il manifest precedente referenziato rimane la fonte autoritativa per i propri valori di valid_from e valid_until. Il campo supersedes_digest alla radice è mantenuto per retrocompatibilità con gli strumenti per gli schemi 1.0 e 1.1. Quando entrambi i campi sono presenti, supersedes_digest DEVE corrispondere a supersedes.digest. Un manifest in cui questi valori differiscono è non conforme.

La finalità architetturale di questa catena va oltre il versionamento tecnico. Le versioni precedenti del manifest devono rimanere pubblicamente accessibili all’URL dichiarato in supersedes.url. Questo consente a qualsiasi parte indipendente – inclusi gli auditor esterni – di recuperare l’esatta dichiarazione in vigore durante un periodo specifico, verificarne l’integrità attraverso il digest e ricostruire la catena completa delle versioni senza affidarsi al resoconto retrospettivo del proprietario del layer.

valid_until: dichiarato alla radice del manifest, questo campo registra la data in cui questo manifest ha cessato di essere la dichiarazione attiva. DEVE essere null sul manifest attualmente attivo e viene popolato solo quando la versione viene archiviata. Non deve essere usato per pre-dichiarare una data di scadenza futura.

manifest_digest vs manifest_signature: GLM v1.0 utilizza manifest_digest (SHA-256 del file così come servito) per la verifica di integrità del contenuto. Una manifest_signature (firma crittografica che lega il digest a un’identità) viene dichiarata separatamente quando disponibile. Il digest verifica l’integrità del contenuto; la firma verifica la paternità.

Vocabolario di machine_readable_status: i valori per boundary_readiness (stable | provisional | experimental) e reviewability_state (portable | partial | environment_dependent) sono vocabolari di lavoro proposti nella v1.0. Non sono ancora enum normativi definiti da un organismo di standardizzazione. Future revisioni dello schema potranno formalizzare questi vocabolari.

boundary_readiness – definizioni (chiarimento): boundary_readiness descrive lo stato di maturità/stabilità della definizione di boundary dichiarata in sé – la sua classificazione strutturale e il contenuto dei campi – e nient’altro. È indipendente dalla maturità operativa del sistema sottostante, dallo stato di deployment, dalla capacità di esecuzione, dalla reviewability degli output, dall’autorità, dall’interoperabilità, dalla conformità, o dalla veridicità di qualunque claim.

• stable – La definizione di boundary è consolidata e soggetta a controllo esplicito di versione/modifica come interfaccia dichiarata stabile.
• provisional – La definizione di boundary è specificata nella sostanza e costituisce la dichiarazione attualmente in vigore per il boundary, ma non è ancora stata congelata come interfaccia dichiarata stabile. È il contenuto dei suoi campi – non la sua classificazione strutturale (layer_type, timing_axis e l’insieme complessivo dei campi usati) – a restare soggetto a revisione.
• experimental – La definizione di boundary viene intenzionalmente utilizzata per scopi esplorativi o valutativi, tali per cui è la sua classificazione strutturale stessa – inclusi layer_type, timing_axis, o l’approccio architetturale complessivo usato per rappresentare il boundary – a restare sotto esame.

Le dichiarazioni di componibilità sono unilaterali – un layer può dichiarare compatibilità con un layer adiacente senza che tale dichiarazione sia reciproca. Gli strumenti che recuperano entrambi i manifest possono determinare se la componibilità è dichiarata reciprocamente.

vendor_framework_constructs: un blocco facoltativo che consente al proprietario di un layer di dichiarare pubblicamente costrutti concettuali definiti dal vendor, senza importarli nel vocabolario controllato GLM. Ogni costrutto reca un canonical_uri per l’isolamento del namespace, un vendor_local_alias per la leggibilità, una label, una descrizione purpose e una version. Il blocco include forbidden_interpretations per prevenire l’ereditarietà semantica o l’interoperabilità implicita da parte dei sistemi a valle. Il campo purpose è descrittivo, non normativo. Dichiara l’intento operativo definito dal vendor per il costrutto e non deve essere interpretato come comportamento semantico standardizzato.

manifest_kind / organization_index: a partire dallo schema 1.3, un manifest può dichiarare manifest_kind: "organization_index" invece del valore predefinito implicito "layer". Un organization index non è un governance layer. Non dichiara alcun claims_boundary, non occupa alcuna posizione su timing_axis e non avanza alcun claim di governance. La sua unica funzione è la discovery: elenca gli URL dei manifest dei layer GLM pubblicati in modo indipendente appartenenti alla stessa organizzazione, facoltativamente ancorati dal digest di ciascun manifest elencato. Un organization index DEVE dichiarare timing_axis: null e DEVE dichiarare forbidden_interpretations che coprano come minimo organization_as_layer, authority_transfer_between_listed_layers, implied_composability e interoperability_certification. Ogni layer referenziato da un organization index rimane un manifest completo e indipendente secondo le regole degli schemi 1.0-1.2, con il proprio claims_boundary, il proprio timing_axis e la propria catena supersedes. La componibilità tra i layer elencati, se presente, continua a essere dichiarata esclusivamente attraverso il campo composable_with_manifests di ciascun layer. Il principio guida: un organization index scopre i layer. Non li compone.

Organization Index (Schema 1.3)

Implementazione Proponente Iniziale

Quanto segue illustra la struttura del manifest GLM utilizzando EVIDE come implementazione proponente iniziale. Il manifest completo è disponibile a https://www.certifywebcontent.com/.well-known/governance-layer-manifest.json.

Come Implementare GLM

Pubblicare un manifest conforme a GLM richiede tre passaggi:

Verifica Indipendente

Qualsiasi terza parte può verificare in modo indipendente che un manifest GLM pubblicato non sia stato alterato da quando è stato calcolato il suo digest. La verifica non richiede strumenti speciali – solo una shell a riga di comando e i comandi riportati sotto.

La verifica funziona scaricando il file live, sostituendo il valore del digest dichiarato con il placeholder standard, calcolando lo SHA-256 del file normalizzato e confrontando il risultato con il valore dichiarato in manifest_digest.value. Se corrispondono, il file è integro.

I passaggi seguenti sono il percorso di verifica legacy/manuale. Sono precedenti a canonicalization_id e localizzano manifest_digest.value tramite sostituzione testuale anziché tramite posizione strutturale JSON Pointer, e non gestiscono la sostituzione di manifest_signature.value. Restano validi per qualsiasi manifest che non dichiara un canonicalization_id.

Canonicalization ID (Schema 1.4)

canonicalization_method descrive in prosa la trasformazione applicata per il digest. Un verificatore non dovrebbe dover interpretare linguaggio naturale per determinare quale trasformazione applicare prima di ricalcolare un digest. canonicalization_id dà a quella trasformazione un nome sotto forma di identificatore machine-dispatchable e versionato. canonicalization_method resta presente accanto ad esso come descrizione human-readable; i due campi non sono alternativi l’uno all’altro.

glm-digest-v1 – algoritmo normativo

Input: il file manifest esattamente come servito, come sequenza di byte. Il file DEVE essere UTF-8 valido. Se non lo è, un verificatore che applica glm-digest-v1 DEVE rifiutare con motivazione “not valid UTF-8 – cannot apply glm-digest-v1” anziché tentare qualsiasi altra codifica.

Passo 1 – Localizza tramite JSON Pointer, mai tramite ricerca testuale. Usando un parser JSON in grado di riportare l’offset in byte di ciascun token, localizza:

• l’intervallo di byte del valore stringa JSON (inclusi i caratteri di virgolette che lo racchiudono) al JSON Pointer /manifest_digest/value;
• se la chiave manifest_signature esiste, e il suo sotto-campo value è presente con tipo JSON string (non null, non assente): l’intervallo di byte del valore stringa JSON al JSON Pointer /manifest_signature/value.

Localizzare tramite percorso strutturale anziché tramite contenuto della stringa è ciò che rende la trasformazione sicura: un valore stringa identico che compare sotto qualsiasi altra chiave si trova a un JSON Pointer diverso e non viene mai esaminato. Non esiste alcuno scenario, in questo algoritmo, in cui una stringa coincidente per caso altrove nel file venga alterata.

Passo 2 – Sostituisci, lasciando intatto ogni altro byte. Sostituisci l’intervallo di byte localizzato per /manifest_digest/value con il letterale di byte UTF-8 esatto, virgolette JSON incluse:

Se nel Passo 1 è stato localizzato un intervallo di byte per /manifest_signature/value, sostituiscilo con il letterale di byte UTF-8 esatto, virgolette JSON incluse:

Questi due letterali sono fissati come parte della definizione di glm-digest-v1 e non possono essere alterati senza definire un nuovo canonicalization_id. La sostituzione viene eseguita direttamente sul buffer di byte originale agli intervalli di byte identificati nel Passo 1 – il file non viene mai completamente parsato e ri-serializzato. Ogni byte al di fuori degli intervalli identificati – spazi bianchi, ordine delle chiavi, indentazione, terminatori di riga, un byte-order mark iniziale se presente, un newline finale se presente – resta identico byte per byte al file servito. Tutti gli offset di byte usati nei Passi 1 e 2 sono offset all’interno della sequenza di byte originale completa, byte-order mark incluso quando presente: il BOM, se esiste, viene preservato esattamente e non viene mai rimosso, spostato o escluso dalla sequenza su cui si calcolano gli offset.

Passo 3 – Calcola l’hash. Calcola lo SHA-256 sulla sequenza di byte prodotta dal Passo 2, senza alcuna ulteriore trasformazione.

Due implementazioni indipendenti che seguono questa definizione, usando qualsiasi parser JSON che riporti gli offset in byte dei token parsati – una capacità ampiamente disponibile, non su misura – producono byte di output identici e un digest SHA-256 identico.

Dichiarazioni di Componibilità

Il campo composable_with_manifests consente a un layer di identificare i manifest specifici con i quali dichiara componibilità. Questo permette agli strumenti di costruire un grafo di componibilità tra i layer partecipanti.

Le dichiarazioni di componibilità sono unilaterali: un layer può dichiarare compatibilità con un layer adiacente senza che tale dichiarazione sia reciproca. Quando entrambi i layer si dichiarano a vicenda nei rispettivi manifest, la componibilità è dichiarata reciprocamente e controllabile in modo indipendente recuperando entrambi i manifest. Questa dichiarazione reciproca non costituisce prova di interoperabilità operativa. Questo consente:

• Verifica automatizzata in fase di procurement senza richiedere documentazione bilaterale
• Costruzione del grafo di composizione a partire da file manifest pubblicamente disponibili
• Valutazione delle relazioni di componibilità dichiarate da parte dei sistemi che consumano le dichiarazioni dei governance layer
• Validazione di scenario pack che conferma dichiarazioni coerenti tra i layer partecipanti

Domande Sollevate Durante la Revisione Architetturale

Le domande seguenti sono emerse durante la revisione architetturale e la discussione pubblica della specifica GLM e dell’implementazione di riferimento EVIDE. Sono conservate qui perché chiariscono distinzioni strutturali che non sono immediatamente evidenti dalla sola specifica.

Posso implementare GLM nel mio progetto commerciale o di ricerca?

Sì. GLM è stato progettato specificamente per incoraggiare implementazioni indipendenti. Puoi implementare, adattare, estendere o pubblicare un manifest conforme a GLM per progetti commerciali, accademici, governativi, open-source o proprietari. L’implementazione proponente non impone alcun permesso, registrazione, accordo di licenza o requisito di attribuzione. Le implementazioni indipendenti sono incoraggiate perché aiutano a valutare il valore del modello di dichiarazione stesso ai fini della valutazione dell’interoperabilità. Le organizzazioni che pubblicano un manifest GLM pubblico possono facoltativamente essere citate negli esempi pubblici di implementazione: Valida qui il tuo manifest GLM

Perché GLM raccomanda la pubblicazione a un well-known URI?

Perché l’individuabilità fa parte del modello di interoperabilità. Una dichiarazione di boundary che non può essere localizzata in modo prevedibile non può essere consumata automaticamente dai sistemi adiacenti. L’uso dei well-known URI segue lo stesso principio architetturale usato da altri meccanismi di discovery su scala internet: la dichiarazione dovrebbe essere individuabile senza coordinamento bilaterale preventivo.

Un governance layer può pubblicare un manifest GLM senza implementare EVIDE?

Sì. GLM è indipendente da EVIDE. Qualsiasi governance layer può pubblicare un manifest conforme a GLM indipendentemente dal fatto che svolga funzioni di witnessing, valutazione di ammissibilità, governance dell’esecuzione, stabilizzazione evidenziaria, revisionabilità o qualsiasi altra funzione di governance. GLM descrive boundary. Non prescrive l’implementazione.

Pubblicare un manifest GLM crea autorità o legittimità di governance?

No. Un manifest GLM dichiara che cosa un layer afferma, che cosa non afferma, dove opera e come si presenta per la composizione. La pubblicazione non crea autorità, legittimità, affidabilità o interoperabilità. Crea una superficie di dichiarazione machine-readable. La validità dei claim dichiarati resta responsabilità del proprietario del layer.

Un layer può essere conforme a GLM pur dichiarando claim molto ampi o irrealistici?

Sì. GLM non valida la veridicità, la qualità, la correttezza o la fattibilità dei claim di un layer. Un manifest può essere sintatticamente valido pur contenendo claim incompleti, esagerati o operativamente irrealistici. GLM rende quei claim machine-readable e rivedibili in modo indipendente. Non li certifica. La responsabilità del contenuto dichiarato resta interamente al proprietario del layer.

Perché GLM non certifica l’interoperabilità?

Perché i claim di interoperabilità e le dichiarazioni di interoperabilità sono funzioni diverse. GLM dichiara boundary, claim, non-claim, posizione temporale e postura di composizione. Non determina se due sistemi siano effettivamente compatibili, né certifica che l’interoperabilità sia stata raggiunta. Dichiarare un boundary non è la stessa cosa che validare una relazione attraverso i boundary.

Perché GLM include forbidden_interpretations?

Perché molti fallimenti di governance nascono da assunzioni anziché da claim espliciti. Un layer può non aver mai dichiarato una capacità, eppure i sistemi adiacenti possono gradualmente iniziare a trattare quella capacità come se esistesse. forbidden_interpretations rende quelle ereditarietà semantiche proibite machine-readable anziché lasciarle implicite.

Perché GLM si concentra così tanto sui non-claim?

Perché i fallimenti di governance nascono spesso da capacità che sono state presunte anziché esplicitamente dichiarate. Negli ecosistemi di governance componibili, capire che cosa un layer non determina può essere importante quanto capire che cosa fa. I non-claim riducono il rischio di trasferimento implicito di autorità, ereditarietà semantica e ambiguità di boundary.

GLM definisce un layer type “boundary”. Avete un’opinione su che cosa dovrebbe occupare quella posizione in pratica, o è intenzionalmente lasciato aperto?

Intenzionalmente lasciato aperto. GLM definisce la posizione sull’asse temporale e la funzione operativa, ma non prescrive quale sistema debba occuparla. Il boundary layer risolve l’ammissibilità al bind-time dell’esecuzione prima che la conseguenza venga committata. Quale sistema svolga quella funzione è una decisione implementativa sovrana lasciata al proprietario di quel layer.

EVIDE sembra collocarsi principalmente post-bind / lato closure. Come gestite le situazioni in cui lo stato di autorità pre-bind è esso stesso contestato?

EVIDE non risolve l’autorità contestata pre-bind. Questo è esplicitamente al di fuori del suo ambito. Ciò che EVIDE fa è registrare lo stato di autorità dichiarato al momento della chiusura, incluso se quello stato era contestato, provvisorio o non verificabile. Uno stato pre-bind contestato non blocca la stabilizzazione. Diventa parte del record evidenziario, con le sue limitazioni dichiarate anziché nascoste.

Quando EVIDE registra il contesto di classificazione dichiarato, valida la stabilità di quella tassonomia a monte o si limita a preservare ciò che è stato dichiarato in quel momento?

Preservato come dichiarato. EVIDE non valida la stabilità o la correttezza della tassonomia a monte. Registra ciò che è stato dichiarato al momento dell’attraversamento. Se la tassonomia cambia successivamente o diventa contestata, il record evidenziario riflette ciò che era dichiarato in quel momento specifico – che è precisamente il suo valore forense.

Come spiegate la differenza tra “supporta la difendibilità” e “soddisfa un requisito regolatorio”?

La distinzione è strutturale. EVIDE supporta la difendibilità producendo un record evidenziario verificabile in modo indipendente delle condizioni di chiusura. Se quel record soddisfi uno specifico requisito regolatorio dipende da ciò che la normativa richiede e da come il record viene valutato dall’autorità competente. EVIDE non determina la conformità. Fornisce l’infrastruttura evidenziaria che rende la difendibilità possibile e ricostruibile in modo indipendente.

Puntate a far diventare GLM uno standard formale, o l’obiettivo attuale è stabilire una superficie di dichiarazione pratica de facto?

L’obiettivo immediato è una superficie di dichiarazione pratica. GLM è attualmente una specifica aperta intesa a stabilire un pattern: dichiarazioni di boundary machine-readable pubblicate a well-known URI, verificabili in modo indipendente, senza richiedere coordinamento bilaterale o trasferimento di autorità. Se quel pattern evolverà infine in un’iniziativa formale di standardizzazione resta una questione aperta. Il valore immediato è pratico più che istituzionale.

Se esistono più dichiarazioni di boundary per lo stesso oggetto operativo e tali dichiarazioni sono reciprocamente incompatibili, GLM fornisce un meccanismo di precedenza o di risoluzione dei conflitti?

No, e intenzionalmente. GLM può rendere visibile un conflitto. Non risolve il conflitto. Nel momento in cui un sistema inizia a determinare quale dichiarazione prevale o come le incompatibilità debbano essere risolte, è passato dalla dichiarazione alla governance. Qualsiasi modello di precedenza, meccanismo di arbitrato o processo di risoluzione dei conflitti appartiene al layer che rivendica esplicitamente la responsabilità di quella funzione. GLM dichiara. GLM non giudica.

GLM rende un costrutto individuabile e il suo significato dichiarato machine-readable. Ma garantisce che sistemi governati in modo indipendente manterranno interpretazioni compatibili nel tempo?

No. L’individuabilità e la compatibilità interpretativa nel tempo sono problemi strutturalmente distinti. GLM rende un costrutto reperibile e il suo significato dichiarato leggibile al momento della dichiarazione. Non garantisce che osservatori governati in modo indipendente manterranno interpretazioni compatibili mentre accumulano le proprie assunzioni intorno ad esso. È precisamente per questo che il manifest si concentra fortemente su forbidden_interpretations, non-claim espliciti, boundary di autorità e vincoli di composizione – non come garanzie di permanenza semantica, ma come meccanismi per ridurre il collasso semantico silenzioso durante l’interoperabilità. Se interpretazioni divergenti richiedano un riallineamento esplicito resta un problema di coordinamento al di fuori della superficie di dichiarazione GLM.

Come restano validi i manifest GLM mentre autorità, stato e condizioni operative cambiano nel tempo?

GLM affronta questo aspetto attraverso il versionamento anziché attraverso un’assunzione di permanenza. Un manifest non pretende di descrivere la postura di governance di un layer a tempo indefinito. Dichiara che cosa un layer afferma, che cosa esclude e come si presenta per la composizione in un momento specifico – ancorato da valid_from, da un digest calcolato e da una catena supersedes che rimanda alle versioni precedenti.

Quando autorità, stato o condizioni operative cambiano, l’aspettativa è che venga pubblicata una nuova versione del manifest – con la versione precedente che resta verificabile in modo indipendente attraverso il suo digest. Questo è strutturalmente simile al modo in cui EVIDE gestisce lo stato di chiusura: il valore del record non sta nel restare vero per sempre, ma nel catturare accuratamente ciò che è stato dichiarato nel momento in cui è stato esternalizzato.

Se il solo versionamento sia sufficiente per ambienti di governance ad alta frequenza o altamente dinamici è una questione aperta – e probabilmente destinata a diventare sempre più rilevante man mano che questi ecosistemi maturano.

GLM rende le dichiarazioni individuabili e machine-readable al momento della pubblicazione. Ma che cosa succede quando sistemi governati in modo indipendente continuano a evolvere dopo la pubblicazione di una dichiarazione – le interpretazioni compatibili possono restare stabili anche quando la dichiarazione originale resta invariata?

Questo è un problema strutturalmente distinto dall’individuabilità. GLM è stato progettato per rendere le dichiarazioni individuabili, machine-readable e confrontabili nel momento in cui vengono pubblicate. Consente a un layer di dichiarare che cos’è, dove opera, che cosa afferma e che cosa esplicitamente non afferma.

Ciò che GLM non tenta di determinare è se le interpretazioni restino allineate nel tempo dopo la pubblicazione. Un manifest può restare invariato mentre l’ecosistema circostante evolve, emergono nuovi layer, le assunzioni cambiano o le relazioni compositive diventano più complesse. Queste domande appartengono a uno spazio di problemi diverso.

Dalla prospettiva GLM, l’obiettivo è più ristretto: fornire una superficie dichiarativa stabile che consenta a sistemi governati in modo indipendente di esporre i propri boundary in una forma coerente e rivedibile. Se l’allineamento semantico persista attraverso il tempo, le revisioni e le composizioni in evoluzione richiederebbe meccanismi al di là della dichiarazione stessa – meccanismi che per progettazione si collocano al di fuori della superficie di dichiarazione GLM.

In questo senso, la revisione dell’estensione del vocabolario è stata preziosa non semplicemente perché è stata accettata una nuova categoria, ma perché ha aiutato a chiarire dove finisce la responsabilità di GLM e dove iniziano altre questioni di governance.

Che cosa impedisce a un governance layer di modificare unilateralmente i propri boundary dichiarati dopo la pubblicazione?

GLM non tenta di stabilizzare permanentemente i boundary come primitiva architetturale. Presuppone che un governance layer abbia già un boundary definito e si concentra nel rendere quel boundary esplicitamente dichiarato, machine-readable e rivedibile in modo indipendente al momento della pubblicazione.

L’evoluzione del boundary non è necessariamente una condizione di fallimento. Sistemi, modelli di governance e vincoli operativi possono cambiare legittimamente nel tempo. Ciò che conta dalla prospettiva evidenziaria è se quei cambiamenti possano essere ricostruiti in modo indipendente. Un governance layer può dichiarare un insieme di boundary oggi e un insieme diverso in seguito. La dichiarazione storica resta verificabile in modo indipendente attraverso il suo digest, e la catena supersedes rende trasparente nel tempo l’evoluzione dei boundary dichiarati.

In questo senso, il focus è meno sul prevenire il cambiamento del boundary e più sul prevenire la perdita di ricostruibilità quando il cambiamento del boundary avviene. Se l’ambiguità del boundary derivi da una dichiarazione iniziale insufficiente, da una deriva del boundary o da fattori strutturali è una domanda che diventa rispondibile precisamente perché le dichiarazioni storiche restano verificabili in modo indipendente.

Le versioni precedenti del manifest dovrebbero restare pubblicamente accessibili dopo la pubblicazione di una nuova versione?

Sì. Questa è la finalità architetturale della catena supersedes. L’URL del manifest corrente serve sempre l’ultima versione. Le versioni precedenti dovrebbero restare pubblicamente accessibili a un URL stabile a tua scelta – un percorso di archivio sul tuo dominio, un file versionato o qualsiasi altra posizione pubblicamente raggiungibile.

La ragione è evidenziaria. Qualsiasi parte indipendente che esamini un evento di governance, una decisione, una controversia o un audit passati dovrebbe poter recuperare la dichiarazione in vigore nel momento in cui quell’evento si è verificato – e verificare attraverso il digest pubblicato che la dichiarazione non sia stata alterata da allora. Senza versioni precedenti pubblicamente accessibili, quella ricostruzione non è possibile nemmeno quando la catena supersedes stessa è intatta.

Un governance layer può legittimamente aggiornare i propri boundary man mano che evolve. Ciò che la catena delle versioni preserva è la capacità di determinare che cosa era dichiarato in qualsiasi momento specifico del passato, senza affidarsi al resoconto retrospettivo del proprietario del layer. Quell’indipendenza è precisamente ciò che rende significativa la chain of custody.

Ciò che resta recuperabile e ciò che resta ammissibile potrebbero non coincidere. Come gestisce GLM le situazioni in cui le condizioni di autorità o di ammissibilità che originariamente supportavano una decisione di governance non esistono più?

GLM non tenta di determinare se le condizioni storiche di autorità restino valide, applicabili o ammissibili nel presente. Ciò che tenta di preservare è la capacità di ricostruire in modo indipendente che cosa è stato dichiarato, quando è stato dichiarato e come quelle dichiarazioni sono evolute nel tempo.

Un governance layer può legittimamente cambiare i propri boundary, dipendenze, strutture di autorità o assunzioni operative man mano che evolve. Dalla prospettiva GLM, la domanda critica non è se il cambiamento avvenga, ma se lo stato storico resti ricostruibile in modo indipendente dopo che il cambiamento è avvenuto. Se un governance layer pubblica un insieme di dichiarazioni oggi e un insieme diverso in seguito, la dichiarazione precedente resta verificabile in modo indipendente attraverso il suo digest pubblicato e la catena supersedes.

La distinzione tra recuperabilità e ammissibilità è importante e deliberata. GLM supporta la recuperabilità. Non determina l’ammissibilità. Se una dichiarazione recuperata sia ammissibile in uno specifico contesto di governance, legale o istituzionale dipende da fattori al di fuori della superficie di dichiarazione GLM – inclusi framework di autorità, requisiti regolatori e mandati istituzionali che GLM non è stato progettato per risolvere.

Quando coesistono più governance layer validi e i loro claim di autorità si sovrappongono parzialmente, come dovrebbero le istituzioni determinare quale dichiarazione di governance prevale?

GLM non dovrebbe determinare quale dichiarazione di governance prevale. Ciò sposterebbe GLM da layer di dichiarazione a layer di risoluzione dell’autorità, che non è il suo ruolo. GLM è progettato per rendere i claim di governance, i non-claim, la posizione temporale, le assunzioni di componibilità e i boundary dichiarati espliciti, machine-readable e rivedibili in modo indipendente.

Quando coesistono più governance layer validi e i loro claim di autorità si sovrappongono parzialmente, la questione della prevalenza dovrebbe essere risolta da una base di autorità esterna: legge, mandato istituzionale, gerarchia contrattuale, statuto di governance interno, obbligo regolatorio o un altro framework di autorità decisionale esplicitamente riconosciuto. GLM può esporre la sovrapposizione. Può rendere visibile il conflitto. Può mostrare dove due layer rivendicano responsabilità adiacenti o concorrenti. Ma non dovrebbe decidere silenziosamente la legittimità.

È qui che EVIDE diventa complementare. Nemmeno EVIDE risolve il conflitto di autorità. Il suo ruolo è preservare evidenza ricostruibile di ciò che è stato dichiarato, quale layer ha agito, quale base di autorità è stata invocata, quale passaggio di consegne o escalation è avvenuto e come la catena decisionale è stata successivamente stabilizzata o contestata.

GLM dichiara il boundary di governance. I framework di autorità determinano la precedenza. EVIDE preserva l’evidenza di come quella precedenza è stata applicata. Questa separazione è importante perché altrimenti un layer tecnico di dichiarazione potrebbe involontariamente diventare un layer costituzionale nascosto.

Quale meccanismo nel modello GLM garantisce che la semantica di governance possa essere ricostruita in modo indipendente in un momento specifico senza affidarsi a una continuità di stato implicita?

Il meccanismo è la combinazione di tre requisiti strutturali. Primo, il manifest stesso deve essere pubblicato contestualmente e verificabile in modo indipendente – il manifest_digest e la catena delle versioni rendono il contenuto dichiarato controllabile in modo indipendente nel tempo. Secondo, il timing_axis obbliga ogni layer a dichiarare esplicitamente dove opera rispetto al momento del bind, impedendo che la continuità venga silenziosamente presunta attraverso i confini temporali. Terzo, explicit_non_claims e forbidden_interpretations rendono visibili i limiti della ricostruzione – un layer che non può garantire l’esternalizzazione contestuale deve dichiarare quella limitazione anziché lasciarla inferenziale. GLM non garantisce la ricostruzione. Rende le condizioni in cui la ricostruzione è, o non è, possibile machine-readable e rivedibili in modo indipendente. In EVIDE nello specifico, quella lacuna è affrontata attraverso l’esternalizzazione contestuale al momento dell’attraversamento: la configurazione responsabile viene esternalizzata quando esiste, non ricostruita in seguito.

Stato della Specifica

GLM-BD (Governance Layer Manifest — Boundary Declarations) è attualmente una specifica aperta proposta alla versione di schema 1.4. È stata sviluppata all’interno dell’EVIDE Governance Lab nel maggio 2026 come parte del lavoro sull’interoperabilità dei governance layer nelle architetture di sistemi ad alta conseguenza.

• Stato: Specifica aperta proposta – non ancora adottata da alcun organismo di standardizzazione
• Licenza: Permissiva per l’implementazione – qualsiasi governance layer può implementare GLM senza restrizioni né requisiti di attribuzione verso il vendor proponente
• Autorità del manifest: GLM dichiara la semantica dei layer. Non decide validità, legittimità, adozione o conformità. Un manifest non deve diventare una meta-autorità sulle primitive di governance sovrane. Un manifest GLM è metadato infrastrutturale auto-dichiarato, non certificazione di terze parti.
• Estensione del vocabolario: Nuovi valori di layer_type richiedono una motivazione documentata e un incremento di versione dello schema
• Prima estensione esterna del vocabolario: Il layer_type formation e il qualificatore temporale source-anchored sono stati accettati il 2026-06-12 a seguito di una revisione formale della motivazione. Implementazione proponente: NOUS (Hlias Staurou). Maintainer revisore: EVIDE Governance Lab. Ciò costituisce la schema_version 1.1. Digest della motivazione (SHA-256): fad8c5a839f601893114b9072f5bedb96d01837bb844c9635339db321d7404bd
• Schema 1.2: Il campo supersedes è stato promosso da stringa semplice a oggetto strutturato che reca il digest della versione precedente e l’url pubblico di archivio. Il campo supersedes_digest è mantenuto come contratto stabile per gli strumenti degli schemi 1.0 e 1.1, che possono continuare a leggere supersedes_digest e ignorare il nuovo oggetto strutturato. In questa impostazione, lo schema 1.2 è una modifica additiva non-breaking, coerente con la policy di incremento della versione minore. Il campo supersedes_digest alla radice è mantenuto per retrocompatibilità e DEVE corrispondere a supersedes.digest quando entrambi sono presenti. È stato inoltre aggiunto un campo valid_until alla radice per registrare quando una versione archiviata del manifest ha cessato di essere attiva. Ciò costituisce la schema_version 1.2.
• Schema 1.3: Introduce manifest_kind, un campo facoltativo alla radice che distingue un manifest a layer singolo ("layer", il valore predefinito implicito per tutti i manifest degli schemi 1.0-1.2) da un artefatto di discovery a livello di organizzazione ("organization_index"). L’estensione risponde alle esigenze delle organizzazioni che pubblicano più governance layer indipendenti e che in precedenza non avevano alcun modo standard per dichiarare, in un’unica posizione prevedibile, quali manifest di layer esistono e dove sono pubblicati. Un organization index non avanza alcun claim di governance, non occupa alcuna posizione sull’asse temporale e non deve essere interpretato come implicante componibilità o trasferimento di autorità tra i layer che elenca. Parte proponente: EVIDE Governance Lab. Maintainer revisore: Stone Shi (CLARIXO/TGTRACING). Revisionato e approvato in linea di principio il 2026-06-17, seguendo la stessa separazione proposta/revisione usata per l’estensione formation dello schema 1.1. Principio guida: un organization index scopre i layer. Non li compone. Ciò costituisce la schema_version 1.3. Nota sulla compatibilità in avanti: un consumer che non riconosce manifest_kind DEVE trattare l’artefatto come opaco e saltare la validazione, anziché ricadere sul valore predefinito implicito layer e segnalare come non conformità l’assenza di claims_boundary o di una posizione su timing_axis. Ciò preserva una compatibilità in avanti sicura per gli strumenti pre-1.3.
• Schema 1.4: Introduce manifest_digest.canonicalization_id, un campo stringa facoltativo accanto all’esistente canonicalization_method human-readable. Dove canonicalization_method descrive in prosa la trasformazione applicata per il digest, canonicalization_id le dà un nome come identificatore machine-dispatchable e versionato su cui un verificatore può agire senza interpretare linguaggio naturale. Il campo è additivo e FACOLTATIVO: un manifest che lo omette resta pienamente conforme a qualsiasi versione di schema e viene trattato dai verificatori come richiedente verifica manuale. Il primo identificatore definito è glm-digest-v1 – vedi Canonicalization ID più sotto per la sua definizione normativa completa. Una volta pubblicata, la trasformazione legata a un dato valore di canonicalization_id non può cambiare; una trasformazione futura richiede un nuovo identificatore (glm-digest-v2 e così via), mai la ridefinizione di uno esistente. Lo schema 1.4 documenta inoltre machine_readable_status.authority_dependency (con il suo campo complementare authority_dependency_note) come campo di vocabolario facoltativo e cross-implementation: osservato in modo indipendente in uso da più di un’implementazione GLM con lo stesso valore dichiarato (external_to_execution_system), e documentato qui per questa ragione. Non è richiesto, e la sua presenza o assenza non influisce sulla conformità. Ciò costituisce la schema_version 1.4.
• Modifiche allo schema: Le modifiche breaking richiedono un incremento di versione maggiore. Le aggiunte non-breaking possono essere introdotte come incrementi di versione minore. La retrocompatibilità all’interno di una versione maggiore è un obiettivo di progettazione.
• Feedback: Feedback architetturali e report di implementazione sono benvenuti a [email protected]