CarbonShift: AI Energy Planning & Emissions Transparency

Plan household electricity use at cleaner times with AI and live grid data. Compare CO₂ estimates, coordinate your day, and verify published records on blockchain.

Comment

Inspiration

At the end of a long day, the laundry still needs washing. The floor needs cleaning. A student needs their computer. A family might want an hour of television together.

These are ordinary needs, woven into ordinary lives.

Yet the environmental information behind those decisions is difficult to see. We can choose when to run an appliance, but we rarely know how the electricity supplying it changes through the day—or whether moving that activity would make a meaningful difference.

That led me to the question behind CarbonShift:

Could a useful climate decision become as understandable as planning tomorrow’s chores?

I wanted to build something people could relate to immediately. Something that respected their responsibilities, available time and existing equipment. A person should be able to say, “This is what I need to do, this is when I am free, and this is the energy information I have,” and receive a clear, practical comparison.

But helping someone choose a time was only half the problem.

If a platform displays a carbon estimate, a reasonable person should be able to ask:

  • Where did the energy assumption come from?
  • Which grid data was used?
  • What was the original plan?
  • What changed?
  • Can another person reproduce the calculation?
  • Has the record been altered since it was published?

CarbonShift brings those questions into the same workflow as the household decision itself.

Its purpose is to make everyday electricity use easier to understand, more practical to plan, and more transparent to inspect.

What it does

CarbonShift is a household electricity simulator and planner with transparent emissions estimates and optional blockchain records.

It connects three things: a person’s routine, the grid data relevant to that routine, and an inspectable record of the comparison.

1. Understand an everyday activity

The simulator supports twelve activity categories, including clothes washing, dishwashing, tumble drying, television, computers, lighting, fans, vacuuming, ironing, car cleaning, charging and custom activities.

A user enters the active duration, number of devices and an energy basis:

  • Operating power in watts.
  • Energy per device or cycle in kWh.
  • A reviewed reference for a listed appliance.
  • An explicit declaration that the activity uses no direct electricity.

CarbonShift then estimates electricity use and the associated grid CO₂ for the selected time. The result shows its assumptions, source information and a breakdown across the relevant grid intervals.

For example, a television modeled at 100 watts for two hours uses 0.2 kWh under that operating assumption. Its CO₂ estimate depends on the grid factors covering those two hours.

That distinction matters: the appliance energy comes from a reviewed input; the grid factor comes from the data service. AI does not become an invisible authority on an unknown device’s wattage.

2. Find a feasible time for one or several tasks

The task planner compares a user’s usual schedule with feasible alternatives.

Users choose their available windows, deadlines and any periods when a task cannot run. They can keep an appointment fixed, identify shared equipment, indicate when an activity needs their attention, and require one task to finish before another starts.

The comparison keeps the task’s energy, duration and quantity constant. This makes the effect of changing its timing visible.

A result can show a lower estimated CO₂ total, an alternative schedule, or no estimated improvement within the supplied constraints. If the window is too short, CarbonShift explains the problem. Users can also request a separate comparison with a modest window extension and review that proposal before applying it.

The user remains in control of the decision.

3. Plan a whole household day

A household routine is more complicated than a single appliance.

Consider laundry, vacuuming, ironing and an evening television session. Laundry should finish before ironing. Two activities may need the same socket. Someone may need to be present throughout an activity. Television time might already be fixed.

CarbonShift’s separate day planner handles up to twelve activities within a selected London calendar day. It brings those constraints into one schedule and compares the combined estimate with the user’s explicit baseline.

This is the practical heart of the project: a recommendation must fit the life of the person expected to follow it.

4. Preserve the plan and report what happened

Accepted schedules are saved privately with the forecast and assumptions used at acceptance.

Later, users can report each activity as completed or skipped, identify its actual start, and confirm whether the accepted energy assumptions still apply. Updated comparisons use retrospective grid factors where available.

Corrections append to the history. They do not silently rewrite the original plan.

If some activities remain unreported or grid factors are incomplete, the interface shows that missing coverage. A partial result is identified as a partial result.

5. Publish an inspectable record

Publication is optional and requires a separate review and consent step.

A user can inspect the exact public copy before requesting a commitment on the Ethereum Sepolia test network. The public receipt connects the disclosed plan, calculation method, result revisions and transaction references.

An exported proof bundle can then be checked locally in the browser. The verifier separates calculation checks from checks that require chain observations.

Track alignment: CarbonShift addresses the emissions-transparency side of Carbon Markets & Emissions Transparency. Its contribution is a practical route from household electricity assumptions to reproducible estimates and records whose integrity can be checked.

The prototype does not issue carbon credits. Its environmental amounts remain estimates with explicit evidence boundaries.

How I built it

I built CarbonShift as a solo developer, using AI coding assistance to support implementation while keeping the product contracts, calculations and integration boundaries explicit.

The system separates the interface, domain calculations, external services, persistence and blockchain worker. This keeps a model response or a network failure from silently changing the underlying accounting rules.

A web application built around distinct user decisions

The frontend uses Next.js, React and TypeScript, deployed on Vercel.

Simulation, task planning and day planning have separate workspaces. Saved reports, public receipts, methodology and file verification also have dedicated views.

The interface follows a restrained paper-and-forest-green design. Useful detail appears alongside the decision it explains: energy assumptions near inputs, constraints before comparison, source information beside estimates, and disclosure information before publication.

Google and GitHub authentication connect to Supabase, which provides PostgreSQL persistence and account access. Row-level security and server ownership checks protect private records.

Live grid data with explicit provenance

CarbonShift retrieves Great Britain national carbon-intensity forecasts and retrospective factors from the NESO Carbon Intensity API.

Responses are validated before use. Snapshots preserve their source, retrieval time and normalized intervals. Planning requires sufficiently fresh data and complete coverage of the requested range.

The current implementation uses a 48-hour forecast horizon, the GB national signal, and Europe/London scheduling.

A missing factor remains unavailable. An expired forecast does not become a successful result simply because an older value exists.

Transparent electricity and carbon calculations

For a constant-power scenario, the basic electricity relationship is:

$$ E_{\mathrm{kWh}} = \frac{P_{\mathrm{W}} \times t_{\mathrm{hours}} \times n}{1000} $$

Here, power, active duration and device quantity come from the confirmed input.

For carbon accounting, energy is allocated across its overlapping grid intervals:

$$ C_{\mathrm{gCO_2}} = \sum_i E_{i,\mathrm{kWh}} \times I_{i,\mathrm{gCO_2/kWh}} $$

The comparison then calculates:

$$ \Delta C = C_{\mathrm{usual}} - C_{\mathrm{selected}} $$

The implementation uses integer energy units and exact intermediate arithmetic, with defined rounding rules. Displayed interval rows are explanatory; rounding those rows does not determine the authoritative total.

These calculations are deterministic and versioned. They can be reproduced without asking a language model to generate the answer.

Scheduling that respects constraints

The scheduling engine evaluates candidate starts on a five-minute grid, together with relevant window boundaries, blocked-period boundaries, fixed starts and the explicit baseline.

It checks that activities fit their windows, respect dependencies and avoid conflicts involving shared equipment or user attention.

The search is bounded. Its result distinguishes a completed search within the candidate set from the best feasible result found before reaching the search budget.

This makes the scope of the recommendation inspectable instead of presenting every result as an unlimited mathematical optimum.

Two bounded AI roles

The application integrates Gemini and Groq through a policy-controlled routing layer.

AI has two deliberately limited responsibilities:

  1. Interpret a household request into editable fields. Missing or ambiguous information should remain a question for the user.
  2. Help explain a saved comparison. Explanations select from facts established by the calculation engine.

The user reviews interpreted fields before comparison. A model cannot independently save a plan, change its energy basis, operate equipment or publish a record.

Model eligibility is specific to the role and variant that was evaluated. Shared quotas, request deduplication, bounded attempts, timeouts and checked explanation caching control external requests. Qualified fallback routes are used where available; the manual editor and deterministic comparison remain usable when assistance is unavailable.

Blockchain for record integrity and chronology

The ShiftReceipt smart contract is written in Solidity, with OpenZeppelin ownership controls and Viem integration.

Public manifests are serialized consistently and hashed using SHA-256. The contract records commitments to the plan and method, together with their timing and issuer context.

Later result commitments follow a revision sequence linked to the preceding result hash. Contract guards reject duplicate receipt identifiers, invalid revision order and inconsistent previous-result references.

A separate worker submits and reconciles transactions. The application distinguishes queued, pending, uncertain, failed and confirmed operations.

The chain holds commitments; the exported bundle carries the disclosed evidence needed to reproduce the record.

The browser verifier checks seven separate areas:

  • Format and limits.
  • Recorded commitment.
  • Known calculation method.
  • Reproducible calculations.
  • Commitment timing.
  • Result revision history.
  • Evidence disclosures.

The issuer is an application operator, and chain observations have an explicit trust source. A matching commitment establishes consistency with recorded content; it does not prove that an appliance physically ran.

Challenges I ran into

Making recommendations fit real lives

A low-intensity interval can be useless if someone is at work, equipment is occupied or a prerequisite activity has not finished.

Expanding from a washing-only baseline into a household planner required a richer constraint model and a feasible baseline for the complete routine.

The resulting engine respects fixed activities, availability, task order, shared resources and attention. That made the project more useful than an isolated “best time” suggestion.

Handling time correctly across locations

I was building from India while the prototype schedules against Great Britain’s grid.

A browser’s local date can differ from the selected London day. Daylight-saving transitions introduce repeated or nonexistent local times. Overnight availability is also different from a calendar-day plan.

I made London scheduling explicit, converted accepted times into UTC instants, preserved occurrence choices for repeated hours and enforced day boundaries separately from general task windows.

Keeping estimates honest

An appliance rating is not necessarily its average consumption. A forecast is not a measurement. A completion report is a user declaration.

Those differences had to survive the entire workflow—from input to saved report to public proof.

I introduced explicit energy sources and limitations, preserved missing values, separated original forecasts from updated estimates, and prevented incomplete coverage from becoming a whole-day result.

Preventing AI convenience from becoming hidden authority

AI interpretation can make input easier, but a confident response can still omit a deadline or misunderstand equipment.

I used strict schemas, clarification questions, editable suggestions and role-specific evaluations. Unsupported or unevaluated routes remain excluded. Unknown energy should produce a request for information rather than an invented number.

Connecting database state to asynchronous transactions

A successful web request does not mean a blockchain transaction has confirmed.

Publication required a durable queue, retry controls, reconciliation and clear status reporting. The signer also needed to remain outside the web application.

Preserving those distinctions made the blockchain integration more demanding—and more meaningful—than displaying a transaction-shaped success message.

Accomplishments I'm proud of

I am proud of taking CarbonShift from a narrow appliance planner to a connected household workflow while preserving the integrity of earlier records.

The implemented prototype includes:

  • Separate simulator, task-planner and day-planner workspaces.
  • Twelve activity categories and support for up to twelve planned activities.
  • Real national grid data with source and retrieval details.
  • Transparent energy inputs, baselines, constraints and alternatives.
  • Immutable accepted schedules and append-only reporting histories.
  • Evaluated, bounded AI assistance with manual recovery.
  • Actual Sepolia commitments, public receipts and portable proof bundles.
  • A browser verifier that reproduces calculations and separates its evidence checks.
  • A live web deployment and public source repository.

The engineering evidence includes automated unit and component checks, isolated PostgreSQL integration checks, local contract tests, production-build browser checks and targeted live integration journeys.

For the expanded AI workflow, a recorded development evaluation passed 24 authored household interpretation cases, and a separate evaluation passed six grounded explanation scenarios. These are bounded development results, not a claim of universal accuracy.

The project also has a public receipt linked to an actual Sepolia transaction.

Those records use authored inputs and modeled estimates. They demonstrate functioning integration and inspectable evidence, not measured household emissions savings.

Most importantly, a person can complete the core planning workflow with an ordinary browser, reviewed device information and their available time. They do not need to buy smart hardware or learn to manage a cryptocurrency wallet.

What I learned

I learned that useful climate software needs to respect both the environment and the person making the decision.

A recommendation becomes more valuable when it acknowledges that someone has a job, a shared appliance, a deadline or a fixed family routine. Supporting those constraints is part of the climate intervention itself.

I also learned how much trust depends on preserving distinctions:

  • Estimated electricity versus measured electricity.
  • Forecast factors versus retrospective factors.
  • A planned activity versus a reported activity.
  • A covered subtotal versus a complete result.
  • A consistent blockchain record versus verified physical behavior.

Each distinction changes what a user or reviewer can reasonably conclude.

AI proved most useful when its authority was bounded and its output could be reviewed. Blockchain proved useful when it preserved a specific record and chronology that another person could inspect.

The strongest technical feature is sometimes the system’s ability to say, clearly, “This is what we know—and this is what remains unknown.”

What's next for CarbonShift

The next step is to validate the workflow with people who have genuinely flexible household loads, including residents of shared homes and small community spaces.

The priorities are:

  1. Run a focused user pilot. Study whether people understand the assumptions, can express their constraints and actually find the recommendations practical.

  2. Introduce measured energy inputs. Optional meter or smart-plug integrations could improve the energy basis while retaining clear separation between measurements, ratings and estimates.

  3. Evaluate environmental benefit carefully. Measure adherence, forecast changes and updated comparisons. Assess the method’s limits and the system’s operating overhead before making broader impact claims. Average grid-intensity accounting alone does not establish marginal avoided emissions.

  4. Expand regional coverage through validated adapters. Additional regions need suitable data, local time handling and explicit method boundaries. The current prototype remains limited to the GB national signal.

  5. Strengthen deployment operations. Move the publication worker from local operation to suitable continuous hosting, complete remaining provider deployment prerequisites, and finish the deferred spoken screen-reader review.

  6. Improve assistance through targeted evaluation. Extend household-language coverage while preserving human review and qualification requirements for every newly enabled route.

CarbonShift’s contribution is the connection between an understandable household decision and a record that can be examined afterwards.

A person should be able to ask whether a different time would fit their day. They should be able to see the assumptions behind the answer. And if they choose to share that answer, another person should be able to inspect how it was produced.

Everyday routines are where CarbonShift begins. Transparent, practical climate decisions are what I want it to make possible.

Built With

Share this project:

Updates

Submission history