> 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/products/release.md).

# Release

**Open this area:** In the CORTEX menu, select **Release & sharing → Releases**.

Bind current Product content to verified internal recipients, retain independent approval and publish an immutable three-format package.

**Who uses this:** Author, Reviewer, Recipient\
**Open in CORTEX:** `/releases`\
**In-app guide:** `/help?topic=release`

**Expected result:** A Released record identifies the exact approved content, audience, package and manifest; receipt remains a recipient action.

## Before you start

* Use a current Product revision with text in every section, valid processing/currency assurance and complete authorised lineage. A minimum internal draft can be saved earlier, but cannot be submitted for release.
* Ensure the requester, reviewer, independent approver and publisher each hold the required operation permissions.
* Identify current eligible internal recipients by exact email, with workspace, handling and provenance access.

## What to do

{% stepper %}
{% step %}

## Bind the content and audience

The Before you begin panel shows release submission access, a current visible product with all section text complete, verified recipients and any processing decision required by the product marking. An unfinished internal product links back to its editor.

Product selects the exact current revision and hash; Audience verifies and adds 1–20 eligible internal recipients by exact email.

Required fields, issue lists and step colors show what blocks Continue.
{% endstep %}

{% step %}

## Assess the intended dissemination

Processing is optional for an unrestricted product. Restricted content needs an independently approved activity permitting Dissemination for this exact product and selected audience; processing read access is needed to choose one.

Changing either product or recipients clears the current selection and requires reassessment.

Review and save needs a 3–1,000 character reason without control characters.

Only the final action retains one Draft; amending a request resets review and approval while preserving history.
{% endstep %}

{% step %}

## Submit the exact scope

As the requester with Release submission access, inspect the Workflow tab on release detail.

If the bound Product revision has no sections or an incomplete section, the page explains the prerequisite before showing Submit. A Product author with write access must complete the Product; then amend the release to bind its new revision.

The saved request stays Draft and its prior audit remains available.

Once the exact bound revision is complete, choose **Submit exact scope for review**, state a 3–1,000 character reason and **Apply action**.

The service rechecks the retained revision and permissions; resolve any reported conflict and confirm the stored state before treating the request as submitted.
{% endstep %}

{% step %}

## Record review

A different eligible account examines content, handling, assurance and recipients.

Select **Endorse reviewed scope** or **Request scope changes**, supply a reason and **Apply action**.

Changes requested require the requester to amend before resubmission.
{% endstep %}

{% step %}

## Approve independently

An eligible approver who is neither requester nor any retained Product or Analysis contributor selects **Approve exact scope independently** with a reason.

A review grant or administrator label does not remove this exclusion.
{% endstep %}

{% step %}

## Publish the package

An authorised publisher selects **Publish controlled package** on this node and **Apply action**.

Check Released state, package/manifest hashes and retained PDF, DOCX, JSON and manifest.

Publication on the node does not send an email or acknowledge receipt.
{% endstep %}

{% step %}

## Find and share the release link

From Product tasks, choose **View releases for this product** to find every currently visible release for that Product.

On a release's Scope and audience tab, use **Copy link** to share its stable local record URL through an authorised channel.

A recipient still needs current access to the release and every protected source; a copied link grants nothing.
{% endstep %}
{% endstepper %}

## Check the result

* Is this the exact current content and assurance intended for release?
* Is every named recipient eligible for the complete retained lineage?
* Are requester/reviewer and contributor/approver restrictions met?
* Has any content or audience changed since review?
* Is publication confirmed with package and manifest identity?

## If you get stuck

<details>

<summary>How do I browse controlled releases?</summary>

Choose a release state and select **Find releases** to apply it. The visible count and page range include only releases in your current access scope.

Previous and Next appear only when results span pages; they keep the submitted state and any product filter.

An unsubmitted state choice does not change the current results.

</details>

<details>

<summary>Why did the releases list stay on the same page?</summary>

A page read may have failed. The last confirmed page and submitted filters remain available so you can retry.

If current release access is lost, CORTEX clears visible release rows and the **Draft a release** action; restore access and search again.

</details>

<details>

<summary>Why is approval obsolete?</summary>

Product content, contributions, audience or processing decision changed.

The requester must reassess processing where necessary, use **Amend release scope** to bind the current scope, then obtain fresh review and approval.

A historical Approved label does not authorise publication.

</details>

<details>

<summary>Why is a recipient not eligible?</summary>

Check the exact email and current account, grant, membership, handling and retained Analysis access.

Obtain a legitimate access decision or choose the appropriate approved audience; do not remove source obligations from the record to force eligibility.

</details>

<details>

<summary>Why can an old package no longer be downloaded?</summary>

Retrieval rechecks current product/evidence access and all named recipients.

An audience member's revocation can block further preparation; use a separately reviewed release when a changed audience is justified.

Existing downloaded bytes cannot be recalled.

</details>

## Responsibility and limits

* Review and approval concern the exact Product and audience; they do not confer command approval, external disclosure rights or declassification.
* A reviewer may also approve when otherwise eligible; do not invent an additional mandatory separation. Handle exported packages under their markings.

**Reference and scope:** JDP 2-00 (4th ed.), 3.49–3.59 inform controlled dissemination and useful production. CORTEX's exact-version and independence rules implement a distinct release decision.

## Related workflows

* [Author an intelligence Product and inspect its exports](broken://pages/262a7998f4bd8e3a741063bf243590ce8bf23fc9)
* [Acknowledge the exact package and close the feedback loop](file:///7397340/feedback/feedback.md)
* [Create an immutable literal-sanitised Product](broken://pages/cdb9c7b59bf661ff4d337957385a22c20e4bc07a)
* [Record processing purposes and privacy applicability](file:///7397340/assurance/processing-activities.md)