Saltar al contenido
Docs
Registro de cambiosPreciosAbrir la consola

Guías

Hallazgos de cumplimiento

Un catálogo de requisitos convierte una directiva en entradas verificables. Oloproof incluye uno para la Directiva sobre la toma de decisiones automatizada del Consejo del Tesoro de Canadá, con los demás que enumera la página de jurisdicciones. oloproof init --example governance los copia en el directorio catalogues/ de un proyecto, junto a un governance.yaml que los lee, de modo que oloproof governance check se ejecuta allí de inmediato. oloproof governance check lo lee frente a sus sistemas y dice, para cada requisito, si se cumple, se cumple parcialmente, no se cumple, no aplica o no se puede determinar. Cada hallazgo nombra en qué se basa: las decisiones de su gate, la declaración de una persona identificada o un borrador revisado.

Un hallazgo es un resumen para un lector. Nunca cambia una decisión y nunca es una autorización para operar. No es asesoramiento jurídico.

El archivo de gobernanza

governance.yaml va junto a 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

Cómo se llega a un hallazgo

  • Los requisitos medidos leen las reglas del gate vinculadas a ellos, en la ejecución más reciente de cada suite de la versión actual del sistema, dentro de su periodo de revisión. Se cumple solo cuando cada regla vinculada es PASS; no se cumple cuando alguna es FAIL; en otro caso no se puede determinar. Nunca se cumple parcialmente.
  • Los requisitos atestiguados leen la última declaración vigente. Una declaración caduca tras el periodo de revisión, o cuando la versión del sistema deja atrás la que nombra.
  • Los requisitos asistidos parten del borrador de un modelo, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, que nunca es un hallazgo hasta que un revisor actúa sobre él: oloproof governance review --action validate|reject|modify|annotate.
  • Los requisitos compuestos combinan sus partes: una parte indeterminada impide que se cumplan.

Las reglas están en docs/engine/FINDING_RULES.md, admitidas por su auditoría el 2 de noviembre de 2026.

Equidad entre grupos

Los apartados 6.3.3 y 6.3.8 de la DADM preguntan si los resultados se sostienen para cada grupo. Vincúlelos a una regla min sobre una métrica worst_group (Referencia de configuración), que somete a la vez a cada grupo nombrado al umbral.

Sellar, firmar y reevaluar

oloproof governance check --seal escribe un registro de hallazgos, numerado y encadenado al anterior, con la cabeza del registro de revisión dentro. Añada --sign office.key --signer "CIO office" para firmarlo con una clave creada por oloproof runner keygen; cualquiera puede comprobarlo con oloproof governance verify RECORD --public-key KEY. Una firma dice quién lo selló, no que los hallazgos sean ciertos. Un sistema se marca para reevaluación cuando nunca se evaluó, venció su periodo de revisión, cambió su versión o cambió el catálogo.

Las acciones correctivas se siguen con oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV muestra, para cada ticket abierto aún no exportado, la incidencia de Jira que crearía (REST v3 /rest/api/3/issue, descripción en Atlassian Document Format); --to servicenow muestra un registro de la Table API para incident, o problem con --table problem. Añada --send --by "A. Officer" para crearlos, con OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN o OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD definidas (nunca guardadas ni mostradas). La clave que devuelve cada servicio se escribe en el registro como anotación sobre el requisito del ticket: los hallazgos la muestran y un ticket nunca se envía dos veces. Probado con respuestas grabadas, no con una instancia real de Jira o ServiceNow.

Antes de enviar un ticket, el registro anota la exportación como pendiente; una nueva ejecución tras un fallo busca el ticket en el servicio (por una etiqueta en Jira, por correlation_id en ServiceNow) y anota la clave existente en lugar de crear otro. Estas anotaciones empiezan por oloproof-export:, un prefijo que la nota propia de un revisor no puede usar. Lo que sale de su organización: la nota del ticket, su requisito y su sistema, el nombre de quien lo abrió tal como figura en el registro, su fecha y su digest; ningún contenido de casos.

oloproof governance mlflow lee un registro de modelos de MLflow: defina MLFLOW_TRACKING_URI y, si el servidor lo exige, MLFLOW_TRACKING_TOKEN (ninguno se guarda ni se muestra). Cada modelo registrado corresponde al sistema cuyo system o id es el nombre del modelo; un modelo que ningún sistema nombra se muestra como sistema para añadir a governance.yaml, fuera de alcance hasta que una persona decida. El número, el id de ejecución y la fuente de cada versión se guardan en .oloproof/governance/mlflow/. Con --tag, los hallazgos del último registro sellado se escriben en la última versión de cada modelo asociado como etiquetas oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Probado con respuestas grabadas y, el 4 de noviembre de 2026, con un servidor MLflow 3.18.0 real ejecutado localmente, con las etiquetas leídas de vuelta.

oloproof governance azureml, oloproof governance sagemaker hacen lo mismo para un área de trabajo de Azure Machine Learning y un Amazon SageMaker Model Registry. Azure ML lee el área de trabajo nombrada por AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE mediante la API de administración, con un token en AZURE_ACCESS_TOKEN (az account get-access-token); --tag añade las cuatro etiquetas a las de la versión más reciente. SageMaker lee los grupos de paquetes de modelos como modelos y sus versiones de paquete como versiones, y firma cada solicitud con las variables estándar AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag fija los cuatro valores como metadatos de cliente del paquete más reciente. Ninguna credencial se guarda ni se imprime; las importaciones se guardan en .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Ambos se probaron con respuestas grabadas en las formas documentadas de cada servicio; no se usó ninguna cuenta real de Azure ni de AWS.

Retención, acceso y residencia

En un espacio de trabajo alojado, el Owner fija en Ajustes cuántos días se conservan el contenido de los casos de las ejecuciones, las trazas y el registro de lecturas; el worker borra lo más antiguo y escribe un recibo que Owners y Admins pueden descargar. Las decisiones, aprobaciones, sellos y registros de gobernanza se conservan siempre. Cada apertura de una ejecución, de los hallazgos o de un sello queda registrada con la cuenta y la hora en el registro de auditoría. Los datos permanecen en la única región del despliegue (oloproof.com: Toronto, copias de seguridad en Toronto con una copia cifrada en Chicago); la residencia implica un despliegue por región.

Varios catálogos, revisión en el espacio de trabajo y la API

Un proyecto puede nombrar varios catálogos con catalogues: [dadm.yaml, ethics.yaml]. Cada sistema se evalúa según los catálogos que enumera (catalogues: en el sistema), los de los grupos que lo nombran (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}) o, si no, todos los catálogos declarados, y cada hallazgo nombra su catálogo. Una nueva versión de un catálogo marca un requisito retired: "2027-01-01" con replaced_by: <id> en lugar de borrarlo: no produce hallazgos después de ese día, y el registro lo nombra.

En el espacio de trabajo alojado, un Owner o Admin valida, rechaza, modifica o anota un hallazgo en la página Gobernanza. Cada acción queda registrada con su cuenta en el registro de revisión encadenado por hash propio del espacio de trabajo, que se lee después del registro enviado, y un sello exporta ambos registros.

Un token con el alcance de lectura lee los mismos objetos de su propio proyecto: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, descritos con OpenAPI 3.1 en /api/openapi.json. Ninguno contiene contenido de casos.

Lo que no puede decirle

Las declaraciones son la palabra de personas; Oloproof registra quién dijo qué y cuándo, y no lo comprueba. Un hallazgo es tan sólido como las reglas vinculadas a él. En un espacio de trabajo alojado, los mismos hallazgos aparecen en la página de Gobernanza del proyecto.