RIPPLE: Mapping Cause and Effect in Canadian Civic Policy

How crowdsourced knowledge, AI compression, and graph databases are building a living map of policy consequences

Every policy decision creates consequences. Some are intended, many are not, and most are poorly documented. When Alberta changed its healthcare funding model, what happened next? When a municipality approved a zoning variance, what were the downstream effects on traffic, housing costs, and local businesses? When the federal government introduced a new immigration pathway, how did it affect labour markets in specific provinces?

These questions have answers. They’re scattered across news archives, government reports, community forums, academic papers, and the lived experiences of Canadians who watched the consequences unfold in real time. But there is no single place where the relationship between a policy decision and its downstream effects is documented in a structured, searchable, and evolving way.

RIPPLE is CanuckDUCK’s attempt to build that place.

What Is RIPPLE?

RIPPLE stands for Relational Impact and Policy Pattern Linking Engine. At its core, it’s a system that takes two types of input — user contributions and published articles — and compresses them into structured cause-and-effect statements following a simple formula:

The RIPPLE Formula

This causes That by Z Logic

This = the policy action, event, or decision

That = the observed or projected consequence

Z Logic = the reasoning chain that connects them — the mechanism by which cause becomes effect

For example, a RIPPLE entry might read: Alberta’s 2024 healthcare restructuring (This) caused a 14% increase in emergency department wait times in rural communities (That) because the consolidation of regional health authorities reduced local decision-making capacity and created administrative bottlenecks in resource allocation (Z Logic).

Each entry is a node in a larger graph. And that graph is where RIPPLE becomes more than a collection of statements.

How It Works

Input: Where Ripples Begin

RIPPLE draws from two primary sources:

• User Contributions: Community members submit cause-and-effect observations directly through the Pond forum. These are grounded in lived experience — a parent who noticed childcare costs shifted after a provincial subsidy change, a small business owner who saw foot traffic drop after a road closure, a healthcare worker who documented the knock-on effects of a staffing policy. These contributions are the raw material of civic knowledge.
• Published Articles: CanuckDUCK’s news aggregation system pulls from 196 RSS feeds covering Canadian news, policy announcements, and analysis. The Forum Analysis Engine (FAE) processes these articles and extracts cause-and-effect relationships, identifying policy actions and their documented consequences.

Both inputs go through the same compression process: extract the action, extract the consequence, and document the reasoning chain that connects them. The result is a standardized RIPPLE entry that can be compared, linked, and traversed regardless of whether it originated from a community forum post or a Globe and Mail article.

The Graph: Neo4j Aura

Individual cause-and-effect statements are useful. A connected network of them is powerful.

RIPPLE stores its entries in Neo4j Aura, a cloud-hosted graph database designed for mapping relationships. Unlike a traditional database where data sits in rows and tables, a graph database represents information as nodes (things) and edges (relationships between things). This architecture is purpose-built for the kind of questions RIPPLE is designed to answer.

In RIPPLE’s graph, every policy action is a node. Every consequence is a node. The causal relationship between them — the Z Logic — is the edge. When multiple policy actions produce the same consequence, those connections become visible. When a single decision creates a cascade of downstream effects, the chain becomes traversable.

Example: Tracing a Policy Cascade

Node: Federal immigration target increased to 500,000 annually

  → Edge: Increased demand for rental housing in major urban centres (mechanism: population growth outpacing housing starts)

    → Node: Average rent in Toronto increased 8.2% year-over-year

      → Edge: Low-income renters displaced to suburban municipalities (mechanism: affordability threshold exceeded)

        → Node: Transit ridership increased 12% on GO Transit suburban routes

          → Edge: Municipal transit budgets strained beyond planned capacity (mechanism: infrastructure designed for lower ridership volumes)

Each node in this chain is independently verifiable. Each edge carries its own logic. And the full cascade — from immigration policy to transit budgets — becomes a documented, queryable path that anyone can examine, challenge, or extend.

This is what makes graph databases essential to RIPPLE’s design. Relational databases can store facts. Graph databases can store how facts relate to each other — and make those relationships searchable at any depth.

AI Compression: Turning Noise Into Signal

Not every forum post or news article contains a clean cause-and-effect statement. Most don’t. A 2,000-word article about healthcare reform might contain one actionable RIPPLE entry buried in paragraphs of context, opinion, and background.

RIPPLE uses AI to perform the compression — reading the source material, identifying the causal claim, extracting the mechanism, and structuring it into the standardized This/That/Z Logic format. The AI doesn’t generate the knowledge. It extracts and structures what’s already present in the source.

This distinction matters. RIPPLE’s value depends entirely on the quality of its source material. The AI is a lens, not a lamp — it focuses existing information, it doesn’t create new information. When the source material is strong (vetted articles, substantive forum contributions), the compressed entries are reliable. When the source material is weak or fabricated, the entries inherit those flaws.

Where Ripples Flow: Downstream Systems

RIPPLE is not an endpoint. It’s a knowledge layer that feeds into two other CanuckDUCK systems, each designed to translate causal knowledge into action.

Ducklings: Budget Simulation for the Next Generation

Ducklings is CanuckDUCK’s educational simulation platform, currently serving 61 Alberta schools with plans to expand to 5,000 schools nationwide. It allows students to engage with real government budget data — $904 billion across federal, provincial, and municipal levels — and simulate the consequences of their allocation decisions.

RIPPLE feeds Ducklings by providing the consequence layer. When a student in the simulation decides to cut healthcare funding by 10%, Ducklings can draw on RIPPLE’s graph to show what has historically happened when similar cuts were made: increased emergency room wait times, deferred maintenance on facilities, migration of healthcare workers to other provinces. These aren’t hypothetical scenarios. They’re documented cause-and-effect relationships extracted from real events.

This transforms Ducklings from a budgeting exercise into a civic reasoning tool. Students don’t just learn that budgets have trade-offs — they learn which trade-offs, supported by evidence of what happened when those choices were made in the real world.

Flightplans: From Consequences to Action

Flightplans is CanuckDUCK’s project and action planning system on Pond. Where RIPPLE documents what happened and why, Flightplans is designed to help communities decide what to do next.

RIPPLE feeds Flightplans by providing evidence-based context for proposed community actions. If a community association is considering advocating for a bike lane on a major corridor, Flightplans can pull RIPPLE data showing what happened in comparable Canadian communities that implemented similar infrastructure: changes in traffic patterns, effects on local business revenue, shifts in property values, safety outcomes.

The goal is to move community planning from opinion-based advocacy to evidence-informed decision-making. Not to replace community judgment — local knowledge and values are irreplaceable — but to ensure that when communities advocate for or against a policy, they have access to the documented history of similar decisions elsewhere.

Challenges and Open Questions

Building a cause-and-effect knowledge graph for an entire country’s policy landscape is ambitious, and there are legitimate concerns that need to be addressed openly.

Source Quality and Bias

RIPPLE is only as reliable as the information that feeds it. News articles carry editorial bias. Forum contributions carry personal bias. Even government reports carry institutional bias. If the 196 RSS feeds skew toward certain outlets or perspectives, the graph will reflect that skew. RIPPLE’s AI compression layer can structure information, but it cannot correct for systemic bias in the source material itself.

The mitigation strategy is transparency: every RIPPLE entry links back to its source. Users can see where a causal claim originated, evaluate the source’s credibility for themselves, and challenge entries they believe are inaccurate or misleading. But this requires an engaged user base willing to do that work, which is not guaranteed.

Correlation vs. Causation

The fundamental risk of any cause-and-effect system is mistaking correlation for causation. If healthcare wait times increased the same year a funding model changed, was the funding model the cause? Or were there confounding factors — population growth, staffing shortages, pandemic aftereffects — that contributed independently?

RIPPLE’s Z Logic requirement is designed to address this by forcing every entry to document the mechanism — not just that A preceded B, but how A caused B. This doesn’t eliminate the risk, but it makes the reasoning visible and challengeable. A RIPPLE entry that says “funding cuts caused wait time increases because hospitals had fewer staff” is more useful and more testable than one that simply says “funding cuts caused wait time increases.”

AI Limitations

The AI compression layer introduces its own risks. Large language models can misidentify causal relationships in text, hallucinate connections that aren’t present in the source material, or strip nuance from complex policy situations. A 2,000-word article about healthcare reform might contain careful hedging (“some researchers suggest”, “preliminary data indicates”) that gets compressed away, leaving a RIPPLE entry that sounds more definitive than the source warrants.

This is a known limitation, not a solved problem. Human review of AI-compressed entries is part of the design, but at scale, not every entry can be manually verified. The question of how to maintain quality at volume — especially as the platform grows — remains open.

Weaponization and Manipulation

A crowdsourced knowledge graph is inherently vulnerable to manipulation. A coordinated group could submit RIPPLE entries that misrepresent causal relationships to support a political agenda. An AI-generated flood of entries could overwhelm the system with plausible-sounding but fabricated claims. If RIPPLE feeds into Ducklings — a platform used by schools — the stakes of data integrity extend to education.

There is no single technical solution to this. The approach combines source verification (linking every entry to its origin), community moderation (allowing users to flag and challenge entries), rate limiting (preventing automated flooding), and editorial oversight for entries that feed into educational contexts. Whether this is sufficient at scale is an honest unknown.

Current Status

RIPPLE is operational in early form. The AI compression pipeline is processing articles from the RSS feed network and extracting cause-and-effect entries. The Neo4j Aura graph is being populated with structured entries. The integration with Ducklings is in development, with the goal of providing consequence data to the 61 schools currently using the simulation platform.

The Flightplans integration is on the roadmap but not yet active. It requires a threshold of graph density — enough interconnected entries across enough policy domains — before the query layer can return useful results for community planning.

The platform is approaching soft launch readiness. The priority now is building graph density in key policy areas (healthcare, housing, education, transportation, and energy) while testing the AI compression pipeline’s accuracy against human-verified entries.

Join the Discussion

RIPPLE is designed to be built by the communities it serves. That means its direction should be shaped by the people who will use it. We’re opening this up for discussion with a few specific questions:

Questions for the Community

1. Source trust: How should RIPPLE weigh different sources? Should a government statistical report carry more weight than a community forum contribution? Or does that create a hierarchy that dismisses grassroots knowledge?

2. Challenge mechanisms: When someone disputes a RIPPLE entry, what should happen? Should the entry be hidden pending review, flagged but visible, or left intact with the challenge appended? Each approach carries trade-offs between accuracy and openness.

3. Educational use: If RIPPLE data feeds into Ducklings and reaches classrooms, what standard of verification should apply? Should educational-facing entries require human review before publication? How do we balance timeliness with accuracy for students?

4. Missing domains: Which policy areas should RIPPLE prioritize? Healthcare and housing are obvious starting points, but what domains matter most to your community? Indigenous governance? Climate policy? Municipal taxation? Labour markets?

5. The hard question: Can a crowdsourced cause-and-effect system ever be trusted enough to inform real policy decisions? Or is it destined to be a reference tool at best? What would it take for you to trust RIPPLE’s data in a council meeting or a school board presentation?

RIPPLE is an experiment in collective civic knowledge. Whether it succeeds depends less on the technology and more on whether communities see value in documenting the consequences of the decisions that shape their lives. We think they will. But we’d rather be proven right through participation than assume it.

The graph is open. The question is what we build on it together.