Skip to content

Method

A study is a pipeline, not an opinion. Here is what runs, in order, and what it deliberately refuses to do.

How a study runs

  1. Discovery

    Thirty to forty five minutes. We qualify fit: grid scale BESS, pre investment, an OEM offer on the table, LFP chemistry. If it is not a fit we say so here.

  2. Intake

    A one page checklist in six categories: project, cell and datasheet, the warranty as offered, duty cycle, site temperature and thermal strategy, economic assumptions. Most of it is already in the OEM's own offer.

  3. Curation

    Your documents become a versioned input file with provenance on every field. Physical validation rejects inconsistencies before anything is modelled.

  4. Execution

    The engine runs the full pipeline: calendar fade, cycling fade, coupling to an SOH trajectory, roll up to usable AC energy, warranty evaluation, gap and augmentation. Minutes, deterministic, reproducible.

  5. Quality gate

    A second byte identical run, clean provenance, physical sanity of the curve, every failure traceable to a checkpoint. The study is not signed until this closes.

  6. Delivery and walkthrough

    Report, manifest, verification note and a scope of limits letter. A sixty to ninety minute session with your team and, if you want, your lender's engineer. Questions answered in writing, citing the manifest.

  7. Re run

    The OEM improves the offer or you change the design. Incremental intake, versioned scenario, side by side comparison at a reduced fee. Two to four runs per project is normal.

The engine

Public physics, private calibration, no secrets from the client.

The functional forms come from published cell degradation literature. Magnitude is anchored to the cycle life points on the manufacturer's own public datasheet for your cell. The calibration set is public data only. We do not publish the internals, and we do not need to: the manifest lets any competent reviewer verify what went in and reproduce what came out, which is the part that actually matters to a lender.

The efficiency chain

Round trip efficiency is a chain, and the contract meters the end of it.

RTE is not one number. It is a chain of losses from the battery terminals to the point of interconnection, and every link has a public benchmark: power conversion around 98.5 percent per pass, the transformer around 99.2, auxiliaries near 2.5 percent of nominal. Public laboratory measurements of the whole chain land near 89.5 percent DC to DC and near 82.6 percent AC at the point of interconnection. The same system, seven points apart, depending on where you put the meter.

~89.5%

DC, battery terminals

~85 to 86%

AC, inverter output

~82.6%

AC, point of interconnection

Representative public envelope for current LFP systems at beginning of life. Sources cited, as always, in the manifest.

Now put a contractual threshold of 85 percent next to that chain. Measured at the point of interconnection, it sits at the edge of the public envelope: not trivial, not impossible, marginal. Two consequences. Averaging across nodes, or quoting a DC figure against an AC requirement, produces a bid that fails its first test. And a declared trajectory with no margin arithmetic behind it is a liability with your signature on it.

Stated before you ask: v0 models this chain as constant, we do not model resistance growth, and we do not sell an RTE degradation curve. What we do is put your declared numbers next to the public envelope, at your metering point, with the margin made explicit. Most declared trajectories fail there already.

The audit manifest

Every study ships with its own receipt.

This is what auditability means in practice, and it is the part no consultancy shows you. Each report is accompanied by a manifest: the model version, the hash of every input and output, and the provenance of every single coefficient. A reviewer verifies it with sha256 and the manifest alone. They do not need our repo, our CLI or our permission. If a parameter cannot cite a public source, it does not compile.

{
  "study_id":      "KYK-2026-0042",
  "model_version": "lfp_generic_v0.3.1",
  "engine_commit": "8b08456",
  "determinism":   "byte-identical re-run verified",

  "inputs": {
    "project.yaml":  "sha256:3f9a…c17d",
    "cell.yaml":     "sha256:a012…9b4e",
    "warranty.yaml": "sha256:77c5…21fa"
  },

  "parameters": {
    "k_cal": { "value": 0.0412, "src": "src-004" },
    "E_a":   { "value": 24.1,   "src": "src-004" },
    "z":     { "value": 0.52,   "src": "src-011" }
  },

  "sources": {
    "src-004": { "type": "paper",     "licence": "CC-BY-4.0" },
    "src-011": { "type": "datasheet", "retrieved": "2026-06-02" }
  },

  "outputs": {
    "report.pdf": "sha256:d41d…e800",
    "curve.csv":  "sha256:9f86…0b3c"
  },

  "tainted_sources": 0
}

Illustrative structure. Values shortened for display.

What the model will not claim

The limits, stated up front.

These are printed on the cover of every report. They are the reason to trust the rest of it.

  • It is not a bankability certificate and it is not a performance guarantee. We are an independent technical study, not the party that carries the risk.

  • The non linearity limit is real: the late knee of LFP is not captured by the functional form. Beyond roughly year 10 the band widens and we say so.

  • Round trip efficiency is modelled as a constant efficiency chain in v0. We do not model resistance growth, so we do not sell an RTE degradation curve.

  • v0 is LFP only. NMC or sodium is either declined or quoted with a recalibration.

  • We do not decompose loss into LLI and LAM. The code does not do it, so the report does not promise it.

  • The model does not produce an availability forecast. Availability enters a study as contractual arithmetic, what your declared index costs when you miss it, not as a prediction.

Scope and limits

A short call, and an honest answer about fit.

Thirty minutes. Bring the OEM offer and your duty cycle assumptions. If the study will not move money for you, we will tell you on that call rather than sell you one.

Start a conversation