INTELLIGENCE LIFECYCLE · 05 / 05
Feedback
Record what the recipient needed next.
Feedback is tied to an acknowledged release package and its recipient. It records usefulness, gaps, corrections and follow-on needs while leaving requirement closure, retasking and analytical changes as explicit human decisions.
01 · Start from explicit acknowledgement
The named current recipient prepares and downloads an authorised package, inspects it and checks its SHA-256 against the authenticated release record. The recipient then records a personal acknowledgement statement and package identity through the acknowledgement workflow.
Access, download preparation, download and acknowledgement are separate events. A displayed expected hash is not evidence that received bytes were checked. Seeded or simulated receipt in an exercise must not be described as a new real acknowledgement.
02 · Assess the product that was actually received
Recipient feedback is bound to the acknowledged package, not to whatever revision the author has most recently edited. Record usefulness, timeliness, gaps, corrections, lessons and suggested satisfaction, with reasons that another user can inspect.
Controlled amendments retain response history. Feedback preserves the recipient’s view of the exact released intelligence. It does not establish that the assessment is correct, that every sentence was understood or that the originating requirement has been answered.
03 · Retain clarification and outcome evidence
The connected loop includes customer clarification, agreed-use dialogue and measures of timeliness, relevance and utility. Qualified outcome evidence can explain how the product informed a decision while keeping the claim within what the record supports.
Distinguish a favourable reaction from an observed operational outcome. A useful product can still leave a central information gap unresolved. Do not invent satisfaction, impact or success merely because feedback is positive.
04 · Make the Direction decision separately
An authorised analyst or owner inspects the feedback and follows the relevant Direction or Collection link to perform an actual change. Close, reopen or retask the original requirement deliberately, or create follow-on work as appropriate.
Return to the response, refresh the requirement observation and retain the resulting state and version. Explain the action or the reason for no change. Feedback itself does not secretly perform the transition; remaining gaps and permitted statuses still govern the requirement.
05 · Assign follow-on actions and lessons
Follow-on needs can become assigned actions and entries in a controlled lessons register. Link the action to the received product, recipient feedback and observed need so later review can distinguish the recommendation from the work actually performed.
Human review retains responsibility for tasking and analytical correctness. A correction may require new collection, analytical reassessment or a revised product and release; the earlier package and acknowledgement remain identifiable.
06 · Preserve history across the next cycle
The retained chain connects the need, acquired material, exact evidence, analytical judgement, approved product, package, recipient acknowledgement and feedback. Controlled amendments retain what changed without turning later information into a claim about an earlier decision.
The next cycle begins with a deliberate question or retasking decision. Earlier observations and released bytes are not silently replaced. Access to historical records still depends on current authority and the relevant handling scope.
07 · Demonstrate the complete loop
For evaluation, use a synthetic requirement and package. Show the real output, independently verify received bytes, record explicit acknowledgement, save feedback and inspect the analyst response. Then show the actual requirement state and any remaining gaps.
This demonstrates recorded workflow behaviour, not a customer endorsement or guaranteed operational result. Acceptance belongs to the named deployment, users and decision criteria. The master reference’s completed-scope description does not certify a generally available release or accredited environment.
Documentation basis: CORTEX Master Project Reference, version 2.0, 28 September 2026. Capability descriptions follow its completed-scope basis; operational acceptance remains specific to the deployed release and environment.