Ripple 如何找出政策變更後受影響的公司文件

A company changes its refund window from 30 days to 14.

The approved policy gets updated. But the help centre still says 30 days. A saved AI reply repeats the old promise. A refund-intake workflow depends on that help page without mentioning a duration at all.

The decision changed. The company’s knowledge didn’t catch up.

That is the problem we built Ripple to solve.

Ripple is a graph-powered company brain built with FalkorDB and Gemini for Graph Hacks 2026, under Track 03: Company Brain.

It connects policies to the documents, claims, workflows and saved agent replies that depend on them. When a policy changes, Ripple finds what needs attention, explains why, and helps an owner review and repair it.

🔗 Try Ripple

🎬 Watch the three-minute working demo

💻 Explore the source code

Why searching documents wasn’t enough

Our starting question was simple:

When one policy changes, how do we find everything that silently becomes wrong?

Searching for “30 days” catches some outdated statements, but it leaves several questions unanswered:

• Does that number describe refunds, trials or cancellation notice?
• Does it apply to self-serve customers or enterprise customers?
• Is it an old policy or a future proposal?
• Which workflows depend on the document without repeating its wording?
• Why should a particular source be changed?

These are relationship questions. We needed to understand how records connect, alongside what each record says.

That made a graph database a useful foundation.

How we modeled company knowledge in FalkorDB

FalkorDB is Ripple’s primary database for company knowledge.

We store policies, documents, reviewed claims, workflows, saved agent replies, owners, decisions, reviews, corrections, research snapshots and publication receipts.

Domain records use native Entity nodes with stable IDs, a queryable kind and a typed JSON payload. Relationships are native graph edges.

The core dependency model looks like this:

Workflow → DEPENDS_ON → Document → ASSERTS → Claim

Claim → DEPENDS_ON → Policy version → DEPENDS_ON → Policy topic

Document → OWNED_BY → Owner

Decision → CREATES → Review → REPAIRS → Document

Publication receipt → DEPENDS_ON → Document

The claim node turned out to be particularly useful.

A single document can contain both a trial statement and a refund statement. Connecting those assertions separately lets a refund change affect the relevant claim while preserving unrelated information.

Policy-topic anchors connect different versions of the same policy. That allows Ripple to discover an old claim even after several newer decisions exist.

The graph visualization is a view of these stored relationships. FalkorDB also powers retrieval, dependency analysis, repairs and persistent recall. Removing the database disables those core features.

SQLite is limited to local authentication records. The development preview simulator is separate from the submitted FalkorDB-backed runtime.

The Cypher query behind impact analysis

Ripple follows active dependencies for up to six hops using this query:

MATCH p=(a:Entity)-[:DEPENDS_ON|ASSERTS*1..6]->(topic:Entity {id: $target})
WHERE all(r IN relationships(p) WHERE r.active = true)
RETURN [n IN nodes(p) | n.id] AS ids,
       [r IN relationships(p) | type(r)] AS relations

For refund analysis, $target is topic-refund.

Trial duration, cancellation notice and support response time have separate topic anchors.

The query returns node IDs and relationship types. Ripple uses them to display an inspectable evidence path explaining why a source appeared in the impact report.

User data is passed through parameters. Gemini does not generate Cypher.

A dependency does not automatically mean something is wrong

This became one of our most important design decisions.

If a workflow depends on a help page, that relationship tells us the workflow may need attention. It does not tell us exactly how to rewrite the workflow.

Ripple therefore separates results into three categories:

After the graph discovers candidate impacts, deterministic application logic checks the policy topic, approval status, audience, effective date and version order.

A self-serve policy change should preserve an enterprise exception. A proposed or future policy should not replace the currently applicable approved version.

Where Gemini fits

Gemini helps interpret language.

It extracts candidate policy claims with exact source quotations and selects a supported read-only policy-context tool when someone asks a question.

Approved graph records determine the authoritative values returned in the answer. Application checks and human approval govern writes.

The prototype currently supports four numeric policy areas:

• Trial duration, measured in days.
• Refund eligibility window, measured in days.
• Cancellation notice before renewal, measured in days.
• Initial support response time, measured in hours.

Keeping these meanings distinct matters.

For example:

“How long does a refund take to process?”

That asks about processing or settlement time. A 14-day refund eligibility window does not answer it.

Ripple rejects unsupported meanings rather than returning a familiar number because the question contains “refund.”

From public policies to reviewed knowledge

Ripple can research a supplied public HTTPS HTML/text page and up to three relevant links on the same host.

The extracted findings remain pending until a person reviews their quotations, audiences and effective dates.

Approved findings establish versioned policies and source relationships. Importing a changed policy can generate impact reviews.

Users can also paste a document into the knowledge library, extract candidate claims, review them and save the source.

We treat public text as evidence. Neither a website nor model output becomes authoritative simply because the agent encountered it.

A complete example: changing refunds from 30 days to 14

Our public demonstration uses fictional Acme company data.

The shared tour is read-only. Clicking Try your own sandbox creates a separate writable FalkorDB graph with a signed visitor session, without requiring an account.

Here is the main workflow.

1. Ask the original policy

Ask:

What is our refund window?

Choose New self-serve and October 17, 2026.

A fresh sandbox returns 30 days, with the approved policy evidence.

2. Record an approved change

In Change studio, set the refund window to 14 days, for the same customer group, effective and analyzed on October 17.

Ripple records a new policy version and runs dependency analysis.

3. Inspect the consequences

In the fresh seeded scenario, the report finds:

• Three confirmed conflicts.
• Two workflows needing review.
• One unaffected enterprise source.

These counts depend on the workspace’s saved data.

Opening an affected help-centre page shows its old 30-day statement and the graph path connecting it to the refund policy.

4. Review and apply a correction

The review workspace displays the original and proposed text side by side.

The supported refund statement changes from 30 days to 14. The surrounding instructions remain intact.

Before saving, Ripple rechecks the applicable policy and source revision/content. Applying the correction preserves the original text, increments the source revision and records the repair history.

Reapplying an already applied review does not create another correction record.

5. Export or publish the repaired copy

Applied corrections can be exported as Markdown or JSON.

The packet includes before-and-after content, source revisions, policy and decision provenance, graph evidence, actor and approval context.

A SHA-256 digest checks content equality. It is a checksum, not a digital signature.

Publishing is a separate action.

In Acme website, clicking Publish approved copy updates our controlled sandbox help centre. The customer copy now shows 14 days, alongside its source revision, publication time and actor.

This demonstrates a completed action while keeping the boundary clear: it updates our sandbox publishing surface, not an unrelated company’s website.

6. Ask again and check history

Ask the same refund question again:

14 days.

Reload the browser and repeat:

14 days.

Change the audience to enterprise:

60 days.

Ask for the self-serve policy on October 1:

30 days.

The graph preserves the new decision, earlier policy versions and customer-group exceptions.

The distinction is important: approving the policy changes the authoritative answer. Applying a correction repairs the internal source. Publishing makes that approved repair visible on the controlled customer surface.

Protecting repairs from concurrent requests

We also had to consider what happens when two hosted server instances write to the same graph.

An in-process queue alone cannot protect against that.

Ripple reads entities, relationships and workspace metadata in one consistent query. Its atomic save checks the workspace revision before updating records:

MERGE (m:RippleMeta {id: 'workspace'})
WITH m WHERE coalesce(m.revision, 0) = $expected
SET m.revision = $expected + 1, m.token = $token, m.commands = $commands

The complete query carries this guard through the node and relationship write groups.

A stale request returns HTTP 409 instead of restoring old source text. Command keys prevent duplicate saved mutations. The writer validates the complete projected graph and saves only changed records.

What we learned while building Ripple

Interface ambiguity can undermine correct graph logic

An earlier version allowed a return-policy title to remain paired with the trial-duration selector.

That routed the request into the wrong policy neighborhood.

We fixed the interface synchronization and added server validation for inconsistent policy areas, values and units. Regression checks cover the original mismatch and cross-topic isolation.

The lesson was straightforward: a correct traversal still needs an unambiguous request.

Query construction affects database behavior

Our original writer generated larger query text as the graph grew. On a small Cloud instance, this consumed query-plan cache memory.

We changed it to a constant-shaped, parameterized UNWIND writer with an allowlist of relationship types.

That fixed the observed failure while preserving graph records. It also taught us to pay attention to the shape of generated queries, beyond whether they return the correct result.

Persistent state needs explicit conflict handling

A refresh should not undo someone else’s correction. Repeating a request should not create duplicate audit records.

Revision checks, source validation and command deduplication became part of the product’s reliability, rather than details we could leave until later.

Good agent behavior includes knowing when to stop

A connected workflow does not justify an invented rewrite. A refund window does not answer processing time. An extracted quotation still requires review.

Clear boundaries made the prototype easier to explain, test and trust.

How we verified it

The release verification record documents 44 passing automated tests and the TypeScript/Vite production build.

Separate Cloud checks exercise:

• The actual HTTP adapter and isolated visitor graphs.
• Correction integrity, exports, publication and session resume.
• Stale-save rejection through two independent database connections.
• Command deduplication, capacity limits and backup restoration.
• Live Gemini extraction and routing across all four supported policy topics.

The October 18 browser recording also exercised the deployed workflow: the 30-to-14-day change, evidence review, approved correction, downloaded packet, publication, recall after refresh, enterprise exception and historical answer.

The three-minute demo shows actual app interactions with synthetic narration.

These checks provide evidence for the demonstrated workflow. They do not guarantee permanent availability of hosting, database or model-provider services.

Current boundaries and possible next steps

Public judge sessions expire after two hours. Admission limits, graph-size limits, shared rate counters and a daily AI allowance bound resource use. Expired access and physical graph cleanup are separate.

Ripple currently preserves policy and decision context. It does not claim unrestricted conversation memory.

Research does not support PDFs, JavaScript-only pages or arbitrary conditional contracts. Slack, Notion, Drive and arbitrary external-site publishing are outside the implemented scope.

Company login and membership checks are available locally. Durable hosted company accounts, domain ownership verification, email recovery and invitation delivery need further work.

Reviewed external publishing adapters and scheduled source-drift detection would be useful next steps.

Try Ripple

The result today is concrete: one policy decision leads to discoverable impacts, reviewable repairs, a published demonstration copy and an answer whose history can be inspected.

• Open the live prototype and choose Try your own sandbox.
• Watch the working demo.
• Explore the GitHub repository.
• Read the graph model.
• Inspect the Cypher queries.
• Follow the judge walkthrough.
• Run the project locally.