Review policies and governance evidence

Use these tasks to review what is allowed, what ran, and which supporting records exist. Policies, execution evidence, and advisory assurance reports answer different questions. Keep the workspace, version, and time of each record with your review notes.

Before you start

Select the relevant workspace. Viewing policies requires asset access; viewing execution evidence requires execution access. Permission evidence, Frameworks, Supplier assurance, and Organization policy each require their own access. Changes and approvals require additional authority. Manage access explains how to request the appropriate access.

Inspect a release policy

1. Open Assure → Policies → Release policies and find the policy by name or owner.
2. Open the policy. In Overview, check the latest version, creator, and checksum when available.
3. Open Content to inspect the policy bundle. This view is read-only.
4. For a particular release, open that release and verify the policy version actually bound to it. The latest policy in the registry may differ from an existing release’s version.

If no version exists, the policy is not ready for a release to bind. Use the asset authoring workflow to prepare it, then follow release review and activation. Inspecting a policy does not approve or activate a release.

Review and approve a model policy

A model policy defines eligible provider routes for a release. New policies are authored through the asset builder; the model policy list is for review and version approval.

1. Open Assure → Policies → Model policies.
2. Find the policy and review its route summary, owner, and version list. For the full configuration, inspect the corresponding model policy asset in Assets.
3. Match the exact version identifier and creator to the version requested for the release. Review its provider and model choices against the workload’s requirements.
4. If you are authorized and the review is satisfactory, select Approve beside that version. Confirm that it changes from Needs approval to Approved.

You cannot approve a version you created yourself. Ask a different authorized reviewer to complete the review. Approval applies to that version; it does not bind it to a release or activate a workload. If approval fails, read the error and confirm your access and the version’s current state before trying again.

Review or update organization policy

Administer → Organization policy opens Governance policy for the organization of the selected workspace. Confirm the organization before saving: these commitments have organization scope.

1. Review the current immutable version and server-reported posture. Use Immutable policy history, Older versions, and Newer versions to inspect earlier commitments.
2. If you have management access and an approved change to record, update the retention settings, jurisdiction, storage choice, and commitment references that apply. The source and authority references should identify the approved basis for the change.
3. Read the retention-mode acknowledgement carefully. COMPLIANCE retention requires acknowledgement of irreversible retention; involve your organization’s responsible owner before accepting it.
4. Select Save new version. Confirm the new current version and history entry.

Saving appends a version; it does not rewrite history. If someone changed the policy while your form was open, select Reload current policy and reconfirm, review their values, and reapply only the still-approved change. Do not overwrite the newer commitment blindly.

This page does not report physical storage-lock capability, shared-chain retention floors, or export health. An organization commitment alone does not prove those operational conditions. Ask the platform operator for that evidence when your review requires it.

Audit an execution

1. Open Assure → Evidence → Evidence log. This page covers the selected workspace.
2. Select Review queue to find cases with missing policy or artifacts, or Evidence complete to narrow to cases whose required evidence is present. Use Search cases… and filters to locate a workload, release, or run.
3. Open a case to reach the run’s Evidence tab. Check who triggered it, its release, the recorded policy decision, and the available artifacts.
4. Use Story and the step timeline to relate the evidence to the run. Record the run and artifact references needed for your review.

Evidence complete means the required evidence was captured. It does not establish that an answer was correct or that a workload meets every obligation. Treat redacted, expired, partial, missing, and unknown evidence according to the limit shown. See monitor runs for investigation and safe recovery.

Inspect permission evidence

Open Assure → Evidence → Permission evidence to review recorded permission decisions and result acknowledgements in the active workspace.

1. Locate the relevant operation using its time, principal, execution, request, or source reference.
2. Check the decision outcome, freshness, expiry, reason codes, and policy or profile revision. Use the lineage reference where a decision follows an earlier decision.
3. Check Acknowledgement separately. A recorded permission decision and an acknowledged result are different records.
4. Use Load more when available to inspect older entries.

An allow decision is not proof that an operation completed successfully. No recorded evidence means no records were returned for this workspace; it does not prove that every attempted action was permitted. If access cannot be confirmed, retry the access check or contact your administrator.

Review framework findings

Open Assure → Compliance → Frameworks. Review Enabled frameworks, the latest report’s readiness caveat, and findings grouped By framework, By system, By owner, or By risk class. Note evidence provenance and any warning that the report includes only the most recent findings.

With framework-management access, use Enable or Disable under Supported frameworks to change workspace monitoring scope. Enabling is opt-in and does not immediately produce a report. No posture report yet means a report has not been generated for the enabled scope. Ask the responsible owner if expected findings remain absent.

These reports support internal review. They are advisory and do not certify compliance. Disabling a framework changes monitoring scope; it does not resolve the findings already observed.

Review supplier assurance

Open Assure → Compliance → Supplier assurance and choose a Provider. The list covers providers recorded in the workspace’s risk register. If none exist, an authorized manager can use Register provider.

1. Review the assurance generation, freshness, requirement mapping, and current claim. Check the claim’s workload, environment, release role, validity time, and reasons.
2. To prepare a mapping, an authorized manager adds the obligation and responsibility pairs that apply, confirms Expected current revision, and selects Propose requirements.
3. A separate authorized reviewer checks that mapping and selects Independently review revision. Do not treat the proposer’s own assessment as independent review.
4. After a reviewed mapping and assurance generation exist, a manager sets the claim’s workload, environment, release role, and expiry, then selects Propose claim.
5. The independent reviewer evaluates every applicable pair as Supported or Gap, supplies its evidence artifact and matching checksum, and selects Submit human semantic review. Review the resulting current outcome and reasons.

The reviewer needs supplier-management and execution-evidence access. Use evidence you have actually inspected; a checksum identifies an artifact but does not establish that its contents support the claim. If the revision or generation changed, reload and review the current material before resubmitting.

Claim history preserves historical decisions and recorded validity times. It does not evaluate current validity. Supplier assurance is an evidence-bound claim for its stated scope, not supplier certification.

Specialist operational controls

Some governance tasks need an incident owner or platform operator because they affect running work, durable restrictions, or platform-wide evidence.

For integration or operational details, use the clearly labeled technical reference index. If a page is absent or denied, confirm its module availability and the required access with your administrator; do not infer that its records or protections are absent.