Ustalenia zgodności

Katalog wymagań zamienia dyrektywę w sprawdzalne pozycje. Oloproof dostarcza jeden dla dyrektywy kanadyjskiego Treasury Board w sprawie zautomatyzowanego podejmowania decyzji wraz z pozostałymi, które wymienia strona o jurysdykcjach. oloproof init --example governance kopiuje je do katalogu catalogues/ projektu, obok pliku governance.yaml, który je odczytuje, więc oloproof governance check działa tam od razu. oloproof governance check odczytuje go względem Twoich systemów i dla każdego wymagania mówi, czy jest spełnione, częściowo spełnione, niespełnione, nie dotyczy lub nie da się ustalić. Każde ustalenie wskazuje, na czym się opiera: na decyzjach Twojej bramki, oświadczeniu wskazanej osoby lub przejrzanym projekcie.

Ustalenie to podsumowanie dla czytelnika. Nigdy nie zmienia decyzji i nigdy nie jest zezwoleniem na eksploatację. Nie jest poradą prawną.

Plik zarządzania

governance.yaml leży obok 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

Jak powstaje ustalenie

• Wymagania mierzone odczytują powiązane z nimi reguły bramki, przy najnowszym przebiegu każdego zestawu bieżącej wersji systemu, w jego okresie przeglądu. Spełnione tylko wtedy, gdy każda powiązana reguła ma PASS; niespełnione, gdy któraś ma FAIL; w przeciwnym razie nie da się ustalić. Nigdy częściowo spełnione.
• Wymagania poświadczane odczytują najnowsze aktualne oświadczenie. Oświadczenie traci aktualność po okresie przeglądu albo gdy wersja systemu wyjdzie poza tę, którą wskazuje.
• Wymagania wspomagane zaczynają się od projektu modelu, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, który nigdy nie jest ustaleniem, dopóki recenzent na nim nie zadziała: oloproof governance review --action validate|reject|modify|annotate.
• Wymagania złożone łączą swoje części: jedna nieustalona część blokuje spełnienie.

Reguły są w docs/engine/FINDING_RULES.md, dopuszczone przez ich audyt 2 listopada 2026.

Sprawiedliwość między grupami

Punkty 6.3.3 i 6.3.8 DADM pytają, czy wyniki utrzymują się dla każdej grupy. Powiąż je z regułą min na metryce worst_group (Dokumentacja konfiguracji), która jednocześnie trzyma każdą wskazaną grupę przy progu.

Pieczętowanie, podpisywanie i ponowna ocena

oloproof governance check --seal zapisuje rejestr ustaleń, numerowany i powiązany łańcuchem z poprzednim, z głową dziennika przeglądu w środku. Dodaj --sign office.key --signer "CIO office", aby podpisać go kluczem utworzonym przez oloproof runner keygen; każdy może go sprawdzić za pomocą oloproof governance verify RECORD --public-key KEY. Podpis mówi, kto go zapieczętował, a nie że ustalenia są prawdziwe. System zostaje oznaczony do ponownej oceny, gdy nigdy nie był oceniany, jego okres przeglądu minął, zmieniła się jego wersja lub zmienił się katalog.

Działania korygujące śledzi się za pomocą oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV wypisuje dla każdego otwartego, jeszcze niewyeksportowanego zgłoszenia zgłoszenie Jira, które by utworzył (REST v3 /rest/api/3/issue, opis w Atlassian Document Format); --to servicenow wypisuje rekord Table API dla incident albo problem z --table problem. Dodaj --send --by "A. Officer", aby je utworzyć, przy ustawionych OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN lub OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD (nigdy nie zapisywanych ani nie wypisywanych). Klucz zwrócony przez usługę jest zapisywany w dzienniku jako adnotacja do wymagania zgłoszenia: ustalenia go pokazują, a zgłoszenie nigdy nie jest wysyłane dwa razy. Testowane na nagranych odpowiedziach, nie na prawdziwej instancji Jira ani ServiceNow.

Przed wysłaniem zgłoszenia dziennik zapisuje eksport jako oczekujący; ponowne uruchomienie po awarii wyszukuje zgłoszenie w usłudze (po etykiecie w Jira, po correlation_id w ServiceNow) i zapisuje istniejący klucz zamiast tworzyć drugie. Te adnotacje zaczynają się od oloproof-export:, prefiksu, którego własna notatka recenzenta nie może używać. Co opuszcza Twoją organizację: notatka zgłoszenia, jego wymaganie i system, nazwisko osoby, która je otworzyła, jak zapisano w dzienniku, data i skrót; żadnej treści przypadków.

oloproof governance mlflow czyta rejestr modeli MLflow: ustaw MLFLOW_TRACKING_URI oraz, jeśli serwer tego wymaga, MLFLOW_TRACKING_TOKEN (żadna nie jest zapisywana ani wypisywana). Każdy zarejestrowany model odpowiada systemowi, którego system lub id jest nazwą modelu; model, którego nie nazywa żaden system, jest wypisywany jako system do dodania do governance.yaml, poza zakresem, dopóki człowiek nie zdecyduje. Numer, id przebiegu i źródło każdej wersji są przechowywane w .oloproof/governance/mlflow/. Z --tag ustalenia ostatniego zapieczętowanego rekordu są zapisywane w najnowszej wersji każdego dopasowanego modelu jako tagi oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Testowane na nagranych odpowiedziach oraz, 4 listopada 2026, na prawdziwym serwerze MLflow 3.18.0 uruchomionym lokalnie, z odczytem tagów.

oloproof governance azureml, oloproof governance sagemaker robią to samo dla obszaru roboczego Azure Machine Learning i Amazon SageMaker Model Registry. Azure ML czyta obszar roboczy wskazany przez AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE przez API zarządzania, z tokenem w AZURE_ACCESS_TOKEN (az account get-access-token); --tag dodaje cztery tagi do tagów najnowszej wersji. SageMaker czyta grupy pakietów modeli jako modele, a ich wersje pakietów jako wersje, podpisując każde żądanie standardowymi AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag ustawia cztery wartości jako metadane klienta najnowszego pakietu. Żadne poświadczenia nie są zapisywane ani wypisywane; importy są przechowywane w .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Oba przetestowano na nagranych odpowiedziach w udokumentowanych kształtach każdej usługi; nie użyto prawdziwego konta Azure ani AWS.

Przechowywanie, dostęp i lokalizacja danych

W hostowanym obszarze roboczym Owner ustala w Ustawieniach, przez ile dni przechowywane są treści przypadków uruchomień, ślady i dziennik odczytów; worker usuwa starsze dane i zapisuje potwierdzenie, które Ownerzy i Admini mogą pobrać. Decyzje, zatwierdzenia, pieczęcie i zapisy ładu są zawsze przechowywane. Każde otwarcie uruchomienia, ustaleń lub pieczęci jest zapisywane z kontem i czasem w dzienniku audytu. Dane pozostają w jednym regionie wdrożenia (oloproof.com: Toronto, kopie zapasowe w Toronto z zaszyfrowaną kopią w Chicago); lokalizacja danych oznacza wdrożenie na region.

Kilka katalogów, przegląd w przestrzeni roboczej i API

Projekt może wskazać kilka katalogów przez catalogues: [dadm.yaml, ethics.yaml]. Każdy system jest oceniany według katalogów, które wymienia (catalogues: przy systemie), katalogów grup, które go wymieniają (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), a w przeciwnym razie wszystkich zadeklarowanych katalogów, a każde ustalenie wskazuje swój katalog. Nowa wersja katalogu oznacza wymaganie retired: "2027-01-01" z replaced_by: <id> zamiast je usuwać: po tym dniu nie daje ono ustaleń, a rekord je wymienia.

W hostowanej przestrzeni roboczej Owner lub Admin zatwierdza, odrzuca, zmienia lub opatruje uwagą ustalenie na stronie Governance. Każda czynność jest zapisywana pod jego kontem we własnym, łańcuchowanym hashami dzienniku przeglądu przestrzeni roboczej, czytanym po dzienniku wysłanym, a pieczęć eksportuje oba dzienniki.

Token z zakresem odczytu odczytuje te same obiekty dla własnego projektu: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, opisane w OpenAPI 3.1 pod /api/openapi.json. Żaden nie zawiera treści przypadków.

Czego to nie powie

Oświadczenia to słowo ludzi; Oloproof zapisuje, kto co powiedział i kiedy, i tego nie sprawdza. Ustalenie jest tak mocne jak powiązane z nim reguły. W hostowanej przestrzeni roboczej te same ustalenia widać na stronie Ład projektu.