CanuckDUCK Developer Framework — Live Initiative Datasets and Outcome Tracking

CanuckDUCK Developer Framework — Live Initiative Datasets and Outcome Tracking

Marker: CDK-DEVELOPER-FRAMEWORK-INITIATIVE-METRICS-V0-1

Status: Strategic addendum. This extends the dataset and research-module model into active initiatives, where live or periodically refreshed data can track whether civic/product interventions are producing measurable results.

Core idea

When CanuckDUCK creates an initiative, the initiative should be able to bind to one or more datasets that update over time. Those datasets can provide baseline conditions, live indicators, outcome measures, and public accountability.

This means an initiative is not only a campaign, project, product, or discussion thread. It can become a measurable civic intervention connected to real-world evidence.

Why this strengthens the civic operating system claim

A civic operating system should not merely host ideas. It should connect:

• an initiative — what CanuckDUCK or a partner is trying to do;
• datasets — what evidence describes the problem and changing conditions;
• topics — where public discussion and context live;
• Consensus questions — what the public is being asked;
• RIPPLE variables — what causal pathways are expected;
• outcome metrics — how success, failure, uncertainty, and side effects are tracked.

This creates a feedback loop between civic action and public evidence.

Example: Winter Warmth / economical winterwear

If CanuckDUCK produces economical winterwear, the initiative can be measured against real data sources rather than only internal distribution counts or marketing claims.

Possible live or periodically refreshed indicators:

• local winter temperature and wind-chill exposure;
• homelessness and shelter-capacity indicators;
• outreach-service demand;
• municipal/provincial cold-weather alerts;
• reported cold-injury, frostbite, or hypothermia trends where public data is available;
• distribution geography and volume;
• replacement/repair rates;
• recipient or frontline-worker aggregate feedback;
• cost per useful-warmth outcome, where measurable;
• environmental/material metrics if recycled inputs are used.

The goal is not to overclaim causality. The goal is to show whether the initiative is plausibly aligned with the need, whether the intervention is reaching the right places, and whether data suggests iteration is required.

Initiative metric model

Each measurable initiative should declare:

• Baseline: the condition before the initiative begins.
• Target population or context: who or what the initiative is intended to support, using aggregate/public descriptors.
• Geographic scope: national, provincial, municipal, community, shelter/service area, etc.
• Dataset bindings: public, aggregate, internal, or partner datasets used for tracking.
• Primary indicators: the most important metrics for progress.
• Secondary indicators: side effects, operational load, repairability, affordability, or environmental impact.
• Update cadence: live, daily, weekly, monthly, seasonal, annual, or manual.
• Review lane: data quality, privacy, neutrality, methodology, and public-claim review.
• Interpretation limits: what the metrics can and cannot prove.

Example initiative manifest

canuckduck_initiative:
  schema_version: 0.1
  initiative:
    id: winter-warmth-economical-winterwear
    title: Winter Warmth — Economical Winterwear
    type: practical_goods
    status: pilot
  civic:
    domains:
      - poverty
      - housing
      - public_health
      - climate_exposure
    jurisdictions:
      supports:
        - municipal
        - provincial
  topics:
    pond:
      primary_topic_path: /canuckduck/forums/merchandise-and-products
      may_attach_metric_panels: true
    consensus:
      may_propose_questions: true
      may_publish_questions: false
  datasets:
    baseline:
      - id: municipal_cold_weather_alerts
      - id: shelter_capacity_public_reports
    live_or_periodic:
      - id: weather_windchill_observations
      - id: outreach_service_demand_aggregate
      - id: winterwear_distribution_summary
      - id: repair_replacement_summary
    prohibited:
      - identifiable_recipient_records
      - student_or_minor_personal_data
  metrics:
    primary:
      - units_distributed_by_geography
      - cost_per_unit
      - warmth_suitability_by_temperature_band
      - frontline_need_alignment
    secondary:
      - repair_rate
      - replacement_rate
      - material_reuse_or_recycled_content
      - aggregate_feedback_score
  ripple:
    expected_variables:
      - cold_exposure_risk
      - shelter_capacity_pressure
      - material_affordability
      - outdoor_worker_wellbeing
    proposes_relationships: true
    writes_directly: false
  privacy:
    aggregate_only: true
    stores_personal_data: false
    stores_minor_data: false
  review:
    required_lanes:
      - dataset-provenance
      - privacy
      - public-claims
      - methodology
      - graph-review

Live update architecture

The live update layer should be conservative and auditable:

1. Dataset adapters fetch or receive data from approved sources.
2. Normalization maps data into a canonical dataset schema.
3. Quality checks detect missing fields, stale sources, outliers, and provenance gaps.
4. Storage preserves snapshots or time-series values with source timestamps.
5. Metric calculators produce initiative indicators.
6. Topic panels render public-facing charts or summaries in Pond/Nest.
7. Consensus draft prompts may suggest public questions based on observed trends.
8. RIPPLE proposals may suggest causal variables or relationships for review.

Public claims discipline

Initiative dashboards should avoid exaggerated causality. For example, the system should distinguish:

• Observed: what the dataset directly shows.
• Operational: what CanuckDUCK directly did, such as units produced or distributed.
• Correlated: what moved at the same time but may have many causes.
• Hypothesized: what RIPPLE or researchers believe may be causally connected.
• Unproven: claims that require more evidence before publication.

This makes the platform more trustworthy: it can show progress while admitting uncertainty.

Research and student opportunity

Students and researchers can contribute modules that evaluate initiatives without requiring access to private data. Examples:

• A student builds a public winter-risk map using weather and shelter-capacity data.
• A researcher builds a methodology module for comparing distribution against need.
• A civic technologist builds a repairability dashboard.
• A policy student proposes Consensus questions based on observed gaps.
• A graph researcher proposes RIPPLE variables that better describe cold-exposure risk.

Recommended SDK additions

1. Add canuckduck.initiative.schema.json.
2. Add canuckduck.metric.schema.json.
3. Add dataset-adapter templates for public/periodic data sources.
4. Add a time-series or snapshot storage pattern for initiative indicators.
5. Add a read-only metric-panel module template.
6. Add a public-claims review checklist.
7. Add examples for Winter Warmth / economical winterwear.

Acceptance criteria for the first initiative-tracking pilot

• An initiative has a manifest that declares datasets, metrics, geography, privacy, review lanes, and RIPPLE expectations.
• At least one dataset updates on a schedule or can be refreshed manually.
• The system stores source timestamps and provenance.
• A Pond or Nest panel displays the current metric state.
• The dashboard separates observed data, operational data, correlations, hypotheses, and unproven claims.
• No personal recipient data or minor/student data is collected.
• The workflow can propose, but not automatically publish, Consensus questions or RIPPLE graph changes.

Positioning statement

CanuckDUCK initiatives should be measurable civic interventions. By binding initiatives to live or periodically refreshed datasets, the platform can track real-world need, operational progress, outcome indicators, and research hypotheses without compromising privacy or overstating causality.