Ripple

Ripple shows what a Jira change touches before it ships: a ranked risk score, affected services, teams to notify, stale Confluence pages and decisions it contradicts. No LLM, fully explainable.

Comment

Inspiration

The people who need to know about a change are rarely the people reviewing it. Move rounding into a shared currency function and three other teams are affected, a runbook now describes old behaviour, and an accepted architecture decision has been quietly reversed. That knowledge lives in call graphs in people's heads, Confluence pages and a decision log. Nobody reads all three before approving a pull request.

What it does

Ripple adds a panel to every Jira issue. It reads the structure a team already keeps in Confluence (a Service map, decision pages, fact tables) and shows, before the change ships:

  • a High, Medium or Low risk verdict with a score and ranked reasons (for example, "Goes against an accepted decision (+40)");
  • the affected services and the call path that reaches them;
  • which teams to notify, split into action needed and for information;
  • which Confluence pages now say something different from the change;
  • which accepted decision the change contradicts, with the conflicting claims side by side;
  • open incidents on the same path;
  • suggested tasks that stay unticked until a person approves them.

A "Ripple releases" project tab does the same for a version: Go or No-Go with ranked blockers and a release-notes task. For a judge's site, an administrator can load a complete sample workspace (53 issues, 12 components, 3 versions, 34 Confluence pages) from Jira settings, with a preview before any write, Cancel and Retry, and a Remove that deletes only what it created.

How we built it

Ripple is a Forge app (Custom UI, React) with a jira:issuePanel, a jira:projectPage and a jira:adminPage, plus a queue consumer for the loader. It declares nine scopes and no external network access.

The engine is deterministic: graph traversal over the call and data-flow tables, a fixed sum of weighted risk factors, and claim comparison (subject, property, value). Every list has a canonical order, so the same data always produces the same brief. Every verdict has to be explainable ("+40 because it contradicts DEC-007") and repeatable for a reviewer, so there is no language model in the product. That is a design decision, and issue text can't inject instructions into something that never reads it. Ripple reads tables and structured fields only. A test with an instruction-filled issue asserts the brief has no tasks and nothing is written.

The same engine serves both modes. Sample mode runs on built-in fixtures, and Live mode reads the site. A contract test proves the Live briefs for three scenarios equal the expected briefs, including on a workspace the loader itself created. 143 tests run with no network, login or secrets.

Every write (tasks, effects, load, remove) needs a click and a confirmation that lists exactly what will change. Task creation runs as the person who clicks, so Jira enforces their permissions, and a second click creates nothing new.

Challenges we ran into

  • Cross-product access. A Jira-installed app can't read Confluence unless it's installed in both. We used multiple-app compatibility (Jira required, Confluence optional) and verified it on a real site.
  • A loader that fits Forge limits. Load runs as queued chunks with resumable progress. Cancel then Retry produced exactly the same 102 items as an uninterrupted run, and Remove restored the project and space.
  • Honest live data. Jira's development information isn't readable from a Forge app, so Live mode shows pull requests as clearly badged sample data rather than pretending.
  • Untrusted text everywhere. Page and issue text never reaches a brief, URLs are built only from validated keys and IDs, and unexpected input produces a warning, not a failure.

Accomplishments that we're proud of

  • A High-risk verdict on a one-line change that traces to a contradicted decision, two stale pages and three teams, with every reason traceable.
  • A negative control: a change to a service nobody depends on gets Low risk and "Nothing else is affected" rather than noise.
  • The prompt-injection test case: instructions inside an issue change nothing.
  • Dozens of documented, verified API findings behind the build, not guesses.

What we learned

Explainability is a feature. Reviewers trust a verdict they can audit line by line, and a deterministic engine makes the audit possible.

What's next for Ripple

  • Pull request and pipeline signals from the repository host once a supported API exists.
  • Assignees mapped from teams to Jira users.

Built With

Share this project:

Updates

Submission history