In this release, we are adding additional data streams to the response object to support an API user's development.

The following keys were added:

In this minor update, we've added to the response object of the and endpoints.

Users can access the carbon intensity in the endpoint by returning .

Users can access the carbon intensties in the endpoint by returning . This object follow the same structure as the other keys in the response, and will return all three levels of specification (Conservative, Best Practices, and Low Carbon), along with the data source and units of the carbon intensity.

In this update, we have enhanced the granularity of the timeseries response object; users will be able to view cumulative operational emissions with more resolution, alongside their annual emission counterparts. Additionally, we have made significant improvements to our testing suite, expanding coverage for the /carbon-intensities endpoint. Lastly, we have adjusted the validation process for the C.Scale parameters, specifically for primary percentages related to and . This change aims to provide more flexibility when a second and/or is not explicitly specified.

We've added , , annual emissions to the timeseries object.

We've also added , , and cumulative emissions, these break down the categories that make up operational emissions (fossil fuels, refrigerants, and electricity).

If there is no explicitly defined, the validation for has been loosened to accept values other than . If the user inputs a value other than and there is no secondary and/or , the model will default this value back to and the user will see and/or .

: "Primary use percentage does not equal 100% when a secondary use category has also not been defined. Primary use percentage has been defaulted back to 100%."

: "Primary structural system percentage does not equal 100% when a secondary structural system has not been defined. Primary structural system percentage has been defaulted back to 100%."

We've expanded our regression testing suite to include the endpoint. This allows us to monitor and report changes to this endpoint that happen in the course of development.

With this update, bills of materials for glazing assemblies are calculated live with each request, rather than preprocessed and then intermittently uploaded. The updates in performance with our re-deployment to AWS Lambda made this possible, and we will be extending this approach to other assemblies in the balance of 2024.

Moving forward, every request to the API will generate a bill of materials for glazing assemblies rather than referencing "pre-baked" bills of materials or carbon intensities. This allows for more precise regionalization of results. The background refactoring necessary to make a transition to a dynamic bill of materials-based approach possible for all other assemblies in C.Scale's calculation engine.

Since the background data previously used and the new approach take the same approach and are based on the same methodology, there new results are within 1-5% of calculations in previous versions.

With the recent improvement to below-grade excavation and structural emissions, a minor difference in calculation for below-grade floors had opened up between the simple and stacked schemas. This update addresses the bug, and adds greater testing coverage to these schemas to ensure their results are aligned moving forward.

We have significantly updated our approach to regression testing, unlocking the ability to version the API results based on the degree of change from one update to the next. The specifics of this versioning are still under development, and we are open to feedback on how it is implemented. In future release notes, we will provide quantitative reports on differences in calculation from one version to the next.

This is a minor update to the geodatabase, patching an error where the geodatabase was being inconsistently queried for recently added geographies (Saudi Arabia, UAE, and Singapore). We have now updated the entirety of the geodatabase to the latest version (which we developed in parallel with the 2.37.00 updates).

With this update to geodata, there will also be a minor regression on some structural emissions or envelope emissions as relates to data regionalization. In our testing, this change is less than 5% everywhere.

With the addition of as a use type in C.Scale, now all users can measure and get bummed out about emissions related to structured parking. We've also addressed a peer review comment on our models with the addition of excavation emissions to all construction below-grade.

Now, both and are available as use types. Life cycle emissions from both are modeled alike, with the one difference being that does not have associated MEP emissions.

To make this change, we changed "conditioned area" from a global parameter to one that can be defined for each level of the stacked building form. Where no value is passed, a use-specific default (typically 100%) is used. Declaring a global value for still functions as expected, overriding all locally defined values. This change also gives us a clear path to the calculation of a richer set of area metrics (CFA, GFA, GIA, etc.), a much-requested improvement we will be targeting in a near-term release.

Following Roy et al. (2024), we are now including estimates for excavation emissions for all below-ground construction.

This update also includes an updated testing suite designed to catch and prevent errors like the one leading to the 2.38.05 hotfix.

About an hour ago, a user alerted us to suspiciously high numbers coming through from the Simple BuildingForm. We traced this to an error in the data model where a percentage [0,100] was being interpreted as a proportion [0,1], leading to a 100x mis-estimation of the envelope area take-offs.

This bug is fixed and coverage to these cases will be added to the testing suite later today.

We've added more resolution in the Life Cycle Stages schema. For specific descriptions of each measure, please refer to our API documentation under . With this update, users can individually include/exclude , , , , , and stages. We've also added new response outputs to and . Finally, Conditioned Parking is now being offered as a use type. These updates do not result in any differences in our model's calculations.

Currently, C.Scale's B-phase module includes ("in-use" emissions), (maintenance, repair, replacement, refurbishment emissions), and (energy use emissions across all fuel types) life cycle stages, which are included by default. A user can access all of these at the top-level using , which will include/exclude all B-phase stages, or at the sub-level (i.e., ), which allows inclusion/exclusion of individual stages.

C.Scale's benefits module includes (recovery, construction, use, and end-of-life carbon burdens), (avoided emissions from the grid), and (storage and release of biogenic carbon), which are included by default. A user can access all of these at the top-level using , which will include/exclude all benefit stages, or at the sub-level (i.e., ), which allows inclusion/exclusion of individual stages.

, , and are new response parameters, and is a new response parameter.

Conditioned Parking is now a supported use type in the C.Scale API.

The API will be triggered when a user uses the Stacked Building Form schema and selects a structural system other than Reinforced Concrete for a below-ground level. Since below-ground levels with non-Reinforced Concrete systems are not currently represented in the background data, the system will default to Reinforced Concrete for such requests.

Data Centers are now a use type supported by the C.Scale API.

The inclusion of data centers is an experimental feature. When a Data Center is declared in the API, we pass :

This morning, a user alerted us to a validation error in for a request using the "stacked" object. This hotfix addresses that bug, and adds additional tests to check for it moving forward.