Constats de conformité

Un catalogue d'exigences transforme une directive en entrées vérifiables. Oloproof en livre un pour la Directive sur la prise de décisions automatisée du Conseil du Trésor, avec les autres que liste la page des juridictions. oloproof init --example governance les copie dans le répertoire catalogues/ d’un projet, à côté d’un governance.yaml qui les lit, si bien que oloproof governance check s’y exécute aussitôt. oloproof governance check le lit au regard de vos systèmes et dit, pour chaque exigence, si elle est satisfaite, partiellement satisfaite, non satisfaite, sans objet ou impossible à évaluer. Chaque constat nomme ce sur quoi il repose : les décisions de votre gate, la déclaration d'une personne nommée ou un projet relu.

Un constat est un résumé pour un lecteur. Il ne change jamais une décision et n'est jamais une autorisation d'exploitation. Ce n’est pas un avis juridique.

Le fichier de gouvernance

governance.yaml se place à côté de 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

Comment un constat est établi

• Les exigences mesurées lisent les règles du gate qui leur sont liées, au run le plus récent de chaque suite de la version actuelle du système, dans sa période de revue. Satisfaite seulement si chaque règle liée est PASS ; non satisfaite si l'une est FAIL ; sinon impossible à évaluer. Jamais partiellement satisfaite.
• Les exigences attestées lisent la dernière déclaration en vigueur. Une déclaration devient périmée après la période de revue, ou quand la version du système dépasse celle qu'elle nomme.
• Les exigences assistées partent du projet d'un modèle, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, qui n'est jamais un constat tant qu'un réviseur n'y a pas donné suite : oloproof governance review --action validate|reject|modify|annotate.
• Les exigences composites combinent leurs parties : une partie indéterminée empêche une exigence d'être satisfaite.

Les règles sont dans docs/engine/FINDING_RULES.md, admises par leur audit le 2 novembre 2026.

Équité entre les groupes

Les articles 6.3.3 et 6.3.8 de la DPDA demandent si les résultats tiennent pour chaque groupe. Liez-les à une règle min sur une métrique worst_group (Référence de configuration), qui soumet d'un coup chaque groupe nommé au seuil.

Sceller, signer et réévaluer

oloproof governance check --seal écrit un registre de constats, numéroté et chaîné au précédent, avec la tête du journal de revue à l'intérieur. Ajoutez --sign office.key --signer "CIO office" pour le signer avec une clé créée par oloproof runner keygen ; n'importe qui peut le vérifier avec oloproof governance verify RECORD --public-key KEY. Une signature dit qui l'a scellé, pas que les constats sont vrais. Un système est signalé pour réévaluation quand il n'a jamais été évalué, que sa période de revue est échue, que sa version a changé ou que le catalogue a changé.

Les mesures correctives sont suivies avec oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV affiche, pour chaque ticket ouvert pas encore exporté, le ticket Jira qu'il créerait (REST v3 /rest/api/3/issue, description en Atlassian Document Format) ; --to servicenow affiche un enregistrement de la Table API pour incident, ou problem avec --table problem. Ajoutez --send --by "A. Officer" pour les créer, avec OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN ou OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD définies (jamais stockées ni affichées). La clé renvoyée par chaque service est inscrite au journal comme annotation sur l'exigence du ticket : les constats l'affichent et un ticket n'est jamais envoyé deux fois. Testé contre des réponses enregistrées, pas contre une instance Jira ou ServiceNow réelle.

Avant l'envoi d'un ticket, le journal note l'export comme en attente ; une nouvelle exécution après un plantage cherche le ticket dans le service (par une étiquette dans Jira, par correlation_id dans ServiceNow) et note la clé existante au lieu d'en créer un second. Ces annotations commencent par oloproof-export:, un préfixe qu'une note d'un relecteur ne peut pas utiliser. Ce qui quitte votre organisation : la note du ticket, son exigence et son système, le nom de la personne qui l'a ouvert tel qu'écrit dans le journal, sa date et son empreinte ; aucun contenu de cas.

oloproof governance mlflow lit un registre de modèles MLflow : définissez MLFLOW_TRACKING_URI et, si le serveur l'exige, MLFLOW_TRACKING_TOKEN (ni l'un ni l'autre n'est stocké ni affiché). Chaque modèle enregistré correspond au système dont le system ou l'id est le nom du modèle ; un modèle qu'aucun système ne nomme est affiché comme système à ajouter à governance.yaml, hors champ jusqu'à ce qu'une personne décide. Le numéro, l'identifiant d'exécution et la source de chaque version sont conservés sous .oloproof/governance/mlflow/. Avec --tag, les constats du dernier registre scellé sont écrits sur la dernière version de chaque modèle associé en étiquettes oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Testé contre des réponses enregistrées et, le 4 novembre 2026, contre un serveur MLflow 3.18.0 réel exécuté localement, étiquettes relues.

oloproof governance azureml, oloproof governance sagemaker font de même pour un espace de travail Azure Machine Learning et un Amazon SageMaker Model Registry. Azure ML lit l'espace de travail nommé par AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE par l'API de gestion, avec un jeton dans AZURE_ACCESS_TOKEN (az account get-access-token) ; --tag ajoute les quatre étiquettes à celles de la dernière version. SageMaker lit les groupes de paquets de modèles comme modèles et leurs versions de paquet comme versions, et signe chaque requête avec les variables standard AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION ; --tag inscrit les quatre valeurs comme métadonnées client du dernier paquet. Aucun identifiant n'est stocké ni affiché ; les importations sont conservées sous .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Les deux ont été testés contre des réponses enregistrées aux formes documentées de chaque service ; aucun compte Azure ou AWS réel n'a été utilisé.

Conservation, accès et résidence

Dans un espace de travail hébergé, le Owner fixe dans les Paramètres combien de jours sont conservés le contenu des cas d'exécution, les traces et le journal des lectures ; le worker supprime ce qui est plus ancien et écrit un reçu que les Owners et Admins peuvent télécharger. Les décisions, approbations, sceaux et dossiers de gouvernance sont toujours conservés. Chaque ouverture d'une exécution, des constats ou d'un sceau est consignée avec le compte et l'heure dans le journal d'audit. Les données restent dans l'unique région du déploiement (oloproof.com : Toronto, sauvegardes à Toronto avec une copie chiffrée à Chicago) ; la résidence signifie un déploiement par région.

Plusieurs catalogues, revue dans l'espace de travail et l'API

Un projet peut nommer plusieurs catalogues avec catalogues: [dadm.yaml, ethics.yaml]. Chaque système est lu selon les catalogues qu'il liste (catalogues: sur le système), ceux des groupes qui le nomment (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), ou sinon tous les catalogues déclarés, et chaque constat nomme son catalogue. Une nouvelle version d'un catalogue marque une exigence retired: "2027-01-01" avec replaced_by: <id> au lieu de la supprimer : elle ne produit plus de constat après ce jour, et l'enregistrement la nomme.

Dans l'espace de travail hébergé, un Owner ou un Admin valide, rejette, modifie ou annote un constat sur la page Gouvernance. Chaque action est consignée sous son compte dans le journal de revue chaîné par hachage propre à l'espace de travail, lu après le journal poussé, et un sceau exporte les deux journaux.

Un jeton doté de la portée de lecture lit les mêmes objets pour son propre projet : GET /api/governance/findings, /seal, /statements, /reviews, /approvals, décrits en OpenAPI 3.1 à /api/openapi.json. Aucun ne contient le contenu des cas.

Ce que cela ne peut pas vous dire

Les déclarations sont la parole de personnes ; Oloproof enregistre qui a dit quoi et quand, et ne le vérifie pas. Un constat ne vaut que les règles qui lui sont liées. Dans un espace de travail hébergé, les mêmes constats apparaissent sur la page Gouvernance du projet.