A policy changed. Which company documents just became wrong?

A company has modified its refund window policy from 30 days to 14 days. However, the company's help centre still reflects the previous 30-day duration. Additionally, an AI-generated help response maintains the outdated 30-day guarantee. The issue arises due to the outdated information not being updated in the relevant workflow.

This situation exemplifies the challenges organizations face when policies change but documentation does not reflect the update. Ripple, a graph-powered company knowledge system, aims to address this problem. Built using FalkorDB and Gemini for Graph Hacks 2026, Ripple links policies to the documents, claims, workflows, and saved agent replies that rely on them.

When a policy changes, Ripple identifies areas requiring attention, explains the reasons, and assists in reviewing and fixing the issues. Searching for outdated information within documents proves insufficient, as it fails to address all implications of a policy change. For example, the same number may represent various scenarios like refunds, trials, or cancellation notices, and the policy may apply to different customer types or be a future proposal.

Ripple's graph database design helps model company knowledge effectively. It stores policies, documents, claims, workflows, saved agent replies, owners, decisions, reviews, corrections, research snapshots, and publication receipts. Relationships between these entities are represented as graph edges. The core dependency model links workflows to documents, claims to policies, and owners to documents.

This structure allows Ripple to understand how records connect and what each record states. The claim node proves particularly useful as it can hold multiple assertions within a single document, such as trial and refund statements. By connecting these assertions separately, Ripple can identify which claims are affected by a policy change while preserving unrelated information.

Policy-topic anchors connect different versions of the same policy, enabling Ripple to find obsolete claims even when newer decisions have been made. Ripple's graph visualization displays these stored relationships, aiding in the inspection of evidence paths explaining why a particular source appeared in the impact report. Ripple follows active dependencies for up to six hops to analyze the impact of a policy change.

A Cypher query is used for this purpose, initiating from an entity and traversing up to six dependent relationships. The query returns node IDs and relationship types, which Ripple uses to display an inspectable evidence path. Ripple separates results into three categories: confirmed conflicts, requiring review; connected workflows needing an owner's judgment; and unaffected sources outside the change's scope.

In addition to internal policies, Ripple can research public websites and relevant links to gather information, which must be reviewed and approved by a person before being incorporated into the knowledge library.