Recommendation Framework

Intelligence analysts walk a razor-thin line between informing decisions and making them. This lesson covers when recommendations are appropriate, how to structure them using the SMART framework, and how to present options without overstepping the analyst-policymaker boundary. You will learn to link your analysis directly to action, stress-test your recommendations for feasibility, and navigate the delicate politics of advising people who outrank you by several pay grades.

Before you start drafting recommendations, ask yourself a fundamental question: should you even be making recommendations at all? The answer depends on your role, your organization's culture, and the specific product you are writing.

When Recommendations Are Appropriate

• You were explicitly asked. A policymaker or commander has requested courses of action. This is the clearest green light you will ever get.

• Your product type calls for it. Threat assessments, vulnerability analyses, and risk reports often include mitigation recommendations by convention.

• Operational context demands it. In tactical and law enforcement intelligence, recommendations for immediate action (surveillance, interdiction, etc.) are expected and sometimes legally required.

When to Stay in Your Lane

• Strategic national assessments. Products like the National Intelligence Estimate traditionally present analysis without policy prescriptions. The IC informs; the NSC decides.

• When you lack operational context. If you do not understand the decision-maker's constraints, resources, or political environment, your recommendation may be worse than none at all.

• When it would compromise objectivity. If recommending action X would make your future analysis on topic X appear biased, think twice.

The fastest way to end your intelligence career: include "the President should probably just call them and apologize" in a finished intelligence product.

When in doubt, frame your analysis in terms of implications rather than recommendations. "This trend suggests that current border security measures may be insufficient" communicates urgency without prescribing a specific policy response.

When recommendations are appropriate, vague advice is worse than no advice. "The government should do something about cyber threats" is not a recommendation -- it is a bumper sticker. The SMART framework ensures your recommendations are actually useful.

Breaking Down SMART

• Specific: What exactly should be done? Name the action, the actor, and the target. "The Cyber Division should deploy endpoint monitoring on all contractor workstations" beats "improve cybersecurity."

• Measurable: How will success be determined? Include metrics or observable indicators. "Reduce average incident response time from 72 hours to 24 hours" gives the decision-maker a benchmark.

• Achievable: Is this within the decision-maker's authority and resources? Recommending a $500 million program to a branch chief with a $2 million discretionary budget is not helpful.

• Relevant: Does the recommendation flow directly from your analysis? Every recommendation must trace back to a specific finding. If you cannot draw a straight line from evidence to recommendation, delete it.

• Time-bound: When should this happen? "Within 90 days" is actionable. "Soon" is not.

Before and After

Before (vague):

"The agency should enhance its collection posture regarding the target network."

After (SMART):

"The SIGINT Division should task two additional collection platforms against Network Alpha's C2 infrastructure within 30 days, with the goal of identifying at least three new nodes by the end of Q2. This directly addresses the gap identified in Finding 3, where current collection covers only 40% of known C2 channels."

"We recommend continued monitoring" is the intelligence equivalent of "thoughts and prayers." It technically counts as a recommendation, but nobody's life was ever changed by it.

The most common failure in intelligence recommendations is the **analytic gap** -- the disconnect between what the evidence shows and what the analyst recommends. Your reader should never have to wonder, "Where did that recommendation come from?"

The Evidence Chain

Think of your recommendation as the final link in a chain: Raw Data → Key Finding → Analytic Judgment → Implication → Recommendation.{" "} If any link is missing, the chain breaks and your recommendation looks like opinion dressed up in fancy formatting.

Options vs. Single Recommendations

Senior decision-makers often prefer options over a single recommendation. Presenting two to three courses of action with trade-offs respects their authority and gives them genuine choices. Structure each option with:

• Description: What the option entails.
• Advantages: Why this option addresses the problem.
• Risks: What could go wrong or what trade-offs are involved.
• Resource requirements: Cost, personnel, time.

You may indicate which option the analysis best supports, but be transparent about doing so. Label it clearly: "Based on the analysis presented, Option B most directly addresses the identified threat."

When presenting multiple options, always include a **"status quo" option** that describes what happens if no action is taken. This gives decision-makers a baseline to compare against and often makes the case for action more compelling than any recommendation could on its own.

Before you finalize any recommendation, run it through the **feasibility test** -- a mental checklist that separates actionable advice from fantasy.

The Five-Question Feasibility Test

• Authority: Does the decision-maker have the power to implement this?

• Resources: Are the necessary budget, personnel, and technology available or obtainable?

• Timeline: Can this be done within the relevant decision window?

• Political viability: Will this survive scrutiny from stakeholders, oversight bodies, and the media?

• Second-order effects: Have you considered unintended consequences?

Navigating the Relationship

The analyst-policymaker relationship is one of the most important and most fraught dynamics in intelligence. A few principles will keep you out of trouble:

• Inform, do not advocate. Your job is to illuminate choices, not to lobby for a preferred outcome. The moment you become an advocate, you lose your credibility as an objective analyst.

• Know your audience. A military commander expects direct, actionable recommendations. A cabinet secretary may prefer implications and options. Tailor your approach to the consumer.

• Accept that they may ignore you. Policymakers have information, pressures, and priorities that you do not see. A rejected recommendation is not a personal failure -- it is the system working as designed.

• Never say "I told you so." Even when you were right. Especially when you were right.

The ideal analyst-policymaker relationship is like a good GPS: you provide the best route, they decide whether to take it, and when they ignore you and drive into a lake, you calmly say "recalculating."

What Makes a Good Recommendation?

Intelligence recommendations are analytical judgements that go beyond assessment to suggest specific actions. A well-constructed recommendation is specific, actionable, grounded in evidence, and sensitive to the consumer's decision-making context:

• Specific, Not Generic: "Improve collection against the target" is not a useful recommendation. "Task a satellite over Location X within the next 48 hours to confirm the presence of identified equipment" is a useful recommendation. Specificity enables action.
• Actionable by the Consumer: A recommendation must be directed at a consumer who has the authority to implement it. Recommending a policy change to an intelligence analyst who cannot change policy is futile. Recommending a shift in collection priorities to a collection manager who controls those priorities is actionable.
• Grounded in the Assessment: Recommendations should follow logically from the analytical assessment. A recommendation that is not supported by the preceding analysis appears arbitrary and reduces confidence in the overall product.
• Timed and Prioritised: Recommendations should indicate when action is needed and how the consumer should prioritise among multiple recommendations. "Recommendation 1 (Priority): Confirm target location within 24 hours. Recommendation 2 (Routine): Develop additional sources on the target's support network."

The Recommendation Structure

Effective recommendations follow a consistent structure:

1. Action Verb: Begin with a clear action verb - Task, Deploy, Monitor, Engage, Report, Prepare, Authorise. The action verb tells the consumer what you want them to do.
2. Target of Action: Specify who or what the action should be directed toward. Monitor "the identified communication node" rather than monitoring "suspicious activity."
3. Rationale: Briefly explain why this action is recommended. The rationale connects the recommendation to the analytical assessment. "Task satellite imagery of Location X because the assessment identifies it as the most likely storage site for the identified equipment."
4. Timeline: Indicate when the action should be taken. "Within 48 hours," "Before the next steering committee meeting," "At the first indication of movement."
5. Expected Outcome: Describe what the recommended action is expected to achieve. "This will confirm the equipment's presence and location, enabling follow-on collection or action."

Common Recommendation Mistakes

Even experienced analysts make predictable errors when formulating recommendations:

• The False Precision Trap: Recommending actions with a degree of precision that the intelligence cannot support. "Deploy assets to Grid 123456" is only useful if the intelligence is precise enough to warrant that specific targeting. Recommending at a higher level of precision than the intelligence supports is counterproductive.
• The "More Collection" Default: The most common intelligence recommendation is "collect more information." While sometimes appropriate, this recommendation should be reserved for cases where additional collection would genuinely change the analytical picture. Recommending more collection when the existing evidence is sufficient delays decision-making unnecessarily.
• Ignoring Consumer Constraints: Recommendations that are technically sound but practically impossible - requiring resources the consumer does not have, timelines the consumer cannot meet, or authorities the consumer does not possess - frustrate consumers and undermine the analyst's credibility.
• The False Choice: Presenting only two options when more exist. "Either authorise direct action or accept the threat" presents a false choice that ignores intermediate options like enhanced monitoring, passive collection, or diplomatic engagement.

Integrating Recommendations into Reports

Recommendations should be integrated into the intelligence report structure, not appended as an afterthought:

• Placement: Recommendations appear after the key judgement and supporting evidence, as the logical conclusion of the analytical argument. They should not precede the evidence that supports them.
• Prioritisation: When multiple recommendations are offered, they should be prioritised. The consumer should know which action is most important and which can be deferred.
• Explicit Connection: Each recommendation should be explicitly connected to the preceding analysis. "Based on the assessment that [key judgement], we recommend [specific action]."
• Separate Recommendations from Findings: Avoid the common error of embedding recommendations within analytical findings. "The target is likely at Location X, and we should task imagery" confuses assessment with recommendation. Keep them structurally separate.