This release introduces an expanded transparent enclosure schema, giving users finer control over transparent envelope assemblies. Additionally, we improve how we handle PVWatts data.

We've redesigned how glazing is specified in the API, supplementing the simplified approach to add a more detailed and customizable schema. This approach largely mirrors our approach to opaque envelope assemblies.

The original simplified schema remains available for backward compatibility.

We've made some improvements to how we manage data from PVWatts. These changes will not affect user's experience accessing that API via ours.

This release introduces an expanded opaque enclosure schema, giving users finer control over opaque envelope assemblies. Additionally, we improve data sources for fuel mix and make a few small bug fixes.

We've redesigned how cladding is specified in the API, supplementing the simplified approach to a more detailed and customizable schema:

The original simplified schema remains available for backward compatibility.

We've refactored how we handle on-site energy use from fossil fuel combustion:

We've addressed several issues with project PDF reports:

Additionally, addressed a bug affecting some reuse projects where A5.2 emissions were still being calculated when that subphase phase was toggled off.

This release brings a few exciting new features, including enhanced unit system granularity, project-level Excel exports, and improvements to our biogenic carbon calculations.

To offer more control over unit handling, we’ve upgraded the parameter and renamed it . Users can now pass an object with both an ingress unit system (input) and an egress unit system (output). If both are the same, you can continue using the parameter as before we'll ensure unit consistency. For backward compatibility, the top-level is still accepted as input and uses the declared unit system for both ingress and egress.

We’ve added new endpoints to support project-level Excel exports. This endpoint collects the time series and category by stages into a .xlsx export and hosts it in an S3 bucket.

Our biogenic carbon calculations now include an additional calculation to account for wet vs. dry product density, this will affect the magnitude of stored biogenic carbon in some cases.

This morning, planned updates to MongoDB Atlas resulted in calls to our tokening service timing out. MongoDB, in their infinite generosity, will not share an RCA of the outage unless we move to the next billing tier. Regardless of what in their system caused the outage, the result was the same - downtime for our API and an accelerated effort to get the heck off MongoDB.

Once we were aware of the issue, we refactored the calls which were dependent on Atlas and redeployed. Total downtime was approximately 68 minutes.

In this update, we move the entirety of our tokening and request increment workloads to an AWS-managed service which plays very nicely with our Lambda functions.

We have load tested this service extensively today and the results are stellar: low-latency and high reliability even at extraordinary call volumes. Additionally, we are mitigating against issues caused by timeouts by implementing retry and failovers in our tokening workloads. In load testing with up to 20 virtual users simultaneously sending high call volumes, we achieve:

Earlier this week, an API user alerted us to an issue with the endpoint where there were (pun intended) a few stacked/compounding issues. This release addresses these issues.

A user approached us with two building examples which included multiple towers over a podium. The structural emissions estimates for that form were lower than expected, and the difference between the two options was wider than anticipated. A few of the issues we identified:

In reviewing the error, we identified an issue in how we were handling complex building forms with multiple use types in a single stack of levels. By performing a set of operations on each chunk individually, the algorithm which interpreted the building form was not tracking how these forms should be re-combined into a whole. This error was identified because the area-weighted SMQi for all chunks was not equal to the SMQi exposed in the API response.

In many cases, this error is small (within a few percent of the total) but, in this case, the three points above led to a more significant deviation. The combination of all these issues led to an underprediction of emissions and an unexpected scale of difference in prediction between a simpler and a more complex building form.

To fix this issue, C.Scale made two changes -

After these fixes have been implemented, we see a change of -5% to +18% difference in emissions predictions for mass timber projects, and larger differences for complex stacked forms. These changes represent improvements to the model and bug fixes.

This patch release contains miscellaneous small improvements, most notably richer descriptive fields in the response object and a preliminary version of the updated response schema.

In the response object, we've added a field to each item describing the material or assembly in some details. Occasionally, these are obvious (woodlumber is lumber) but sometimes less so (especially for assemblies which include many subassemblies, such as interiors).

This is a non-breaking name change to create closer correspondence between the language we use in the API and how the LCA calculation is actually performed. We updated this name since we are counting B4 replacements and not B5 refurbishment. The choice of phrase here was determined in consultation with the Tally team to better align our language with theirs.

In some cases, A1-A3 emissions in building reuse scenarios were being incorrectly calculated in the time series object only. This bug fix addresses this issue, and includes additional unit tests to check for correspondence between the first year of the time series and A1-A3 emissions in the object.

We were seeing a bug where users entered 0% conditioned area and were still seeing operational emissions present. This was due to the 0 being validated as a null value and then reset to 100%. In this update, we treat null-ish 0 and null values differently.

In cases where users inputted solar pv, D2 emissions were being double counted in as they appeared in both and . This was ultimately a terminology issue, and we've corrected these results so that D2 emissions would only be present in .

The current response schema is getting long in the tooth. The structure of this schema evolved over time and, as the capabilities of the API have evolved, the schema's structure has shown itself to be a limitation. Additionally, we need to make space in the schema to work towards reconciling our BIM-based, BoM-based, and predictive models into a single calculation structure.

To preview the updated schema (still in development), set the top-level param to .

This release brings significant improvements to our Solar PV and Refrigerants modeling capabilities, offering users more granular control and precision in both areas. These updates are the culmination of our planned feature set for these modules, providing a more comprehensive and flexible approach to modeling their impacts 🎊

We've completely revamped how solar panels are specified in the API, moving from smart defaults to direct panel descriptions:

These changes allow for more accurate modeling of solar energy production across different panel configurations and installation scenarios.

We've completely redesigned our refrigerants modeling to support both simplified and detailed approaches:

This dual approach ensures that both casual users and detailed modelers have access to refrigerant emissions calculations at their preferred level of precision.

We've also made several improvements to our backend systems:

There is a regression in the calculation of panel area as we have re-set our default from 0.7 to 0.6 and upgraded our default panel capacity from 250W to 300W, reflective of user feedback about typical installations.

This update is the first of a few expanding the resolution of the interiors model, allowing input of the takeoffs and specifications on an assembly basis.

Additionally, there are two unit-related bug fixes.

Previously, a user could only enter interiors data on a per-area basis for the entire area with an interiors fitout. This was difficult, as users couldn't target reductions or tune take-offs to better match their project or ambitions.

Now, users can input more granular data on the following: interior walls (), interior doors (), casework (), ceiling finish (), floor finish (), and fitout & equipment ().

All of these improvements are detailed in the schema. For the simple schema, all takeoffs happen in the object. For the stacked schema, all takeoffs happen with the . In all cases, specifications, reuse, and service life parameters happen in the object.

We all make youthful mistakes, and one of ours was equivocating between 0,100 and 0,1 ranges for parameters that are conceptualized as percentages. Regrettable, but fixable. In this release, we're addressing this for one troublesome parameter (). If a value is less than 1, we interpret the value as a proportion (0.67 is interpreted as 67%); if a value is greater than 1, we interpret it as a percent (67 is also interpreted as 67%).

We'll do a deeper (e.g. breaking) refactor here in the future, but this adjustment meets the needs of everyone currently using those parameters in production.

The refrigerant data exposed in the response object was erroneously subject to a unit conversion in our egress function. This has been fixed.

Since the data was correct in the calculation itself and the bug was only in how the data was presented in the response object, there are no changes to any calculation results.

The last few weeks saw a massive evolution of our codebase as we work iteratively toward integrating our BIM, BoM, and predictive engines into a single shared architecture. In addition to progress this direction, we also delivered a number of smaller improvements targeting specific user feedback.

The API can now accept a reference period of 25 years and all service life parameters can now accept any integer value (in years).

Our users ask and they shall receive! In this release of the API, there are now include/exclude toggles on all life cycle stages and scope categories.

Previously, some cases existed where building reuse scenarios led to a miscalculation of A5.2 Jobsite Emissions. Thanks to our diligent users, we identified the bug earlier this week and were able to push out a fix and expanding our library of unit tests to prevent this behavior in the future.

The bulk calculation endpoints were refactored to better parallelize IO-bound calculations. This is the first step in a longer journey of squeezing even more efficiency out of these endpoints to better support our portfolio clients and use cases that require massive parameterization.

There are no changes to calculation results in this release 🌴