Compliance-Befunde

Ein Anforderungskatalog macht aus einer Richtlinie prüfbare Einträge. Oloproof liefert einen für die Directive on Automated Decision-Making des kanadischen Treasury Board sowie die weiteren, die die Seite zu Rechtsräumen aufführt. oloproof init --example governance kopiert sie in das Verzeichnis catalogues/ eines Projekts, neben eine governance.yaml, die sie liest, sodass oloproof governance check dort sofort läuft. oloproof governance check liest ihn gegen Ihre Systeme und sagt für jede Anforderung, ob sie erfüllt, teilweise erfüllt, nicht erfüllt, nicht anwendbar oder nicht bestimmbar ist. Jeder Befund nennt, worauf er beruht: die Entscheidungen Ihres Gates, die Erklärung einer namentlich genannten Person oder einen geprüften Entwurf.

Ein Befund ist eine Zusammenfassung für einen Leser. Er ändert nie eine Entscheidung und ist nie eine Betriebsgenehmigung. Er ist keine Rechtsberatung.

Die Governance-Datei

governance.yaml liegt neben 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

Wie ein Befund zustande kommt

• Gemessene Anforderungen lesen die an sie gebundenen Gate-Regeln, beim neuesten Lauf jeder Suite der aktuellen Systemversion, innerhalb ihres Prüfzeitraums. Erfüllt nur, wenn jede gebundene Regel PASS ist; nicht erfüllt, wenn eine FAIL ist; sonst nicht bestimmbar. Nie teilweise erfüllt.
• Bestätigte Anforderungen lesen die neueste gültige Erklärung. Eine Erklärung veraltet nach dem Prüfzeitraum oder wenn die Systemversion über die genannte hinausgeht.
• Unterstützte Anforderungen beginnen mit dem Entwurf eines Modells, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, der nie ein Befund ist, bis ein Prüfer darauf reagiert: oloproof governance review --action validate|reject|modify|annotate.
• Zusammengesetzte Anforderungen kombinieren ihre Teile: ein unbestimmter Teil verhindert ein Erfüllt.

Die Regeln stehen in docs/engine/FINDING_RULES.md, zugelassen durch ihr Audit am 2. November 2026.

Fairness über Gruppen hinweg

DADM 6.3.3 und 6.3.8 fragen, ob die Ergebnisse für jede Gruppe gelten. Binden Sie sie an eine min-Regel auf einer worst_group-Metrik (Konfigurationsreferenz), die jede genannte Gruppe zugleich an die Schwelle hält.

Versiegeln, signieren und neu bewerten

oloproof governance check --seal schreibt ein Befundprotokoll, nummeriert und mit dem vorherigen verkettet, mit dem Kopf des Prüfprotokolls darin. Fügen Sie --sign office.key --signer "CIO office" hinzu, um es mit einem von oloproof runner keygen erzeugten Schlüssel zu signieren; jeder kann es mit oloproof governance verify RECORD --public-key KEY prüfen. Eine Signatur sagt, wer es versiegelt hat, nicht dass die Befunde wahr sind. Ein System wird zur Neubewertung markiert, wenn es nie bewertet wurde, sein Prüfzeitraum abgelaufen ist, seine Version sich geändert hat oder der Katalog sich geändert hat.

Korrekturmaßnahmen werden mit oloproof governance ticket verfolgt. oloproof governance export-tickets --to jira --project GOV gibt für jedes offene, noch nicht exportierte Ticket das Jira-Issue aus, das es anlegen würde (REST v3 /rest/api/3/issue, Beschreibung im Atlassian Document Format); --to servicenow gibt einen Table-API-Datensatz für incident aus, oder problem mit --table problem. Mit --send --by "A. Officer" werden sie angelegt, sofern OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN oder OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD gesetzt sind (nie gespeichert oder ausgegeben). Der Schlüssel, den der Dienst zurückgibt, wird als Anmerkung zur Anforderung des Tickets ins Protokoll geschrieben: Befunde zeigen ihn, und ein Ticket wird nie zweimal gesendet. Gegen aufgezeichnete Antworten getestet, nicht gegen eine echte Jira- oder ServiceNow-Instanz.

Bevor ein Ticket gesendet wird, vermerkt das Protokoll den Export als ausstehend; ein erneuter Lauf nach einem Absturz sucht das Ticket im Dienst (in Jira über ein Label, in ServiceNow über correlation_id) und vermerkt den vorhandenen Schlüssel, statt ein zweites anzulegen. Diese Anmerkungen beginnen mit oloproof-export:, einem Präfix, das eine eigene Notiz einer prüfenden Person nicht verwenden darf. Was Ihre Organisation verlässt: die Notiz des Tickets, seine Anforderung und sein System, der Name der Person, die es eröffnet hat, wie im Protokoll geschrieben, sein Datum und sein Digest; kein Fallinhalt.

oloproof governance mlflow liest eine MLflow-Modellregistrierung: Setzen Sie MLFLOW_TRACKING_URI und, falls der Server es verlangt, MLFLOW_TRACKING_TOKEN (keines davon wird gespeichert oder ausgegeben). Jedes registrierte Modell gehört zu dem System, dessen system oder id der Modellname ist; ein Modell, das kein System nennt, wird als System ausgegeben, das in governance.yaml aufzunehmen ist, außerhalb des Geltungsbereichs, bis ein Mensch entscheidet. Nummer, Run-ID und Quelle jeder Version werden unter .oloproof/governance/mlflow/ aufbewahrt. Mit --tag werden die Befunde des letzten versiegelten Datensatzes auf die neueste Version jedes zugeordneten Modells als Tags oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue geschrieben. Gegen aufgezeichnete Antworten getestet und am 4. November 2026 gegen einen lokal betriebenen echten MLflow-3.18.0-Server, die Tags wurden zurückgelesen.

oloproof governance azureml, oloproof governance sagemaker tun dasselbe für einen Azure-Machine-Learning-Arbeitsbereich und eine Amazon SageMaker Model Registry. Azure ML liest den durch AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE benannten Arbeitsbereich über die Verwaltungs-API, mit einem Token in AZURE_ACCESS_TOKEN (az account get-access-token); --tag fügt die vier Tags den Tags der neuesten Version hinzu. SageMaker liest Modellpaketgruppen als Modelle und ihre Paketversionen als Versionen und signiert jede Anfrage mit den üblichen AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag setzt die vier Werte als Kundenmetadaten des neuesten Pakets. Keine Anmeldedaten werden gespeichert oder ausgegeben; Importe liegen unter .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Beide wurden gegen aufgezeichnete Antworten in den dokumentierten Formen jedes Dienstes getestet; kein echtes Azure- oder AWS-Konto wurde verwendet.

Aufbewahrung, Zugriff und Datenresidenz

In einem gehosteten Workspace legt der Owner in den Einstellungen fest, wie viele Tage Fallinhalte von Runs, Traces und das Lese-Log aufbewahrt werden; der Worker löscht Älteres und schreibt einen Beleg, den Owner und Admins herunterladen können. Entscheidungen, Freigaben, Siegel und Governance-Datensätze werden immer aufbewahrt. Jedes Öffnen eines Runs, der Befunde oder eines Siegels wird mit Konto und Zeit im Audit-Log festgehalten. Die Daten bleiben in der einen Region des Deployments (oloproof.com: Toronto, Backups in Toronto mit einer verschlüsselten Kopie in Chicago); Datenresidenz bedeutet ein Deployment pro Region.

Mehrere Kataloge, Prüfung im Workspace und die API

Ein Projekt kann mit catalogues: [dadm.yaml, ethics.yaml] mehrere Kataloge nennen. Jedes System wird an den Katalogen gemessen, die es aufführt (catalogues: am System), an denen der Gruppen, die es nennen (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), oder sonst an allen deklarierten Katalogen, und jeder Befund nennt seinen Katalog. Eine neue Katalogversion markiert eine Anforderung mit retired: "2027-01-01" und replaced_by: <id>, statt sie zu löschen: Nach diesem Tag ergibt sie keinen Befund mehr, und der Datensatz nennt sie.

Im gehosteten Workspace bestätigt, verwirft, ändert oder kommentiert ein Owner oder Admin einen Befund auf der Seite Governance. Jede Aktion wird unter dem Konto im eigenen, per Hash verketteten Prüfprotokoll des Workspace festgehalten, nach dem gepushten Protokoll gelesen, und ein Siegel exportiert beide Protokolle.

Ein Token mit dem Lese-Scope liest dieselben Objekte für sein eigenes Projekt: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, beschrieben mit OpenAPI 3.1 unter /api/openapi.json. Keines enthält Fallinhalte.

Was es Ihnen nicht sagen kann

Erklärungen sind das Wort von Menschen; Oloproof hält fest, wer was wann gesagt hat, und prüft es nicht. Ein Befund ist nur so stark wie die an ihn gebundenen Regeln. In einem gehosteten Workspace erscheinen dieselben Befunde auf der Governance-Seite des Projekts.