Utilyzed

Methodology

How the numbers are made.

The full methodology behind every Utilyzed output. Public, versioned, and readable without a login.

Version 1.0 · July 2026

Scope and intended use

Utilyzed models behind-the-meter and distributed battery energy storage across North America. The platform covers the whole span from source documents to a pro forma: intake of the paperwork a site already generates, structural modeling of the tariff that governs it, dispatch optimization, revenue stream modeling, and financial modeling.

Outputs are analysis produced to support a decision. They are not investment advice, not an offer or a solicitation, and not a substitute for the independent diligence a transaction requires.

This document is written for the people who have to defend a number: developers in diligence, operators reconciling delivered revenue against what was modeled, and lenders in credit review. It states what the engines do, what they take as inputs, and where the boundaries are. It is public and versioned so that a reader can check a result against the method that produced it, without an account.

Data intake and provenance

A storage analysis begins as paperwork. The platform accepts utility bills, tariff filings and their supporting schedules, meter interval data, and incentive program documents.

AI performs document intake only. It reads documents and turns them into structured values. It does not compute, select, rank, or adjust any figure that reaches an output. No output figure is produced by a language model. That boundary is a construction constraint, not a stated preference, and everything below depends on it.

Every extracted value carries a reference back to the document and the page it came from. A reader who disputes a number can open the source and check it. Extracted values are not silently altered downstream: where an engine needs a quantity the source documents do not contain, that quantity is an assumption, is recorded as an assumption, and is reported as one alongside the result.

Tariff modeling

A tariff is represented structurally, not as an average. Energy charges, demand charges, time-of-use windows, ratchets, riders, fixed charges, and export compensation are each modeled as the rule they are, with the conditions that trigger them and the periods they apply to. An average price per unit of energy cannot express a ratchet, and a battery is valued largely by the charges an average hides.

Tariff records are versioned with effective dates. A record states the period it applies to, and superseded records stay readable, so an analysis of a past period uses the tariff that was actually in force then rather than today's.

Before a tariff model is relied on, it is validated against real bills for the site. The modeled bill is compared against the issued bill, line by line, across the available billing history. Differences are investigated and either explained or corrected in the model. A tariff model that cannot reproduce an issued bill is not used to project bill impact.

Dispatch optimization

The battery is dispatched by an optimization model against the tariff and the market signals it will actually face, on the site's own load, at its own point of interconnection. Dispatch is solved, not assumed from a duty cycle or a typical day.

Operating constraints are explicit inputs rather than adjustments applied to a result: power limits, usable energy capacity, round-trip efficiency, state-of-charge bounds, and cycling limits. Where an offtake agreement, warranty, or interconnection condition constrains how the asset may run, that condition enters the model as a constraint.

Degradation and augmentation are modeled inside the analysis horizon. Capacity fade changes what the battery can do in a given year, which changes how it is dispatched, which changes what it earns. Applying a fade percentage to a first-year result afterward misses that interaction and cannot recover it. Planned augmentation is modeled as capacity restored on the date it is restored, with its cost recognized in the same period.

Revenue streams

Each value stream is modeled from its own program rules as filed: the tariff schedule, market rules, or program document that governs it. Demand charge management, energy arbitrage, wholesale market participation, capacity and resource adequacy, ancillary services, demand response, and export compensation each carry their own eligibility conditions, performance obligations, measurement conventions, and settlement timing, and each is modeled with them.

Streams interact. Some are mutually exclusive. Some compete for the same stored energy in the same period. Some impose an availability obligation that constrains what the battery may do for any other purpose. Those interactions are resolved explicitly inside the optimization, not by adding independently derived stream values together. A stack summed from separate single-stream studies overstates the total, and the size of the overstatement is not recoverable from the summed number.

Financial modeling

The pro forma is built on stated conventions: the period basis, escalation applied per cost and revenue component, the treatment of operating expense and warranty terms, and the residual assumption at the end of the horizon. Conventions are written down with the model so a reviewer can test them rather than infer them.

Debt is sized to a coverage constraint rather than to a target leverage. The model solves for the debt that satisfies the required debt service coverage ratio (DSCR) under the case being tested, and reports coverage period by period, including the periods where it is tightest. Downside cases move the inputs a credit committee will move.

Tax and incentive treatment follows the governing statutes and program documents for the project's jurisdiction: eligibility, qualifying basis, timing, transferability where it applies, and recapture exposure. Where a treatment depends on a determination that has not been made, or on a program whose rules are unsettled, it is carried as a stated assumption rather than resolved in the model's favor.

Reproducibility and versioning

Engines are versioned. This methodology is versioned, and the version in force appears at the top of this page.

Every delivered output records the versions of the engines that produced it, the methodology version in force when it ran, and an input manifest identifying every source document and every stated assumption that entered the calculation.

That record is what makes the re-run guarantee meaningful: the same inputs, run against the same versions, produce identical outputs. Not close, identical. A result delivered months ago can be reproduced today and set beside a result run on current versions, and any difference between them is attributable to a specific change in an input or a specific change in a version.

Superseded versions of engines and of this methodology remain readable. A number is only defensible for as long as the method that produced it can still be read, and methods get replaced.

Alignment with model risk expectations

Utilyzed outputs are used inside processes that are supervised, so the platform is built to the vocabulary of the revised interagency guidance on model risk management issued on April 17, 2026 by the Office of the Comptroller of the Currency, the Federal Reserve, and the FDIC. That guidance describes what an institution is expected to have around a model it relies on: development that is documented and conceptually sound, validation that is independent of development, ongoing monitoring, and documentation that a reviewer who did not build the model can follow.

The mapping is direct. Development: each engine implements a stated method with documented inputs, assumptions, and limitations, and this document is part of that record. Validation: modeled bills are checked against issued bills, delivered results are checked against operating data where a site is running, and assumptions are stated in a form that lets a third party test them. Documentation: versioning, the input manifest, and per-value source references make the path from a source document to a delivered figure traceable end to end.

The 2026 guidance leaves generative AI outside the framework it describes for validated models. That is the reason for the intake boundary stated above: AI is confined to reading documents, and every number in an output comes from a deterministic engine that can be versioned, validated, and re-run. Where an outcome has to be explained to the party it affects, CFPB Circular 2026-03 on adverse-action explainability points the same way, since an explanation that cannot be traced to specific inputs and a stated method is not an explanation.

These are supervisory expectations, not a certification any vendor can hold. Nothing here asserts that a Utilyzed output has been validated by an institution's own review. It asserts that the output arrives with the documentation such a review asks for.

What you may rely on, and limitations

Outputs support decisions. They do not replace independent judgment, and no result is a representation or warranty of future performance.

Results depend on the accuracy and completeness of the source documents provided and on the assumptions stated for the engagement. Where an input is uncertain, the analysis states an assumption instead of resolving it silently. Where a tariff, market rule, program, or tax treatment changes after a result is delivered, that result continues to reflect the rules in force when it ran.

Read the assumptions with the numbers. Any figure carried into a transaction should be checked against the assumption set and the source documents behind it.

Change log

Version Date Change
1.0 July 2026 Initial public release.

Access

Put the methodology to work.

Tell us about the project and we will run this method on your own documents.