Skip to content
Docs
ChangelogPricingOpen console

Guides

Compliance findings

A requirements catalogue turns a directive into checkable entries. Oloproof ships one for the Treasury Board's Directive on Automated Decision-Making, with the others the jurisdictions page lists. oloproof init --example governance copies them into a project's catalogues/ directory beside a governance.yaml that reads them, so oloproof governance check runs there at once. oloproof governance check reads it against your systems and says, for each requirement, whether it is met, partially met, not met, not applicable or unable to determine. Each finding names what it rests on: your gate's decisions, a named person's statement, or a reviewed draft.

A finding is a summary for a reader. It never changes a decision, and it is never an authorization to operate. It is not legal advice.

The governance file

governance.yaml sits beside 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

How a finding is reached

  • Measured requirements read the gate rules bound to them, at the newest run of each suite of the system's current version, within its review period. Met only when every bound rule is PASS; not met when any is FAIL; otherwise unable to determine. Never partially met.
  • Attested requirements read the latest current statement. A statement goes stale after the review period, or when the system's version moves on from the one it names.
  • Assisted requirements start from a model's draft, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, which is never a finding until a reviewer acts on it: oloproof governance review --action validate|reject|modify|annotate.
  • Composite requirements combine their parts: one undetermined part blocks a met.

The rules are in docs/engine/FINDING_RULES.md, admitted by their audit on 2 November 2026.

Fairness across groups

DADM 6.3.3 and 6.3.8 ask whether results hold for every group. Bind them to a min rule on a worst_group metric (Configuration reference), which holds every named group to the bar at once.

Seal, sign and reassess

oloproof governance check --seal writes a findings record, numbered and chained to the one before, with the review log's head inside it. Add --sign office.key --signer "CIO office" to sign it with a key made by oloproof runner keygen; anyone can check it with oloproof governance verify RECORD --public-key KEY. A signature says who sealed it, not that the findings are true. A system is flagged for reassessment when it was never assessed, its review period lapsed, its version changed, or the catalogue changed.

Corrective actions are tracked with oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV prints, for each open ticket not yet exported, the Jira issue it would create (REST v3 /rest/api/3/issue, the description in Atlassian Document Format); --to servicenow prints a Table API record for incident, or problem with --table problem. Add --send --by "A. Officer" to create them, with OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL and OLOPROOF_JIRA_TOKEN, or OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER and OLOPROOF_SERVICENOW_PASSWORD, set (never stored or printed). The key each service answers is written into the log as an annotation on the ticket's requirement, so findings show it and a ticket is never sent twice. Both were tested against recorded responses, not a live Jira or ServiceNow instance.

Before a ticket is sent, the log records the export as pending; a rerun after a crash looks the ticket up in the service (by a label in Jira, by correlation_id in ServiceNow) and records the existing key instead of creating a second. These annotations start with oloproof-export:, a prefix a reviewer's own note may not use. What leaves your organisation: the ticket's note, its requirement and system, the name of whoever opened it as written in the log, its date and its digest; no case content.

oloproof governance mlflow reads an MLflow model registry: set MLFLOW_TRACKING_URI and, where the server needs one, MLFLOW_TRACKING_TOKEN (neither is stored or printed). Each registered model matches the system whose system or id is the model's name; a model no system names is printed as a system to add to governance.yaml, out of scope until a person decides its scope. Every version's number, run id and source is kept under .oloproof/governance/mlflow/. With --tag, the last sealed record's findings are written on each matched model's latest version as oloproof.findings, oloproof.findings_digest, oloproof.assessed_on and oloproof.catalogue tags. It was tested against recorded responses and, on 4 November 2026, against a live MLflow 3.18.0 server run locally, tags read back.

oloproof governance azureml and oloproof governance sagemaker do the same for an Azure Machine Learning workspace and an Amazon SageMaker Model Registry. Azure ML reads the workspace named by AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP and AZURE_ML_WORKSPACE through the management API, with a token in AZURE_ACCESS_TOKEN (from az account get-access-token); --tag adds the four tags to the latest version's tags. SageMaker reads model package groups as models and their package versions as versions, signing each request with the standard AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN and AWS_REGION; --tag sets the four values as the latest package's customer metadata. No credential is stored or printed, and imports are kept under .oloproof/governance/azureml/ and .oloproof/governance/sagemaker/. Both were tested against recorded responses in each service's documented shapes; no live Azure or AWS account was used.

Retention, access and residency

In a hosted workspace the Owner sets, in Settings, how many days run case content, traces and the read log are kept; the worker deletes what is older and writes a receipt Owners and Admins can download. Decisions, sign-offs, seals and governance records are always kept. Each opening of a run, the findings or a seal is logged by account and time on the audit log. Data stays in the deployment's one region (oloproof.com: Toronto, backups in Toronto with an encrypted copy in Chicago); residency means a deployment per region.

Several catalogues, review in the workspace, and the API

A project may name several catalogues with catalogues: [dadm.yaml, ethics.yaml]. Each system is read against the catalogues it lists (catalogues: on the system), those of the groups that name it (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), or else every catalogue declared, and each finding names its catalogue. A new version of a catalogue marks a requirement retired: "2027-01-01" with replaced_by: <id> instead of deleting it: it yields no finding after that day, and the record names it.

In the hosted workspace an Owner or Admin validates, rejects, modifies or annotates a finding on the Governance page. Each action is logged under their account in the workspace's own hash-chained review log, read after the pushed log, and a seal exports both logs.

A token with the read scope reads the same objects for its own project: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, described by OpenAPI 3.1 at /api/openapi.json. None carries case content.

What it cannot tell you

Statements are people's word; Oloproof records who said what, when, and does not check it. A finding is only as strong as the rules bound to it. In a hosted workspace the same findings show on the project's Governance page.