WhatIf Graph: Using FalkorDB to Understand the Impact of Decisions Before They Happen

By Tanya Garg | Graph Hacks 2026 | WeMakeDevs × FalkorDB

What if a critical service went down right before a product launch? What if a team lost access to an essential resource? What if one delayed task affected an entire project?

In interconnected systems, a single change can trigger a chain reaction. Understanding these dependencies before making a decision can help teams reduce risk, prioritize actions, and make better decisions.

That is the idea behind WhatIf Graph — a graph-powered decision simulator built around FalkorDB.

The goal is simple: help users explore hypothetical scenarios, understand potential downstream impacts, and discover the relationships behind each result.

The Problem: Decisions Don't Exist in Isolation

Modern applications, businesses, and projects depend on interconnected components.

A payment service may depend on an authentication service. A release may depend on several tasks being completed. A team may depend on a shared resource.

When one component changes, the consequences can spread across multiple connected components.

Traditional dashboards often show individual metrics, logs, or status indicators. However, understanding why something is affected and which connected components may be impacted requires reasoning across relationships.

This is where graph databases become valuable.

Instead of treating every component as an isolated record, a graph represents entities as nodes and their dependencies as relationships.

That makes it possible to explore how a change could propagate through a connected system.

Introducing WhatIf Graph

WhatIf Graph explores how graph-based reasoning can support hypothetical decision-making.

The system represents components such as services, teams, resources, and tasks as connected entities. When a user proposes a scenario, the application can use graph relationships to investigate potential consequences.

For example:

What happens if the Payment Service goes down?

A useful answer should go beyond a simple statement that the service is unavailable. It should identify connected components, show the dependency paths that support the analysis, and help the user understand which areas may require attention.

The key principle is evidence before explanation: graph relationships should establish the potential impact, while an AI model can help explain the findings in natural language.

Why FalkorDB?

FalkorDB is a graph database designed to work with connected data and graph queries.

For WhatIf Graph, the graph model is important because the problem itself is about relationships: which component depends on another, how dependencies connect, and where a change could have downstream effects.

A graph database allows us to represent those connections directly and query them without manually assembling every possible dependency chain.

The project explores three core ideas:

  • Connected data: Model system components and their dependencies as a graph.
  • Multi-hop reasoning: Traverse relationships beyond immediate neighbors to investigate potential downstream effects.
  • Explainability: Connect impact findings to the graph paths that support them.

Instead of asking an AI model to guess which components are affected, the application should first retrieve relevant evidence from the graph.

How the System Works

The proposed workflow follows a straightforward pipeline.

1. Model the system

Represent the relevant entities as nodes and their dependencies as relationships.

For example, a payment service might depend on an authentication service, while an order-processing service depends on payments.

2. Receive a hypothetical scenario

The user enters a question such as:

What could be affected if the Authentication Service becomes unavailable?

The scenario describes a hypothetical change, not a real production action.

3. Query connected relationships

Use Cypher queries to retrieve relevant dependencies and traverse the graph. The traversal depth should be controlled so the result stays useful and understandable.

4. Identify potential impact

Analyze the returned paths to determine which connected components may be affected under the modeled assumptions.

A direct dependency and a multi-hop dependency should not automatically be treated as equally severe. Impact depends on the relationship type, direction, and assumptions encoded in the model.

5. Explain the result

Present the affected components, evidence paths, assumptions, and possible mitigation steps in a readable report.

An AI-generated explanation should remain grounded in the retrieved graph data. If the graph does not contain enough information, the system should say so instead of inventing a dependency.

A Simple Cypher Example

Suppose the graph contains directed relationships in which a service points to the components that depend on it. A hypothetical query can traverse outgoing dependency edges to discover downstream components.

For example, if your actual graph uses the relationship type DEPENDS_ON and the starting service has a unique name property, a query could look like this:

MATCH path = (source:Service {name: $service_name}) -[:DEPENDS_ON*1..5]-> (affected) RETURN path LIMIT 100;

Here, $service_name is a parameter supplied by the application, and 1..5 limits the traversal to between one and five relationship hops.

Important: This example assumes that the relationship direction is source service → dependent component. If your schema stores dependencies in the opposite direction, reverse the traversal accordingly. Adjust labels and relationship names to match your actual graph schema.

The query is an illustrative starting point, not a guarantee that every returned node will experience an outage. Real impact analysis needs to consider dependency semantics, optional relationships, redundancy, and other domain-specific rules.

Protecting the Baseline Graph

One important design consideration is that a hypothetical scenario should not accidentally alter the baseline system model.

If a user asks what would happen if a service went down, the application should analyze that hypothetical state without permanently changing the original dependency graph.

A safer approach is to keep the baseline graph read-only during simulation and represent hypothetical changes separately. The application can then compare the baseline results with the scenario results.

This separation helps preserve repeatability and makes it easier to explain what changed between the two analyses.

The exact implementation should be verified in the running application: a read-only query alone does not simulate every kind of state change, so more complex scenarios may require a separate scenario model or temporary in-memory representation.

What Makes This Approach Useful?

WhatIf Graph explores several practical benefits of graph-powered scenario analysis:

  • Dependency visibility: Understand how components connect instead of looking at isolated records.
  • Multi-hop investigation: Examine potential effects that extend beyond direct dependencies.
  • Evidence-based explanations: Trace findings back to the relationships that support them.
  • Safer experimentation: Explore hypothetical changes without unintentionally modifying the baseline graph.
  • More informed decisions: Use the identified dependencies and assumptions to guide further investigation.

The quality of the result still depends on the completeness and accuracy of the underlying graph. A missing relationship can produce a missing impact, and a modeled dependency does not always imply a guaranteed failure.

That is why transparency about assumptions and limitations is essential.

Challenges and Learnings

Building a graph-powered simulator involves more than connecting an application to a database.

The graph schema must represent dependencies clearly. Traversal must follow the correct relationship direction. Hypothetical scenarios must be separated from the baseline state. Finally, any AI-generated explanation must stay consistent with the evidence returned by the graph.

These considerations shaped the design of WhatIf Graph and highlighted an important lesson: AI becomes more useful when it can explain evidence from structured data rather than relying on unsupported guesses.

What's Next?

There is room to extend this approach with:

  • Scenario comparison across multiple hypothetical changes.
  • Confidence indicators based on graph completeness and evidence quality.
  • Dependency criticality and risk scoring.
  • Better visual highlighting of multi-hop impact paths.
  • Audit trails showing which graph evidence supported each explanation.
  • More robust testing for large graphs and complex dependency structures.

These are potential next steps, not claims about features that are already implemented.

Conclusion

WhatIf Graph explores a practical question: can we understand the potential consequences of a decision before making it?

By combining connected data, graph traversal, and evidence-grounded explanations, the project demonstrates how FalkorDB can support a more transparent approach to hypothetical impact analysis.

The broader idea is simple: before changing a connected system, understand what that change could affect — and be able to explain why.

Built for Graph Hacks 2026 by WeMakeDevs × FalkorDB.

Explore the Project

If you are building with graph databases, AI agents, or connected-data applications, I would love to hear how you approach dependency analysis and explainability.