DEV Community: Ace-2504

Turning Behaviour into Climate Accountability

Ace-2504 — Tue, 24 Feb 2026 18:57:22 +0000

One winter morning in Delhi, the AQI crossed 460 — officially hazardous. Schools shut. Hospitals filled. Transport slowed. Offices continued. Every day, millions of environmental decisions are made. Whether to drive or take public transport. Whether to allow remote work. Whether to burn waste or compost. These choices influence emissions — yet we rarely measure the pollution that did not happen because of them.

That is the missing piece.

Most environmental systems measure what exists: current emissions, fuel consumption, air quality levels. They do not formally measure avoided emissions. Counterfactual attribution addresses this gap by comparing two clearly defined scenarios:

Business-as-usual baseline — what would have happened
Verified alternative — what actually occurred

Impact = Baseline − Verified Alternative.

A Practical Example: Urban Commuting
Consider a professional living 14 km from work. A 28 km daily round trip in a petrol car (≈ 120 g CO₂/km) results in about 3.36 kg CO₂ per day. Across 240 working days, that equals approximately 806 kg CO₂ annually. That is the baseline.

Now introduce two behavioural shifts:

Work from home two days per week → avoids ~322 kg per year
Shift to electric metro on remaining days (≈ 15 g CO₂/km) → saves ~423 kg

Total avoided emissions ≈ 745 kg CO₂ Remaining footprint ≈ 61 kg

That is a reduction of over 90%, derived from a measurable behavioural delta — not offsets, not assumptions.

If the remaining 61 kg is neutralised through verified sequestration (e.g., monitored urban trees at ~10 kg per tree annually), the commuting footprint approaches net zero.

Baseline → Reduction → Net Impact. Each step is quantifiable.

Preventing Double Counting
A critical issue emerges: duplication.

If an employee reports work-from-home reductions, and their employer's HR department also reports the same reduction in ESG disclosures, total claimed impact exceeds actual impact.

To prevent this, the framework introduces a non-duplication constraint.

Let:

Δ_total = Verified avoided emissions
C_i = Claim attributed to entity i

The system enforces:

Σ Cᵢ ≤ Δ_total

No combination of claims may exceed the verified delta.

Each reduction event is assigned:

A unique registry ID
A defined ownership tag
A claim status flag

Work-from-home emissions may be attributed to the enabling institution, while individual dashboards reflect behavioural contribution — without generating duplicate claimable credits unless formally allocated.

This ensures:

Measurability
Additionality
Non-duplication
Audit defensibility

Without duplication control, avoided-emission accounting collapses under verification.

Enterprise Implications
Most sustainability reports rely on estimated participation and averaged emission factors. A verification-first counterfactual architecture instead:

Establishes defined baselines
Verifies behavioural change in a privacy-preserving manner
Models avoided emissions at corridor level
Applies attribution constraints
Produces audit-ready metrics

Under such a system, work-from-home is not merely HR flexibility. It becomes measurable climate infrastructure.

The Broader Shift
This logic applies anywhere a conservative baseline can be defined:

Agricultural burn avoidance
Household waste diversion
Fuel switching in buildings
Distributed renewable adoption
Industrial efficiency upgrades

For decades, climate systems focused on measuring what we emit.

The next frontier is measuring what we prevent — without inflation, without duplication, and without ambiguity.

Climate accountability will not be built on slogans.

It will be built on baselines, constraints, and verifiable delta.

Patent Filed, 2026. A technical paper detailing the verification-first MRV architecture, statistical bias bounds, and attribution constraints is under preparation.

How McKinsey Frameworks Fixed My Scattered API

Ace-2504 — Sun, 04 Jan 2026 15:51:33 +0000

While building the backend for Ace Rentals, I realized that my authorization logic, although functionally correct, felt increasingly fragile. Ownership checks were scattered across multiple routes, duplicated in several places, and easy to forget when adding new endpoints. Over time, this made the system harder to reason about and increased the risk of subtle security gaps.

Rather than continuing with incremental fixes, I stepped back and redesigned authorization as a system-level concern using centralized middleware. This article explains how I identified the issue, how I reasoned about the redesign, how it was implemented, and what improved as a result.

Previous Authorization Approach

Authorization checks were implemented directly inside individual route handlers. Each protected endpoint contained its own logic to verify whether the current user was allowed to perform the requested action.

While this approach worked initially, it introduced several challenges as the application grew:

The same ownership logic was copied across multiple routes
Route handlers mixed business logic with authorization concerns
Adding new endpoints required manual checks, increasing the chance of mistakes

The system did not fail outright, but correctness increasingly depended on careful and repetitive implementation.

Identifying the Design Issue

The problem was not a missing check or a faulty condition—it was a structural issue. Authorization was treated as an implementation detail instead of a rule enforced consistently by the architecture.

This meant security relied on developer memory rather than system guarantees. As the number of routes increased, so did the effort required to maintain consistency and confidence in the design.

Design Analysis and Decision-Making

To avoid patching individual routes, I analyzed the problem at a design level.

I used MECE-style analysis to verify whether authorization was applied consistently across all relevant routes. This exposed gaps and overlap in enforcement.
I compared alternative approaches and found that centralized middleware offered the best balance between reuse, clarity, and maintainability.
I set clear constraints for the refactor—no change in behavior, minimal surface area, and focused scope—to avoid unnecessary complexity.

This structured approach helped ensure the redesign addressed the root cause rather than its symptoms.

Authorization Redesign and Implementation

Authorization was elevated to a system-level concern and implemented through middleware:

Ownership checks were consolidated into a single, reusable middleware function
API endpoints were reorganized around resources rather than actions, improving clarity
Authorization was enforced early in the request pipeline, before any business logic executed

With this setup, routes automatically inherit authorization rules. Developers no longer need to remember to reapply checks when adding or modifying endpoints.

Observed Impact of the Redesign

The redesign produced clear and measurable improvements:

Authorization logic now exists in one place instead of being duplicated
All protected routes enforce authorization consistently by default
Maintenance effort and regression risk were significantly reduced
Resource relationships are clearer through resource-based routing
Route handlers are simpler and focus only on business logic

A qualitative review showed that core domain logic is stable. Remaining risk is isolated to shared authorization middleware, where it is explicit, visible, and easier to reason about.

Key Learning

Repeated logic is often a signal of a deeper design issue. Treating security as a structural concern—rather than a manual step—leads to systems that are easier to maintain, extend, and trust over time.

Design Decisions and Learnings

This article provides a high-level summary of the decisions and outcomes from redesigning authorization in Ace Rentals.

For a deeper look into my learning experience—including diagrams, structured reasoning, trade-offs, and implementation details—you can read the full write-up here:

👉 https://ace-2504.github.io/api-design-blog/

The full version documents the complete thought process and lessons learned while designing and refactoring the system.