LaunchLens: Building an Explainable Release-Readiness Agent with FalkorDB
Most release checklists show open tasks, but not the dependency chains that delay a release. In this article, I explain how I built LaunchLens using FalkorDB to trace blockers, calculate downstream impact, and connect decisions to the work they influence.
LaunchLens: Seeing the Blast Radius Before You Ship
Building an explainable release-readiness agent with FalkorDB, Python, and Streamlit.
The problem: open tasks don't tell the whole story
Imagine that your team is preparing a software release.
The authentication service is still in progress. The sign-in interface depends on it. Integration tests depend on both the interface and a working test environment. Release approval requires successful integration tests and a completed security review.
A conventional task board can show which tickets are open. But understanding how those tickets affect one another requires more than reading a list.
Which unfinished task is holding up the release? If we finish one task today, what becomes possible? And which previous decision explains why a particular check is mandatory?
These questions inspired LaunchLens, a release-readiness agent I built for Graph Hacks 2026, organized by WeMakeDevs in collaboration with FalkorDB.
The central idea is to represent project work as a graph and let the application query those relationships to explain what should happen next.
What is LaunchLens?
LaunchLens helps software teams investigate three questions:
- Can we release?
- What is blocking us?
- What gets unblocked if we complete a particular task?
It also connects decisions to the tasks they affect, making project context easier to retrieve.
The demo uses a synthetic authentication-release workflow containing seven tasks and two decisions. This small example is enough to demonstrate multi-step dependencies, release blockers, downstream impact, and connected decision memory without loading private project information.
The hosted application uses Streamlit for its interface and FalkorDB Cloud for graph storage. The web application is hosted on Render, while the FalkorDB instance runs in the AWS Mumbai region (
ap-south-1 ). This is a Render-hosted application using a graph database hosted on AWS infrastructure, rather than a claim that the application itself is deployed on AWS services.Why use a graph database?
A graph represents entities as nodes and their connections as relationships.
LaunchLens uses three primary node types:
- Project represents the release project.
- Task represents an item of work, including its status, priority, owner, and due date.
- Decision represents recorded project context, such as a security policy or a release requirement.
The relationships are:
-
(Project)-[:HAS_TASK]->(Task)connects a project to its tasks.
-
(Task)-[:DEPENDS_ON]->(Task)connects a task to a prerequisite.
-
(Decision)-[:AFFECTS]->(Task)connects a decision to the work it influences.
The direction of
DEPENDS_ON is important. If task A depends on task B, the relationship points from A to B. Starting at a blocked task, the application can follow these edges upstream to find unfinished prerequisites.It can also traverse the same relationships in reverse to discover downstream work affected by a task.
FalkorDB is not simply used to display a graph. The application depends on its graph queries to determine readiness, find blockers, analyze impact, and retrieve related decisions.
How LaunchLens reasons about release readiness
1. Identify actionable work
The first query looks for active tasks whose direct prerequisites are all complete.
A simplified version of the Cypher query is:
MATCH (p:Project {id: $project_id})-[:HAS_TASK]->(t:Task)WHERE t.status IN ['todo', 'in_progress']OPTIONAL MATCH (t)-[:DEPENDS_ON]->(dep:Task)WITH t, collect(dep) AS depsWHERE all(dep IN deps WHERE dep.status = 'done')RETURN t.id, t.title, t.status, t.priority;This is a graph-based readiness rule, not a machine-learning prediction. The result depends on the current task statuses and dependency relationships stored in FalkorDB.
LaunchLens then prioritizes eligible tasks using their current status and priority, with downstream impact providing an additional signal.
2. Trace multi-step blockers
A release can be blocked by a task several relationships away.
LaunchLens uses variable-length path traversal to find unfinished prerequisites:
MATCH path = (t:Task {id: $task_id})-[:DEPENDS_ON*1..]->(dep:Task)WHERE dep.status <> 'done'RETURN dep.id, dep.title, dep.status, length(path) AS dependency_depth;The important part is
[:DEPENDS_ON*1..] . Instead of examining only immediate prerequisites, this pattern allows the query to traverse dependency chains of multiple edges.For example, a release-approval task can be affected by unfinished authentication work through the integration-test task, even when the release task does not depend directly on the authentication service.
3. Calculate the downstream impact
The most important interaction in the LaunchLens demo is:
"What gets unblocked if T2 is done?"
T2 represents the authentication service.
Completing it can affect both the sign-in interface and the authentication security review. Those tasks become eligible to start because their other prerequisites are already complete.
Integration testing and final release approval remain later in the chain because they depend on additional unfinished tasks.
LaunchLens distinguishes immediate readiness from eventual downstream impact. A task can be affected by the completion of another task without becoming ready immediately.
This distinction makes the result more useful than simply counting connected nodes.
The application traverses the graph in reverse, returns shortest dependency paths, and checks the downstream task's other prerequisites before labeling it immediately ready.
4. Retrieve decisions connected to the work
Dependencies explain what must happen first. Decisions explain why the team chose a particular approach.
LaunchLens stores decisions as nodes and connects them to affected tasks using
AFFECTS .For example, the synthetic project includes a decision requiring short-lived access tokens. The application can retrieve that decision and show its links to the related authentication tasks.
This gives the agent a way to recover context from the graph rather than treating every user question as an isolated conversation.
Turning the graph into an interactive application
LaunchLens is implemented with Python, Streamlit, and the FalkorDB Python client.
The main components are:
Streamlit interface: presents the release gate, task board, decision memory, and graph-evidence view.
Graph service: reads and updates task records,
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article