Data Flow

How Data Moves Across the CanuckDUCK Ecosystem

From authoritative source, to geographic routing, to public-facing civic experience.

The CanuckDUCK platform is built on a simple principle:
All civic data should originate from one trusted source and flow consistently to the place where residents interact with it.

To support this, the system uses a streamlined pipeline:

CDKDB (Harlequin) → Pond → Pond Modules → Pages & Services

This chapter explains how that pipeline works and how it keeps the entire ecosystem coherent, reliable, and geographically aware.

1. CDKDB (Harlequin): The Authoritative Source of Civic Data

CDKDB is the central, canonical database of all civic information within the CanuckDUCK ecosystem.
It holds the authoritative record for:

  • provinces
  • municipalities
  • communities
  • postal codes and boundary mappings
  • businesses
  • nonprofits
  • schools
  • associations & BIAs
  • civic project metadata
  • CDKIDs for all civic entities

If something exists in CDKDB, it exists across the platform.
If something does not exist in CDKDB, it is not yet part of the civic record.

CDKDB’s role:

Store civic data accurately, consistently, and permanently.

It is the backbone of the platform.

2. Pond: The Public Civic Hub

Pond is the primary public-facing site through which residents experience CanuckDUCK.

It is responsible for:

  • interpreting civic data
  • routing users through the geographic hierarchy
  • rendering community and city pages
  • delivering business and nonprofit directories
  • displaying civic projects
  • hosting forums and discussions
  • presenting news, events, alerts, and polls
  • tying content to specific locations

Pond transforms raw civic data from CDKDB into the services and tools residents interact with daily.

Pond’s core function:

Convert authoritative data into meaningful public experiences.

Everything residents see originates from Pond interpreting CDKDB.

3. Geographic Routing Through the /flightplans Module

The /flightplans module inside Pond serves as the foundation of all geographic navigation on the platform.

Its responsibilities include:

  • interpreting province, municipality, and community slugs
  • mapping postal codes to community boundaries
  • determining which civic entities belong to which locations
  • attaching services to community paths

  • constructing URLs such as:

     

    /ca/ab/calgary/sunnyside

The module is the central routing engine for geography-aware features, including:

  • community homepages
  • civic project pages
  • local directories (business, nonprofit, school)
  • forum topics tied to a community
  • localized news and event views

Its purpose:

Ensure that every civic page and service is grounded in the correct geographic context.

4. How Data Moves From CDKDB Into Pond

The data pipeline is intentionally straightforward:

 

CDKDB → Pond's internal data services → Pond's modules → Public pages

Step-by-step flow:

  1. CDKDB provides the complete civic dataset.
  2. Pond reads the data via internal queries and structured access patterns.
  3. Pond’s geographic layer (via /flightplans) assigns the data to provinces, cities, and communities.
  4. Pond’s feature modules (business, nonprofits, forums, etc.) use the assigned location to generate the correct content.
  5. Pond renders the final pages that residents interact with.

At every step, the data remains:

  • consistent
  • structured
  • tied to geography
  • authoritative

There are no intermediate sites, no external syncs, and no duplicated databases.

5. Pond Modules: Turning Data Into Services

Each module within Pond has a dedicated responsibility:

Business Directory Module

Uses postal codes and CDKDB mappings to list businesses within a community.

Nonprofit Directory Module

Shows community-serving organizations based on official records.

Civic Projects Module

Renders public project information tied to geographic coordinates or community boundaries.

Forums Module

Anchors discussions to the geographic path (national → provincial → municipal → community).

News & Events Modules

Surface localized content relevant to residents of the selected area.

Education Module

Lists schools and educational facilities based on their assigned community.

Every module draws from:

  • CDKDB as the truth
  • Pond’s geographic routing for context
  • Pond’s rendering for presentation

This ensures a unified civic experience wherever the user navigates.

6. Why This Architecture Works

Single Source of Truth

Data lives in one authoritative location (CDKDB).

Single Point of Experience

Residents interact with one site (Pond).

Consistent Geography

The same routing logic powers all civic pages.

Unified Identity & SSO

Pond integrates seamlessly with Core for user permissions and pseudonymous identities.

Better Maintainability

Updates in CDKDB are immediately reflected across the platform.

Scalable Foundation

New features—polls, dashboards, directories, civic alerts—fit naturally into Pond.

This structure keeps CanuckDUCK stable, predictable, and easy to extend.

7. The Philosophy Behind the Pipeline

The architecture follows three guiding principles:

Accuracy

Civic information should come from authoritative registries and structured datasets.

Clarity

Geography should organize the experience, not algorithms or opaque categories.

Trust

Data should be stable, transparent, and never exploited commercially.

By grounding everything in CDKDB and delivering the experience through Pond, CanuckDUCK ensures that civic engagement remains:

  • relevant
  • respectful
  • coherent
  • geographically meaningful
  • privacy-preserving

Exactly as a civic platform should function.