Pular para o conteúdo
Docs
Registro de alteraçõesPreçosAbrir o console

Guias

Constatações de conformidade

Um catálogo de requisitos transforma uma diretiva em entradas verificáveis. O Oloproof traz um para a Diretiva sobre Tomada de Decisão Automatizada do Conselho do Tesouro do Canadá, com os outros que a página de jurisdições lista. oloproof init --example governance os copia para o diretório catalogues/ de um projeto, ao lado de um governance.yaml que os lê, então oloproof governance check roda ali de imediato. oloproof governance check o lê em relação aos seus sistemas e diz, para cada requisito, se está atendido, parcialmente atendido, não atendido, não aplicável ou impossível de determinar. Cada constatação nomeia aquilo em que se apoia: as decisões do seu gate, a declaração de uma pessoa identificada ou um rascunho revisado.

Uma constatação é um resumo para um leitor. Ela nunca muda uma decisão e nunca é uma autorização para operar. Não é aconselhamento jurídico.

O arquivo de governança

governance.yaml fica ao lado 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

Como se chega a uma constatação

  • Requisitos medidos leem as regras do gate vinculadas a eles, na execução mais recente de cada suíte da versão atual do sistema, dentro do seu período de revisão. Atendido somente quando cada regra vinculada é PASS; não atendido quando alguma é FAIL; caso contrário, impossível de determinar. Nunca parcialmente atendido.
  • Requisitos atestados leem a declaração vigente mais recente. Uma declaração fica desatualizada após o período de revisão, ou quando a versão do sistema passa da que ela nomeia.
  • Requisitos assistidos partem do rascunho de um modelo, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, que nunca é uma constatação até que um revisor aja sobre ele: oloproof governance review --action validate|reject|modify|annotate.
  • Requisitos compostos combinam suas partes: uma parte indeterminada impede o atendimento.

As regras estão em docs/engine/FINDING_RULES.md, admitidas por sua auditoria em 2 de novembro de 2026.

Equidade entre grupos

Os itens 6.3.3 e 6.3.8 da DADM perguntam se os resultados se mantêm para cada grupo. Vincule-os a uma regra min sobre uma métrica worst_group (Referência de configuração), que submete de uma vez cada grupo nomeado ao limite.

Selar, assinar e reavaliar

oloproof governance check --seal grava um registro de constatações, numerado e encadeado ao anterior, com a cabeça do log de revisão dentro dele. Adicione --sign office.key --signer "CIO office" para assiná-lo com uma chave criada por oloproof runner keygen; qualquer pessoa pode verificá-lo com oloproof governance verify RECORD --public-key KEY. Uma assinatura diz quem o selou, não que as constatações são verdadeiras. Um sistema é sinalizado para reavaliação quando nunca foi avaliado, seu período de revisão expirou, sua versão mudou ou o catálogo mudou.

Ações corretivas são acompanhadas com oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV imprime, para cada ticket aberto ainda não exportado, a issue do Jira que criaria (REST v3 /rest/api/3/issue, descrição em Atlassian Document Format); --to servicenow imprime um registro da Table API para incident, ou problem com --table problem. Adicione --send --by "A. Officer" para criá-los, com OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN ou OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD definidas (nunca armazenadas nem impressas). A chave que cada serviço devolve é escrita no log como anotação no requisito do ticket: os achados a mostram e um ticket nunca é enviado duas vezes. Testado com respostas gravadas, não com uma instância real do Jira ou do ServiceNow.

Antes de enviar um ticket, o log registra a exportação como pendente; uma nova execução após uma falha procura o ticket no serviço (por um rótulo no Jira, por correlation_id no ServiceNow) e registra a chave existente em vez de criar um segundo. Essas anotações começam com oloproof-export:, um prefixo que a nota de um revisor não pode usar. O que sai da sua organização: a nota do ticket, seu requisito e sistema, o nome de quem o abriu como escrito no log, sua data e seu digest; nenhum conteúdo de casos.

oloproof governance mlflow lê um registro de modelos do MLflow: defina MLFLOW_TRACKING_URI e, se o servidor exigir, MLFLOW_TRACKING_TOKEN (nenhum é armazenado ou impresso). Cada modelo registrado corresponde ao sistema cujo system ou id é o nome do modelo; um modelo que nenhum sistema nomeia é impresso como sistema a adicionar ao governance.yaml, fora de escopo até que uma pessoa decida. O número, o id de execução e a origem de cada versão ficam em .oloproof/governance/mlflow/. Com --tag, os achados do último registro selado são escritos na versão mais recente de cada modelo associado como tags oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Testado com respostas gravadas e, em 4 de novembro de 2026, com um servidor MLflow 3.18.0 real executado localmente, com as tags lidas de volta.

oloproof governance azureml, oloproof governance sagemaker fazem o mesmo para um workspace do Azure Machine Learning e um Amazon SageMaker Model Registry. O Azure ML lê o workspace nomeado por AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE pela API de gerenciamento, com um token em AZURE_ACCESS_TOKEN (az account get-access-token); --tag adiciona as quatro tags às da versão mais recente. O SageMaker lê grupos de pacotes de modelos como modelos e suas versões de pacote como versões, assinando cada requisição com as variáveis padrão AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag define os quatro valores como metadados de cliente do pacote mais recente. Nenhuma credencial é armazenada ou exibida; as importações ficam em .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Ambos foram testados com respostas gravadas nos formatos documentados de cada serviço; nenhuma conta real do Azure ou da AWS foi usada.

Retenção, acesso e residência

Em um workspace hospedado, o Owner define nas Configurações por quantos dias o conteúdo dos casos das execuções, os traces e o registro de leituras são mantidos; o worker apaga o que for mais antigo e grava um recibo que Owners e Admins podem baixar. Decisões, aprovações, selos e registros de governança são sempre mantidos. Cada abertura de uma execução, das constatações ou de um selo é registrada com conta e horário no log de auditoria. Os dados ficam na única região da implantação (oloproof.com: Toronto, backups em Toronto com uma cópia criptografada em Chicago); residência significa uma implantação por região.

Vários catálogos, revisão no workspace e a API

Um projeto pode nomear vários catálogos com catalogues: [dadm.yaml, ethics.yaml]. Cada sistema é avaliado pelos catálogos que lista (catalogues: no sistema), pelos dos grupos que o nomeiam (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}) ou, caso contrário, por todos os catálogos declarados, e cada constatação nomeia seu catálogo. Uma nova versão de um catálogo marca um requisito retired: "2027-01-01" com replaced_by: <id> em vez de apagá-lo: ele não gera constatações depois desse dia, e o registro o nomeia.

No workspace hospedado, um Owner ou Admin valida, rejeita, modifica ou anota uma constatação na página Governança. Cada ação é registrada na conta dele no log de revisão do próprio workspace, encadeado por hash, lido depois do log enviado, e um selo exporta os dois logs.

Um token com o escopo de leitura lê os mesmos objetos do próprio projeto: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, descritos em OpenAPI 3.1 em /api/openapi.json. Nenhum traz conteúdo de casos.

O que isso não pode dizer

Declarações são a palavra de pessoas; o Oloproof registra quem disse o quê e quando, e não verifica. Uma constatação é tão forte quanto as regras vinculadas a ela. Em um espaço de trabalho hospedado, as mesmas constatações aparecem na página de Governança do projeto.