INTELLIGENCE LIFECYCLE · 01 / 05
Direction
Define the decision need before tasking collection.
Direction records the question, decision context, owner, priority, deadline and gaps that intelligence work is intended to address. Those requirements remain linked to collection, assessment, released products and feedback as the work changes.
01 · Record the requirement and its decision context
Create an intelligence requirement (IR), priority intelligence requirement (PIR), specific intelligence requirement (SIR), essential element of information (EEI) or request for information (RFI). Record the question, description, decision point, priority, due date and specific information gaps. Handling, kind and parent relationships are selected before creation; they are not ordinary later edits.
Search existing needs before creating a new one. A subordinate information need can be attached to a suitable parent. Workspace context is editable background, not a substitute for stating the decision the requirement must support. Priority does not confer command approval.
02 · Assign an eligible owner
Ownership is an explicit decision. A user with assignment authority searches for currently eligible identities, selects the exact account and records an assignment rationale. Current authority governs reads, searches and changes; a familiar account name or broad role does not by itself authorise an operation.
Requirement content and lifecycle changes retain versions, reasons and audit history. Expected-version checks expose stale edits as conflicts instead of silently overwriting another user’s work. A changed question or owner may invalidate its review state.
03 · Activate, review and resolve the need
Activation requires a decision point. The responsible user selects a permitted new status, records the reason and inspects the retained result. The workflow supports deliberate movement through review, satisfaction and closure; satisfaction requires that no outstanding gaps remain.
A completed collection plan, published product or favourable recipient response does not automatically satisfy the requirement. Revisit the actual gaps and decision context before changing status. If the need returns, reopen it deliberately and retain the earlier outcome.
04 · Use an RFI for information already held
An addressed RFI connects an internal requester with an eligible responder. The responder reviews holdings and can provide an exact-evidence answer or record an explicit nil, refusal or referral outcome. The requester records closure. A changed question requires reissue rather than reusing an old answer as if it addressed the new scope.
An RFI cannot directly originate a new collection plan. Additional acquisition must use an appropriate separate requirement. Internal addressing does not establish external transmission, and a referral does not automatically task another organisation.
05 · Carry the exact requirement into collection
Eligible non-RFI work can initiate a collection plan. The plan retains the requirement version and connects the objective to reviewed sources, eligible collectors and a defined task window. Later requirement changes can require renewed source-use review for new tasking or acquisition.
This linkage distinguishes the need from the means chosen to address it. Collection results record observations and remaining gaps. Analysis records judgement. Direction retains the accountable decision about whether the original need has actually been answered.
06 · Adopt policy and terminology deliberately
Versioned applicability profiles and terminology govern new work. An adopted profile revision stays identifiable; a later catalogue update does not silently rewrite existing judgements, reviews or released bytes. Changed sources trigger impact review rather than automatic activation of new requirements.
Probability, confidence, source reliability, information grading and handling are separate dimensions. The displayed SIR term is specific intelligence requirement. Historical terminology remains intelligible in its original version rather than being retrospectively reclassified.
07 · Inspect the outcome, not just the status
A useful Direction review follows the retained chain: requirement revision, tasking decisions, source material, analysis, exact product revision, release, acknowledgement and feedback. Inspect unresolved gaps and the reason for any closure, reopening or follow-on task.
Recipient feedback can prompt a change, but the responsible user performs that change through the Direction workflow. The application records the resulting state and relevant version; it does not infer operational success from a positive comment.
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.