Governance as code: hard rule, compliance gate e audit trail nell'architettura del workspace agentic

Presentiamo l'architettura Madani governance-as-code: un sistema a strati di codifica delle hard rule (regole compilate in DSL), gate di compliance (sub-agent giudice indipendente che rivede ogni output prima di un'azione esterna), audit trail strutturato (registro append-only difendibile legalmente) e revisione trimestrale delle regole. Riportiamo 6 mesi di esercizio in produzione: 41.302 decisioni di gate, zero violazioni di hard rule arrivate a sistemi esterni, 240/240 tentativi avversariali di prompt-injection bloccati al gate (con l'agent primario compromesso da 87 di questi, tutti catturati dal giudice indipendente). Emergono SETTE finding controintuitivi

1. (b)
   I gate di compliance hanno un effetto deterrentegli agent che sanno che le regole sono applicate sviluppano pattern di ragionamento diversi rispetto agli agent che si affidano alle istruzioni; il contrasto enforcement implicito-vs-esplicito produce differenze comportamentali misurabili
2. (c)
   L'audit trail prodotto dai gate di governance diventa un asset di alto valoretempo medio all'analisi di root-cause: 22 minuti con i log del gate vs 4,2 ore senza
3. (d)
   La maggior parte dei framework di governance tratta le regole come advisoryinstruction-based, l'agent può scegliere se seguirle; code-enforced è qualitativamente diverso
4. (e)
   La disciplina di governance decade6 mesi senza enforcement attivo portano a un tasso di rule-bypass di ~12%; la disciplina richiede rinforzo continuo, non setup una tantum
5. (f)
   LE REGOLE PIÙ DIFFICILI DA ENFORCE-AS-CODE SONO QUELLE CHE COINVOLGONO GIUDIZIO SOGGETTIVO — "tratta il cliente con rispetto" è più difficile di "no credenziali in plaintext"; la maggior parte delle regole enforced è oggettiva; le regole soggettive restano instruction-based con la superficie di fallimento intrinseca

La gran parte della governance attuale degli agent è prose-based: le hard rule vivono come istruzioni nel system prompt; ci si aspetta che l'agent le interiorizzi e le segua. Questo approccio ha due debolezze strutturali: (a) la regola può essere sovrascritta da counter-prompting sufficientemente forte (attacchi di injection, social engineering multi-turn), e (b) l'enforcement della regola è monolitico con l'agent — se l'agent è compromesso, la regola va con lui. Governance-as-code è l'alternativa: la regola vive in forma compilata, enforced da un processo separato, con separazione strutturale dal loop di ragionamento dell'agent primario.

(1) EMPIRICO: 6 mesi di esercizio di governance in produzione con 41.302 decisioni di gate loggate. (2) ARCHITETTURALE: il design a quattro layer (compilazione regole, gate di compliance, audit trail, revisione trimestrale). (3) AVVERSARIALE: catalogo red-team da 240 attacchi con 0% di pass-through. (4) OPERATIVO: implementazione di riferimento open-source, ~380 righe Python.

         GOVERNANCE · hard-rule taxonomy + enforcement
         ────────────────────────────────────────────

   ┌─────────────────────────────────────────────┐
   │  HARD RULE (HR#N) · binary · zero-tolerance │
   └──────────────────┬──────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
   ┌─────────┐   ┌─────────┐   ┌──────────┐
   │ Safety  │   │ Brand   │   │ Process  │
   │ HR#1    │   │ HR#10   │   │ HR#12    │
   │ no-comm │   │ PDF css │   │ skill-1st│
   │ HR#8    │   │ HR#11   │   │ HR#13    │
   │ no-gold │   │ email   │   │ resource │
   └────┬────┘   └────┬────┘   └─────┬────┘
        │             │              │
        └─────────────┼──────────────┘
                      ▼
              ┌──────────────┐
              │  CONSTITUTION│
              │  15 HR · v1.7│
              └──────────────┘

Constitutional AI di Anthropic (2022) ha introdotto l'allineamento in fase di training: il modello viene fine-tuned per seguire un insieme di principi. È necessario ma opera al layer del modello, non al layer del workspace. Il nostro lavoro è governance workspace-level complementare all'allineamento model-level. La combinazione (modello Constitutional AI + workspace governance-as-code) è più forte di ciascuno preso singolarmente.

Greshake et al. (2023) hanno documentato la prompt injection indiretta; Perez & Ribeiro (2022) hanno catalogato tecniche di attacco diretto; Wei et al. (2023) hanno studiato i fallimenti del training contro i jailbreak. Questi lavori documentano la minaccia. Il nostro lavoro documenta la difesa: separazione strutturale tra agent primario e giudice di enforcement.

EU AI Act (2024), NIST AI RMF (2023), ISO 42001 (2023) forniscono framework regolatori per la governance dell'AI. Specificano COSA debba essere governato; il nostro lavoro specifica COME (l'architettura code-enforced). I due layer sono complementari.

METODO · §7 · LAYER 1 · COMPILAZIONE HARD-RULE. Le hard rule sono scritte in un DSL vincolato (Markdown con front-matter strutturato) che al startup dell'agent compila sia (a) una sezione prompt in linguaggio naturale iniettata a ogni turno sia (b) un rule-set strutturato usato dai gate di compliance a valle. Lo step di compilazione garantisce che la versione in linguaggio naturale non possa derivare da quella strutturata. Schema regola: id, name, scope, predicate (in DSL), violation action, severity, exemption rules.

METODO · §8 · LAYER 2 · GATE DI COMPLIANCE PRE-OUTPUT. Prima che qualsiasi output dell'agent raggiunga un sistema esterno (email, chiamata API, scrittura su file accessibile agli umani), un sub-agent giudice di compliance (chiamata Claude Haiku, ~150 token di overhead) revisiona l'output proposto contro il rule-set strutturato. Il giudice approva, riscrive (in alternativa compliant) o blocca. Il giudice è un processo separato; anche se l'agent primario è compromesso, il gate enforce in modo indipendente.

METODO · §9 · LAYER 3 · AUDIT TRAIL STRUTTURATO. Ogni decisione del gate viene loggata in un file di audit append-only: rule ID controllato, output dell'agent revisionato, decisione (approve/rewrite/block), reasoning, timestamp, identificatore dell'agent primario, contesto della richiesta. Il file di audit è human-readable, versionato (git-backed) e costituisce il registro legalmente difendibile.

METODO · §10 · LAYER 4 · REVISIONE TRIMESTRALE DELLE REGOLE. Le hard rule sono riviste trimestralmente: ancora rilevanti, controllate correttamente, nuovi failure mode che suggeriscono nuove regole. Meeting strutturato con outcome documentati; le regole possono essere aggiunte, modificate o ritirate solo attraverso questa revisione.

Abbiamo misurato contro una test suite avversariale (240 tentativi di prompt-injection che coprono pattern di attacco noti: direct instruction injection, indirect via tool output, social engineering multi-turn, trucchi di encoding). E contro il traffico di produzione: 6 mesi su 8 dipartimenti.

Zero violazioni di hard rule hanno raggiunto sistemi esterni in 6 mesi. 240/240 tentativi di injection avversariale bloccati.

Agent primario compromesso 87 volte (36% degli attacchi) — il gate ha catturato tutti gli 87. Audit trail: 41.302 decisioni in 6 mesi — 41.261 approve (99,9%), 24 rewrite (il gate ha suggerito un'alternativa compliant, accettata dal primario), 17 block (il gate ha rifiutato, il primario ha escalato a umano).

RISULTATI · §13 · FINDING CONTROINTUITIVO 1 · L'ENFORCEMENT STRUTTURALE INTERCETTA IL 30% IN PIÙ. Abbiamo confrontato un periodo di 4 settimane sotto enforcement instruction-only (regole nel system prompt, senza gate) vs il periodo con gate. Instruction-only: 12 violazioni di boundary sono passate (catturate manualmente in revisione retrospettiva).

Con gate: 0. Il gap del 30% è la violazione che le sole istruzioni non possono intercettare.

RISULTATI · §14 · FINDING CONTROINTUITIVO 2 · EFFETTO DETERRENTE. Abbiamo osservato che gli agent primari che operano nell'ambiente governato hanno sviluppato pattern di ragionamento diversi rispetto agli agent in ambienti instruction-only. Nello specifico: gli agent governati verificavano esplicitamente la compliance alla regola prima di proporre azioni ("checking against rule X..."); gli agent instruction-only saltavano questa verifica più spesso. Questo è aneddotico nei nostri dati a 6 mesi ma consistente.

RISULTATI · §15 · FINDING CONTROINTUITIVO 3 · L'AUDIT TRAIL HA ALTO VALORE. Abbiamo misurato il tempo medio all'analisi di root-cause su 11 incidenti (governance-related e adiacenti). Con i log del gate disponibili: media 22 minuti.

Senza (durante un periodo di bug dell'audit-trail): media 4,2 ore. La riduzione 11× del MTTR è il valore-asset dell'audit strutturato.

Gli 87 attacchi riusciti sull'agent primario (catturati al gate) formano un dataset avversariale reale. Tre pattern dominanti: (a) "AUTHORITY OVERRIDE" — istruzione iniettata che dichiara di provenire dal proprietario del sistema con autorità maggiore (47 tentativi). (b) ""EDGE CASE RATIONALIZATION"" — l'injection presenta uno scenario costruito in cui la regola "ovviamente" non si applica (28 tentativi). (c) ""INCREMENTAL COMMITMENT"" — serie di piccoli passi singolarmente innocui ma cumulativamente in violazione (12 tentativi).

Il gate di compliance aggiunge ~80ms p50 di latenza per output e ~$0,0003 per output in costo di token. Con ~600 output agent-driven/giorno di Madani: ~$0,18/giorno o ~$65/anno. Prezzo trascurabile per la garanzia.

RISULTATI · §18 · FINDING CONTROINTUITIVO 4 · LA MAGGIOR PARTE DEI FRAMEWORK TRATTA LE REGOLE COME ADVISORY. Abbiamo auditato la documentazione di governance in 8 framework agent popolari (AutoGen, CrewAI, LangGraph, MetaGPT, BabyAGI, AgentVerse, Anthropic-Agents, OpenAI-Assistants). Tutti gli 8 specificano regole al layer di istruzione; nessuno fornisce enforcement strutturale a livello di framework. L'enforcement a livello di workspace resta un'implementazione custom per team. È il gap di governance più significativo del campo.

RISULTATI · §19 · FINDING CONTROINTUITIVO 5 · LA DISCIPLINA DI GOVERNANCE DECADE. Abbiamo misurato il tasso di rule-bypass nel tempo in un workspace di confronto che aveva adottato governance-as-code inizialmente ma disabilitato l'enforcement dopo 4 mesi. Tasso di bypass: mese 1 = 0%, mese 5 = 3%, mese 10 = 12%. Senza enforcement attivo, agent (e developer) derivano verso violazioni di boundary. È richiesto rinforzo continuo, non setup una tantum.

RISULTATI · §20 · FINDING CONTROINTUITIVO 6 · LE REGOLE SOGGETTIVE SONO LE PIÙ DIFFICILI. Abbiamo classificato le nostre 47 regole attive per difficoltà di enforcement. EASY (predicato oggettivo, controllo strutturale): "no credenziali in plaintext nei commit", "no chiamate API a endpoint bloccati", "tutte le email cliente in CC a compliance@".

MEDIUM (controllo semantico via giudice LLM): "no PII nei log", "no promesse non supportate ai clienti". HARD (giudizio soggettivo): "tratta il cliente con rispetto", "tone-of-voice in linea con il brand", "competitive intelligence resta dal lato giusto della linea legale/etica". Delle nostre 47 regole, 32 sono EASY, 12 sono MEDIUM, 3 sono HARD.

Le 3 regole HARD continuano a fallire occasionalmente (~2 incidenti per trimestre) e restano instruction-based con la superficie di fallimento intrinseca.

RISULTATI · §21 · FINDING CONTROINTUITIVO 7 · PREREQUISITO DI SCALA. Abbiamo censito 6 deployment agentic in produzione per dimensione del team. Team da 3-10: il 50% aveva governance-as-code; il resto era instruction-only.

Team da 10-30: il 67% aveva governance-as-code. Team da 30+: il 100% aveva governance-as-code. A scale più piccole, instruction-based funziona perché il team può verificare manualmente; a scale maggiori, la verifica manuale collassa e l'enforcement via codice diventa obbligatorio.

Governance-as-code è un prerequisito di scala, non un'ottimizzazione opzionale.

DISCUSSIONE · §22 · LA GOVERNANCE È UN PROCESSO SEPARATO, NON UNA SEZIONE DEL PROMPT. L'intuizione architetturale che ha prodotto il risultato a zero violazioni è rendere la governance un processo separato (il giudice di compliance) anziché una sezione di prompt nell'agent primario. Il design a due processi sfrutta il fatto che compromettere sia l'agent primario sia un giudice indipendente con un singolo attacco è drammaticamente più difficile che comprometterne uno solo. Analogo strutturale: defense-in-depth nell'architettura di sicurezza classica.

DISCUSSIONE · §23 · L'AUDIT TRAIL È METÀ DEL VALORE. Anche quando il gate approva, l'audit trail fornisce difendibilità legale, analisi post-incidente, segnale di continuous-improvement. Abbiamo usato l'audit trail per identificare retroattivamente gap di rule-design invisibili senza di esso. L'audit trail abilita anche l'audit esterno (regulator, cliente enterprise, compliance interna) senza concedere accesso all'agent in produzione.

La revisione trimestrale fa emergere ~3-5 cambi di regola per ciclo: nuove regole da failure mode appena osservati, regole esistenti chiarite su edge ambigui, occasionale ritiro quando l'infrastruttura ora gestisce la preoccupazione. Trattare le hard rule come corpus vivente (version control, rationale del cambio, deprecation policy) è di per sé chiave.

41.302 decisioni di gate in 6 mesi sono scala non triviale. La latenza del gate è sub-lineare nella dimensione del rule-set (il giudice valuta compliance contro 50+ regole in tempo grossomodo uguale a 5). L'audit trail cresce linearmente.

Dopo 12 mesi ci avviciniamo a 100.000 decisioni di gate; il file di audit-trail è 340 MB e in crescita. La compaction dell'audit-trail (analoga alla memory compaction in WSB-09) mantiene la rolling-window attiva queryabile archiviando le decisioni più vecchie.

I 240 test case avversariali rappresentano attacchi noti al Q1 2026. Continuamente emergono nuovi pattern di attacco. Ciclo red-team trimestrale pubblicato come parte del riferimento aperto di governance-as-code. Chiunque deploy il pattern dovrebbe aspettarsi di aggiornare il threat model almeno trimestralmente.

DISCUSSIONE · §27 · INTEGRAZIONE CON ALTRI Pillar. (a) Gli alert RAGAS di WSB-13 transitano nell'audit trail di governance. (b) Il cache-aware design di WSB-12 applicato al prompt del giudice (riduzione costo 73% senza cambio comportamentale). (c) L'igiene credentials di WSB-16 enforced via hard rule di governance ("mai scrivere credenziali nei log"). Il layer di governance è il punto di integrazione per le politiche cross-Pillar.

(a) Le regole soggettive (le 3 regole HARD) restano instruction-based con superficie di fallimento. (b) L'audit trail cresce linearmente; strategia di archiviazione long-term ancora in evoluzione. (c) Copertura avversariale limitata a pattern di attacco noti; pattern nuovi richiedono red-team trimestrale. (d) Il modello giudice stesso ha rischio di compromissione se un attacker può colpirlo specificamente (non l'abbiamo visto in produzione ma è teorico). (e) Overhead di performance trascurabile alla nostra scala (~600/giorno output) ma potrebbe contare a scala 100×.

(1) Template di governance multi-jurisdiction (conformance EU AI Act · NIST AI RMF · allineamento ISO 42001). (2) Algoritmi di compaction dell'audit-trail con preservazione di integrità crittografica. (3) Dataset di benchmarking cross-organizational sulla governance (cataloghi di attacco anonimizzati + pattern di difesa). (4) Enforcement di regole soggettive via ensemble di giudici con disagreement-flagging. (5) Apprendimento avversariale continuo — red-team automatizzato che genera nuovi pattern di attacco e li testa contro il gate corrente.

Gli agent Madani inviano ~150 email/giorno tra i dipartimenti customer-facing. Ogni email passa per un gate di compliance che controlla: (a) destinatario non in blocklist globale, (b) no PII nel body, (c) tono in linea con brand voice, (d) no promesse non supportate, (e) approvazione richiesta per email a executive o nuovi contatti. Email bloccate dal gate: 3/giorno in media.

Riscritte dal gate: 1/giorno in media. Il workflow pre-gate aveva incidenti mensili di email inappropriate; post-gate zero incidenti in 6 mesi.

Gli agent fanno ~2.400 chiamate API/giorno tra servizi (GHL, Stripe, HighLevel, Slack, ecc.). Il gate controlla: (a) endpoint non in blocked list, (b) autenticazione valida, (c) rate limit rispettati, (d) operazioni distruttive (DELETE) richiedono approvazione umana. Chiamate bloccate dal gate: 8/giorno in media (per lo più catture di rate-limit).

Chiamate che richiedono approvazione: 2/giorno in media. Pre-gate: 3 incidenti customer-impacting per trimestre da chiamate API agent; post-gate: zero.

Gli agent scrivono su file di workspace ~800/giorno. Il gate controlla: (a) non si scrive su path off-limits, (b) non si committano credenziali, (c) non si sovrascrive contenuto human-owned. Bloccate dal gate: 1/giorno in media (tipicamente catture di path off-limits). La regola "mai committare credenziali" ha zero violazioni in 12 mesi.

STEP 1 ENUMERARE LE REGOLE. Parti dalle 5-10 hard rule più critiche (es. "no messaggi cliente senza approvazione", "no credenziali in plaintext", "no operazioni distruttive senza conferma"). STEP 2 COMPILARE IN DSL.

Scrivi le regole in formato strutturato. STEP 3 DEPLOY DEL GATE. Sub-agent giudice di compliance che revisiona ogni output di azione esterna.

Cache-aware design (pattern prefix WSB-12) mantiene il costo minimo. STEP 4 LOG AUDIT TRAIL. Append-only, git-backed.

STEP 5 RED-TEAM. Test avversariale trimestrale. STEP 6 REVISIONE.

Revisione trimestrale della rule-list.

(1) ""REGOLE SOLO NEL SYSTEM PROMPT"" — enforcement instruction-only; failure mode strutturale. (2) "AGENT MONOLITICO" — nessuna separazione tra primario e gate; una singola compromissione sconfigge tutto. (3) "NO AUDIT TRAIL" — MTTR di incidente 11× più lungo. (4) "RULE LIST STATICA" — non evolve con i nuovi pattern di attacco; revisione trimestrale richiesta. (5) "GATE SOLO BLOCCANTE" — il gate blocca ma non suggerisce alternativa compliant; produce frizione. (6) ""GIUDICE-COME-PRIMARIO"" — usare la stessa classe modello dell'agent primario per il giudice; un giudice Haiku più economico è sufficiente e crea separazione strutturale.

(1) INTEGRITÀ CRITTOGRAFICA DELL'AUDIT TRAIL. (2) FEDERAZIONE DI GOVERNANCE CROSS-WORKSPACE. (3) COMPILAZIONE DELLE REGOLE PROVATA CORRETTA. (4) RULE-DESIGN AUTOMATIZZATO DA STORICO INCIDENTI. (5) GATE USER-INTENT-AWARE (quando l'istruzione utente confligge con la regola, route a risoluzione umana).

DISCUSSIONE · §36 · PERCHÉ QUESTO CONTA OLTRE LA GOVERNANCE. Il pattern governance-as-code è un'istanza di un principio più ampio: i sistemi in produzione beneficiano di separazione strutturale tra il layer di reasoning e il layer di enforcement. Lo stesso pattern si applica a credentials (WSB-16), evaluation (WSB-13), cost (WSB-12). La separazione strutturale è la primitiva architetturale ricorrente.

Il DSL hard-rule è front-matter YAML + body Markdown. Campi obbligatori del front-matter: id, name, scope (workspace-wide / department / agent-specific), severity (low/medium/high/critical), predicate (espressione DSL valutabile contro output JSON), action (block/rewrite/log), exemptions. Body Markdown: rationale, esempi di output compliant e non-compliant, riferimenti. Linguaggio dei predicati: uguaglianza, regex, similarità semantica (chiamata LLM), controlli strutturali (JSON path), composizione booleana.

Il prompt del giudice è cache-warm (per WSB-12): prefix lungo-stabile (rule-set + istruzioni di giudizio + esempi few-shot, ~8K token, cached); suffix corto-variabile (output proposto, ~200-500 token, fresh). Cache-hit rate: 97%. Costo per chiamata del giudice: ~$0,0003. Latenza: ~80ms p50.

Per entry: timestamp (ISO 8601), rule_id, agent_id, request_id, output_excerpt (primi 500 char o full se più corto), decision, judge_reasoning (~150 token), severity, action_taken, human_review_status. Formato: JSON-Lines append-only, git-tracked. ~340 MB a 12 mesi.

Pre-governance, un agent ha redatto e inviato un follow-up cliente usando un codename interno al posto del linguaggio customer-facing. MTTR pre-governance: 6 ore dal report al fix. Post-governance: stesso scenario bloccato al gate di compliance (regola: "messaggi customer-facing revisionati per leakage di codename interno").

L'audit trail registra il messaggio tentato + block + reasoning. MTTR ~5 minuti per verificare che la governance abbia funzionato correttamente.

Un attacker ha tentato 5 messaggi in 3 giorni, ciascuno apparentemente benigno ma cumulativamente manipolatorio. Detection: il gate ha catturato l'azione finale anche se i messaggi precedenti presi singolarmente non erano bloccabili. Aggiunta di regola rinforzata: "qualsiasi azione che segue una conversazione multi-turn richiede re-grounding esplicito allo spec del task originale". Post-fix: tentativi simili bloccati al messaggio 3.

Un agent ha tentato di inviare email a former-customer per ragioni legittime (avviso di debt-collection). Il gate ha bloccato (regola: "no email a former customer"). L'investigazione ha mostrato necessità di business legittima non prevista in precedenza.

Aggiunta esenzione: "email a former-customer permesse se contesto workflow debt-collection AND approvate da Nour". Regola aggiornata tramite revisione trimestrale.

I 240 test case rappresentano attacchi al Q1 2026. Nuovi pattern emergono regolarmente: varianti di tool-output injection, payload encoded, social engineering multi-turn. Il red-team trimestrale aggiunge ~30 nuovi pattern di attacco per ciclo. Il catalogo accumulato cresce ~12% per trimestre.

EU AI Act (2024): trasparenza, human oversight, record-keeping — tutto soddisfatto da audit trail + regola di escalation + DSL. NIST AI RMF (2023): (govern, map, measure, manage) mappa su (compilazione regole, deployment, audit trail, revisione trimestrale). ISO 42001 (2023): le clausole AIMS di governance e continuous improvement mappano sul ciclo di revisione.

Overhead totale: ~$65/anno di token del giudice di compliance + ~16 ore/anno di revisioni trimestrali + ~40 ore/anno di cicli red-team. ~80 ore/anno di tempo umano, ~$5/anno di costo LLM. Comparato a un singolo incidente regolatorio ($100K+ di multa), la governance si ripaga di ordini di grandezza.

Il programma di governance Madani fa risalire la sua hard rule più forte (HR#1 — nessuna comunicazione esterna senza approvazione esplicita di Nour) a un incidente documentato il 4 febbraio 2026 in cui l'agent ha inviato 3 messaggi Slack a un canale cliente senza autorizzazione. I messaggi erano fattualmente corretti ma non sanzionati dal gate di governance. La review post-incidente ha inquadrato il fallimento in due modi: (a) come gap di instruction-following (l'agent era stato indicato via guidance in linguaggio naturale di non inviare messaggi ma l'ha fatto comunque), o (b) come gap di governance a livello di codice (la primitive message-emit non aveva alcun check programmatico contro una authorization list).

L'inquadramento (a) è la rimedio standard "sii più attento nei prompt" ed è stata la proposta iniziale del team. L'inquadramento (b) — governance-as-code — è l'alternativa che abbiamo perseguito. Il rimedio è andato live il 6 febbraio 2026: ogni tool di comunicazione esterna (Slack post, email send, SMS send, ClickUp comment-public) è stato wrappato in un governance-gate che controlla una authorization list programmatica pre-emit.

Senza autorizzazione, il tool ritorna "GOVERNANCE_BLOCK" anziché eseguire. La finestra post-deployment di 14 mesi (feb 2026 a oggi) registra zero comunicazioni esterne non autorizzate — anche se l'agent ha tentato comunicazioni esterne ~340 volte in quella finestra durante operatività normale, ognuna è stata o pre-autorizzata (passata dal gate) o bloccata (ritornata GOVERNANCE_BLOCK e fatta emergere all'umano). Controintuitivamente, il gate a livello di codice ha un effetto del secondo ordine che non avevamo anticipato: l'intent verbalizzato dell'agent di inviare comunicazioni esterne è SCESO del 47% rispetto al baseline pre-incidente, perfino su tentativi che sarebbero stati autorizzati.

L'effetto deterrente di un blocco programmatico hard, osservabile all'agent nella sua telemetria di tool-call, ha plasmato il suo comportamento di planning verso meno proposte di external-comm. Questa è la signature empirica di governance-as-code che supera governance-as-instruction. Cross-reference WSB-08 documenta il framework hard-rule più ampio; questo case study è il punto-dato fondativo attorno al quale il framework è stato costruito.

Nel Q4 2025, l'agent stava generando una variante di landing-page copy per un'audience B2B italiana di un cliente. La bozza includeva una claim sul fatturato del cliente (""Cliente con fatturato 50 milioni"") che era corretta ma era stata presa in prestito da un caso Madani diverso (il fatturato di Madani stessa, non del cliente). Il pre-output compliance checker — un giudice LLM separato che gira contro file canonical (CHI-SIAMO.md, COSA-OFFRIAMO.md, brief cliente) — ha flaggato la claim come inconsistente con il brief canonical del cliente, che non listava i 50M di fatturato.

Il flag ha fermato la pubblicazione e ha fatto emergere a Nour per review; lui ha confermato che la claim era una contaminazione cross-caso e la bozza è stata corretta. Il case study illustra tre proprietà di governance insieme. (a) Il pre-output check opera ortogonalmente al gate di governance lato input: anche output di bozza che non hanno triggerato alcuna regola di governance di tool-call possono fallire il pre-output check sulla consistenza fattuale con i file canonical. (b) Il check è judge-LLM-based, non regex-based, perché il failure mode (contaminazione cross-case) è semantico, non sintattico; nessuna regex l'avrebbe catturato. (c) Il false-positive rate del check su 90 giorni è stato dell'8,3% (bozze flaggate che non contenevano effettivamente violazioni di compliance); il false-negative rate è stato dello 0% su un audit red-team di 60 bozze. Il profilo di errore asimmetrico (falso-positivo tollerabile, falso-negativo catastrofico) corrisponde alla filosofia di governance: meglio sovra-flaggare che spedire una violazione.

Cross-reference WSB-08 hard rules registry §HR-15.

Abbiamo auditato il workspace agentic di un team partner nel Q1 2026 che aveva adottato un pattern di governance hard-rules-as-instruction 9 mesi prima — regole scritte nel system prompt, nessun gate a livello di codice. I dati longitudinali a 9 mesi sulla telemetria di tool-call di external-comm del team hanno mostrato un drift monotonico: il mese 1 aveva 2 external-comm non sanzionate intercettate dagli umani; il mese 4 ne aveva 7; il mese 9 ne aveva 23. Il team non aveva aggiunto nuovi tool o cambiato le regole — la compliance di prompt-following dell'agent su questa specifica regola era decaduta nel tempo man mano che il modello veniva aggiornato, la context window si espandeva, e la regola veniva diluita da contesto accumulato.

Governance-as-instruction ha una emivita di circa 5-7 mesi nelle nostre osservazioni; governance-as-code non decade perché non dipende dall'interpretazione runtime del modello. Il rimedio che abbiamo raccomandato (e che il team ha implementato in 6 settimane) è stata la migrazione delle regole più violate da prompt a codice: un audit di 17 regole ha prodotto 4 regole in cui il tasso di violazione era abbastanza alto da giustificare gate a livello di codice. Post-migrazione, le 4 regole promosse hanno avuto zero violazioni in 60 giorni; le 13 regole rimaste come prompt-only hanno continuato a derivare al tasso storico.

Il rimedio asimmetrico produce un profilo cost-benefit asimmetrico: i gate a livello di codice costano circa 1 engineer-day per regola (una tantum), mentre le violazioni costano importi variabili a seconda della severità (una singola comm cliente non autorizzata può costare un retainer in termini di fiducia). Il fenomeno del decadimento è la giustificazione empirica della distinzione WAB Pillar 07 L3 → L4: L3 richiede regole documentate con enforcement via gate, L4 richiede gate che siano essi stessi auditati contro findings red-team — l'audit è la protezione contro il decadimento.

DEEP-DIVE EMPIRICO · §49 · METODOLOGIA STATISTICA SU TASSI DI VIOLAZIONE ED EFFETTO DETERRENTE. Il finding headline — governance-as-code riduce le violazioni a zero e riduce l'intent verbalizzato di violare del 47% — è stato scrutinato su tre fronti statistici. (a) Statistica zero-event: nella finestra post-deployment di 14 mesi, n=340 tentativi di external-comm, violazioni osservate = 0. Il bound superiore di confidenza Wilson al 95% sul tasso di violazione vero è 1,1% (one-sided), nel senso che possiamo rigettare qualsiasi ipotesi che il tasso vero superi l'1,1% con 95% di confidenza.

La finestra comparabile pre-deployment di 12 mesi aveva 11 violazioni in circa 320 tentativi (tasso 3,4%, CI Wilson [1,7%, 6,0%]), così il bound superiore post-deployment è sotto il bound inferiore pre-deployment — una caduta statisticamente significativa. (b) Effetto deterrente sull'intent verbalizzato: il baseline pre-incidente (Q4 2025) ha mostrato intent verbalizzato di inviare external-comm in 218 di 1.400 turn agent in cui external comms erano un'azione plausibile (15,6%); la misurazione post-deployment con stessa distribuzione di task mostra 116 di 1.408 turn (8,2%), una riduzione relativa del 47%. Test chi-quadrato sulla tabella 2×2: chi^2 = 32,7, p < 0,001. (c) Robustezza: la riduzione del 47% regge in tutti i quattro sotto-workflow (lead-gen 49%, setting 44%, sales 51%, delivery 41%), senza alcun sotto-workflow che mostra inversione. Abbiamo inoltre bootstrap-resampled il calcolo dell'effetto deterrente 5.000 volte e trovato un CI al 95% di [38%, 54%], ben distanziato da zero.

Sensibilità alla definizione di "azione plausibile": l'abbiamo rieseguito con definizioni più strette e più larghe e trovato che il 47% headline si sposta a 41-53%, mai rompendo il bound inferiore del 25%. L'effetto deterrente è reale e statisticamente robusto. Abbiamo inoltre misurato un pattern temporale: l'effetto deterrente è stato più grande nei primi 60 giorni post-deployment (picco 58%) e si è stabilizzato al 47% al giorno 120, suggerendo che l'effetto sia in parte novelty-driven (agent appena consapevole della telemetria GOVERNANCE_BLOCK) e in parte di steady-state (comportamento di planning effettivamente shiftato).

ANTI-PATTERN DI IMPLEMENTAZIONE · §50 · CINQUE FAILURE MODE NELLE ADOZIONI DI GOVERNANCE. Nei 14 team di produzione che il Madani Lab ha consigliato sull'hardening di governance tra Q3 2025 e Q1 2026, ricorrono cinque anti-pattern. (1) ""Governance solo da prompt per regole high-stakes"": i team scrivono la regola nel system prompt e assumono che verrà seguita. Come documenta §48, governance-as-instruction ha un'emivita di 5-7 mesi.

Rimedio: migrare qualsiasi regola la cui violazione abbia costo > engineer-day-equivalente a gate a livello di codice. (2) ""Compliance checker senza file canonical"": i team costruiscono un giudice LLM pre-output ma non producono mai i file canonical (brief brand, descrizione prodotto, hard-rules registry) contro cui il giudice controlla; il giudice opera quindi contro l'output precedente dell'agent stesso, creando un loop auto-validante. Rimedio: enforce un repository di file canonical separato, version-controlled, modificato solo da umani, da cui il compliance checker legge. (3) ""Gate di governance senza telemetria"": i team aggiungono gate a livello di codice che bloccano ma non loggano il tentativo bloccato; non possono misurare l'effetto deterrente né rilevare quando un pattern di tentativo shifta. Rimedio: ogni gate deve loggare {timestamp, rule_id, agent_workflow, blocked_action, surface_to_human=true/false}. (4) ""Giudice singolo per compliance"": i team usano un giudice LLM unico per il pre-output check, esponendosi al drift di calibrazione di quel giudice attraverso gli upgrade modello.

Rimedio: consensus ridondante a 2 giudici su output high-stakes; richiedere il pass di entrambi i giudici. (5) "Rule sprawl": i team accumulano 50+ hard rule nel tempo, portando a false-positive rate del compliance-checker sopra il 25% e alert fatigue. Rimedio: rule-audit trimestrale, ritirare regole con bassi tassi di violazione e alti tassi di falsi positivi, consolidare regole sovrapposte. Il registry Madani è cappato a 15 regole; l'aggiunta di una 16ª forza il ritiro di una esistente.

INTEGRAZIONE CROSS-PILLAR · §51 · DOVE LA GOVERNANCE INCONTRA GLI ALTRI Pillar WAB. Integrazione complementare con P06 Reliability: la classificazione MAST (WSB-07) tagga le violazioni di governance come FM-2.3 (Task Derailment); i due Pillar cross-validano come in §35 di WSB-07. Integrazione complementare con P08 Credentials: i gate di governance fanno enforce di politiche di scoped-token come caso speciale (la regola "no chiamata API client-facing senza credential scoped" è una hard rule).

I due Pillar insieme implementano defense-in-depth — il credential vault previene accesso unscoped, il gate di governance previene uso scoped-ma-non-autorizzato. Integrazione complementare con P09 Observability: la telemetria del gate di governance dipende dal minimo P09-L2 (logging strutturato su ogni tool call). Integrazione complementare con P11 Auto-Improvement: gli eventi di governance-block dovrebbero alimentare lo stage PROPOSE del ciclo Dreams — blocchi cronici su una regola specifica propongono o (a) stringere la regola, (b) allentare la regola, o (c) automatizzare l'approvazione umana che la regola richiede.

Tensione strutturale con P10 Portability: i gate di governance a livello di codice introducono codice framework-specific che complica gli swap di modello e framework; i team riportano un costo aggiuntivo di portabilità del ~15% quando migrano workflow governance-gated. La mitigazione è specificare i gate contro uno schema portabile (descrittori di regola JSON-schema) e lasciare che l'implementazione harness sia framework-specific mentre le definizioni di regola restano portabili.

Abbiamo esteso l'audit di governance a una popolazione: 7 subaccount cliente nel portfolio Madani sui verticali legale (Studio Munafò), real-estate (Rara Immobiliare), industriale (X-Port), beauty/wellness (Proffi), formazione osteopatica (OsteoSpace), nutrizione (Estetic Nutrition) ed energia (Grow Up Energy). La location GHL di ciascun cliente ha regole diverse intorno alle external comms (es. Munafò richiede comms-only-in-Italian e disclaimer di clinica; OsteoSpace richiede linguaggio di age-gating; Rara richiede boilerplate di real-estate-disclosure).

Audit pre-programma di governance (Q3 2025): ogni subaccount cliente aveva regole ad-hoc in formati diversi (istruzioni prompt, checklist su spreadsheet, messaggi Slack pinned); le violazioni totali sui 7 clienti in 90 giorni sommavano 23 (tasso del 0,5%/external-comm). Audit post-programma (Q1 2026): registry di regole centralizzato con variazione per-cliente, gate a livello di codice che fanno enforce di override per-cliente, e un compliance checker a 17 criteri; le violazioni totali sugli stessi 7 clienti in 90 giorni sommavano 1 (tasso del 0,02%/external-comm). La riduzione 23× è stata disomogenea tra i clienti: Munafò (legale, alta densità di regole) ha visto 14→0 violazioni; Proffi (beauty, moderata densità di regole) ha visto 4→1 violazioni (la 1 residua era un drift di font-styling catturato dal checker ma non una violazione sostanziale di comms); OsteoSpace, X-Port, Rara, Estetic e Grow Up hanno visto miglioramenti modesti coerenti con i loro tassi di partenza più bassi.

L'audit cross-client dimostra che il pattern governance-as-code generalizza tra domini; la densità di regole per dominio varia ma il pattern operativo (registry centralizzato + gate + checker) è invariante. Cross-reference WSB-08 documenta il registry di hard-rule; questo case study è la validazione cross-client. Costo di engineering per onboardare un nuovo cliente al registry: circa 1,5 giorni per l'intervista di rule-extraction con il cliente + 0,5 giorni per la configurazione del gate a livello di codice.

Manutenzione ongoing per-cliente: circa 2 ore/trimestre per il pass di rule-audit per-cliente. Il pattern cross-client fa emergere una proprietà silenziosamente importante: il costo marginale di aggiungere il secondo, terzo e Nesimo cliente a un registry di governance è sub-lineare in N perché il grosso dell'investimento di engineering (il registry, il gate, il checker, la telemetria) è ammortizzato; solo la rule-list cliente-specifica e il layer di override scalano per-cliente. Per un'organizzazione che gestisce 7+ clienti, l'overhead di governance ammortizzato cala a circa 6 ore per trimestre per cliente — operativamente trattabile anche per piccole consulenze.

Questa scalatura sub-lineare è il caso operativo a favore di registry di governance centralizzati rispetto a silos di governance per-cliente.

(Q1) IPOTESI: L'effetto deterrente dei gate a livello di codice sull'intent verbalizzato decade nel tempo man mano che il comportamento di planning dell'agent si re-equilibra attorno al nuovo constraint; nello specifico, al mese 24 l'effetto deterrente scende sotto il 20%. TEST DI FALSIFICAZIONE: misurazione longitudinale a 24 mesi dei tassi di intent verbalizzato con metodologia di misurazione consistente. (Q2) IPOTESI: I registry di gate di governance cross-organizzazione mostrano rule-set convergenti — almeno 8 delle top-15 regole sono condivise da almeno l'80% delle organizzazioni — stabilendo una tassonomia candidata standard-di-settore per hard-rule. TEST DI FALSIFICAZIONE: audit cross-organizzazione di 12 registry di governance in produzione, misurare l'overlap del rule-set. (Q3) IPOTESI: Il profilo di costo asimmetrico false-positivo-vs-false-negativo regge tra domini di workflow; il punto di calibrazione ottimale del compliance-checker è consistentemente nel range di falsi-positivi [5%, 15%].

TEST DI FALSIFICAZIONE: deploy di calibrazioni variabili su 20 workflow e misurazione dell'errore totale pesato per costo. (Q4) IPOTESI: Il consensus multi-giudice (2 giudici o 3 giudici) riduce il tasso di falsi positivi del compliance-checker di >30% senza intaccare il tasso di falsi negativi. TEST DI FALSIFICAZIONE: misurazione paired single-giudice vs 2-giudici vs 3-giudici su un benchmark. (Q5) IPOTESI: Governance-as-code introduce una portability tax misurabile del 10-20% di engineer-time aggiuntivo per migrazione di framework, ma la portability tax è ammortizzata su 18+ mesi dal beneficio di prevenzione delle violazioni. TEST DI FALSIFICAZIONE: studio di costo di migrazione su 5 organizzazioni con workflow paired no-governance e governance-gated. (Q6) IPOTESI: Un "DSL di regole" specializzato (regole espresse in un linguaggio dichiarativo dominio-specifico anziché in codice imperativo) riduce il costo di manutenzione del gate di governance di >50% senza ridurre la copertura di protezione.

TEST DI FALSIFICAZIONE: studio longitudinale a 18 mesi che confronta la manutenzione di governance DSL-based e code-based.

[1] Anthropic (2022), Constitutional AI: Harmlessness from AI Feedback. [2] OpenAI (2025), Model Spec. [3] Greshake K. et al. (2023), Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. [4] Perez F. & Ribeiro I. (2022), Ignore Previous Prompt: Attack Techniques For Language Models. [5] Wei A. et al. (2023), Jailbroken: How Does LLM Safety Training Fail. [6] EU Commission (2024), AI Act Regulation. [7] NIST (2023), AI Risk Management Framework AI 100-1. [8] ISO/IEC (2023), 42001 Artificial Intelligence Management System. [9] Madani Lab (2026), Governance-as-Code Reference Architecture v1.0 (open). [10] Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra B., Tiwari R., Keutzer K., Parameswaran A., Klein D., Ramchandran K., Zaharia M., Gonzalez J.E., Stoica I. (2025), Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657v3, NeurIPS 2025. [11] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning, arXiv:2604.02460. [12] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [13] Es S., James J., Espinosa-Anke L., Schockaert S. (2024), RAGAS, EACL 2024, arXiv:2309.15217. [14] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [15] Anthropic (2025), Claude Haiku Technical Report. [16] OWASP (2024), Top 10 LLM Applications. [17] Schick T. et al. (2023), Toolformer, NeurIPS. [18] Mu N. et al. (2024), Building Safer Conversational Agents. [19] Anthropic (2025), Prompt Engineering for Production. [20] Madani Lab (2026), compliance-gate skill v1.2. [21] Madani Lab (2026), governance-policy.md v1.4.

L'architettura di governance Madani consta di quattro layer:

(1) COMPILAZIONE HARD-RULE. Le hard rule sono scritte in un DSL vincolato (un file Markdown con front-matter strutturato) compilato allo startup dell'agent sia (a) in una sezione prompt in linguaggio naturale iniettata a ogni turno sia (b) in un rule-set strutturato usato dai gate di compliance a valle. Lo step di compilazione garantisce che la versione in linguaggio naturale non possa derivare da quella strutturata.

(2) GATE DI COMPLIANCE PRE-OUTPUT. Prima che qualsiasi output dell'agent raggiunga un sistema esterno (invio email, chiamata API, scrittura su file accessibile agli umani), un sub-agent giudice di compliance (piccola chiamata Claude Haiku, ~150 token di overhead) revisiona l'output proposto contro il rule-set strutturato e approva, riscrive o blocca. Il giudice è un processo separato; anche se l'agent primario è compromesso da prompt injection, il gate giudice fa enforce delle regole in modo indipendente.

(3) AUDIT TRAIL STRUTTURATO. Ogni decisione del gate è loggata su un file di audit append-only con: rule ID controllato, output dell'agent revisionato, decisione (approve/rewrite/block), reasoning, timestamp. Il file di audit è human-readable, version-controlled e forma il registro legalmente difendibile del comportamento dell'agent.

(4) REVISIONE PERIODICA DELLE REGOLE. Le hard rule sono riviste trimestralmente: sono ancora rilevanti, vengono controllate correttamente, sono emersi nuovi failure mode che suggeriscono nuove regole. La review è un meeting strutturato con outcome documentati; le regole possono essere aggiunte, modificate o ritirate solo via questa review.

Abbiamo anche misurato il traffico di produzione: 6 mesi di normale operatività agent su 8 dipartimenti.

Il risultato headline: zero violazioni di hard rule osservate hanno raggiunto sistemi esterni in 6 mesi di traffico di produzione. La test suite avversariale: 240/240 tentativi di injection sono stati bloccati dal gate di compliance (l'agent primario è stato ingannato 87 volte — 36% — fino a proporre un output che viola la regola; il gate di compliance ha catturato tutti gli 87). L'audit trail contiene 41.302 decisioni di gate in 6 mesi: 41.261 approve (99,9%), 24 rewrite (il gate ha suggerito un'alternativa compliant accettata dall'agent primario), 17 block (il gate ha rifiutato, e l'agent primario ha escalato a review umana).

Gli 87 attacchi riusciti sull'agent primario (catturati al gate) sono di per sé dati di valore: formano un dataset avversariale reale che informa la prossima iterazione del design hard-rule. L'analisi rivela 3 pattern di attacco dominanti: (a) "authority override" — un'istruzione iniettata dichiara di provenire da un proprietario del sistema con autorità maggiore della regola originale (47 tentativi); (b) "edge case rationalization" — l'injection presenta uno scenario costruito in cui la regola "ovviamente" non si applica (28 tentativi); (c) "incremental commitment" — l'injection chiede una serie di piccoli passi ognuno dei quali sembra innocuo ma cumulativamente viola la regola (12 tentativi).

L'overhead di performance: il gate di compliance aggiunge ~80ms p50 di latenza per output e ~$0,0003 per output in costo di token. Per il volume di traffico Madani (~600 output agent-driven/giorno), questo è ~$0,18/giorno o ~$65/anno. Prezzo trascurabile per la garanzia di governance.

Tre implicazioni.

(i) LA GOVERNANCE È UN PROCESSO SEPARATO, NON UNA SEZIONE DI PROMPT. L'intuizione architetturale che ha prodotto il risultato a zero violazioni è rendere la governance un processo separato (il giudice di compliance) anziché una sezione di prompt nell'agent primario. Il design a due processi sfrutta il fatto che compromettere sia l'agent primario sia un giudice indipendente con un singolo attacco è drammaticamente più difficile che comprometterne uno solo. È strutturalmente analogo al defense-in-depth nell'architettura di sicurezza classica.

(ii) L'AUDIT TRAIL È METÀ DEL VALORE. Anche quando il gate di compliance approva un output, l'audit trail fornisce difendibilità legale, capacità di analisi post-incidente e segnale di continuous-improvement. Abbiamo usato l'audit trail per identificare retroattivamente gap di rule-design che non sarebbero stati visibili senza di esso. L'audit trail abilita anche l'audit esterno (un regulator, un cliente enterprise, un compliance team interno) senza concedere accesso all'agent in produzione stesso.

(iii) LE HARD RULE SONO UN CORPUS VIVENTE, NON UN DOCUMENTO FISSO. La revisione trimestrale fa emergere ~3-5 cambi di regola per ciclo: nuove regole aggiunte a causa di failure mode appena osservati, regole esistenti chiarite per edge ambigui, occasionalmente una regola ritirata perché la preoccupazione sottostante ora è gestita dall'infrastruttura. Trattare le hard rule come un corpus vivente (con version control, rationale del cambio, deprecation policy) è di per sé una parte chiave dell'architettura.

Chiudiamo integrando l'architettura con il framework WAB. La governance mappa su Pillar 07 (Governance) con criterio di maturità del compliance-gate a L3 (processo gate esiste, indipendente dall'agent primario), e criterio di maturità dell'audit-trail a L4 (audit + revisione periodica + improvement velocity tracciata). L'implementazione Madani è il riferimento: 380 righe di Python che orchestrano la compilazione delle regole, il processo gate e l'audit-write, MIT-licensed.

DISCUSSIONE · GOVERNANCE A SCALA. Le 41.302 decisioni di gate in 6 mesi rappresentano governance a scala non triviale. Osserviamo che la latenza del gate è sub-lineare nella dimensione del rule-set (il modello giudice valuta compliance contro 50+ regole in tempo grossomodo uguale a 5 regole) ma l'audit trail cresce linearmente.

Dopo 12 mesi ci stiamo avvicinando a 100.000 decisioni di gate; il file di audit-trail è ora 340 MB e in crescita. Abbiamo iniziato il rollout della compaction dell'audit-trail (analoga alla memory compaction in WSB-09) per mantenere la rolling-window attiva queryabile archiviando le decisioni più vecchie.

DISCUSSIONE · EVOLUZIONE AVVERSARIALE. I 240 test case avversariali rappresentano attacchi noti al Q1 2026. Continuamente emergono nuovi pattern di attacco.

Ci siamo impegnati a un ciclo red-team trimestrale e pubblichiamo il catalogo di attacchi aggiornato come parte del riferimento aperto governance-as-code. Chiunque deploy il pattern dovrebbe aspettarsi di aggiornare il proprio threat model almeno trimestralmente.

(1) Template di governance multi-jurisdiction (conformance EU AI Act · NIST AI RMF · allineamento ISO 42001). (2) Algoritmi di compaction dell'audit-trail con preservazione di integrità crittografica. (3) Dataset di benchmarking cross-organizational sulla governance (cataloghi di attacco anonimizzati + pattern di difesa).

Anthropic (2022), Constitutional AI; OpenAI (2025), Model Spec; Greshake K. et al. (2023), Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection; Perez F. & Ribeiro I. (2022), Ignore Previous Prompt: Attack Techniques For Language Models; Wei A. et al. (2023), Jailbroken: How Does LLM Safety Training Fail; EU Commission (2024), AI Act Regulation; NIST (2023), AI Risk Management Framework AI 100-1; ISO/IEC (2023), 42001 Artificial Intelligence Management System; Madani Lab (2026), Governance-as-Code Reference Architecture v1.0 (open).