Inspiration

Regulatory change rarely affects just one document. A single amended deadline or obligation can ripple through policies, procedures, templates, playbooks, and training materials across an organisation. Legal teams often discover these dependencies manually by searching folders, opening documents individually, and relying on institutional knowledge. We built Ripple to answer a more useful question than “What regulation changed?” “What did that change break inside our organisation?”

What it does

Ripple maps external regulations to the exact internal clauses that depend on them. Users can upload regulations and internal documents in PDF, DOCX, or TXT format. Ripple extracts individual regulatory requirements, analyses the organisation’s document corpus, and creates a dependency map at: Regulation → Requirement → Document → Section → Sentence When a regulation changes, Ripple follows those dependencies and identifies the affected documents and passages. Each impact includes its severity, confidence score, reasoning, source requirement, affected sentence, and the person who contributed that content. Users can view regulatory changes, inspect downstream impacts, open affected documents with problematic clauses highlighted, and navigate directly to the original regulatory source. They can also explore dependencies using an interactive graph, generate suggested amendments for human review, simulate hypothetical changes, and search the corpus by meaning. Ripple never silently edits source documents or provides legal advice. It identifies what requires attention and leaves every decision with the lawyer.

How we built it

Ripple is a local application built with FastAPI, Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui. Its data is stored locally using SQLite. We use SQLite FTS5 for keyword retrieval and sqlite vec for semantic search. OpenAI compatible models support requirement extraction, embeddings, dependency classification, impact analysis, and amendment recommendations. Every regulatory requirement has a stable lineage across versions. Dependencies point to that lineage instead of one specific version. This allows Ripple to preserve its dependency map when a requirement is amended. Internal documents are divided into section aware passages while retaining page numbers and character positions. These positions allow Ripple to highlight the exact affected text and connect it to its regulatory source and contributor. Longer operations such as document ingestion, embedding, mapping, scanning, and impact analysis run as background jobs. The interface waits until a sample environment has been fully processed before allowing users to explore it. We also integrated PDF.js so users can read the original regulation and jump directly to the referenced clause.

Challenges we ran into

The hardest problem was creating reliable links between legal concepts and exact text. Semantic similarity alone is not enough. Two clauses may discuss the same topic without creating a genuine legal dependency. We combined semantic retrieval, keyword search, structured model decisions, confidence scores, and evidence spans to make the mapping more defensible. Accurate highlighting was another major challenge. Extracted PDF text does not always match what is visually displayed because of line breaks, punctuation, and formatting. We had to preserve source positions and build tolerant matching while ensuring Ripple did not highlight unrelated text. We also learned that a demonstration corpus must be internally consistent. If a requirement exists in the database but not in the source PDF, the resulting impact analysis becomes misleading. We expanded and aligned our sample environments so every dependency and change can be traced back to real source text. Finally, coordinating background processing without exposing incomplete results required careful job state and loading screen design.

Accomplishments that we're proud of

We are proud that Ripple goes beyond document level classification. It identifies the specific sentence that requires review, explains why it is affected, shows who contributed it, and connects it back to the original regulation. We also built a complete workflow covering scenario import, requirement extraction, dependency mapping, change detection, impact analysis, graph exploration, highlighted evidence, and suggested amendments. Most importantly, Ripple is transparent. Users can inspect the source regulation, dependency evidence, affected clause, contributor, reasoning, and confidence behind every result.

What we learned

We learned that trust in legal AI comes from traceability, not confidence alone. A polished answer is not enough. Legal professionals need to understand where a conclusion came from, which evidence supports it, and where human judgment is still required. We also learned that data lineage is just as important as model quality. Stable requirement identities, source positions, contributor attribution, and recorded dependency evidence make the entire system more reliable. Finally, combining keyword and semantic retrieval works much better for legal text than relying on either approach alone.

What's next for Ripple

Next, we want to add richer document revision history, collaborative review workflows, comments, assignments, and exportable redlines. We also plan to support scanned documents, additional jurisdictions, live regulatory monitoring, and integrations with document management systems such as SharePoint and iManage. In the longer term, Ripple could learn from accepted and rejected recommendations. This would help each legal team build an increasingly accurate map of how external law connects to its internal policies while keeping lawyers firmly in control.

Built With

Share this project:

Updates