Purpose:

Even where the science is perfect, many solutions do not have the desired impact because:

  • Information arrives too late, or not at all
  • Messages are misinterpreted
  • Channels exclude key groups or intermediaries
  • Responsibilities at handoffs are unclear
  • Assumptions about use go untested

An information chain analysis (ICA) makes these challenges visible, specific, and fixable by tying information flow directly to decisions, behaviors, and outcomes.

An ICA is a tool used to examine how information and data from a solution moves through a system to support specific decisions. It is intended to capture where that flow can break down in ways that matter for solution design, outcomes, access, and impact. It is informed by stakeholder mapping and needs assessment and is integrated in solution design, testing, and validation.

An ICA breaks down a broad decision into decision-specific pathways, to trace how information is generated, transformed, packaged, transmitted, interpreted, and ultimately used. In aggregate, these pathways create a full picture for how information flows to inform decisions.

The goal is actionable insight. The ICA helps with identifying potential gaps where breakdowns in information flow prevent informed decisions, and what must change in design, packaging, dissemination, or engagement to fix them. This has the added benefit of increasing opportunities for impact.

The primary outputs of an ICA are 1.) a prioritized list of information-flow risks and 2.) design actions that must be addressed during co-design, delivery, and monitoring.

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 58

How and When to Use This Tool:

An ICA can be started during Phase 1 after stakeholder mapping and needs assessment are completed. During this phase, the ICA helps to sharpen understanding of stakeholder needs and constraints to help teams better understand practical limitations and opportunities for impact. However, consulting an ICA is useful throughout the lifecycle of a project, as outlined in the following table.

How and when
Lifecycle Moment What ICA Clarifies What It Informs
Stakeholder Mapping and Needs Assessment
Use once stakeholder insights and needs are available
  • How information currently moves from data to decisions
  • Where interpretation, timing, or access break down
  • Early risks, bottlenecks, and access gaps
  • Problem framing
  • Impact hypotheses
  • Early risk identification
Solution co-design
Use in translating needs into solution concepts
  • How EO products fit real decision workflows
  • Roles and responsibilities across information handoffs
  • Viable channels for dissemination and feedback
  • Technical design choices
  • Workflow and architecture decisions
Co-design & integration
Use for aligning technical, institutional, and partner inputs
  • Where information flow assumptions affect feasibility
  • Which failures matter most for decisions and outcomes
  • What trade-offs are required
  • Co-design priorities
  • Partnership and delivery planning
Development & early use
Use for building, piloting, or refining solutions
  • Whether information is usable in practice
  • Where design intent diverges from real use
  • Where additional support or adaptation is needed
  • System refinements
  • Adoption and sustainability strategies
Monitoring and Impact Assessment
Use for defining metrics or impact monitoring questions
  • Whether information reaches and is used by intended audiences
  • Which assumptions hold or fail in practice
  • How access and outcomes differ across groups
  • Results Framework assumptions
  • Solution implementation and impact metrics

Understanding Decision Pathways

An ICA focuses on decision-specific pathways rather than mapping entire information systems at once. Each ICA traces how information supports one decision, even if multiple sources or channels converge at that point. Over time, multiple ICAs can be layered to reveal the broader information system and recurring bottlenecks. If an analysis spans multiple decisions, it should be split to preserve clarity and actionability.

For each decision pathway, an ICA traces only the information that is necessary for one specific decision, following it step by step from source to action. At each step, the analysis asks:

  • Where does the information needed for this decision originate?
    (e.g., which EO datasets, models, reports, or observations are relied upon)
  • Who interprets or translates it—and how?
    (e.g., analysis, aggregation, contextualization, or judgment applied before it becomes decision-relevant)
  • How is it delivered to the decision-maker, and when?
    (e.g., format, channel, frequency, and timing relative to the decision window)
  • Who is expected to act on it, and under what constraints?
    (e.g., authority, incentives, capacity, institutional rules)

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 60

In an ICA, a decision pathway defines what is being analyzed: the sequence of information flows required to support one specific decision. Chain links define where analysis occurs within that pathway.

Each chain link represents a moment of transition along a decision pathway—a point at which information changes form, moves between actors, or crosses an institutional or technical boundary. An information chain often follows a sequence such as: EO product generation → analyst interpretation → advisory or alert formulation → channel transmission → decision-maker uptake.

Mapping a pathway as a series of chain links allows ICA to pinpoint exactly where information may be delayed, distorted, or lost as it moves toward a decision. By breaking the pathway into discrete links, the analysis clarifies who is responsible at each step and under what conditions information is handed off or transformed. This, in turn, makes it possible to distinguish whether failures arise from solution design, institutional capacity, incentives, timing constraints, or barriers to access, enabling targeted, corrective or preventative action.

Importantly, ICA does not assume that all links function equally well. A decision pathway may be technically sound overall but still fail because of one or two critical weak links. By making chain links explicit, ICA enables targeted design and delivery actions focused on the points where intervention will have the greatest impact.

How and when

Each box is a chain link in the decision-making process—a specific hand-off or transformation of the data that leads to the decision.
Fig. 1 Illustration of chain links constituting a decision pathway

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 61

Comprehensive Information Chain Analysis
Shared actors, channels, bottlenecks identified across ICAs over time
If an analysis spans multiple decisions, it should be split into multiple ICAs

Fig. 2 Visualization of how decisions based on decision pathways lead to a comprehensive information system

Information Channels and Target Audiences

Because ICA traces how information moves from data to decisions, it is essential to consider both who participates in information flows and how information is communicated along the decision pathway.

EO-derived information often changes form multiple times—from data to analysis, from analysis to alerts, and from alerts to action. Many failures occur not because EO data are inaccurate, but because information is misinterpreted, delayed, or transmitted through channels that users cannot access or do not trust.

Actors who produce, translate, transmit, or act on information include:

  • Technical and communications staff (science, data, IT, communications)
  • National, regional, and local government departments
  • Disaster management agencies and Emergency Operations Centers (EOCs)
  • NGOs, CSOs, and implementing partners
  • Extension services and field officers
  • Community leaders and representatives
  • End users and affected community members
  • Donors and coordinating bodies (where relevant)

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 62

Note that different actors may appear multiple times in the chain with different roles.

Common Channels for Sharing EO-Enabled Information

Broadcast and print

  • Radio, television, newspapers, public service announcements

Digital and mobile

  • Websites and dashboards
  • Email and data portals
  • Mobile apps
  • SMS, WhatsApp, and other messaging platforms

Institutional and operational

  • Briefings, situation reports, internal memos
  • Coordination meetings and command centers

Community-based and informal

  • Community boards and local announcements
  • Town meetings, markets, roadside signs
  • Trusted intermediaries (local leaders, extension workers)

Feedback and response channels

  • Hotlines, reporting apps, community meetings, forums
Key Considerations When Assessing Channels
  • Which stakeholders rely on which channels—and at what stage?
  • Where are bottlenecks, delays, or points of distortion?
  • Are channels one-way (broadcast) or two-way (interactive)?
  • Do accessibility, literacy, language, or connectivity constraints limit use?
  • Do users understand and trust the information?
  • Are informal channels complementing or substituting for formal ones?

ICA in Practice: Conducting an Information Chain Analysis

To conduct an ICA, follow the steps outlined in the instructions on this Excel ICA Worksheet

If you prefer to follow the written steps only, you can reference the step-by-step document.

STEP 1: Define and Anchor the ICA to a Decision

Purpose: Define a single, decision-anchored information pathway to prevent scope creep and analytic drift.

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 63

Define (before mapping):

  • Decision to be supported
  • Decision-maker (individual or body)
  • Decision timing
  • Intended beneficiary / end user
  • Information product(s) informing the decision
  • Consequence of failure if information is delayed, distorted, or missing
Rule: If more than one decision or endpoint is identified, split the analysis into multiple ICAs.
Example
  • Chain 1 Decision: Activate district flood preparedness measures
    • Decision-maker: District Disaster Management Committee
    • Timing: 24–72 hours before peak flooding
    • Information product: Flood forecast and alert bulletin
    • Consequence of failure: Delayed evacuation increases risk to life
  • Chain 2 Decision: Inform resilience planning efforts
    • Decision-maker: State Climate Resilience Office
    • Timing: Post-event
    • Information product: Flood expansive maps and socio-economic data layer
    • Consequence of failure: Repeated flood events
STEP 2: Map the Information Chain

Purpose: Create a shared, chronological map of how information moves and is interpreted from production to use.

Method

  • Break the pathway into chain links (C1, C2, C3…)
  • Each link represents a handoff, where information:
    • Moves to a new actor or authority, and/or
    • Is interpreted, translated, or acted upon, changing its meaning, level of instruction, or decision implication
  • Capture both:
    • The information received, and
    • The decision or interpretation applied at that step
  • Stop when information reaches the intended user with a clear, actionable instruction.

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 64

Clarification

Information chains do not only transmit data; they progressively convert signals (e.g., forecasts or alerts) into decisions and directives (e.g., prepare, evacuate, shelter). These interpretation points are often where failure or confusion occurs and must be explicitly mapped.

Example (Flood Evacuation Decision)
C1
National Meteorological Org → National DRM Input: Flood forecast data
Interpretation: Determine national alert level
C2
National DRM → District DRM Input: Alert level
Interpretation: Decide whether evacuation thresholds are met
C3
District DRM → Local NGO Input: Evacuation decision and guidance
Interpretation: Translate decision into local instructions and channels
C4
Local NGO → Households Input: Evacuation instruction
Interpretation: Households understand what action to take (evacuate vs. prepare)
STEP 3: Stress-Test Each Handoff

Purpose: Identify where the chain could potentially fail in practice.

For each step, examine:

  • What must go right
  • What actually happens
  • The type of breakdown (delay, capacity, access issue, lack of trust, distortion)
Issues must be tied to a specific handoff, not described generically.
Building on the flood evacuation example above:
  • C2: Alerts translated too slowly on weekends → Delay
  • C4: WhatsApp excludes elderly → Access barrier

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 65

STEP 4: Prioritize by Decision and Outcome Impact

Purpose: Filter issues to those that materially affect decisions and outcomes.

Prioritization criteria:

  • Impact on decision quality or timing
  • Impact on outcomes
  • Impact on equity or access

Output

A short list of high-impact issues that move forward.

Example
  • C4 access barrier affecting elderly households → High priority (prevents evacuation)
STEP 5: Identify Design, Delivery, and Engagement Actions

Purpose: Translate prioritized issues into actionable interventions.

For each priority issue, specify:

  • Intervention type (design, delivery, engagement)
  • Concrete action
  • Responsible actor
  • Implementation phase (co-design, pilot, deployment)
Rule: Every action must link to:
  • One chain link
  • One prioritized issue
Example
  • C2 delay → Delivery → Automate SMS alerts to district leads (National DRM)
  • C4 access barrier → Delivery → Add radio announcements targeting elderly households
  • C4 trust issue → Engagement → Train community leaders on key messages

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 66

STEP 6: Surface Assumptions and Risks

Purpose: Make implicit assumptions explicit and testable.

Assumptions should be extracted from earlier steps—not brainstormed from scratch—and paired with:

  • The risk (if false)
  • How the assumption will be monitored or tested

These assumptions inform results framework indicators and MEL questions.

Example
  • C3: Assumes district staff act on alerts immediately → Risk if false = no evacuation → Monitor via post-event staff meetings
  • C4: Assumes NGOs disseminate messages promptly → Risk if false = late info → Monitor via periodic, randomized checks

NASA Earth Action Solutions Co-Development Toolkit, v0.1 | 67