> For the complete documentation index, see [llms.txt](https://docs.cortex.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.aic.io/workflow-guides/assurance/system-assurance.md).

# System Assurance

**Open this area:** In the CORTEX menu, select **Assurance & governance → System assurance**.

Record controls, exact evidence, accountable owners, exceptions, quality actions and deployment limits for a specific UK system.

**Who uses this:** Reviewer, Administrator\
**Open in CORTEX:** `/governance/systems`\
**In-app guide:** `/help?topic=system-assurance`

**Expected result:** An immutable sequence of baseline revisions and owner decisions makes evidence gaps and expired risk visible.

## Before you start

* Have assurance.read in the current organisation/workspace and the complete handling scope. Editing also needs assurance.manage; owner decisions need assurance.approve.
* Prepare a distinct system key and deployment identifier.
* Keep missing contract, network or release evidence explicit.
* Selecting a person never grants them permissions.

## What to do

{% stepper %}
{% step %}

## Register the system

The Before you begin panel shows assurance read and management access, accountable owner selections and whether runtime connection binding is available.

System and owners needs:

* A 3–40 character stable key
* A 3–200 character name
* A 10–4,000 character boundary
* Environment
* A 3–300 character deployment identifier
* UK allocation or unresolved location
* Eligible security and contract owners

Required labels, issue lists and colored step states update as values change. Missing sponsor inputs can remain explicit in a draft.
{% endstep %}

{% step %}

## Assess each control

Controls and evidence groups optional controls, exact evidence and authority clauses. When you add a row, its required labels and the domain-rule issue list show what is still missing before Continue.

Give each control a stable key, owner and reason. Select:

* Unassessed
* Applicable
* Not applicable
* Unmet
* Evidenced

Evidenced needs exact evidence keys. Identify derived software controls explicitly; an authority control also needs a supplied mapped clause.
{% endstep %}

{% step %}

## Pin evidence and sources

Add evidence with:

* An exact locator
* SHA-256
* Verification method

Use an exact CORTEX record to pin its current version/hash, or describe external evidence and verification limits.

Clause mappings select an authorised retained publication edition. Exclude withdrawn JSP 604; never invent missing restricted clauses.
{% endstep %}

{% step %}

## Record risk and quality

Exceptions and quality is optional until a row is added.

Each exception needs:

* Control
* Scope
* Residual risk
* Authority
* UTC expiry
* Reassessment trigger

Quality actions connect a finding, owner, corrective action, affected retained revisions and verification evidence. A repeat links to a prior finding.

Verification requires evidence.
{% endstep %}

{% step %}

## Assess deployment limits

Deployment and data flows checks added rows before Continue.

Add each proposed handling level, boundary, owner, required control keys and missing inputs.

The current host supports OFFICIAL and OFFICIAL-SENSITIVE configurations only. Higher levels remain unsupported; empty assessments remain unassessed.
{% endstep %}

{% step %}

## Save and review

Artifact and review accepts an absent artifact; supplying any artifact field requires the complete exact signed identity and verification evidence.

Enter a 10–1,000 character reason.

Only final Save baseline revision retains a draft; Back and completed-step selection preserve the unsaved form.

The appointed security owner must be different from the latest baseline editor to record security review. Contract confirmation and scoped risk acceptance are separate decisions.

Editing resets review and flow approval; control, evidence, authority or boundary changes also clear affected risk acceptance.
{% endstep %}

{% step %}

## Inspect history

On detail, select a retained revision. Earlier hashes, content and actors remain fixed.

Read Current readiness against the latest revision; expired exceptions remain unresolved even when their old acceptance is retained.
{% endstep %}

{% step %}

## Verify an offline snapshot

Prepare a signed snapshot using the node's configured offline metadata key. Copy its JSON only through an authorised transfer.

Select a saved JSON file and Verify against retained history to check its trusted signature and matching local baseline.

This changes no records and needs current evidence access; it does not certify current readiness.
{% endstep %}
{% endstepper %}

## Check the result

* Are owners, scope and exact evidence correct?
* Are missing inputs and limitations explicit?
* Is each risk still within its scope and expiry?
* Can each repeated defect be traced to verification and an affected revision?

## If you get stuck

<details>

<summary>Why can I not find an owner?</summary>

Use the exact organisation email. The person must have current assurance read access and the complete selected workspace/handling scope. Appointment alone never grants access or approval permission.

</details>

<details>

<summary>Why did a save or review fail?</summary>

Follow the reported field or reference error. Reload after a concurrent change; check current permissions and supporting-record access. A changed or withdrawn source requires an explicit impact review and revised baseline before review.

</details>

<details>

<summary>Why does readiness still show gaps after review?</summary>

Review records who assessed the baseline. It does not supply missing evidence, confirm absent contracts, resolve unknown locations, verify corrective actions or renew expired risk.

</details>

<details>

<summary>Can I edit or approve an old revision?</summary>

No. History is read-only. Decide against the current version or create a new revision. A withdrawn baseline remains historical; register a separate replacement.

</details>

## Responsibility and limits

* Recorded decisions are accountability evidence; they do not grant deployment authority or confer accreditation.
* Revisions retain history, with limits of 64 revisions and 6 MiB per baseline. No history is silently truncated.

## Reference and scope

Derived software support for UK security and quality governance. Actual contract/SAL and current sponsor network inputs must be supplied separately; this workflow does not certify accreditation.

## Related workflows

* [Record UK processing paths and approved uses](broken://pages/d1a5ce8a791f7e21103f6f699e97b63ddcffb253)
* [Preserve an exact revision and manage holds](broken://pages/0185ca5a2331760fb4c59665b8dde7f4d80e0fc6)
* [Manage accounts, grants and workspace membership](broken://pages/99c8701bc497eefb32769b668198b1f9f5fc6a93)
* [Work through connection and deployment limits](broken://pages/e2892068271c3c1f3c4471ca5a8f532a8174ba43)