Working Standard v0.1

Purpose and status

Working Standard v0.1 is a proposal for discussion, dated 1 November 2026. It is not a ratified standard, certification programme, implemented API or production service. MUST, SHOULD and MAY below express proposed conformance requirements only. No implementation is currently certified against this draft.

CarbonKit began with the 2019 design proposal by Laura Guzman, Stephen Makonin and Alex Clapp. This draft develops an interoperability profile around its common API, personal dashboard, voluntary participation and privacy principles. The paper does not specify the record structures, calculation rules, governance or test suite proposed here.

A Consumer Bill of Rights for Energy Conservation (Makonin, Guzman Flores, Gill, Clapp, Bartram and Gill, 2014) is an additional informative design reference for access, privacy, security, equality, comfort and staged participation. Its proposed rights inform the discussion; this draft does not claim that they are enacted law or already implemented by CarbonKit.

The core scope is voluntary personal activity tracking and transparent emissions estimates. Health and fitness, money-saving tools, social functions and incentives are optional extensions. Each extension needs separate consent and a separate review before implementation.

• Inventory describes estimated emissions associated with recorded activity within a declared boundary.
• A baseline describes a counterfactual or reference scenario; a comparison describes a difference. Neither is an additional inventory item.
• Points, badges and rewards are separate from emissions, money, verified offsets and tradable allowances. No credit issuance, trading or offset verification is defined by v0.1.

Record model and ownership

Providers MUST retain their underlying raw records. CarbonKit coordination MUST be limited to connections, permissions, preferences, goals, progress and the minimum derived summaries needed for the dashboard. Detailed records in this profile are exchanged between an authorised adapter and a private user context; their existence does not authorise central collection.

A separately consented user-controlled vault MAY hold a user export or reproducibility bundle. That vault is an explicit extension to the paper's provider-retention model, not the default CarbonKit database. Its operator, access, retention, recovery and deletion rules MUST be disclosed.

IDs MUST be opaque, stable within their declared scope and free of direct identifiers. A source reference MUST support deduplication within a provider. Pairwise subject references SHOULD differ by provider/client. Pseudonymisation does not make a record anonymous. Private evidence references MUST require authorisation even if the reference is discovered.

Calculation and provenance

• An activity MUST use an explicit unit. Version 0.1 core examples use kWh; other units require a documented method profile and dimensional validation. Carbon output MUST use kgCO2e, not an unlabelled carbon score.
• An estimate MUST retain the exact input values or a recoverable authorised snapshot, their units and a canonical input digest. The method MUST identify the exact input objects and a versioned serialisation rule, including key order, string escaping, number representation and encoding. A digest alone is not sufficient to reproduce a result.
• Each factor MUST record its identifier, version, value and unit, source URI, source-artifact digest, geographical scope, valid period, gas coverage and global-warming-potential basis. Invented factors MUST be visibly labelled synthetic and MUST NOT enter real user inventories.
• The method MUST record the implementation version, expression or resolvable algorithm, allocation choices, boundary, conversions and rounding. Round only for display; preserve unrounded calculation values.
• The method MUST check time, geography and unit compatibility before use. A mismatch MUST fail or produce a separately labelled scenario with an explicit override rationale; it MUST NOT silently replace the applicable factor.
• The estimate MUST declare whether it covers operational emissions, embodied emissions or another boundary. Gaps and exclusions MUST be visible. Different boundaries or GWP bases MUST NOT be silently merged.
• Uncertainty MUST state quantified bounds and their interpretation, or explicitly say unknown with a rationale. Missing uncertainty is not zero uncertainty. Methods MUST NOT manufacture precision from coarse assumptions.

A reproducibility bundle SHOULD contain the method version, factor snapshot, authorised input snapshot, conversion/allocation rules and expected output. If the provider cannot make evidence available, the estimate MUST carry a reproducibility limitation and MUST NOT claim full reproducibility.

The synthetic example distributed with this draft is 10 kWh multiplied by an invented 0.1 kgCO2e/kWh factor, yielding 1 kgCO2e. Its geography is EXAMPLE-ONLY. For this ASCII-only fixture, input_sha256 hashes the complete activity object serialised with Python json.dumps(activity, sort_keys=True, separators=(comma, colon), ensure_ascii=False, allow_nan=False), encoded as UTF-8, with no trailing newline. Comma and colon mean the literal single-character separators. This fixture rule is not a general canonicalisation profile for other implementations. The factor artifact digest hashes the exact UTF-8 bytes of examples/synthetic-factor.txt, also without a trailing newline. It is a schema fixture, not an electricity factor recommendation or an estimate of any person's activity.

Missing data, correction and totals

• Missing activity MUST use a null value and quality=missing with a reason. Zero MUST be a reported or explicitly estimated zero with provenance. A null MUST NOT be coerced to zero in totals or charts.
• Time intervals MUST be half-open [start,end), with RFC 3339 timestamps and offsets. End MUST follow start. Summaries MUST declare the reporting timezone and interval. Methods MUST document allocation across interval boundaries.
• Records MUST be immutable revisions. A correction creates a new ID and a supersedes link to the prior record in the same subject/provider lineage. Cycles, forks and cross-subject supersession MUST be rejected or quarantined for resolution.
• Recalculation under a changed factor/method creates a new estimate revision. The system MUST retain the old method/factor provenance while it remains lawfully retained. A current summary MUST include only the active revision. Historical exports MUST identify the requested as-of time.
• Adapters MUST deduplicate retries with a provider-scoped source reference and idempotency key. Unresolved collisions MUST be shown, not automatically summed.
• Overlapping coverage MUST be resolved by a declared aggregation policy. Whole-home electricity and appliance estimates, or measured electricity and modelled streaming electricity, MUST NOT both be counted for the same consumption. Disaggregation MAY annotate the whole, not enlarge it.
• Inventory, baseline and comparison records MUST be stored and presented separately. Baseline subtraction requires matching periods, boundaries, allocation and assumptions and a named comparison method.
• Summaries MUST show coverage and unresolved overlap alongside a total. Partial coverage MUST be labelled partial; the product MUST NOT imply a complete personal footprint.

Deletion may remove prior revisions and their evidence. In that case an authorised history export MUST report the gap without retaining deleted personal data merely to maintain an audit trail. Non-personal aggregate service metrics require a separate, disclosed retention policy.

Consent, security and lifecycle

• Sharing MUST be opt-in and specific to provider, purpose, recipient and data scope. Health, social, money and incentive access MUST be independently selectable. Refusing an extension MUST NOT block the core tracker.
• Grant and renewal screens MUST explain the data requested, retention, expiry, recipients and effects of revocation in plain language. Clients MUST request only the minimum scope needed. Sensitive disclosure and public sharing MUST be off by default.
• Every data operation MUST enforce the current consent and authorisation at the responsible boundary. Remote services MUST enforce authorisation server-side; local components MUST check the locally valid grant before processing. Revoke MUST stop new synchronisation and block subsequent reads under that grant immediately; queued jobs and caches MUST check revocation before use. Previously exported copies cannot be remotely recalled; this limitation MUST be disclosed.
• Transport MUST be encrypted. Private records MUST be encrypted at rest with per-user isolation and a documented key/recovery design. Secrets MUST stay out of browsers, public repositories, URLs and logs. A profile ID MUST NOT function as an access token.
• Audit records MUST capture grant, access, correction, export and deletion events with minimal personal detail. Operations staff MUST use least privilege. Retention periods, backup purge windows and lawful exceptions MUST be disclosed before collection.
• Users MUST be able to export their authorised activity, estimates, factors and provenance in a documented machine-readable format, including coverage, revisions and schema version. Exports MUST omit reusable access tokens.
• Users MUST be able to request deletion and see completion status. The operator MUST publish a deletion target, maximum backup expiry, provider handoff process and exception policy before a pilot; unresolved deletion failures MUST remain visible. Deletion from CarbonKit MUST NOT be presented as deletion from an independent provider unless confirmed.

This public website is static project documentation. It has no account system, activity ingestion, carbon calculator, analytics script or application database. GitHub serves the pages under its own service policies; contacting volunteers uses the visitor's email application.

Interchange, conformance and governance

Download the proposed activity schema, estimate schema, synthetic activity, synthetic estimate and invented factor artifact. The core shape profile currently covers electricity in kWh; other categories require a reviewed profile.

The proposed transport is HTTPS with UTF-8 JSON and an explicit spec_version. A future API profile should define resource paths, scoped authentication, pagination, idempotency, error codes and retry rules. Those interfaces are design work, not existing endpoints. Version 0.1 here provides record schemas and fixtures only.

Required fields MUST NOT change meaning within a minor version. Breaking changes need a new major profile and a migration guide. The 0.1 shape profile rejects unknown fields and unsupported versions. Extension namespaces are deferred to a later reviewed profile. Clients MUST never silently reinterpret unknown units or categories. JSON Schemas check record shape; semantic checks below are also required.

Conformance claims require an identified implementation version, profile version, test evidence, exceptions and independent review. Passing the distributed shape/fixture checks alone does not establish full conformance. No conformance badge is offered by this draft.

Proposed governance: discuss changes through repository issues and pull requests; publish rationale, compatibility and privacy/method impacts; invite at least one software reviewer and one carbon-method or privacy reviewer for affected changes. Maintainer roles and decision rules remain to be agreed. Volunteer interest does not constitute an appointment or partnership.

Open decisions before v0.2: pilot geography and categories; approved factor sources and licensing; GWP basis; user-vault custody and keys; consent protocol; deletion deadlines; governance; accessibility review; and evidence thresholds for modelled estimates.