Every company has a version of this story. Someone decides to sunset an old API. Engineering ships the plan. Three weeks later Legal finds out a customer contract promises that API until next summer, Support learns about it from an angry ticket, and nobody can say who was actually told.
The change itself was never the hard part. Knowing who it hits, and whether they heard, was.
So for the WeMakeDevs x FalkorDB Graph Hacks I built Ripple: you ask it what a change touches, and it answers from a graph, with the receipts.
Live: https://ripple.vaibhav.quest · Code: https://github.com/Vaibhav91one/ripple
The idea: "not told" is a missing edge
Ripple keeps decisions, systems, customers, deals, contracts and teams in one FalkorDB graph. Telling a team is just an edge (INVOLVED_IN, ACKED). That turns the scary question, who doesn't know yet?, into something a database can answer: find the teams the change reaches that have no "told" edge.
In the demo company, Ledgerly is sunsetting API v1. One question gives back:
- 40 customers and about $180K of ARR still on v1
- two signed contracts that guarantee v1 past the sunset date, with both quotes side by side
- three teams (Legal, Security, DevRel) that were never told
Every claim links to the artifact it came from and shows the Cypher it ran. If the graph has no path, Ripple says so instead of guessing.
The name comes from this. Drop one stone in a ripple tank and the waves reach every corner, crossing each other on the way. A company change behaves the same: one decision travels through systems, customers, contracts and teams. Ripple just draws where each wave lands.
Why a graph, and not five API calls
The impact query walks Decision -SUNSETS-> System <-DEPENDS_ON*0..2- and then fans out to tickets, deals, contracts, customers and the teams that own them. In SQL that's a pile of joins you write once per question. In FalkorDB it's one traversal that runs in a few milliseconds, which is fast enough to do on every single question.
Two details that made it trustworthy:
-
Every edge has
valid_from/valid_toand a verbatim source quote. Moving a sunset date ends the old edge instead of overwriting it, so history stays. - The model never writes Cypher. Agents call a fixed set of query tools. If an answer cites something no query returned, it's rejected.
Agents that propose, people that approve
Specialist agents (impact, contracts, security, docs, access and a few more) watch for changes and draft the follow-ups: a notice to Legal, a customer email, a docs fix. Nothing runs on its own. A person approves, then it executes, and the case file records it.
Where it shows up
You don't have to open the app. Ripple speaks MCP, so it works from Claude Code (/plugin install ripple), Claude Desktop, Codex and Cursor. It also answers when you @mention it in Slack or on a GitHub issue, and it adds a "Ripple impact" check to pull requests.
What I learned
- Modelling "telling someone" as data was the unlock. Once it's an edge, missing it is a query.
- Temporal edges cost almost nothing to add and save you from a lot of "but what did it say last week?"
- Keeping the model on rails (fixed tools, citation checks) mattered more than prompt tricks.
Ripple is open source and self-hostable with one docker compose up. I'd love feedback, especially from anyone who's been on the wrong end of a change nobody announced.
Top comments (0)