Nalevingsbevindingen

Een catalogus van eisen maakt van een richtlijn controleerbare items. Oloproof levert er een voor de Directive on Automated Decision-Making van de Canadese Treasury Board met de andere die de pagina over rechtsgebieden noemt. oloproof init --example governance kopieert ze naar de map catalogues/ van een project, naast een governance.yaml die ze leest, zodat oloproof governance check daar meteen draait. oloproof governance check leest die tegen uw systemen en zegt per eis of die is vervuld, gedeeltelijk vervuld, niet vervuld, niet van toepassing of niet te bepalen. Elke bevinding noemt waarop ze rust: de beslissingen van uw gate, de verklaring van een met naam genoemde persoon of een beoordeeld concept.

Een bevinding is een samenvatting voor een lezer. Ze verandert nooit een beslissing en is nooit een toestemming voor gebruik. Ze is geen juridisch advies.

Het governancebestand

governance.yaml staat naast 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

Hoe een bevinding tot stand komt

• Gemeten eisen lezen de gateregels die eraan gekoppeld zijn, bij de nieuwste run van elke suite van de huidige versie van het systeem, binnen de beoordelingsperiode. Vervuld alleen als elke gekoppelde regel PASS is; niet vervuld als er een FAIL is; anders niet te bepalen. Nooit gedeeltelijk vervuld.
• Verklaarde eisen lezen de nieuwste geldige verklaring. Een verklaring verloopt na de beoordelingsperiode, of wanneer de versie van het systeem voorbij de genoemde gaat.
• Ondersteunde eisen beginnen bij het concept van een model, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, dat nooit een bevinding is totdat een beoordelaar ermee aan de slag gaat: oloproof governance review --action validate|reject|modify|annotate.
• Samengestelde eisen combineren hun delen: één onbepaald deel blokkeert vervuld.

De regels staan in docs/engine/FINDING_RULES.md, toegelaten door hun audit op 2 november 2026.

Eerlijkheid tussen groepen

DADM 6.3.3 en 6.3.8 vragen of de resultaten voor elke groep standhouden. Koppel ze aan een min-regel op een worst_group-metriek (Configuratiereferentie), die elke genoemde groep tegelijk aan de drempel houdt.

Verzegelen, ondertekenen en herbeoordelen

oloproof governance check --seal schrijft een bevindingenrecord, genummerd en geketend aan het vorige, met de kop van het beoordelingslogboek erin. Voeg --sign office.key --signer "CIO office" toe om het te ondertekenen met een sleutel gemaakt door oloproof runner keygen; iedereen kan het controleren met oloproof governance verify RECORD --public-key KEY. Een handtekening zegt wie het verzegelde, niet dat de bevindingen waar zijn. Een systeem wordt gemarkeerd voor herbeoordeling als het nooit is beoordeeld, de beoordelingsperiode is verstreken, de versie is gewijzigd of de catalogus is gewijzigd.

Corrigerende maatregelen worden gevolgd met oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV toont voor elk open, nog niet geëxporteerd ticket de Jira-issue die het zou aanmaken (REST v3 /rest/api/3/issue, beschrijving in Atlassian Document Format); --to servicenow toont een Table API-record voor incident, of problem met --table problem. Voeg --send --by "A. Officer" toe om ze aan te maken, met OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN of OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD ingesteld (nooit opgeslagen of getoond). De sleutel die elke dienst teruggeeft, wordt in het logboek geschreven als annotatie op de eis van het ticket: bevindingen tonen hem en een ticket wordt nooit twee keer verstuurd. Getest tegen opgenomen antwoorden, niet tegen een echte Jira- of ServiceNow-instantie.

Voordat een ticket wordt verstuurd, noteert het logboek de export als in behandeling; een nieuwe run na een crash zoekt het ticket op in de dienst (via een label in Jira, via correlation_id in ServiceNow) en noteert de bestaande sleutel in plaats van een tweede aan te maken. Deze aantekeningen beginnen met oloproof-export:, een voorvoegsel dat de eigen notitie van een beoordelaar niet mag gebruiken. Wat uw organisatie verlaat: de notitie van het ticket, de eis en het systeem, de naam van wie het opende zoals in het logboek geschreven, de datum en de digest; geen inhoud van cases.

oloproof governance mlflow leest een MLflow-modelregister: stel MLFLOW_TRACKING_URI in en, als de server erom vraagt, MLFLOW_TRACKING_TOKEN (geen van beide wordt opgeslagen of getoond). Elk geregistreerd model hoort bij het systeem waarvan system of id de modelnaam is; een model dat geen systeem noemt, wordt getoond als systeem om aan governance.yaml toe te voegen, buiten scope tot een mens beslist. Nummer, run-id en bron van elke versie worden bewaard onder .oloproof/governance/mlflow/. Met --tag worden de bevindingen van het laatst verzegelde record op de nieuwste versie van elk gekoppeld model geschreven als tags oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Getest tegen opgenomen antwoorden en, op 4 november 2026, tegen een lokaal gedraaide echte MLflow 3.18.0-server, met de tags teruggelezen.

oloproof governance azureml, oloproof governance sagemaker doen hetzelfde voor een Azure Machine Learning-werkruimte en een Amazon SageMaker Model Registry. Azure ML leest de werkruimte die AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE noemen via de beheer-API, met een token in AZURE_ACCESS_TOKEN (az account get-access-token); --tag voegt de vier tags toe aan die van de nieuwste versie. SageMaker leest modelpakketgroepen als modellen en hun pakketversies als versies, en ondertekent elk verzoek met de standaard AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag zet de vier waarden als klantmetadata van het nieuwste pakket. Geen enkele referentie wordt opgeslagen of getoond; imports staan onder .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Beide zijn getest tegen opgenomen antwoorden in de gedocumenteerde vormen van elke dienst; er is geen echt Azure- of AWS-account gebruikt.

Bewaring, toegang en dataresidentie

In een gehoste workspace stelt de Owner in Instellingen in hoeveel dagen de case-inhoud van runs, traces en het leeslog worden bewaard; de worker verwijdert wat ouder is en schrijft een ontvangstbewijs dat Owners en Admins kunnen downloaden. Beslissingen, goedkeuringen, zegels en governance-records worden altijd bewaard. Elke keer dat een run, de bevindingen of een zegel wordt geopend, wordt dat met account en tijd in het auditlog vastgelegd. Data blijven in de ene regio van de deployment (oloproof.com: Toronto, back-ups in Toronto met een versleutelde kopie in Chicago); residentie betekent een deployment per regio.

Meerdere catalogi, beoordeling in de workspace en de API

Een project kan met catalogues: [dadm.yaml, ethics.yaml] meerdere catalogi noemen. Elk systeem wordt gelezen tegen de catalogi die het noemt (catalogues: op het systeem), die van de groepen die het noemen (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), of anders alle gedeclareerde catalogi, en elke bevinding noemt haar catalogus. Een nieuwe versie van een catalogus markeert een eis met retired: "2027-01-01" en replaced_by: <id> in plaats van haar te verwijderen: na die dag levert ze geen bevinding meer op, en het record noemt haar.

In de gehoste workspace valideert, verwerpt, wijzigt of annoteert een Owner of Admin een bevinding op de pagina Governance. Elke actie wordt onder het eigen account vastgelegd in het eigen, met hashes geketende beoordelingslogboek van de workspace, gelezen na het gepushte logboek, en een zegel exporteert beide logboeken.

Een token met de leesscope leest dezelfde objecten voor het eigen project: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, beschreven in OpenAPI 3.1 op /api/openapi.json. Geen ervan bevat inhoud van cases.

Wat het u niet kan vertellen

Verklaringen zijn het woord van mensen; Oloproof legt vast wie wat wanneer zei, en controleert het niet. Een bevinding is maar zo sterk als de regels die eraan gekoppeld zijn. In een gehoste werkruimte staan dezelfde bevindingen op de Governance-pagina van het project.