> 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/domestic-delivery.md).

# Domestic Delivery

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

Publish exact approved bytes, record explicit receipt and acknowledge correction or withdrawal notices without exposing private source lineage.

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

**Expected result:** Named recipients can inspect their authorised package; operators can distinguish download attempts, explicit receipts and pending notice actions.

## Before you start

* Operators need explicit UK-package distribute access and normal private lineage access. Recipients need only current receive access, named membership and the recipient handling within the selected workspace.
* Use an independently approved exact package. Publication rechecks the current UK agreement, derivative, processing scope, recipient authority and separate related protected-use decisions.

## What to do

{% stepper %}
{% step %}

## Publish approved bytes

An operator opens the approved UK package, records a reason and publishes it to the named recipients.

Publication preserves the prepared ZIP and records a download expiry bounded by derivative, processing and protected-use validity. It creates no email or automatic receipt.
{% endstep %}

{% step %}

## Inspect your recipient inbox

Open Product, Received UK packages.

Your current identity, receive grant, workspace and handling control the inbox. Inspect the recipient content, package SHA-256 and any fixed notices.

You are not granted source records, risk narratives, other recipient identities or private approval reasons.
{% endstep %}

{% step %}

## Record actual receipt

Enter a reason and prepare the approved ZIP download. That records an attempt only.

After receiving and checking the exact package, enter its SHA-256, choose receipt, explicitly confirm and submit.

An unchanged retry recovers the same event; a different hash fails.
{% endstep %}

{% step %}

## Issue a correction or withdrawal

An authorised operator chooses a fixed notice on the published request.

A correction needs a separately published replacement covering every original recipient within the original handling. Private rationale is retained internally; recipients receive only the fixed warning and exact replacement link.

Both notices stop new downloads of the original bytes.
{% endstep %}

{% step %}

## Acknowledge each notice

Recipients open the warning, take the stated action, select the notice, enter the affected package hash and explicitly confirm.

Operators refresh their recipient table to distinguish receipt from each notice acknowledgement. Pending does not mean seen; urgent or unreachable recipients require the approved contact process.
{% endstep %}
{% endstepper %}

## Check the result

* Is this the exact approved SHA-256?
* Was receipt explicitly recorded separately from download preparation?
* Have all correction or withdrawal notices been acted on and acknowledged?

## If you get stuck

<details>

<summary>Why is an earlier package still listed?</summary>

Its descriptor, warnings and your evidence remain visible through current recipient access after expiry, correction or withdrawal. Content downloads stop, but you can still record a truthful receipt or notice action.

</details>

<details>

<summary>Did a failed download prove that nothing transferred?</summary>

No. The service records preparation only and checks for a concurrent notice before returning bytes. A browser or network failure cannot establish receipt or remote destruction. Inspect your events, retry unchanged when appropriate and acknowledge only what actually happened.

</details>

<details>

<summary>Why did my acknowledgement conflict?</summary>

The package or notice changed, or that receipt/notice is already recorded. Refresh and compare without discarding entered notes. Use the current exact hash and notice; access loss clears the recipient page and notes.

</details>

## Responsibility and limits

* Publication, recipient download attempts, receipt and notice acknowledgement are distinct retained decisions. Operators preserve the original bytes and full internal lineage.
* Current recipient access and the retained download period are checked at download. Later source/policy concerns require an explicit package withdrawal or correction; the inbox is not an automatic source-policy monitoring service.
* Withdrawal and expiry stop further downloads; they cannot erase earlier copies. Follow the recorded handling/retention instructions and organisational contact process.
* Each recipient has a separate bounded history of 128 events. No private-case write or other recipient history is required for acknowledgement.

**Reference and scope:** F16-R05/R06 and F17 disclosure scope: independent exact-package approval precedes publication; a download attempt is not receipt, and withdrawal cannot erase downloaded copies.

## Related workflows

* [Prepare an approved UK recipient package](broken://pages/6b0f4486869945a5ea190d9b499799cbe47ee3c7)
* [Review a derivative for UK sharing](broken://pages/0f2353fa172e1221893de98a680eecbabeae16c1)
* [Prepare a UK sharing agreement](broken://pages/d01ab7701685aeb8c20c3f2edef3d644081ce5d4)
* [Protect source identity and review each use](file:///7397340/collection/source-protection.md)
* [Review, approve and publish an exact internal release](broken://pages/470978e3be0758fbc43448d1d7b8fc918bd9675f)
* [Manage accounts, grants and workspace membership](file:///7397340/assurance/access.md)