> 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/lifecycle/feedback.md).
# Feedback
Feedback closes the working loop. A recipient records how useful and timely an acknowledged product was. An authorised analyst then reviews the observation and makes any Direction or Collection change separately.
## Before you start
{% stepper %}
{% step %}
### Confirm the workspace and release
Confirm that you are in the intended workspace and that you can open the exact controlled release.
{% endstep %}
{% step %}
### Acknowledge the package
If you are the recipient, open **Release & sharing → Releases**, find the package you received, and complete its explicit acknowledgement. Feedback must be linked to your acknowledged package.
{% endstep %}
{% step %}
### Review release details
Read the product revision and package details before you rate them. Feedback about one release must not be attached to a different revision or audience.
{% endstep %}
{% endstepper %}
## Find feedback already recorded
{% stepper %}
{% step %}
### Open recipient feedback
In the menu, select **Intelligence cycle → Feedback**. The page title is **Recipient feedback**.
{% endstep %}
{% step %}
### Review visible records
Read the visible records. Use **Previous**, **Next**, or **Refresh feedback** as needed.
{% endstep %}
{% step %}
### Verify receipt and provenance
Open the relevant feedback record. Check **Receipt and provenance** to confirm the release, product revision, requirement version, recipient, acknowledgement time, package SHA-256, and handling.
{% endstep %}
{% endstepper %}
Recipients see their own observations. Authorised analysts can see feedback within their handling scope. A missing record can mean that the recipient has not acknowledged the package, the current page does not contain it, or you lack access.
## Record recipient feedback
{% stepper %}
{% step %}
### Select the acknowledged package
On **Recipient feedback**, select **Record feedback**. If you do not arrive from an exact release link, use **Choose an acknowledged package** to select the correct release.
The page lists up to 25 recent releases you can read; only a package that you acknowledged can be selected. Use **Find a released package** if it is outside that page.
{% endstep %}
{% step %}
### Verify the exact release
In **Exact acknowledged release**, compare the product revision, requirement version, handling, and package SHA-256 with the package you received.
{% endstep %}
{% step %}
### Complete the feedback form
Complete the two form steps: **Recipient assessment** and **Corrections and follow-on**.
{% endstep %}
{% step %}
### Record your assessment
In **Recipient assessment**, choose **Usefulness** and **Timeliness**. Choose **Your assessment of requirement satisfaction**.
This is your view as a recipient; it does not change the requirement.
{% endstep %}
{% step %}
### Explain usefulness and timeliness
Enter **Usefulness and timeliness rationale** (10–4,000 characters). Say what helped or hindered your decision, and explain the timing in relation to the actual need.
{% endstep %}
{% step %}
### Add corrections and follow-on needs
In **Corrections and follow-on**, enter **Corrections** if you found an error, **Lessons** if the process should change, and **Follow-on information needs (one per line, up to 20)** if a new question remains.
These fields are optional. Be specific enough that an analyst can check or act on the point.
{% endstep %}
{% step %}
### Save feedback
Review the form and select **Save recipient feedback**. The feedback is retained with the exact acknowledged release, product revision, requirement version, and your identity.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
The feedback record does not alter the release package or its original product. A suggested correction does not automatically amend the product. A follow-on need does not create a new Direction requirement or a Collection task.
{% endhint %}
## Revise your observation
If you need to correct your own feedback, open it and select **Revise feedback** when the action is available. Review the current entry, change the appropriate fields, enter **Revision reason** (10–500 characters), and save.
CORTEX retains both the earlier and current recipient revisions. The analyst can see which revision their response addressed.
## Review feedback as an analyst
{% stepper %}
{% step %}
### Review the feedback record
Open the feedback record and read **Current observations**, **Follow-on information needs**, **Receipt and provenance**, and **Retained recipient revisions**.
{% endstep %}
{% step %}
### Compare feedback with the requirement
Read the linked requirement and its current version. Compare the recipient's suggested satisfaction with the actual answer and open gaps.
{% endstep %}
{% step %}
### Record an analyst response
In **Deliberate analyst response**, enter **Response, corrections and decision rationale** (10–4,000 characters). Select **Record analyst response**.
{% endstep %}
{% step %}
### Make a separate Direction decision
Use **Manage requirement state** to make a separate Direction decision if the requirement needs to be satisfied, reopened, or changed. A response in Feedback does not make that state change.
{% endstep %}
{% step %}
### Accept and assign new needs
If you accept a new need, use **Accept and assign feedback action** to enter the deliberate proposal workflow. Then create or amend the appropriate Direction and Collection records with their normal permissions.
{% endstep %}
{% step %}
### Respond to later revisions
If the recipient revises feedback later, read the new revision and record a new response if needed. An earlier analyst response remains attached to the feedback revision it reviewed.
{% endstep %}
{% endstepper %}
The product may also need a corrected content revision and a new release. Follow the ordinary Products and Releases workflow. A feedback response cannot change bytes already released or downloaded.
## Record deeper follow-up when appropriate
The feedback detail page offers **Clarification and agreed use**, **Outcome evidence**, **Register a lesson**, and **Lessons register**.
* Use **Clarification and agreed use** when you need a retained exchange about a question, a proposed use, or an agreed limitation. Select **Record exchange** for each actual exchange; do not treat a note as consent that has not been given.
* Use **Outcome evidence** when you have evidence about the product's actual decision use or correctness. Select **Record outcome evidence** after reviewing the exact package context and agreed measures.
* Use **Register a lesson** for an accountable improvement action with a deadline. Select **Register lesson and action** after reviewing the supporting feedback and other retained evidence.
{% hint style="info" %}
These are separate records. They support learning and accountability; they do not rewrite the original recipient observation or approve a new release.
{% endhint %}
## If you cannot continue
No acknowledged package is offered
Open the correct release and check that you explicitly acknowledged the exact package with your own account.
The feedback link is unavailable
Check your workspace membership, release access, handling, and feedback permission.
Your satisfaction choice has no effect on Direction
That is expected. The requirement owner or authorised analyst must make a separate, reasoned Direction decision.
A correction is urgent
Use the approved operational or incident route as required by your organisation, then retain the appropriate CORTEX correction and response records. A Feedback entry alone does not notify every previous recipient.
A save conflicts or its outcome is uncertain
Select **Refresh feedback** and inspect **Retained recipient revisions** and **Audit history** before you submit again.
Return to [Direction](/lifecycle/direction.md) to review the requirement and start a new question when the evidence calls for it.