Proposal / Working draft 0.1 / 1 November 2026
Architecture & rollout
A proposed path from open documentation to tested adapters and a consented pilot.
Copyright © 2026 Stephen Makonin. Draft documentation.
Reference architecture: proposed boundaries
This architecture is a staged implementation proposal. The live public site publishes documents only. No user vault, adapter service, consent service or private dashboard described below has been deployed.
| Component | Responsibility and boundary |
|---|---|
| Public project site | Static GitHub Pages content: paper attribution, draft, schemas, examples and volunteer contact. No private records or credentials. |
| Provider and adapter | Raw data remains with the provider. An authorised adapter maps minimum required observations into a private user context, validates units and coverage, and supplies provenance. It may run provider-side or locally. |
| Private user context | User device or separately consented vault holds detailed authorised records and evidence. The dashboard reads these within the user boundary. Device loss and key recovery need an explicit design. |
| Calculation module | Runs locally or in the consented private context. Uses pinned methods and versioned factors; produces immutable estimates with uncertainty and exclusions. No provider-to-provider raw data sharing. |
| Minimal coordination | Stores connections, consent state, preferences, goals, progress and necessary derived summaries. It does not act as a central raw activity warehouse. Opaque pairwise identifiers link authorised contexts. |
| Factor/method registry | Versioned non-personal artifacts, source licenses, checksums, units, valid times, geography and method profiles. A factor revision never silently rewrites historical estimates. |
| Optional extensions | Health, money, social and incentives are separate capabilities, off by default. Each has purpose-limited scopes, separate storage and an agreed review before enablement. |
Proposed flow: provider raw record -> consent check -> adapter -> private activity record -> versioned calculation -> private estimate -> minimum derived dashboard summary. Factors flow from the registry into the calculation. Revocation signals reach adapters, calculations, caches and coordination before further processing.
The dashboard must explain what was counted, what is missing, why an estimate changed and which connections have access. It should support the paper's motivate, track, inform, adjust, reward loop without promising a measured behavioural or health effect.
Privacy, operations and failure behaviour
- Threats to test include cross-user data access, token theft, public evidence links, insider access, provider correlation, reidentification from detailed timestamps, duplicate/replayed data and unsafe factor substitution.
- Use short-lived scoped provider tokens where supported, isolated user keys, auditable access and explicit recovery choices. The pilot must document who can decrypt records; encryption alone is not a complete privacy design.
- A provider outage yields stale/partial coverage and last-success time, not fabricated zeros. Failed jobs retry within bounds and use idempotency keys. Provider rate limits and revocation take precedence over retries.
- Validate incoming records before calculation. Quarantine invalid units, impossible intervals, missing provenance and unresolved overlap. User-visible summaries distinguish stale, missing, synthetic and scenario-only data.
- Exports use authenticated, time-limited delivery with an expiry. Logs redact credentials and raw activity. Backups follow the published purge schedule. Restore tests must prove deleted grants do not resume sync.
- A documented incident process must identify an owner, stop affected connectors, revoke credentials, assess exposed data and communicate with affected participants through an approved channel. No incident response team is currently claimed.
Design review gate: a data-flow inventory, threat model, retention/deletion schedule, consent screens, key custody/recovery plan and cross-user access tests must be complete before any real personal data pilot. Applicable legal obligations need jurisdiction-specific review before collection; this draft is a technical proposal, not legal advice.
The 2014 Consumer Bill of Rights for Energy Conservation adds a consumer-centred design reference alongside StreamingCalc. Its proposals support affordable, understandable feedback, local processing, secure communications and conservation choices that respect essential comfort. Before a pilot, review access barriers and options for staged participation and re-entry. These are proposed CarbonKit applications of the paper, not an implemented service or a statement of current law. See the consumer-rights research note for all seven articles and the full citation.
StreamingCalc: a concrete integration candidate
Inspect the pinned repository · Read the StreamingCalc paper
The inspected StreamingCalc main revision is f75d50924d1cc621f40d3a80052e54983787b424 (27 May 2022). It provides a macOS Numbers model for estimating streaming-video electricity consumption, accompanying research material and references. It is not an executable web API or a CarbonKit connector. Its README seeks volunteers for a Python version.
A suitable first adapter would accept duration and streaming assumptions, compute a documented electricity estimate, emit an activity record with quality=estimated and kWh units, and attach a versioned model manifest. A separately reviewed carbon method would apply appropriate electricity factors to create kgCO2e estimates. kWh is not kgCO2e.
| Mapping | Proposed treatment |
|---|---|
| Inputs | Duration, download rate, simultaneous streams, data-centre demand, core/local-network intensity or demand, device power and manufacturing assumptions. Preserve units and the exact model version. |
| Boundary | Separate data centre, core network, local network, device and embodied proxy assumptions. Geography and electricity-factor coverage may differ by component; do not assign the user's grid factor to all components without justification. |
| Output | Estimated electricity per stream plus model assumptions/limitations. For carbon, use component-aware factors or declare a limited scenario. No claim of measured household consumption or avoided emissions. |
| Overlap | If whole-home electricity already includes local network/device use, allocate or annotate those components rather than adding them again. Remote components need a separately declared inventory boundary. |
| Validation | Audit workbook formulas and sources, then port with permission-compatible attribution; compare outputs against frozen workbook fixtures within a declared tolerance. Reproduce component totals and allocation under multiple stream counts. |
StreamingCalc carries an MIT license (copyright 2022 SFU Computational Sustainability Lab); CarbonKit's existing AGPL-3.0 license is preserved. Retain StreamingCalc notices and the requested paper citation in any port, and review copied material's individual licenses. The paper and third-party reference PDFs are not relicensed by this website.
StreamingCalc research citation: S. Makonin, L. U. Marks, R. Przedpelski, A. Rodriguez-Silva and R. ElMallah (2022), Calculating the Carbon Footprint of Streaming Media: Beyond the Myth of Efficiency. Eighth Workshop on Computing within Limits. DOI: 10.21428/bf6fb269.7625cc76. Its historical UK scenario and assumptions are not unqualified current defaults.
Rollout with evidence gates
The following sequence is proposed and depends on volunteer capacity. No delivery dates, participant numbers, funding or current partners are asserted. Advance only when the prior gate has evidence; record what was learnt before expanding scope.
| Stage | Deliverable and acceptance gate |
|---|---|
| 0 - Public foundation | Publish this site, paper review, draft, schemas and source. Check links, mobile/keyboard access, Pages deployment and domain HTTPS. Invite issues and volunteers; agree maintainers and review responsibilities. |
| 1 - Interoperability sandbox | Use synthetic records only. Implement record validation, reproducible calculations, correction, duplicate/overlap rules and export. Gate: all core conformance scenarios pass in two independently written adapters; disagreement is documented and resolved. |
| 2 - StreamingCalc adapter | Audit/port the workbook with a method manifest and frozen fixtures. Gate: independent review of formulas, component allocation, units, uncertainty and carbon mapping; repeatable results and clear overlap treatment. Electricity-only output is acceptable until carbon methods are reviewed. |
| 3 - Consented pilot | Choose geography, category and approved factors; complete privacy/security and accessibility reviews. Gate before collection: consent/revoke/export/delete demonstrations, cross-user isolation, backup expiry, incident owner, participant information and approvals required for the chosen setting. |
| 4 - Evaluate and revise | Measure coverage, reproducibility, error/correction rates, lifecycle completion and participant understanding. Publish limitations and changes. Behavioural/health benefits require an appropriate study design and evidence; usage alone does not establish them. |
| 5 - Optional extensions | Consider health, money, social and non-tradable rewards one at a time, with separate consent, method and equity review. Allowances, trading and verified offsets remain outside v0.1 and would require a separate policy and assurance framework. |
Pilot operating measures should report provenance completeness, calculation replay success, duplicate/overlap resolution, consent-revocation latency, deletion completion/backup expiry, accessibility task success and participant comprehension. Set targets before recruitment; publish denominator, missingness and method with each result.
Call for volunteers
CarbonKit invites collaborators to help turn a research proposal into a careful, useful open platform. Interest is welcome from people with lived experience and from people learning a field, as well as established specialists. Roles are proposed work areas, not claims of an existing team or funded positions.
| Work area | A useful first contribution |
|---|---|
| Standards and interoperability | Review one record shape, field definition or correction/overlap case; propose a fixture. |
| Carbon methods | Review units, factor provenance, boundaries, geography and uncertainty for one activity category. |
| Software | Audit a StreamingCalc formula, prototype an adapter or improve validation and reproducibility. |
| Accessibility and usability | Try navigation, keyboard use, screen-reader structure and plain-language consent explanations. |
| Privacy and security | Review a data flow, key/recovery choice, revocation case or deletion/backup procedure. |
| Community and governance | Help define inclusive participation, documentation, review processes and what success should mean. |
Contact Stephen Makonin at smakonin@sfu.ca with your area of interest, a possible first contribution and your availability. The website's volunteer link opens a draft in your email application; it does not send a message automatically. Please do not include sensitive personal data or provider credentials.