Chuyển đến nội dung
Tài liệu
Nhật ký thay đổiGiáMở bảng điều khiển

Hướng dẫn

Phát hiện tuân thủ

Một danh mục yêu cầu biến một chỉ thị thành các mục có thể kiểm tra. Oloproof kèm theo một danh mục cho Chỉ thị về ra quyết định tự động của Hội đồng Ngân khố Canada, cùng các danh mục khác mà trang khu vực pháp lý liệt kê. oloproof init --example governance sao chép chúng vào thư mục catalogues/ của một dự án, bên cạnh một governance.yaml đọc chúng, nên oloproof governance check chạy được ở đó ngay. oloproof governance check đọc nó đối chiếu với các hệ thống của bạn và cho biết, với mỗi yêu cầu, là đáp ứng, đáp ứng một phần, không đáp ứng, không áp dụng hay không thể xác định. Mỗi phát hiện nêu rõ nó dựa trên điều gì: các quyết định của gate của bạn, tuyên bố của một người được nêu tên, hoặc một bản nháp đã được xem xét.

Một phát hiện là bản tóm tắt cho người đọc. Nó không bao giờ thay đổi một quyết định và không bao giờ là giấy phép vận hành. Nó không phải là tư vấn pháp lý.

Tệp quản trị

governance.yaml nằm cạnh 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

Một phát hiện được đưa ra như thế nào

  • Yêu cầu đo lường đọc các quy tắc gate được gắn với chúng, tại lần chạy mới nhất của mỗi bộ thuộc phiên bản hiện tại của hệ thống, trong kỳ xem xét của nó. Chỉ đáp ứng khi mọi quy tắc được gắn đều PASS; không đáp ứng khi có quy tắc FAIL; nếu không thì không thể xác định. Không bao giờ đáp ứng một phần.
  • Yêu cầu được xác nhận đọc tuyên bố hiện hành mới nhất. Một tuyên bố trở nên lỗi thời sau kỳ xem xét, hoặc khi phiên bản của hệ thống vượt qua phiên bản mà nó nêu.
  • Yêu cầu có hỗ trợ bắt đầu từ bản nháp của một mô hình, oloproof governance draft --system triage --target DADM-6.2.1 --document notice.txt --model <model>, không bao giờ là một phát hiện cho đến khi người xem xét xử lý nó: oloproof governance review --action validate|reject|modify|annotate.
  • Yêu cầu tổng hợp kết hợp các phần của chúng: một phần chưa xác định sẽ ngăn trạng thái đáp ứng.

Các quy tắc nằm trong docs/engine/FINDING_RULES.md, được chấp nhận qua kiểm toán ngày 2 tháng 11 năm 2026.

Công bằng giữa các nhóm

DADM 6.3.3 và 6.3.8 hỏi liệu kết quả có đứng vững cho mọi nhóm không. Hãy gắn chúng với một quy tắc min trên chỉ số worst_group (Tham chiếu cấu hình), quy tắc này giữ mọi nhóm được nêu tên ở ngưỡng cùng một lúc.

Niêm phong, ký và đánh giá lại

oloproof governance check --seal ghi một bản ghi phát hiện, được đánh số và nối chuỗi với bản trước, có phần đầu của nhật ký xem xét bên trong. Thêm --sign office.key --signer "CIO office" để ký nó bằng một khóa tạo bởi oloproof runner keygen; bất kỳ ai cũng có thể kiểm tra bằng oloproof governance verify RECORD --public-key KEY. Chữ ký cho biết ai đã niêm phong nó, không phải các phát hiện là đúng. Một hệ thống được đánh dấu cần đánh giá lại khi chưa từng được đánh giá, kỳ xem xét đã hết, phiên bản đã thay đổi hoặc danh mục đã thay đổi.

Các hành động khắc phục được theo dõi bằng oloproof governance ticket. oloproof governance export-tickets --to jira --project GOV in ra, cho mỗi phiếu đang mở chưa được xuất, issue Jira mà nó sẽ tạo (REST v3 /rest/api/3/issue, mô tả theo Atlassian Document Format); --to servicenow in ra một bản ghi Table API cho incident, hoặc problem với --table problem. Thêm --send --by "A. Officer" để tạo chúng, khi đã đặt OLOPROOF_JIRA_URL, OLOPROOF_JIRA_EMAIL, OLOPROOF_JIRA_TOKEN hoặc OLOPROOF_SERVICENOW_URL, OLOPROOF_SERVICENOW_USER, OLOPROOF_SERVICENOW_PASSWORD (không bao giờ được lưu hay in ra). Khóa mà mỗi dịch vụ trả về được ghi vào nhật ký dưới dạng chú thích trên yêu cầu của phiếu: các phát hiện hiển thị nó và một phiếu không bao giờ được gửi hai lần. Đã kiểm thử với các phản hồi được ghi lại, không phải một phiên bản Jira hay ServiceNow thật.

Trước khi gửi một ticket, nhật ký ghi việc xuất là đang chờ; lần chạy lại sau sự cố sẽ tìm ticket đó trong dịch vụ (bằng nhãn trong Jira, bằng correlation_id trong ServiceNow) và ghi lại khóa đã có thay vì tạo ticket thứ hai. Các chú thích này bắt đầu bằng oloproof-export:, tiền tố mà ghi chú riêng của người xem xét không được dùng. Những gì rời khỏi tổ chức của bạn: ghi chú của ticket, yêu cầu và hệ thống của nó, tên người mở như được ghi trong nhật ký, ngày và digest; không có nội dung ca.

oloproof governance mlflow đọc sổ đăng ký mô hình MLflow: đặt MLFLOW_TRACKING_URI và, nếu máy chủ yêu cầu, MLFLOW_TRACKING_TOKEN (không biến nào được lưu hay in ra). Mỗi mô hình đã đăng ký khớp với hệ thống có system hoặc id là tên mô hình; mô hình không hệ thống nào nêu tên được in ra như một hệ thống cần thêm vào governance.yaml, ngoài phạm vi cho đến khi một người quyết định. Số hiệu, id lần chạy và nguồn của mỗi phiên bản được giữ trong .oloproof/governance/mlflow/. Với --tag, các phát hiện của bản ghi niêm phong gần nhất được ghi lên phiên bản mới nhất của mỗi mô hình đã khớp dưới dạng thẻ oloproof.findings, oloproof.findings_digest, oloproof.assessed_on, oloproof.catalogue. Đã kiểm thử với các phản hồi được ghi lại và, vào ngày 4 tháng 11 năm 2026, với một máy chủ MLflow 3.18.0 thật chạy cục bộ, các thẻ được đọc lại.

oloproof governance azureml, oloproof governance sagemaker làm điều tương tự cho một không gian làm việc Azure Machine Learning và một Amazon SageMaker Model Registry. Azure ML đọc không gian làm việc được đặt tên bởi AZURE_SUBSCRIPTION_ID, AZURE_RESOURCE_GROUP, AZURE_ML_WORKSPACE qua API quản lý, với token trong AZURE_ACCESS_TOKEN (az account get-access-token); --tag thêm bốn thẻ vào thẻ của phiên bản mới nhất. SageMaker đọc các nhóm gói mô hình như mô hình và các phiên bản gói như phiên bản, ký mỗi yêu cầu bằng các biến chuẩn AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_REGION; --tag đặt bốn giá trị làm siêu dữ liệu khách hàng của gói mới nhất. Không thông tin xác thực nào được lưu hay in ra; các lần nhập được giữ trong .oloproof/governance/azureml/, .oloproof/governance/sagemaker/. Cả hai đều được kiểm thử với các phản hồi được ghi lại theo dạng đã được tài liệu hóa của từng dịch vụ; không dùng tài khoản Azure hay AWS thật nào.

Lưu giữ, truy cập và nơi lưu trú dữ liệu

Trong một workspace được lưu trữ, Owner đặt trong Cài đặt số ngày giữ nội dung ca của các lần chạy, các trace và nhật ký đọc; worker xóa những gì cũ hơn và ghi một biên nhận mà Owner và Admin có thể tải xuống. Quyết định, phê duyệt, niêm phong và hồ sơ quản trị luôn được giữ. Mỗi lần mở một lần chạy, các phát hiện hoặc một niêm phong đều được ghi theo tài khoản và thời gian vào nhật ký kiểm toán. Dữ liệu nằm trong một vùng duy nhất của bản triển khai (oloproof.com: Toronto, bản sao lưu ở Toronto kèm một bản sao được mã hóa ở Chicago); yêu cầu lưu trú nghĩa là một bản triển khai cho mỗi vùng.

Nhiều danh mục, rà soát trong không gian làm việc và API

Một dự án có thể nêu nhiều danh mục bằng catalogues: [dadm.yaml, ethics.yaml]. Mỗi hệ thống được đánh giá theo các danh mục nó liệt kê (catalogues: trên hệ thống), danh mục của các nhóm nêu tên nó (groups: {public: {catalogues: [ethics.yaml], systems: [chatbot]}}), hoặc nếu không thì mọi danh mục đã khai báo, và mỗi phát hiện nêu danh mục của nó. Phiên bản mới của một danh mục đánh dấu một yêu cầu retired: "2027-01-01" kèm replaced_by: <id> thay vì xóa nó: sau ngày đó yêu cầu không còn tạo phát hiện, và bản ghi nêu tên nó.

Trong không gian làm việc được lưu trữ, Owner hoặc Admin xác nhận, bác bỏ, sửa đổi hoặc chú thích một phát hiện trên trang Governance. Mỗi hành động được ghi dưới tài khoản của họ vào nhật ký rà soát riêng của không gian làm việc, được xâu chuỗi bằng hash, đọc sau nhật ký được đẩy lên, và một con dấu xuất cả hai nhật ký.

Một token có phạm vi đọc đọc cùng các đối tượng cho dự án của chính nó: GET /api/governance/findings, /seal, /statements, /reviews, /approvals, được mô tả bằng OpenAPI 3.1 tại /api/openapi.json. Không đối tượng nào chứa nội dung ca.

Những gì nó không thể cho bạn biết

Tuyên bố là lời của con người; Oloproof ghi lại ai đã nói gì, khi nào, và không kiểm tra điều đó. Một phát hiện chỉ mạnh bằng các quy tắc được gắn với nó. Trong không gian làm việc được lưu trữ, các phát hiện này hiển thị trên trang Quản trị của dự án.