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.

Building on our schema updates from last week, we have improved some defaults used in the model to reflect the building's region and use type. These changes are summarized below and reflected in updates to our documentation.

There is no change in values between this version and the previous version (except where using the default values) and no breaking changes.

The default R-value of the opaque wall assembly is now set in relation to the building's climate zone. As with other characteristics of the envelope, it can be overridden using the "description" field of the request object.

The default R-values here are recorded in our documentation.

The floor-to-floor height defaults in C.Scale are now a function of use category. Floor to floor (F2F) height can still be set by users for each floor individually (if using the stacked object) or for all floors together (in the simple object).

The default floor-to-floor heights here are recorded in our documentation.

The API now accepts requests with up to 15 floors below-grade. If more than 8 floors are passed, the API raises a warning in the object.

Danish LCA guidelines require a 50-year reference service life. This has been added as an option to .

Aligning with emerging standards worldwide, all instances of in the API are now alias'ed to . We will continue to accept both, but recommend API users change over to the new label to stay in alignment with future documentation, as all future Swagger docs will reference the new parameter name.

This update represents a major re-factor of C.Scale's internal schemas and how they're managed. These changes will not be visible on any of the exposed endpoints. Additionally, this change includes a minor update to the stacked to better handle instances where the list of levels is not sequential.

Objects shared by more than one request schemas are now all pulled from a single source of truth. Default values previously stored in the schema itself are now injected via functions.

These changes pay down a significant amount of the technical debt we had accrued in keeping our schemas backwards-compatible. This will allow us to develop future features faster. Additionally, this clears roadblocks for the near-term development of "smarter" defaults dependent on building type, building form, relevant standards, and other characteristics of the model.

This change has no effect on the API's use or functionality.

The stacked object was originally written to deal with non-sequential levels correctly (e.g. if the passed levels are ). But today we learned that the API struggled when the order of the levels in the list did not match the sequence of levels in the building (e.g., ). Moving forward, we now sort all levels to be sequential before evaluating them. In these cases, we pass :