가이드

규정 준수 발견 사항

요구 사항 카탈로그는 지침을 확인 가능한 항목으로 바꿉니다. Oloproof는 캐나다 재무위원회의 자동화된 의사결정에 관한 지침용 카탈로그를 관할권 페이지가 나열하는 다른 카탈로그와 함께 제공합니다. oloproof init --example governance는 이를 프로젝트의 catalogues/ 디렉터리에 복사하고 이를 읽는 governance.yaml을 옆에 두므로, oloproof governance check가 그곳에서 바로 실행됩니다. oloproof governance check는 이를 여러분의 시스템에 대조해 읽고, 각 요구 사항이 충족, 부분 충족, 미충족, 해당 없음, 판단 불가 중 무엇인지 알려 줍니다. 각 발견 사항은 근거를 밝힙니다. 게이트의 판정, 이름이 밝혀진 사람의 진술, 또는 검토된 초안입니다.

발견 사항은 독자를 위한 요약입니다. 판정을 바꾸지 않으며 운영 승인이 되지도 않습니다. 법률 자문이 아닙니다.

거버넌스 파일

governance.yaml은 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

발견 사항이 도출되는 방식

측정 요구 사항은 연결된 게이트 규칙을, 시스템 현재 버전의 각 스위트의 최신 실행에서 검토 기간 안에 읽습니다. 연결된 모든 규칙이 PASS일 때만 충족, 하나라도 FAIL이면 미충족, 그 밖에는 판단 불가입니다. 부분 충족은 없습니다.
진술 요구 사항은 가장 최근의 유효한 진술을 읽습니다. 진술은 검토 기간이 지나거나 시스템 버전이 진술이 지목한 버전을 넘어서면 만료됩니다.
보조 요구 사항은 모델의 초안 oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>에서 시작하며, 검토자가 조치하기 전에는 발견 사항이 되지 않습니다: oloproof governance review --action validate|reject|modify|annotate.
복합 요구 사항은 부분들을 결합합니다. 판단 불가인 부분이 하나라도 있으면 충족이 될 수 없습니다.

규칙은 docs/engine/FINDING_RULES.md에 있으며 2026년 11월 2일 감사로 승인되었습니다.

그룹 간 공정성

DADM 6.3.3과 6.3.8은 결과가 모든 그룹에서 유지되는지 묻습니다. 이를 worst_group 지표에 대한 min 규칙에 연결하세요(구성 참조). 이 규칙은 이름이 지정된 모든 그룹을 한 번에 기준에 맞춥니다.

봉인, 서명, 재평가

oloproof governance check --seal은 번호가 매겨지고 이전 기록에 연결되며 검토 로그의 헤드를 담은 발견 기록을 씁니다. --sign office.key --signer "CIO office"를 추가하면 oloproof runner keygen으로 만든 키로 서명합니다. 누구나 oloproof governance verify RECORD --public-key KEY로 확인할 수 있습니다. 서명은 누가 봉인했는지를 말할 뿐 발견 사항이 참이라는 뜻은 아닙니다. 시스템은 한 번도 평가되지 않았거나, 검토 기간이 지났거나, 버전이 바뀌었거나, 카탈로그가 바뀌면 재평가 대상으로 표시됩니다.

시정 조치는 oloproof governance ticket으로 추적합니다. oloproof governance export-tickets --to jira --project GOV는 아직 내보내지 않은 열린 티켓마다 만들 Jira 이슈(REST v3 /rest/api/3/issue, 설명은 Atlassian Document Format)를 출력합니다. --to servicenow는 incident용, --table problem이면 problem용 Table API 레코드를 출력합니다. --send --by "A. Officer"를 붙이면 생성하며, OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN 또는 OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD를 설정해야 합니다(저장되거나 출력되지 않습니다). 각 서비스가 돌려준 키는 티켓의 요구 사항에 대한 주석으로 로그에 기록되므로 판정에 표시되고 티켓이 두 번 전송되지 않습니다. 실제 Jira나 ServiceNow 인스턴스가 아닌 기록된 응답으로 테스트했습니다.

티켓을 보내기 전에 로그는 내보내기를 대기 중으로 기록합니다. 충돌 후 다시 실행하면 서비스에서 그 티켓을 찾고(Jira에서는 레이블, ServiceNow에서는 correlation_id로) 두 번째를 만드는 대신 기존 키를 기록합니다. 이 주석은 oloproof-export:로 시작하며, 검토자의 메모는 이 접두사를 쓸 수 없습니다. 조직 밖으로 나가는 것: 티켓의 메모, 요구 사항과 시스템, 로그에 적힌 작성자의 이름, 날짜와 다이제스트이며, 케이스 내용은 없습니다.

oloproof governance mlflow는 MLflow 모델 레지스트리를 읽습니다. MLFLOW_TRACKING_URI와, 서버가 요구하면 MLFLOW_TRACKING_TOKEN를 설정하세요(둘 다 저장되거나 출력되지 않습니다). 등록된 각 모델은 system 또는 id가 모델 이름인 시스템에 대응합니다. 어떤 시스템도 지정하지 않은 모델은 governance.yaml에 추가할 시스템으로 출력되며, 사람이 정할 때까지 범위 밖입니다. 각 버전의 번호, 실행 id, 소스는 .oloproof/governance/mlflow/에 보관됩니다. --tag를 붙이면 마지막으로 봉인된 기록의 판정이 대응하는 각 모델의 최신 버전에 oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue 태그로 기록됩니다. 기록된 응답으로, 그리고 2026년 11월 4일에 로컬에서 실행한 실제 MLflow 3.18.0 서버로 테스트했으며, 태그를 다시 읽어 확인했습니다.

oloproof governance azureml, oloproof governance sagemaker는 Azure Machine Learning 작업 영역과 Amazon SageMaker Model Registry에 대해 같은 일을 합니다. Azure ML은 AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE로 지정한 작업 영역을 관리 API로 읽으며, 토큰은 AZURE_ACCESS_TOKEN (az account get-access-token)에서 가져옵니다. --tag는 최신 버전의 태그에 네 개의 태그를 추가합니다. SageMaker는 모델 패키지 그룹을 모델로, 그 패키지 버전을 버전으로 읽고, 각 요청을 표준 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION로 서명합니다. --tag는 네 값을 최신 패키지의 고객 메타데이터로 설정합니다. 자격 증명은 저장되거나 출력되지 않으며, 가져온 결과는 .oloproof/governance/azureml/, .oloproof/governance/sagemaker/에 보관됩니다. 둘 다 각 서비스의 문서화된 형식으로 기록된 응답으로 테스트했으며, 실제 Azure나 AWS 계정은 사용하지 않았습니다.

보존, 접근, 데이터 거주지

호스팅 워크스페이스에서 Owner는 설정에서 실행의 케이스 내용, 트레이스, 열람 로그를 며칠 동안 보존할지 정합니다. 워커는 그보다 오래된 것을 삭제하고 Owner와 Admin이 내려받을 수 있는 영수증을 기록합니다. 결정, 승인, 봉인, 거버넌스 기록은 항상 보존됩니다. 실행, 결과, 봉인을 열 때마다 계정과 시각이 감사 로그에 기록됩니다. 데이터는 배포의 단일 리전(oloproof.com: 토론토, 백업은 토론토, 암호화된 사본은 시카고)에 머뭅니다. 데이터 거주지 요건은 리전마다 배포하는 것으로 충족합니다.

여러 카탈로그, 워크스페이스에서의 검토, 그리고 API

프로젝트는 catalogues: [dadm.yaml, ethics.yaml]로 여러 카탈로그를 지정할 수 있습니다. 각 시스템은 자신이 나열한 카탈로그(시스템의 catalogues:), 자신을 포함하는 그룹의 카탈로그(groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), 둘 다 없으면 선언된 모든 카탈로그에 비추어 판단되며, 각 결과는 해당 카탈로그를 밝힙니다. 카탈로그의 새 버전은 요구사항을 삭제하는 대신 retired: "2027-01-01"와 replaced_by: <id>로 표시합니다. 그날 이후에는 결과를 만들지 않으며, 기록에 그 요구사항이 표시됩니다.

호스팅된 워크스페이스에서는 Owner 또는 Admin이 Governance 페이지에서 결과를 승인, 거부, 수정하거나 주석을 답니다. 각 작업은 해당 계정으로 워크스페이스 자체의 해시 체인 검토 로그에 기록되고, 푸시된 로그 다음에 읽히며, 봉인은 두 로그를 모두 내보냅니다.

읽기 범위를 가진 토큰은 자기 프로젝트의 같은 객체를 읽습니다: GET /api/governance/findings, /seal, /statements, /reviews, /approvals. /api/openapi.json에 OpenAPI 3.1로 설명되어 있습니다. 어느 것도 케이스 내용을 담지 않습니다.

알려 줄 수 없는 것

진술은 사람의 말입니다. Oloproof는 누가 언제 무엇을 말했는지 기록할 뿐 확인하지 않습니다. 발견 사항은 연결된 규칙만큼만 강합니다. 호스팅 워크스페이스에서는 같은 발견 사항이 프로젝트의 거버넌스 페이지에 표시됩니다.