This PR represents a ground-up rebuild of all our roofing assemblies so that material takeoffs all happen live in each calculation, rather than being "pre-packaged." With this, we built a fair amount of infrastructure to knit together our bill of materials-based LCA tooling with our lightweight analysis.

With this release, a user can configure a roofing assembly from nine different roofing types:

For each of these roof assemblies, we calculate takeoffs down to the fasteners. The description of the assembly is passed back to the user in the field.

By declaring an R-value (or RSI, depending on the unit system), we calculate insulation takeoffs. The user can declare one of six insulation types:

The expanded API functionality introduces computational overhead that impacts response times. This release includes corresponding infrastructure updates to increase Lambda memory allocation, addressing immediate performance requirements. As a longer-term optimization, we're evaluating whether to extract computationally intensive operations into dedicated endpoints to improve overall system responsiveness.

There are new endpoints which benchmark results against the results of the CLF wbLCA benchmark study. These endpoints return the percentile of the current project in the benchmark set and a short description of the benchmark and the scope of comparison. When representing these benchmarks to users, we recommend using this text directly.

This bottom-up refactor to the roofing assemblies has the carbon intensities of the roofing assemblies. This is mainly due to enforcing the exclusion of all structure and finish materials from our library of roofing details, and by allowing the roofing R-value to depend on climate zone in the absence of user inputs (our previous model assumed a relatively higher insulating value, which wasn't parameterized). Across our test set, we see the following changes to envelope emissions overall:

This is a patch update with minor improvements to how the API ingests, calculates, and returns data for building assemblies.

This update moves some code over from our bill of materials-based LCA repo to improve how units are declared and interpreted. Parts of the API still use implicit units. Allowing explicit unit declarations also supports our use of more complex units (e.g., thermal resistivity) for performing insulation takeoffs.

In the responses for each assembly, we how return total (A-C) emissions for that assembly. This wa a request related to improving visualization of these impacts.

The endpoints which return carbon intensities by assembly now validate the passed ID against a list of valid IDs. Previously, a user could pass silly strings and potentially trip an uncaught error.

This is a small but mighty PR to improve how the model handles unit conversion for some interiors assemblies.

Additionally, C.Scale is adjusting our generic FFE (furniture, fixtures, and equipment) carbon intensity estimates downward to reconcile its scope with the new bottom-up (assemblies and material-based) model. This update reduces C.Scale's estimates for interiors by 3 - 13%, depending on building form.

This patch release makes a number of minor updates to the interiors model:

This is minor release improving the schema for interiors and adding a new way to send construction activities data to the API.

Additionally, we expand our support for A5.2 (construction activity) emissions tracking by allowing users to enter data by fuel type.

This release adds a field to assembly-level calculations. The purpose of this field is to allow API users (at least one in particular 😉) to better connect request and response objects without indexing.

This update allows API users to calculate construction activities emissions through a calcuation of fuel use on the building site. The fuel types that C.Scale accepts are:

C.Scale accepts a list of "fuel receipts" to the key which describe how much fuel is used, when it is used, and (optionally) by whom.

This is a patch release which makes a number of small changes:

No change in calculation.

This is a minor update to expand C.Scale's support for interior assemblies and make a fundamental update to the way that reuse is handled at the assembly- and material-level.

At the category-level, C.Scale supports the declaration of reuse as a percentage of total assemblies. This is a useful abstraction, but is not extensible to the assembly- or material-level. At these finer levels of resolution, there are three options for

This update includes data for "shared" interior walls. These walls are cut at their centerline so one one half is counted in the analysis. This allows takeoffs to happen on a per-room basis while avoiding double-counting of shared walls.

This patch release opens up a set of experimental endpoints to query, view, and edit EPD data.

No change to calculations.

This minor release contains a greatly expanded and enriched interiors model as well as updates to how we handle DB connections. There are a few minor bugs we are aware of and working to address ASAP, noted below.

To support some enterprise API users, we are expanding how interiors modeling is performed in the application. The alternate schema for the object is a list of , each of which is a collection of (and some overall descriptive data.).

The takeoffs are all tagged to an field. Acceptable entries for the field can be queried with a GET request to . To get the full description of a particular assembly, pass that in a GET request to

In the past week, we have had intermittent issues with how we are sharing database connections across Lambda executions. To solve this, we are performing health checks and retries w/ backoff when the database is not behaving as expected. This appears to have addressed the issue in development environment. While this will make finicky requests slower, we prefer the occasional slow request to the same frequency of failures.

In addition to the above, we made a variety of small updates -

This release adds additional endpoints and data describing refrigerant emissions in buildings, as well as a global update to our energy use and fuel mix benchmark values.

With this update, a user may pass in specific refrigerant types and their charges as a list. From this, we can describe refrigerant emissions of at a granular level, with full capability to support LEED credits related to refrigerant management.

The C.Scale data model now includes 141 refrigerants in its internal library. The characteristics of these refrigerants can be queried at the endpoint and included in the calculation by passing the descriptions within the object in the request.

We have harmonized our data source for benchmark EUI and fuel mix values - using time series aggregates from OEDI to construct typical values by climate zone and building type.

This harmonization is particularly exciting as it sets a course for integrating more granular 12x24 or 8760 energy data into the API, as well as exposing estimates by end use.

These values may have regional overrides where more specific data is available.

As part of this update, we also eliminated a vestigial data structure for organizing regional data. The elimination of this data structure gives us greater agility in adding additional geographies to the API.