Prescriptive, total building performance, ERI, REScheck, COMcheck.
2
hours
0.2
CEUs
Codes and Standards
1.7.3
This course covers material relevant to the following ICC certification exams:
Prescriptive, total building performance, ERI, REScheck, COMcheck.
Format
On-Demand Online
Delivery
Self-Paced
Access
24/7 After Enrollment
Certification
Certificate of Completion
Have questions about this course or our platform?
Contact our support teamUnderstand prescriptive and performance-based compliance paths
No two buildings meet an energy target the same way. A low-rise office with a compact footprint and modest glazing can satisfy the code's intent through straightforward assemblies and standard equipment. A building with an ambitious glass curtain wall, unusual massing, or a design feature that trades against efficiency needs a different route to the same destination. The IECC recognizes that reality by offering more than one legitimate way to demonstrate compliance, rather than forcing every project through an identical checklist. Understanding why multiple paths exist — and that a project must pick one and follow it completely — is the foundation everything else in this course builds on.
The reason for multiple paths is flexibility without sacrificing the target. The code sets a floor for energy performance that every building must meet or beat, but does not mandate a single method of getting there. A designer working on a simple, conventional building benefits from a path that is fast to document and fast to check. A designer working on a complex or unconventional building benefits from a path that lets performance in one area offset a shortfall in another, as long as the building as a whole still meets the target. Both outcomes protect the same underlying goal through different mechanics. Recognizing which mechanic a project has chosen, and confirming the documentation supports that choice, is the core skill this module develops.
Of the available paths, the prescriptive path is the simplest to describe and the simplest to review. Under this approach, the designer commits to meeting each individual requirement in the code exactly as written — one component at a time, with no averaging, no trading, and no substitution of a stronger measure in one area to compensate for a weaker one elsewhere. That rigidity is the path's defining trait: it offers the least design flexibility of any compliance option, but in exchange it offers the most straightforward verification. A reviewer working from a prescriptive submittal is not evaluating judgment calls or modeling assumptions — the reviewer is confirming, item by item, that what is shown on the drawings matches what the code requires for that building's classification and location. There is no room for interpretation about whether an underperforming item is "made up for" somewhere else, because the prescriptive path does not permit that kind of trade-off.
That component-by-component discipline is also the prescriptive path's practical limitation. A designer who wants an architectural feature that falls outside what the checklist allows — more glazing than the prescriptive limit typically accommodates, or an unconventional envelope assembly — cannot simply document a good reason and move on. The prescriptive path has no mechanism for that kind of accommodation; if a component cannot meet its individual requirement, the project either changes that component or moves to a different compliance path altogether. If a submittal identifies itself as prescriptive but shows a component that misses its individual target, that is not a minor deviation to wave through — it is a sign the project needs a design change or actually belongs on a different path.
A reviewer receives a submittal for a straightforward single-story commercial building declaring the prescriptive path. Rather than skimming the summary and moving on, the reviewer treats the declaration as a starting checklist: each envelope component, each piece of mechanical equipment, and each applicable system gets checked individually, with no assumption that strength in one area offsets weakness in another. When the reviewer finds a mechanical component that falls short of its individual requirement, the reviewer does not look for an offsetting strength elsewhere — because the prescriptive path does not work that way — and instead flags the component as noncompliant, requiring either a design change or a switch to a path that permits that kind of flexibility.
The most common error with prescriptive submittals is treating them with the flexibility that belongs to a different path — assuming that because one part of the building performs well, a weaker component elsewhere is acceptable. It is not; the prescriptive path grants no such allowance. A second is approving a prescriptive submittal from a summary sheet without checking every individual applicable item, on the assumption that if most components pass, the whole submittal is fine. A third is failing to recognize when a project has quietly drifted into needing a different compliance mechanism, and continuing to review it under prescriptive rules anyway. The correction is the same discipline every time: verify each applicable component independently, hold the line on the declared path, and require a formal path change — with its own complete documentation — rather than allowing informal blending.
Code Reference: IECC - The code establishes minimum requirements for prescriptive to ensure public health, safety, and welfare. Requirements vary based on occupancy classification, construction type, and building height and area.
Use energy modeling tools and compliance documentation methods
Where the prescriptive path checks each component against a fixed target, the performance path — sometimes called the simulated path — evaluates the building as a whole. Rather than confirming that every wall, window, and piece of equipment independently clears its own bar, the performance path relies on whole-building energy modeling: a simulation of how the proposed design will consume energy across a full year, compared against a code-defined baseline building of the same size, shape, and use built to minimum requirements. If the model shows the proposed design performs at or better than that baseline, the building complies — even if individual components, taken in isolation, would not have satisfied the prescriptive requirement.
That flexibility is the performance path's defining advantage. A design team chasing a feature the prescriptive checklist would reject outright — generous glazing for daylighting, an unconventional envelope assembly, a distinctive massing — can still comply by offsetting that choice elsewhere: more efficient mechanical equipment, better lighting controls, a tighter envelope in other assemblies. The performance path substitutes a single whole-building target for the fixed component-by-component minimums the prescriptive path imposes, letting designers make tradeoffs across systems as long as the total picture holds up.
That flexibility comes at the cost of a fundamentally different — and more demanding — kind of review. A prescriptive submittal is a checklist exercise: does this component meet this value, yes or no. A performance submittal is a judgment exercise: does the model itself deserve to be trusted. The reviewer's job is not to accept a modeling report's bottom-line conclusion at face value, but to scrutinize the inputs and assumptions behind it. A model is only as reliable as what was fed into it — if the assumed operating schedule, occupancy pattern, or equipment performance does not reasonably reflect how the building will actually be used and built, the comparison between the proposed design and the baseline is distorted, and a noncompliant building can appear to pass on paper.
This is also where compliance documentation software becomes central to the process. Rather than requiring every design team to build a model from first principles and every reviewer to evaluate an unfamiliar bespoke calculation, standardized software walks the applicant through the applicable requirements — whichever path is chosen — and produces a uniform, structured documentation package. That consistency benefits both sides: the applicant gets a guided process that flags what is required, and the reviewer gets a report in a familiar, comparable format. But standardized output is still only a record of what was entered — it documents a claim, not a verified fact — so a clean-looking compliance certificate is never a substitute for confirming the inputs behind it make sense for the building being built.
A design team submits a whole-building energy model showing a proposed commercial building outperforming the code baseline, supporting their chosen performance compliance path. Before accepting the result, the reviewer sets aside the summary conclusion and works through the modeling inputs: the assumed hours of operation, the occupancy schedule, and the control sequences driving the mechanical and lighting systems. The reviewer notices the model assumes an operating pattern that does not match how this particular building — a facility with a much more limited daily schedule — will actually function. Because that assumption meaningfully changes the comparison, the reviewer does not accept the modeling report as submitted and instead requires the design team to revise the inputs to reflect the building's actual anticipated operation before the comparison can be considered valid.
The most frequent error on performance-path submittals is accepting the model's bottom-line result without examining what produced it — treating a compliance certificate as proof in itself rather than a summary whose assumptions still need verifying. A second is failing to recognize when modeling inputs are unrealistic for the specific building being reviewed, rather than generic values carried over from another project. A third is not recognizing that the performance path, despite its flexibility, does not eliminate every requirement outright — some provisions remain mandatory regardless of how favorably the whole-building comparison comes out. The correction is to always look past the summary: read the inputs, confirm they reasonably describe the actual building, and treat a favorable model result as the beginning of the review rather than the end of it.
Code Reference: IECC - The code establishes minimum requirements for use energy modeling tools to ensure public health, safety, and welfare. Requirements vary based on occupancy classification, construction type, and building height and area.
Apply ERI, REScheck, and COMcheck tools for code compliance verification
Beyond the prescriptive and performance paths already covered, the IECC recognizes an additional named alternative for commercial compliance: demonstrating compliance through the referenced ASHRAE energy standard rather than through the IECC's own prescriptive or performance provisions directly. This alternative exists because the IECC and the referenced ASHRAE standard are built to achieve comparable levels of energy performance, and a project team already working from that standard — because of familiarity, a client requirement, or how the design process unfolded — can use it as the compliance vehicle instead of duplicating the effort under the IECC's own path structure. The principle that governs every compliance path applies here too: once a project declares it is complying through the referenced standard, it follows that standard's requirements completely, rather than mixing selected pieces of the standard with selected pieces of the IECC's own provisions.
This is also where the ready-made compliance software tools that support each path deserve specific attention. For commercial projects, a widely used tool — generically referred to as commercial compliance software — walks a design team through the applicable requirements, whichever path governs the submittal, and produces a standardized report. These tools exist because most jurisdictions want a uniform, comparable documentation format rather than a different bespoke calculation package from every design team. Recognizing what a compliance software report represents — a structured record of the inputs and path the applicant selected — is essential to using it correctly during review; the report is documentation to be scrutinized, not a verdict to be rubber-stamped.
Across every path, one principle sits underneath all of it: the entire compliance demonstration is tied to the project's climate zone. Whether a project is following the prescriptive checklist, running a whole-building model, or complying through the referenced ASHRAE standard, the applicable requirements, the reference baseline, and the software defaults are all calibrated to where the building sits. A reviewer should treat climate zone as a foundational fact to confirm early, not a detail assumed correct because the paperwork says so. This connects directly to the broader energy code plan review process: the review mechanics — confirming scope, verifying the documentation package is complete, and connecting the approved compliance basis to field verification — apply across whichever path a project has chosen, even though what a reviewer specifically checks differs by path.
The single most important discipline across all of this is that a compliance path is an internally consistent system, not a menu to select items from. Each path — prescriptive, performance, or the referenced-standard alternative — has its own internal logic for demonstrating that a building meets the code's intent. A project cannot borrow the easiest individual requirement from the prescriptive checklist, the most favorable modeling assumption from the performance path, and a convenient provision from the referenced standard, and call the result compliant. The documentation has to show one path, followed completely. A reviewer's first and most important question for any energy submittal is not "does this pass" — it is "which path is this claiming, and does the entire submittal actually follow it."
A commercial submittal arrives with a compliance certificate identifying the referenced ASHRAE standard as the compliance basis. Rather than checking the report for a pass/fail result and moving on, the reviewer confirms that every supporting document in the package — the envelope schedule, the mechanical equipment data, the lighting information — is evaluated against that standard's own requirements, not partially against IECC prescriptive values left over from an earlier draft. The reviewer also confirms the climate zone used throughout the package matches the actual project location, and only then moves to evaluating the substance of the submitted values.
The most consequential error at this stage is path-mixing: a submittal that blends prescriptive values in one part of the documentation with performance-path or referenced-standard assumptions in another, producing a package that cannot be judged against any single consistent rule set. A second is treating a compliance software report as an automatic pass simply because it was generated by recognized software, without confirming the path was followed consistently throughout. A third is carrying over a climate zone or baseline assumption from an earlier project without re-verifying it. The correction is always the same: identify the single declared path first, confirm every part of the package is consistent with that path and the correct climate zone, and require a complete, internally consistent resubmission — not a piecemeal patch — whenever paths turn out to have been mixed.
Code Reference: IECC - The code establishes minimum requirements for eri to ensure public health, safety, and welfare. Requirements vary based on occupancy classification, construction type, and building height and area.
This course provides professional development in IECC energy code compliance paths and documentation, building on the review mechanics introduced in *Energy Code Plan Review: Documenting Compliance* to focus specifically on the paths themselves: why the code offers multiple routes to one energy performance target, the rigid component-by-component discipline of the prescriptive path, the whole-building modeling and assumption-scrutiny the performance path demands, the referenced ASHRAE standard as a named commercial alternative, the role of standardized compliance documentation software, the climate-zone dependence underlying every path, and — above all — the principle that each path is an internally consistent system to be followed completely, not a menu to select convenient pieces from. Through structured modules, scenarios, and code reference integration, participants learn to identify which path a submittal declares, hold it to that path's own requirements, and catch the path-mixing errors that undermine otherwise well-organized packages.