Vai al contenuto
Docs
Registro delle modifichePrezziApri la console

Guide

Rilievi di conformità

Un catalogo di requisiti trasforma una direttiva in voci verificabili. Oloproof ne fornisce uno per la Direttiva sul processo decisionale automatizzato del Treasury Board canadese, con gli altri elencati nella pagina delle giurisdizioni. oloproof init --example governance li copia nella directory catalogues/ di un progetto, accanto a un governance.yaml che li legge, così oloproof governance check vi si esegue subito. oloproof governance check lo legge rispetto ai vostri sistemi e dice, per ogni requisito, se è soddisfatto, parzialmente soddisfatto, non soddisfatto, non applicabile o non determinabile. Ogni rilievo nomina ciò su cui si basa: le decisioni del vostro gate, la dichiarazione di una persona nominata o una bozza revisionata.

Un rilievo è un riepilogo per un lettore. Non cambia mai una decisione e non è mai un'autorizzazione all'esercizio. Non è una consulenza legale.

Il file di governance

governance.yaml sta accanto a oloproof.yaml:

catalogue: catalogues/dadm_catalogue_2025-06-24.yaml   # as `init --example governance` copies it
systems:
  - id: triage
    name: Benefits triage
    system: triage            # the oloproof system name its runs are recorded under
    in_scope: true
    scope_reason: assesses eligibility for a federal benefit
    environment: production
    production_since: 2026-06-01
    aia_level: II
    review_period_days: 365
    bindings:
      DADM-6.3.1: [accuracy-floor]      # the gate rules that decide a measured requirement
      DADM-6.3.3#1: [every-region]      # or one part of a composite
statements:
  - id: s1
    system: triage
    target: DADM-6.1.1
    says: met                 # met, not_met or not_applicable
    by: A. Officer
    role: CIO office
    on: 2026-10-01
    link: https://example.org/aia

Come si arriva a un rilievo

  • I requisiti misurati leggono le regole del gate collegate a essi, all'esecuzione più recente di ogni suite della versione attuale del sistema, entro il suo periodo di revisione. Soddisfatto solo quando ogni regola collegata è PASS; non soddisfatto quando una è FAIL; altrimenti non determinabile. Mai parzialmente soddisfatto.
  • I requisiti attestati leggono l'ultima dichiarazione valida. Una dichiarazione scade dopo il periodo di revisione, o quando la versione del sistema supera quella che nomina.
  • I requisiti assistiti partono dalla bozza di un modello, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, che non è mai un rilievo finché un revisore non agisce su di essa: oloproof governance review --action validate|reject|modify|annotate.
  • I requisiti compositi combinano le loro parti: una parte indeterminata impedisce che siano soddisfatti.

Le regole sono in docs/engine/FINDING_RULES.md, ammesse dal loro audit il 2 novembre 2026.

Equità tra gruppi

I punti 6.3.3 e 6.3.8 della DADM chiedono se i risultati reggono per ogni gruppo. Collegateli a una regola min su una metrica worst_group (Riferimento della configurazione), che sottopone in una volta ogni gruppo nominato alla soglia.

Sigillare, firmare e rivalutare

oloproof governance check --seal scrive un registro di rilievi, numerato e concatenato al precedente, con la testa del registro di revisione al suo interno. Aggiungete --sign office.key --signer "CIO office" per firmarlo con una chiave creata da oloproof runner keygen; chiunque può verificarlo con oloproof governance verify RECORD --public-key KEY. Una firma dice chi l'ha sigillato, non che i rilievi siano veri. Un sistema viene segnalato per una rivalutazione quando non è mai stato valutato, il suo periodo di revisione è scaduto, la sua versione è cambiata o il catalogo è cambiato.

Le azioni correttive si seguono con oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV stampa, per ogni ticket aperto non ancora esportato, la issue Jira che creerebbe (REST v3 /rest/api/3/issue, descrizione in Atlassian Document Format); --to servicenow stampa un record della Table API per incident, o problem con --table problem. Aggiungete --send --by "A. Officer" per crearli, con OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN oppure OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD impostate (mai salvate né stampate). La chiave restituita da ciascun servizio è scritta nel registro come annotazione sul requisito del ticket: i rilievi la mostrano e un ticket non è mai inviato due volte. Testato su risposte registrate, non su un'istanza reale di Jira o ServiceNow.

Prima dell'invio di un ticket, il registro annota l'esportazione come in sospeso; una nuova esecuzione dopo un arresto anomalo cerca il ticket nel servizio (tramite un'etichetta in Jira, tramite correlation_id in ServiceNow) e annota la chiave esistente invece di crearne un secondo. Queste annotazioni iniziano con oloproof-export:, un prefisso che la nota di un revisore non può usare. Cosa esce dalla vostra organizzazione: la nota del ticket, il suo requisito e il suo sistema, il nome di chi l'ha aperto come scritto nel registro, la data e il digest; nessun contenuto dei casi.

oloproof governance mlflow legge un registro di modelli MLflow: impostate MLFLOW_TRACKING_URI e, se il server lo richiede, MLFLOW_TRACKING_TOKEN (nessuno dei due è salvato o stampato). Ogni modello registrato corrisponde al sistema il cui system o id è il nome del modello; un modello che nessun sistema nomina è stampato come sistema da aggiungere a governance.yaml, fuori ambito finché una persona non decide. Numero, id di esecuzione e sorgente di ogni versione sono conservati in .oloproof/governance/mlflow/. Con --tag, i rilievi dell'ultimo record sigillato sono scritti sull'ultima versione di ogni modello associato come tag oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Testato su risposte registrate e, il 4 novembre 2026, su un server MLflow 3.18.0 reale eseguito in locale, con i tag riletti.

oloproof governance azureml, oloproof governance sagemaker fanno lo stesso per un'area di lavoro Azure Machine Learning e un Amazon SageMaker Model Registry. Azure ML legge l'area di lavoro indicata da AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE tramite l'API di gestione, con un token in AZURE_ACCESS_TOKEN (az account get-access-token); --tag aggiunge i quattro tag a quelli dell'ultima versione. SageMaker legge i gruppi di pacchetti di modelli come modelli e le loro versioni di pacchetto come versioni, firmando ogni richiesta con le variabili standard AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag imposta i quattro valori come metadati cliente dell'ultimo pacchetto. Nessuna credenziale viene salvata o stampata; le importazioni restano in .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Entrambi sono stati testati su risposte registrate nelle forme documentate di ciascun servizio; nessun account Azure o AWS reale è stato usato.

Conservazione, accesso e residenza

In un workspace ospitato, l'Owner stabilisce nelle Impostazioni per quanti giorni si conservano il contenuto dei casi delle esecuzioni, le tracce e il registro delle letture; il worker elimina ciò che è più vecchio e scrive una ricevuta che Owner e Admin possono scaricare. Decisioni, approvazioni, sigilli e registri di governance si conservano sempre. Ogni apertura di un'esecuzione, dei risultati o di un sigillo è registrata con account e ora nel registro di audit. I dati restano nell'unica regione del deployment (oloproof.com: Toronto, backup a Toronto con una copia cifrata a Chicago); la residenza significa un deployment per regione.

Più cataloghi, revisione nel workspace e l'API

Un progetto può indicare più cataloghi con catalogues: [dadm.yaml, ethics.yaml]. Ogni sistema è valutato rispetto ai cataloghi che elenca (catalogues: sul sistema), a quelli dei gruppi che lo nominano (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}) o altrimenti a tutti i cataloghi dichiarati, e ogni rilievo indica il suo catalogo. Una nuova versione di un catalogo segna un requisito retired: "2027-01-01" con replaced_by: <id> invece di eliminarlo: dopo quel giorno non produce rilievi, e il record lo indica.

Nel workspace ospitato un Owner o un Admin convalida, respinge, modifica o annota un rilievo nella pagina Governance. Ogni azione è registrata con il suo account nel registro di revisione del workspace, concatenato tramite hash, letto dopo il registro inviato, e un sigillo esporta entrambi i registri.

Un token con l'ambito di lettura legge gli stessi oggetti per il proprio progetto: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, descritti in OpenAPI 3.1 su /api/openapi.json. Nessuno contiene il contenuto dei casi.

Cosa non può dirvi

Le dichiarazioni sono la parola di persone; Oloproof registra chi ha detto cosa e quando, e non lo verifica. Un rilievo è solido quanto le regole collegate a esso. In uno spazio di lavoro ospitato, gli stessi rilievi compaiono nella pagina Governance del progetto.