> 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/reference/retained-records.md).

# Retained Records

CORTEX links the work in a case. A requirement states the question. A collection plan names the work to gather information. Material records preserve what arrived. An analysis explains what the evidence may mean. A product prepares a result. A release controls who receives an exact package. Feedback records the recipient's response. The requirement owner then decides what to do next.

Each part has its own saved record. Moving to the next part does not silently change the earlier part. This separation helps a later reader see what people knew and decided at each step.

## A view, a draft, and a saved record are different

| What you did                                                       | What it changes                                                         |
| ------------------------------------------------------------------ | ----------------------------------------------------------------------- |
| Open a page or select a tab                                        | Your view. It does not change the record.                               |
| Type in a form or select **Continue**                              | The current unsaved draft. It does not create a saved record.           |
| Select **Back** in a guided form                                   | The form step. It keeps the current in-memory entries.                  |
| Select **Cancel**, refresh, or close an unsaved form               | The in-memory draft can be lost.                                        |
| Select the form's final save action and receive a confirmed result | One retained record or revision is saved, subject to current checks.    |
| Change a list filter or layout                                     | The current view. It does not change records, permissions, or handling. |

Read the save result and the current version before you tell a colleague that work is complete. If the connection stops after you select Save, the result can be uncertain. Open the current record and check its saved version before you submit the same action again.

Some pages use a **Before you begin** panel. Read it before you start a long form. **Ready** means that the page found a usable current selection. It does not reserve a record or guarantee the final save. **Required input** identifies missing entries. The service checks access, source versions, and handling again when you save.

## Revisions and history

A saved change can create a new revision. Older revisions remain available for review. The current revision and the older one are different. A reviewer decision applies to the exact revision that the reviewer saw.

If another person changes the record after you open it, your save can report a conflict. Keep your notes, read the current saved version, compare the changes, and then decide what to enter again. Do not assume your earlier screen contains the latest state.

A changed requirement can leave collection, analysis, or product work linked to an earlier requirement version. CORTEX shows that earlier link. The owner must assess the effect and decide whether to update or repeat work. A new requirement version does not make every linked record current.

A reviewed analysis that is edited returns to draft review state for the new revision. A previous review does not approve the new text. A changed product or release audience needs its own release checks.

## Original material and processed evidence

An original file is the material that CORTEX received. The record can keep its bytes, hash, acquisition details, source link, and handling. Processing can produce an extraction or other derivative for search and citation. These are distinct. A later extraction does not rewrite an earlier exact evidence pin.

When you use evidence:

{% stepper %}
{% step %}

## Open the original material details

Open **Evidence memory** and read the original material details.
{% endstep %}

{% step %}

## Check readiness

Check whether the material is Ready for the proposed use.
{% endstep %}

{% step %}

## Read the exact evidence

Read the exact extraction and passage you intend to cite.
{% endstep %}

{% step %}

## Check decisions and limitations

Check the source decision, handling, limitations, and any correction.
{% endstep %}

{% step %}

## Use the exact citation

Use the exact citation in **Analyse** or **Products**.
{% endstep %}
{% endstepper %}

A search result, entity, graph link, or generated suggestion does not prove that an allegation is true. Review the underlying evidence and any alternative explanation. A quarantine or failed scan needs its own recovery before use.

## Analysis, product, and release

An analysis can contain cited evidence, hypotheses, assumptions, a judgement, uncertainty, and an independent review. The review is a recorded decision on the exact version. The analyst must still show limitations and competing explanations.

A Product is saved in **Products**. It can have sections, source notes, citations, and an exact content revision. An internal PDF, Word, or JSON export comes from a selected content revision. Exporting does not approve the content for delivery.

A release is a separate record in **Releases**. It binds the intended recipient and the exact approved content to a controlled package. Review, approval, distribution, download, and acknowledgement are separate events. A download alone does not create a recipient acknowledgement. The intended recipient must acknowledge the exact package.

**Shield sanitisation** creates a separate literal sanitised product when authorised. It does not change the original product, lower the handling by itself, or replace release review. UK sharing agreements, reviewed derivatives, and UK recipient packages each have their own decisions where those features are used.

## Feedback and the next question

A recipient gives feedback against an acknowledged release. The feedback can describe usefulness, timeliness, corrections, lessons, and new information needs. These are the recipient's observations. They do not automatically close a requirement, amend a plan, or create a new task.

The requirement owner reads the response and makes a separate decision in **Direction**. They can keep the question active, close it when its rules are met, reopen it, retask collection, or start follow-on work as permitted. The fictional Demo cases keep their first question active because a gap remains, even though a package and feedback exist.

## Audit and personal read state

**Pulse & audit** shows authorised activity from retained records. It can help you find the actor, action, record, and time. A personal read marker means you marked an item read in your own view. It is not a review, approval, receipt, or workflow decision.

Dates and times in operational records use UTC. Read the full time when order matters. A missing time is different from a proven delay. The words **Unknown** and **Partial** mean CORTEX did not establish a complete answer from the current authorised sources. Do not turn them into zero, success, or failure.

## Handling and access still apply

The selected workspace has a handling floor. A record can also carry compartments and caveats. Copying a passage into a Product, export, note, or research report does not remove those rules. Use approved synthetic records for training and research. Keep passwords, real sources, and protected operational content out of research notes.

For a study, record the exact page, state, saved revision, and message that a participant saw. Use [Roles and access](broken://pages/416d06428c8d999658f1e0e4e9c73a38a62447e2) to explain why a person may see less than another person. Use the [practice scenario](file:///7397340/research/practice-scenario.md) to see how retained records connect from start to finish.