> 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/direction/requirements.md).

# Requirements

**Open this area:** In the CORTEX menu, select **Intelligence cycle → Direction**.

Connect an information gap to a decision, accountable owner, priority and due date, then retain deliberate lifecycle decisions.

**Who uses this:** Requirement owner, Analyst, Reviewer.\
**Open in CORTEX:** `/direction`.\
**In-app guide:** `/help?topic=requirements`.

**Expected result:** A saved requirement states what is needed and why, with an appropriate next state and retained history.

## Before you start

* Select the intended workspace and confirm Direction read/write authority.
* Identify the decision-maker's question, decision point and outstanding gaps.
* Choose the correct parent and handling before saving; kind, parent and handling cannot be amended later.

## What to do

{% stepper %}
{% step %}

## Retry child expansion

If the first child request fails, the parent remains collapsed. Select Expand again to retry; no empty branch is implied by that failure.

If a later child-page request fails, the already confirmed child rows remain visible while you retry More children.

Loss of current Direction access clears those rows and any unsaved child draft.
{% endstep %}

{% step %}

## Browse the requirement tree

Browse requirement tree loads one bounded top-level page. Expanding a suitable parent loads its children on demand, with a separate More children action; an RFI is a leaf.

CORTEX checks the selected workspace, current actor and every returned row before and after each read.

While an ordinary top-level page or filter request is running, the last confirmed tree remains visible and paging is disabled. A transient failure keeps the confirmed tree and applied filters for retry.

A changed actor, workspace, handling grant or unavailable row clears the hierarchy, plan selection and any unsaved child draft. Confirm the intended workspace and Direction access, then reload.

Counts and urgency signals describe only the loaded page, not every matching requirement.
{% endstep %}

{% step %}

## Build a collection plan from the tree

The requirement tree defines the questions and their parent/child relationships; it is not itself a collection plan.

With current Collection read/write authority, tick 1–20 Draft or Active non-RFI questions at any loaded level. Expand parents to select child questions, and keep selections while paging or searching within the current workspace.

Create plan for selected requirement opens the focused editor; two or more selections open the grouped editor with those current questions.

The editor rechecks access, status, exact versions and handling, then saves a separate Draft plan with a collection objective. Inaccessible or closed questions cannot be carried forward.

Selecting a parent does not silently select its children.
{% endstep %}

{% step %}

## Check existing direction

Direction opens with a page-scoped workload board. Overdue open requirements appear first, followed by those due within seven days, scheduled work, work without a due date and completed work.

Edit the search or status, then select Find requirements to apply both from page 1; Previous and Next continue through the last applied filters while edits remain unsubmitted.

The pager range covers the matching requirements visible to your current account, while workload signals and ordering cover only the loaded page rather than global urgency.

While a page or filter request is running, the last confirmed results remain visible and the pager is disabled. A transient failure keeps that confirmed page and submitted filters for retry; loss of current Direction access clears the visible rows.

Choose Browse requirement tree to see top-level questions and expand their children on demand; each level has its own bounded page and More children action. Only types that can contain children have an expand control; an RFI is a leaf.

An empty expanded branch means no children are visible to the current account, not that none exist.

The summary says whether the count covers all top-level requirements visible to you or active filters.

When no top-level question is visible without filters, the authorised New top-level requirement action is beside the heading and search controls stay out of the way; this does not prove that hidden records do not exist.

A filtered empty result retains the search controls and offers to show all visible requirements instead.

Use Add child draft on a suitable Draft or Active parent when the new question is subordinate rather than unrelated.
{% endstep %}

{% step %}

## Add a child draft in context

In the requirement tree, choose Add child draft on a Draft or Active row.

Focus moves to the labelled child-draft panel directly after that parent, where its type, status, priority, timing and owner remain visible.

Available child types are restricted by the selected parent. Confirm the inherited type and priority before entering a 3–200 character question; context is optional.

The new record starts as Draft with the parent's handling restrictions and the current workspace scope; the service rechecks current parent status, access and handling at save.

The quick action does not activate, satisfy or task collection.

Open the saved row to add its decision point, due date, gaps and other detail. Cancel discards only the unsaved browser fields.
{% endstep %}

{% step %}

## Write the requirement

Open the new requirement guide. Before entering details, check the workspace and Direction write prerequisite.

SIR and EEI require a visible Draft or Active parent; open it and choose Add information need. A selected parent must also remain Draft or Active, with all handling restrictions retained.

For a plain top-level requirement, enter a 3–200 character title and review the displayed type, priority, due date and full inherited handling.

Create basic draft then retains one Draft through the same service checks; its unavailable list names any question, authority or handling condition to correct.

Use Continue when you want to add decision context, gaps or handling changes before Review. Back changes only the draft, and Cancel returns without creating a record.

The shortcut is not shown for a child, watch proposal or geographic hand-off.

Review suggested workspace context rather than accepting it as a finding.
{% endstep %}

{% step %}

## Review, create and assign

Review the complete draft, then select Create requirement once. No intermediate step saves a partial requirement.

Check the confirmed version.

If a different owner is needed and you hold assignment authority, use Find eligible owner with the exact email, select the returned account, enter a rationale and Assign owner.

CORTEX queues the owner's dashboard notification and configured email; assignment grants no access and does not approve the work.
{% endstep %}

{% step %}

## Activate deliberately

On the current detail view, choose from the valid next states, resolve any prerequisite named beside the selector, record the reason and select Update status.

Activation needs a decision point; satisfaction needs every recorded information gap resolved.

A failed refresh keeps the last confirmed detail available when safe to retry, while lost or hidden access clears the protected requirement and its actions.

Add information need and Create collection plan are for eligible non-RFI requirements; RFIs use their addressed holdings workflow.
{% endstep %}

{% step %}

## Reassess the outcome

Review the actual evidence and remaining gaps before moving through InReview to Satisfied and Closed.

Satisfaction requires no outstanding gaps.

Reopen deliberately when circumstances change; editing or assigning during review returns the requirement to Active.
{% endstep %}
{% endstepper %}

## Check the result

* What decision will this answer support?
* Are gaps specific enough to guide collection or holdings review?
* Are kind, parent and complete handling correct before creation?
* Does the named owner currently have appropriate access?
* Does the requested state match actual work and evidence?

## If you get stuck

<details>

<summary>Why does the requirement tree look empty?</summary>

An unfiltered empty state describes only your current authorised view and does not prove that hidden records do not exist.

The New top-level requirement action appears beside the heading only with a valid selected workspace and Direction write authority; use it when the intended question is not already represented.

Search controls appear when requirements are visible or filters are active.

No requirements match these filters means records may exist outside the current search or status, so choose Show all top-level requirements.

If creation is unavailable, check the selected workspace and ask its Manager to verify Direction write authority.

</details>

<details>

<summary>Why is a status unavailable?</summary>

The detail page lists only valid next states for the current status. It names a missing decision point before activation and unresolved information gaps before satisfaction.

Complete the named prerequisite, reload the current version if another analyst changed it, and then record a meaningful transition reason.

The service checks the current version, access and prerequisites again when saving.

</details>

<details>

<summary>Why is a parent or owner unavailable?</summary>

A parent must satisfy hierarchy, state and access rules; an owner must be eligible for the full handling and workspace.

Check the intended record and exact email, then resolve legitimate access with the responsible Manager rather than choosing an unrelated substitute.

</details>

<details>

<summary>Why did my save conflict or my review return to Active?</summary>

Reload the current requirement and reconcile the newer changes.

Content or owner changes during review intentionally invalidate that review state; arrange a fresh review of the changed question.

</details>

<details>

<summary>Why can I read a legacy requirement but not edit it?</summary>

Missing retained history may require an explicit operator migration.

Ask the operator to follow the approved migration procedure; do not imply that missing historic text can be reconstructed.

</details>

## Responsibility and limits

* The owner judges relevance, priority and satisfaction; a workflow state does not supply command approval.
* Record a meaningful change reason and preserve earlier decisions instead of creating misleading duplicates to avoid history.

**Reference and scope:** JDP 2-00 (4th ed.), 1.7–1.12 and 3.1–3.9 inform direction and requirements. The state transitions and validation are CORTEX workflow policy.

## Related workflows

* [Address and answer an RFI from existing holdings](/workflow-guides/direction/rfi.md)
* [Plan collection and record observed results](/workflow-guides/collection/collection-plans.md)
* [Acknowledge the exact package and close the feedback loop](/workflow-guides/feedback/feedback.md)
