L1-01 · The Requirements Chain — PIR → Indicator → SIR

One-line idea: You cannot collect against a vague request. The requirements chain is the discipline that turns “go look into this” into a short list of specific, located, deadlined tasks a researcher or tool can actually execute — and that, when answered, demonstrably answer the client’s real question.

Learning objectives

Terminal: after this module the analyst can take a vague tasking and decompose it into a written collection plan — prioritised PIRs, observable indicators, taskable SIRs, each pinned to a where (NAI) and a when (LTIOV) — without skipping a link or starting from sources.
Enabling:
1. State, in plain language, what each link in the chain is for and how to tell a good one from a bad one.
2. Convert a single PIR into 2–4 indicators and each indicator into one or more taskable SIRs.
3. Recognise the five marks of a sound indicator and the most common ways the chain breaks.

Concept

From the F1 foundations (assumed, not required): you bring the habit of decomposing a fuzzy problem and holding a question open under uncertainty. This card gives that habit its first concrete machine — the chain that turns a vague request into tasks you can actually collect against.

Calibrate: A client says “our CEO is travelling to Riverton next month — are there threats we should worry about?” Before reading on, jot your first three moves. Hold them; §0 is about to use them against you.

0. Why this exists — the beginner’s trap

A client says: “Our CEO is travelling to Riverton for an investor summit next month. Are there any threats we should worry about?” The untrained reflex is to open a browser and start typing the CEO’s name. Three hours later you have 40 tabs, no way to know when you are “done”, and nothing that maps cleanly to the decision the client actually has to make (do we add a protective detail? change the hotel? alter the route?).

The professional move is to stop and engineer the question first. Every intelligence tradition — US Army doctrine, civilian law-enforcement strategic analysis, business intelligence — independently arrived at the same answer: decompose the request, top-down, into collectible atoms before you collect anything. That decomposition is the requirements chain. It is the single highest-leverage habit that separates an analyst from a person with a search bar.

The chain is question-directed, never source-directed. Decide what you must know first; only then ask which source can tell you. Starting from “what can this tool give me?” reverses the logic and builds your blind spots straight into the plan. [mcdowell Ch.13 — "the driving force is not the question-directed ICP, but one that is source driven"]

1. The chain, end to end

Each link is more concrete than the one before — you start with something too abstract to collect and end with something a junior researcher or an automated monitor can execute without guessing:

Link	In one phrase	Who uses it
Tasking	the vague client request	analyst ↔ client
PIR	the priority question the decision rests on	analyst / client
Indicator	what you’d see if the answer were “yes”	analyst (thinking tool)
SIR	the specific, assignable task	collector / researcher / tool
NAI + LTIOV	where to look, and when it stops mattering	collector
Collection plan	all of it, synchronised	the whole team

The rest of this card walks the links one at a time.

2. Tasking — the raw request

The tasking (also: RFI — request for information, or in McDowell’s world the Terms of Reference) is what the client hands you. It is almost always too broad, and that is normal — clarifying it is your job, not theirs. [mcdowell Ch.9 — the TOR "clearly identifies what is to be studied, for whom, and why"]
Before anything else, pin down three things: what decision the answer feeds, for whom, and by when. A tasking with no decision attached is a fishing trip — push back and find the decision.
Tradecraft note: in McDowell’s strategic model the tasking is negotiated into a written, agreed Terms of Reference with an Aim (one sentence: who + why) and a Scope (the key sub-issues). That TOR is the civilian ancestor of the military PIR list. [mcdowell Ch.9] — TOR mechanics are taught in L1-04.

3. PIR — the priority intelligence requirement

A PIR is a single, decision-driving question, written sharply enough that you could imagine an answer.

“An intelligence requirement, stated as a priority for intelligence support, that the commander and staff need to understand the adversary or other aspects of the operational environment.” [atp-2-01 §2-9 / glossary]
In OSINT terms: a PIR is the client’s real question, rewritten so it is answerable and tied to a decision. Replace “are there threats?” with “Are there individuals or groups with both the intent and the capability to harm the principal during the Riverton trip (12–14 Mar)?”

Q: Two candidate PIRs — “Assess the threat environment around the Riverton trip” vs “Are there individuals with both intent and capability to harm Reyes during 12–14 Mar?” One is collectible, one isn’t. Which, and what exactly makes the difference? Decide before you read the marks below.

Marks of a good PIR [atp-2-01 §2-12, §3-22]:
- Decision-linked — answering it changes what the client does.
- Specific — names the who/what/where/when; not a topic, a question.
- Answerable — you can picture evidence that would settle it (yes or no).
- Prioritised & few — doctrine insists you limit the number of PIRs so finite collection stays focused. Three sharp PIRs beat ten vague ones. [atp-2-01 §2-12]
- Bounded — in time and space (the trip window, the venue/route, the 30-day horizon).
Why it is “priority”: “Answering PIRs is mission-essential … failure to satisfy the PIRs endangers the command’s mission accomplishment.” [atp-2-01 §3-22] A PIR is not “nice to know” — it is the question the client’s decision rests on. Everything that is merely interesting is not a PIR.
(Writing PIRs well — the “so what” test, the intent/capability framing — gets its own card, L1-02.)

4. Indicator — the observable sign

An indicator answers: “If the answer to this PIR were YES, what would I actually SEE in the world?”

“An item of information which reflects the intention or capability of an adversary to adopt or reject a course of action.” [atp-2-01 §3-29, from JP 2-0]
Plainly: an indicator is an observable — a fact, event, or condition you could detect — that pushes a hypothesis toward true or false. “Indicators take on meaning only in the context of a specific scenario.” [sat §9.11]
Critical distinction — indicators are for analysts, not collectors. You do not hand a collector “the indicator list”; an indicator is a thinking tool that tells you what would count as evidence. You turn it into a task (the next link) before anyone collects. [atp-2-01 §3-30 — indicators are "typically not sent out as part of the information collection tasks"]

The five marks of a sound indicator [sat §9.11.2] — memorise these; they are how you weed a list:

Mark	Test	Pass / fail example
Observable & collectible	Can a reliable source actually see it, legally, repeatedly over time?	“protest permit filed” ✓ / “the organiser’s private intent” ✗
Valid	Does it actually measure the thing the PIR asks about?	“permit near the venue on trip dates” ✓ / “national protest statistics” ✗
Reliable	Tangibly defined, so two analysts would score it the same way?	“number of demonstrators” ✓ / “growing nervousness” ✗ `[sat §9.11.2]`
Stable	Useful over time, ideally visible early enough to act on?	“venue booking changes” ✓ / a sign that only appears the day-of ✗
Unique / diagnostic	Does it point at this answer and away from the alternatives?	the hardest and most valuable mark — see below

The first two are required of every indicator; the last three are “extremely important but cannot always be satisfied.” [sat §9.11.2]
Diagnosticity is the prize: “Valuable indicators are those that are consistent with a specified scenario or hypothesis and inconsistent with alternative scenarios or hypotheses.” [sat §9.11.2] An indicator that would be present no matter which scenario is true (a non-diagnostic indicator) tells you almost nothing on its own — though it may still earn its place inside a cluster. [sat §9.11.3]

(Generating, validating and scoring indicator lists is a full method of its own — L1-06. Here you only need to know what an indicator is and what a good one looks like.)

5. SIR — the specific information requirement

Q: Your indicator reads “a protest is being organised at the venue.” Hand it to a junior researcher exactly as written — what do they still have to guess? Name the missing pieces before reading on.

A SIR is an indicator turned into a task you could hand to a person or a tool with no further guessing.

“SIRs facilitate tasking by matching requirements to asset capability.” [atp-2-01 Fig 2-2 caption] They specify the information needed about specific activity, at a specific place, timed to the LTIOV. [atp-2-01 §4-18–4-20]
A well-formed SIR names four things:
1. What exactly to find (the precise data, not the topic).
2. Where to look — the NAI (next link).
3. By when — the LTIOV (the link after that).
4. Who/what can get it — matched to a real capability (a researcher, a database, a monitor).
Indicator vs SIR, said simply: the indicator is “a protest is being organised at the venue”; the SIR is “Search the Riverton city special-events permit portal for any permit within 1 km of the Grand Forum dated 12–14 Mar; report filer, stated purpose, and expected crowd size by 10 Mar.” One you watch for; the other you can assign.

6. NAI — where to look

An NAI (Named Area of Interest) is the specific place — or, for OSINT, the specific platform, account, feed, or node — where you expect the indicator to show up.

“The geospatial area or systems node or link against which information that will satisfy a specific information requirement can be collected, usually to capture indications of … courses of action.” [atp-2-01.3 §1-46, from JP 2-0]
The cleanest way to hold it: the NAI is the where to look; the indicator is the what to look for there. [atp-2-01.3 §6-67]
In military use an NAI is a patch of ground; in OSINT it is digital-or-physical and concrete: the Riverton permit portal, the Grand Forum’s Instagram geotag, a named local activist Telegram channel, the hotel’s Google-review stream, the r/Riverton subreddit, the arrivals concourse of RVT airport. Naming your NAIs before you collect is exactly what converts “open-ended scanning” into “focused monitoring.”
(NAIs come from the IPOE process and pair with the event template and event matrix*, where each NAI is cross-referenced to the indicators expected there [atp-2-01.3 §6-70]. That machinery is taught in the C-place and E-protective tracks; here you only need the “where to look” idea.)*

7. LTIOV — when it stops mattering

Q: The summit runs 12–14 Mar. What’s the latest your finished threat read is still worth anything — and is that the same as “the day before”? Commit to a date, then test it against the reverse-planning rule below.

The LTIOV (Latest Time Information Is Of Value) is the decision-linked deadline for the answer.

“The time by which an intelligence organization or staff must deliver information to the requester in order to provide decisionmakers with timely intelligence.” [atp-2-01 §1-15 / glossary]
It is not a due-date you pick for convenience. You reverse-plan it from the client’s decision point, leaving time for collection → processing → analysis → writing → and the decision itself. [atp-2-01 §3-23] For the Riverton trip, advance intelligence that arrives after the protective team has finalised the route and briefed the principal is worthless, however accurate — so the LTIOV is ~48–72 h before arrival, not “the day of travel.”
Every SIR carries its own LTIOV; the earliest one drives your schedule.

8. From chain to plan — synchronise it

The decomposed atoms get laid into a collection plan: McDowell’s ICP (a table of hypotheses → indicators → questions × sources) [mcdowell Fig 13.3], or the Army’s information collection synchronization matrix (assets × time, each cell an NAI/SIR being covered) [atp-2-01 §4-24, Fig 4-2]. Both are the same artifact: what gets collected, from where, by whom, by when.
When you assign assets, layer them deliberately — the collection strategy [atp-2-01 §4-13]:
- Cue — let a cheap/fast source trip a deeper dive (a keyword alert cues a manual investigation).
- Redundancy — put two independent researchers/sources on a high-stakes SIR so one miss isn’t fatal.
- Mix — answer a must-know PIR from different kinds of source (social + public record + news), which both raises confidence and guards against a single source being wrong or deceptive.
(Building the plan/ICP itself, and gap analysis, are L1-03 and L1-05 — this card stops at producing the decomposed atoms that feed them.)

Procedure — vague tasking → collection plan, step by step

Do these in order. Resist the urge to jump to a browser before Step 7.

Capture the tasking verbatim. Write down exactly what was asked, who asked, and what they will decide.
Find the decision. If you can’t name the decision the answer feeds, go back to the client. No decision → no PIR.
Set the horizon and the boundary. When is the decision? What’s in scope (who/where/what window)?
Draft PIRs. Rewrite the tasking as 2–4 sharp, answerable, prioritised questions. Cut anything merely interesting. Rank them.
For each PIR, brainstorm indicators. Ask “if the answer were yes, what would I see?” — and also the negative: “what would I see if it were no?” List liberally; think across dimensions (people, money, movement, online, physical).
Validate the indicators. Run each against the five marks (§4). Discard the ones that fail observable or valid; keep diagnostic ones; keep non-diagnostic ones only if they strengthen a cluster.
Turn each surviving indicator into one or more SIRs. Make each a concrete, assignable task: what / where (NAI) / by when (LTIOV) / by which capability. This is the first step that touches a source.
Set NAIs. Name the exact place/platform/feed where each SIR’s evidence would appear.
Set LTIOVs. Reverse-plan each from the decision point; surface the earliest one as your real deadline.
Lay it into a collection plan and assign assets with cue / redundancy / mix.
Trace it back up. For each PIR, confirm its SIRs—if answered—would actually settle it. If a PIR has no SIR that bears on it, you have a gap (→ L1-05). If a SIR serves no PIR, cut it.

Pre-mortem. Imagine you ran all eleven steps, handed over the plan, and it still failed — researchers chased noise and the real risk went unseen. What most likely went wrong, and at which step? (Usual culprits: a PIR that was a topic in disguise, indicators that weren’t diagnostic, or SIRs with no NAI/LTIOV so they never closed. Name your prime suspect before you trust the plan.)

Worked example — “Is the Riverton trip safe?”

Tasking (raw): “Our CEO, Jane Reyes, is travelling to Riverton for the investor summit, 12–14 Mar (28 days out). Are there threats we should worry about?” Decision it feeds: whether to add a protective detail, change the hotel, and how to plan the route. (This is the front end of OSINT-042 pre-travel-threat-assessment.)

Step 4 — PIRs (prioritised):

PIR 1. Are there individuals or groups with both intent and capability to harm Jane Reyes during the Riverton trip (12–14 Mar)?
PIR 2. Do any planned protests, civil disturbances, or events at or near the summit venue or her hotel coincide with her movements?
PIR 3. Has Jane’s itinerary, hotel, or schedule leaked into public/open channels?

Steps 5–9 — decompose PIR 2 (the other two decompose the same way):

Indicator (what we’d see if yes)	Diagnostic?	→ SIR (the task)	NAI (where)	LTIOV (when)
A protest permit filed near the venue on trip dates	high	Search Riverton special-events/protest permit portal for any permit ≤1 km of the Grand Forum, 12–14 Mar; capture filer, purpose, crowd estimate	city permit portal	8 Mar
Calls to mobilise at the venue/hotel on those dates	high	Monitor named local-activist channels + venue geotag for posts naming the Grand Forum / Jane’s hotel / the summit, 12–14 Mar	activist Telegram, IG/X venue geotag	rolling → 10 Mar
Prior protests/incidents at this venue or against this company	medium	Search local news archive (24 mo) for protests at the Grand Forum and actions targeting [Company]	local news archive	6 Mar
A labour action / activist campaign currently aimed at the company	medium	Check union/activist sites + recent filings for live campaigns against [Company]	sector/union sites	6 Mar

Step 11 — trace back up: if those four SIRs come back clean, PIR 2 is answered “no credible venue-proximate disturbance found” — a real, defensible analytic line, not “I googled and didn’t see anything.” If the permit SIR hits, PIR 2 escalates and immediately cues deeper collection on PIR 1 (who is organising, do they have a history of violence) — that is cueing in action.

Notice what the chain bought you: a bounded, finishable task list; an explicit deadline; named places to watch; and a built-in way to know when each question is answered. That is the whole point.

Practical exercise — the competency gate, not enrichment

Tasking: “A vendor we’re about to sign, Meridian Logistics, was just named in a news article about a fraud probe. The CFO needs to know by Friday whether to pause the contract. Look into them.”

Do this (≈60–90 min), producing a one-page collection plan:

Write the decision in one sentence and the LTIOV (reverse-planned from “by Friday”).
Draft 2–3 PIRs. (Hint: intent/capability doesn’t fit here — think exposure, corroboration, materiality.)
For your top PIR, list at least 4 indicators; mark each pass/fail on observable and valid.
Convert the surviving indicators into SIRs, each with an NAI and an LTIOV.
Tag where you’d apply cue / redundancy / mix.
Red-team your own plan. Write the strongest case a skeptical senior analyst would make that this plan misses the real risk or tasks busywork — then revise it in light of that critique. The revision is the deliverable; the first draft is only raw material.

Self-check rubric (you’ve got it when):

Every PIR names a decision and could be answered yes or no.
No PIR is really a topic; no “background research on Meridian” masquerading as a requirement.
Every indicator would be observable by an OSINT source and validly bears on its PIR.
Every SIR is a task you could paste into a ticket with no further questions — what/where/when/who.
Every SIR has a named NAI and an LTIOV; the earliest LTIOV ≤ your reverse-planned deadline.
You can trace each PIR down to ≥1 SIR and each SIR back up to exactly one PIR.

(This exercise is the front half of OSINT-001-style due diligence; you’ll finish the back half in the B-org applied track.)

Common errors

The pattern that ports to live casework is the diagnostic question — naming the bias doesn’t help an analyst at 0200; asking the question does.

Tell (what you’d observe)	Diagnostic question	Fix
Plan organised by tool, not question — “let me check Pipl / Sherlock…” before any PIR exists	”What decision does this search change — can I name the PIR it serves?”	Write the PIR first; pick the source only at the SIR step. `[mcdowell Ch.13]`
A “PIR” you can’t picture a yes/no answer to — “background on the subject,” “social-media presence"	"What evidence would settle this, yes or no?” — if nothing comes, it’s a topic	Force a decision and a verb — Are…? Did…? Will…?
Tasks read “look for anything concerning” — you jumped PIR → search	”What exactly would I SEE if the answer were yes?”	Name the observable (the indicator), then task that. `[atp-2-01 §3-29]`
”Growing tension,” “suspicious behaviour” — two analysts would score them differently	”Could two analysts independently score this the same way?”	Make it tangible and countable — “number of demonstrators,” “permit filed.” `[sat §9.11.2]`
A SIR that reads “monitor social media” — nowhere to look, no cutoff	”Where exactly, and by when does this stop mattering?”	Name the platform/feed (NAI) and the decision-linked LTIOV. `[atp-2-01 §4-18, §3-23]`
A must-know PIR answered off a single platform	”If this one source is wrong or gamed, does my judgment collapse?”	Design mix into the high-stakes SIRs. `[atp-2-01 §4-15]`

Figures

Mermaid drafts — redrawn from the cited source figures; verify against originals before publishing.

Fig L1-01·A — The requirements chain (after ATP 2-01 Fig 2-2 + Fig 2-3)

flowchart TD
    T["TASKING / RFI<br/><i>vague client request</i>"] --> CCIR["Decision need<br/>(CCIR)"]
    CCIR --> PIR["<b>PIR</b><br/>priority question<br/>the decision rests on"]
    CCIR -. "friendly-force side<br/>(do WE have the capacity?)" .-> FFIR["FFIR"]
    PIR --> I1["<b>Indicator</b><br/><i>what we'd see if YES</i>"]
    PIR --> I2["<b>Indicator</b>"]
    PIR --> I3["<b>Indicator</b>"]
    I1 --> S1["<b>SIR</b><br/><i>the specific task</i>"]
    I2 --> S2["<b>SIR</b>"]
    I3 --> S3["<b>SIR</b>"]
    S1 --> A["📍 NAI = where to look<br/>⏱ LTIOV = when it stops mattering"]
    S2 --> A
    S3 --> A
    A --> PLAN["Collection plan<br/>(ICP / sync matrix)"]

Fig L1-01·B — Same chain as a decomposition ladder (after McDowell Fig 12.2 indicator pyramid)

flowchart TD
    L1["TASKING / proposition  —  most abstract"]:::a
    L2["PIRs  (key issues)"]:::b
    L3["Indicators  (what we'd see)"]:::c
    L4["SIRs  (the specific collection tasks)"]:::d
    L5["NAI + LTIOV  —  most concrete, ready to collect"]:::e
    L1 --> L2 --> L3 --> L4 --> L5
    classDef a fill:#1f2937,color:#fff;
    classDef b fill:#374151,color:#fff;
    classDef c fill:#4b5563,color:#fff;
    classDef d fill:#6b7280,color:#fff;
    classDef e fill:#9ca3af,color:#000;

Fig L1-01·C — Worked example, PIR 2 decomposed (the Riverton case)

flowchart LR
    P["PIR 2<br/>Protest/disturbance at<br/>or near venue during trip?"]
    P --> I1["Indicator:<br/>permit filed near venue"]
    P --> I2["Indicator:<br/>online calls to mobilise"]
    P --> I3["Indicator:<br/>prior protests at venue"]
    I1 --> S1["SIR: search city permit portal<br/>≤1km, 12–14 Mar"]
    I2 --> S2["SIR: monitor activist channels<br/>+ venue geotag"]
    I3 --> S3["SIR: news archive 24mo,<br/>venue + company"]
    S1 --> N1["NAI: permit portal · LTIOV 8 Mar"]
    S2 --> N2["NAI: Telegram/IG geotag · LTIOV 10 Mar"]
    S3 --> N3["NAI: local news archive · LTIOV 6 Mar"]

Doctrinal notes / variants

NAI is, strictly, an IPOE product (ATP 2-01.3), not originally a requirements-shelf term. It is introduced here because every SIR needs a “where,” but its full machinery (event template, event matrix, NAI↔indicator cross-referencing) is taught in C-place / E-protective. [atp-2-01.3 §6-65–6-70]
Indicator types (anticipatory vs descriptive/diagnostic; signpost vs marker) are deferred to L1-06. This card needs only the single idea: an indicator is an observable, and a good one is diagnostic. [sat §9.11.1]
Clark’s contribution — strategies-to-task decomposition and the gap concept (a missing element in the target model) — is the same top-down logic from the analyst’s side; it powers gap analysis in L1-05. [clark Ch.2, Ch.8]

Adversarial questions

Red-team prompts a senior analyst would push on your requirements package — and the operator’s review bank.

Point to a PIR in your set that’s actually a topic wearing a question mark. If you can’t, prove it: what’s the yes/no?
Which of your indicators would show up whether or not the threat is real? Why is it still on the list — cluster value, or padding?
Defend your earliest LTIOV against “why not just collect until the day before the trip?”
Your SIRs came back clean. Is that “no credible threat” or “wrong NAIs” — and how would you tell the difference?
A source-first analyst reached the same answer faster by just running tools. What did the chain buy that their scan didn’t?
Name the single SIR whose false-negative would sink the whole assessment. Where is your redundancy on it?

Links

Prerequisite cards: none (entry point to L1).
Leads into: L1-02 (writing good PIRs / the “so what”) · L1-03 (the collection plan / ICP) · L1-05 (gap analysis & collection strategy) · L1-06 (indicators: generate / validate / evaluate).
Composed by applied tracks: A · B · C · D · E · F · G — every track opens by setting requirements with this chain.
Deliverable(s) this maps to (examples):
- /home/farseer/Projects/osint-cell-dev/deliverables/reports/OSINT-042-pre-travel-threat-assessment.md (worked example)
- /home/farseer/Projects/osint-cell-dev/deliverables/profiles/OSINT-001-standard-subject-dossier.md (exercise)
- /home/farseer/Projects/osint-cell-dev/deliverables/reports/OSINT-029-intelligence-estimate.md (capstone)
Collection map(s):
- /home/farseer/Projects/osint-cell-dev/collections/reports/OSINT-042-pre-travel-threat-assessment-collection.md
- /home/farseer/Projects/osint-cell-dev/collections/profiles/OSINT-001-standard-subject-dossier-collection.md
- The 00 · Collection Plan branch in every collection map is this chain, instantiated.

Provenance (ICD 206)

Claim / element	Source	Location
PIR definition (priority intelligence requirement)	atp-2-01	§2-9; glossary p. 2664
”Answering PIRs is mission-essential … failure … endangers the command’s mission”	atp-2-01	§3-22
Limit the number of PIRs; refine into specific questions	atp-2-01	§2-12, §3-22
CCIR → PIR (intel) + FFIR (friendly) structure	atp-2-01	§2-11–2-13; Fig 2-3
Indicator definition (item of info reflecting intent/capability)	atp-2-01 (from JP 2-0)	§3-29; glossary
Indicators are analyst tools, not collection tasks	atp-2-01	§3-30
PIR → indicator → SIR refinement chain	atp-2-01	§2-9, §3-27–3-30, §4-18–4-20; Fig 2-2
SIR definition (specify info / place / time; match to asset capability)	atp-2-01	§4-18–4-20
”SIRs facilitate tasking by matching requirements to asset capability”	atp-2-01	Fig 2-2 caption
LTIOV definition; reverse-plan from the decision point	atp-2-01	§1-15, §3-23–3-26; glossary
Collection strategy — cue / redundancy / mix	atp-2-01	§4-13–4-17
Information collection synchronization matrix (assets × time)	atp-2-01	§4-24–4-27; Fig 4-2
Five marks of a sound indicator (observable & collectible, valid, reliable, stable, unique)	sat	§9.11.2
First two marks required; diagnosticity is the prize	sat	§9.11.2
”Growing nervousness” fails reliability; “number of demonstrators” passes	sat	§9.11.2
Diagnostic = consistent with one scenario, inconsistent with alternatives	sat	§9.11.2
Non-diagnostic indicators may still earn a place in a cluster	sat	§9.11.3
STEMPLES+ to generate indicators across dimensions	sat	§9.11.1
Indicators take meaning only within a scenario	sat	§9.11
NAI definition; “where to look” for a SIR	atp-2-01.3 (from JP 2-0)	§1-46; glossary
NAI = where to look / indicator = what to look for there; event matrix cross-ref	atp-2-01.3	§6-67, §6-70; Fig 6-13
Question-directed vs source-directed collection	mcdowell	Ch.13
Terms of Reference — Aim + Scope; what/for whom/why	mcdowell	Ch.9
Decomposition pyramid (proposition → key issues → question sets → detailed questions)	mcdowell	Ch.12; Fig 12.2
ICP structure (hypotheses × indicators × questions × sources)	mcdowell	Ch.13; Fig 13.3
Strategies-to-task decomposition (top-down, analyst side)	clark	Ch.2
Gap = missing element in the target model (feeds L1-05)	clark	Ch.8

Next: L1-02

OSINT Analyst Course

Explorer

The requirements chain — PIR → indicator → SIR