CanuckDUCK Developer Framework — Datasets, Research Modules, and Civic Operating System Positioning

CanuckDUCK Developer Framework — Datasets, Research Modules, and Civic Operating System Positioning

Marker: CDK-DEVELOPER-FRAMEWORK-RESEARCH-MODULES-V0-1

Status: Strategic addendum to the CanuckDUCK Developer Framework. This document clarifies that the framework is not only for internal site features; it is also a pathway for students, researchers, civic technologists, and approved third-party contributors to build modules that connect datasets, analysis, and civic topics.

Core intent

CanuckDUCK can house and curate civic datasets while giving students and researchers a safe, documented way to create modules that connect those datasets to public topics, jurisdictions, Consensus questions, Pond discussions, and RIPPLE graph context.

This turns CanuckDUCK from a collection of civic websites into a credible civic operating system: a platform where data, discussion, public questions, causal models, education, and research outputs can interoperate through governed modules.

Civic operating system claim

The phrase civic operating system becomes defensible if CanuckDUCK provides more than pages and forums. The platform should provide:

• Datasets: curated public-interest data with provenance, jurisdiction, update cadence, and usage constraints.
• Topics: stable civic containers in Pond organized by geography, jurisdiction, and domain.
• Questions: Consensus polls and deliberative prompts connected to topics and source material.
• Graph context: RIPPLE/Neo4j variables and causal relationships that help explain downstream effects.
• Research modules: student/researcher-built extensions that visualize, analyze, annotate, or connect datasets.
• Governance: privacy, neutrality, review, and safety rules that preserve public trust.

Student and researcher module model

A research module should be a bounded, reviewable extension that declares:

• Which dataset or datasets it uses.
• Which civic topic, geography, or jurisdiction it connects to.
• Whether it visualizes, analyzes, summarizes, compares, or annotates the data.
• Whether it only reads data or proposes new metadata/graph/question artifacts.
• What privacy class applies.
• What review lane is required before public display.

Example research module manifest

canuckduck:
  schema_version: 0.1
  module:
    machine_name: cdk_research_housing_affordability_viewer
    type: research_module
    audience:
      - student
      - researcher
    status: experimental
  datasets:
    uses:
      - id: statcan_rent_burden_by_cma
        access: read_only
        provenance_required: true
      - id: municipal_shelter_capacity
        access: read_only
        provenance_required: true
  civic:
    domains:
      - housing
      - poverty
    jurisdictions:
      supports:
        - municipal
        - provincial
    topic_bindings:
      pond:
        may_attach_to_topics: true
        creates_public_content: false
      consensus:
        may_propose_draft_questions: true
        may_publish_questions: false
  ripple:
    reads_context: true
    proposes_variables: true
    writes_directly: false
  privacy:
    stores_personal_data: false
    stores_minor_data: false
    aggregate_only: true
  review:
    required_lanes:
      - code
      - dataset-provenance
      - privacy
      - civic-neutrality
      - graph-review

Dataset layer recommendation

CanuckDUCK should define a dataset registry that can be referenced by modules. The registry should track:

• Dataset ID: stable machine-readable identifier.
• Title and description: human-readable purpose.
• Source/provenance: original publisher, retrieval method, license, and date.
• Jurisdiction: federal, provincial, municipal, school-board, community, etc.
• Civic domains: housing, education, healthcare, transit, public finance, legal/justice, environment, etc.
• Update cadence: static, annual, monthly, daily, event-driven.
• Privacy class: public, aggregate-only, restricted, internal, prohibited for student use.
• Allowed uses: visualization, analysis, topic attachment, Consensus draft questions, RIPPLE read/proposal, educational use.
• Quality notes: known caveats, missing fields, uncertainty, sample limits, bias risks.

Topic connection model

Research modules should connect to topics without taking over the topic. A module can become a panel, tab, attachment, visualization, or supporting artifact associated with a Pond topic or civic stream. For example:

• A housing affordability module attaches charts to a municipal housing topic.
• A transit accessibility module attaches maps to a local transportation topic.
• A school-supply affordability module attaches aggregate cost data to a Ducklings-adjacent public policy topic without collecting student personal data.
• A researcher module proposes draft Consensus questions based on a dataset but cannot publish them automatically.
• A graph-context module reads RIPPLE variables and proposes new relationships for review rather than mutating Neo4j directly.

Contributor lanes

Trust boundaries

The research-module program should be generous with public/aggregate data and strict with authority:

• Modules may read approved public or aggregate datasets.
• Modules may attach visualizations or analysis to topics after review.
• Modules may propose Consensus questions, metadata, and RIPPLE additions.
• Modules should not directly publish official questions, mutate graph state, collect personal data, access private content, manage accounts, or touch Ducklings student data.
• All high-impact civic claims should include dataset provenance, methodology, limitations, and uncertainty notes.

Why this matters strategically

This model creates a real platform advantage. CanuckDUCK is not just hosting public discussion. It can become a place where Canadian civic data is operationalized into structured public understanding:

• Datasets become civic artifacts instead of isolated spreadsheets.
• Student work can become useful public infrastructure without compromising privacy.
• Researchers can connect evidence to live public topics.
• Consensus questions can be grounded in data rather than vibes.
• RIPPLE can turn research into causal hypotheses and reviewable graph proposals.
• Pond can host the public-facing narrative and deliberation around the data.

Recommended next build additions

1. Add a datasets/ section to the proposed canuckduck-module-sdk.
2. Draft canuckduck.dataset.schema.json.
3. Extend canuckduck.module.yml to support research_module and dataset_viewer module types.
4. Create a first example dataset registry entry.
5. Create a read-only student/researcher starter module template.
6. Create a review checklist for dataset provenance, civic neutrality, privacy, and graph proposals.
7. Select one pilot dataset and one topic to demonstrate the model.

Recommended first pilot

Choose a low-risk public dataset with clear provenance and connect it to an existing Pond topic as a read-only visualization or context panel. The pilot should prove:

• dataset registry entry;
• module manifest;
• topic binding;
• public visualization;
• privacy-safe operation;
• review workflow;
• documentation pattern for students and researchers.

Positioning statement

CanuckDUCK is a civic operating system because it does not merely publish civic information; it provides governed interfaces for civic data, public discussion, consensus-building, graph reasoning, research modules, and AI-assisted civic workflows to interoperate safely.