Part of a set of structural observations — see #1695 (index) for context.
Description
Computing emissions for a platform isn't one problem, it's an open-ended one: every installation has its own mix of compressor trains, pump layouts, turbines, and idiosyncratic equipment specs, and no fixed enumeration of cases is ever complete. A closed vocabulary of keywords (yaml_keywords.py currently defines 158) is the wrong tool for a problem that is not enumerable: it either stays permanently incomplete, or it grows indefinitely chasing new cases.
class ConsumerFunction(ABC), defined in domain/infrastructure/energy_components/legacy_consumer/consumer_function/consumer_function.py, is a genuine extension point — a stable interface (implement .evaluate(...), return an energy-usage result) that a new kind of equipment behavior could satisfy without eCalc's own maintainers touching anything else. But it isn't mentioned anywhere in the public docs. As it stands, supporting a new kind of equipment isn't "implement this interface" for a user — it requires the eCalc team to add a new Union member, a new YAML type, a new DTO, a new mapper case, and a new keyword, then cut a release. Regulatory/compliance reporting only requires controlling what ships as officially certified; it doesn't require hiding the interface's existence.
Examples
No code example — this is a request to document/expose an existing internal interface, not new syntax.
Business/User Value
Users and integrators with equipment that doesn't fit an existing keyword currently have no path forward except filing a feature request and waiting on a release. Documenting ConsumerFunction as a supported extension point would let that class of need be met without expanding the closed vocabulary indefinitely, while eCalc retains full control over what ships as officially certified.
Files
yaml_keywords.pydomain/infrastructure/energy_components/legacy_consumer/consumer_function/consumer_function.py
Part of a set of structural observations — see #1695 (index) for context.
Description
Computing emissions for a platform isn't one problem, it's an open-ended one: every installation has its own mix of compressor trains, pump layouts, turbines, and idiosyncratic equipment specs, and no fixed enumeration of cases is ever complete. A closed vocabulary of keywords (
yaml_keywords.pycurrently defines 158) is the wrong tool for a problem that is not enumerable: it either stays permanently incomplete, or it grows indefinitely chasing new cases.class ConsumerFunction(ABC), defined indomain/infrastructure/energy_components/legacy_consumer/consumer_function/consumer_function.py, is a genuine extension point — a stable interface (implement.evaluate(...), return an energy-usage result) that a new kind of equipment behavior could satisfy without eCalc's own maintainers touching anything else. But it isn't mentioned anywhere in the public docs. As it stands, supporting a new kind of equipment isn't "implement this interface" for a user — it requires the eCalc team to add a newUnionmember, a new YAML type, a new DTO, a new mapper case, and a new keyword, then cut a release. Regulatory/compliance reporting only requires controlling what ships as officially certified; it doesn't require hiding the interface's existence.Examples
No code example — this is a request to document/expose an existing internal interface, not new syntax.
Business/User Value
Users and integrators with equipment that doesn't fit an existing keyword currently have no path forward except filing a feature request and waiting on a release. Documenting
ConsumerFunctionas a supported extension point would let that class of need be met without expanding the closed vocabulary indefinitely, while eCalc retains full control over what ships as officially certified.Files
yaml_keywords.pydomain/infrastructure/energy_components/legacy_consumer/consumer_function/consumer_function.py