Advice Process Proposal - Consolidate Measures Ownership in Calcs Service

Advice Process Proposal: Consolidate Measures Ownership in Calcs Service

Proposer: Jeremy Parker Date: October 24, 2025 Status: Seeking Advice

Please add/remove yourself as consent or advice stakeholder

Consent

Bomee Jung

Chuck Lin

Maksym Khrystunov

François Huet

Advice

Robin Neri

Naina Shah

Mathieu de Gracia

Problem or Opportunity

Currently, the concept of “measures” is split across two services: Momentum and Calc Service. This creates significant fragility in our system architecture:

Every measure known to the Calc service must have a corresponding ID in the Momentum database
Both applications maintain intimate knowledge of measure objects rather than one consuming them through a defined, tested interface
This tight coupling exposes multiple points of failure and makes the system vulnerable to breakage
The lack of clear ownership and a single source of truth makes maintenance and evolution difficult

Why Now?

The NYCA project requires introducing numerous additional measures. We have a critical decision point: add these measures to the current fragmented architecture, or clean up the code debt first. Addressing this technical debt now will:

Make the NYCA measure additions safer and faster
Prevent compounding the existing fragility
Establish a better pattern for future measure-related work

Proposed Solution

Transfer complete ownership of measures to the Calc Service, since Calc Service is the origin of these objects.

Key Changes

Single Source of Truth: Calc service becomes the sole owner and authority for all measure logic
Reference by Slug: For persistence requirements (e.g., in saved custom scopes) Momentum will reference measures by the Id provided by Calc Service (i.e. a slug). This is similar to how it references other non-Momentum resources like S3 files or EPA Portfolio Manager accounts
API-Based Access: Measure mutual exclusivity and other measure-related logic will live in Calc Service and be accessible via API endpoints

Implementation Approach

Step 1: Introduce Abstraction Layer

Move all Momentum’s Measure model access behind a repository pattern
Replace all ID-based references with slug-based references
No external behavior changes; this is pure refactoring for flexibility

Step 2: Swap Implementation

Replace direct database calls with calls to Calc Service endpoints
The repository abstraction means no other code needs to change
Calc API becomes the interface; Momentum becomes a pure consumer

Reasoning and Benefits

Technical Benefits

Reduced Coupling: Clear service boundaries with defined interfaces
Single Source of Truth: Eliminates synchronization issues between services
Easier Testing: Repository pattern enables easier mocking Calc Service
Faster Development: Services can evolve independently

Business Benefits

Faster NYCA Delivery: Clean architecture allows faster, safer measure additions
Reduced Risk: Less fragility means fewer production issues
Lower Maintenance Cost: Changes to measures happen in one place
Better Developer Experience: Clear ownership and patterns are easier to work with

Risk Mitigation

Incremental Approach: Two-step process allows us to validate each phase
No Breaking Changes: Behavior remains unchanged, so we don’t need a PRD
Rollback Capability: Step 1 creates the abstraction that makes Step 2 reversible if needed

Next Steps

Review this proposal and ask clarifying questions
Schedule Advice Process Meeting with Consent Stakeholders and advisors
Refine proposal based on input
Obtain consent from all Consent Stakeholders
Create detailed implementation plan for both steps
Execute with monitoring and feedback loops

Success Criteria

Step 1 complete with all tests passing and no behavior changes
Step 2 complete with Momentum successfully consuming measures from Calc API
Calc team (Naina) able to add new measures through Calc service only
No increase in measure-related production issues
Improved developer velocity for measure-related changes