# GaugeH₂ LCOH / TEA Calculator — Methodology changes, 5.2.0 / 2.5 → 7.1.0 / 3.33

**model_version:** `7.1.0` · **methodology_version:** `3.33`
**Status:** FROZEN. This file is content-addressed: its sha256 is published in
`docs/methodology/calculator-methodology-v7.1.0-m3.33-changes.sha256.txt`. Editing one
byte of this file without regenerating that one invalidates the anchor, and the test
suite fails.

## What this document is

The continuation of §11 of `calculator-methodology-v5.2.0.md`, for thirty methodology
bumps that carry **no model bump**, and five that do. Under the first seventeen the engine
did not change: every formula, every default and every reproducibility claim in `5.2.0` /
`2.5` held, and that document — with its own published sha256 — remains the specification of
the METHOD for every report issued under them. The eighteenth, `3.12` → `3.13`, comes with the
model `5.3.0`, the nineteenth with `6.0.0` and the twentieth, `3.14` → `3.15`, with `6.1.0`;
from each of them on, the method is that model's frozen document, published beside its sha256.
The twenty-first, `3.15` → `3.16`, the twenty-second, `3.16` → `3.17`, the twenty-third,
`3.17` → `3.18`, the twenty-fourth, `3.18` → `3.19`, the twenty-fifth, `3.19` → `3.20`, the
twenty-sixth, `3.20` → `3.21`, the twenty-seventh, `3.21` → `3.22`, the twenty-eighth, `3.22` →
`3.23`, the twenty-ninth, `3.23` → `3.24`, the thirtieth, `3.24` → `3.25`, the thirty-first,
`3.25` → `3.26`, and the thirty-second, `3.26` → `3.27`, carry no model bump:
under them the method is still `calculator-methodology-v6.1.0.md`. The thirty-third, `3.27` →
`3.28`, comes with the model `6.2.0`, and from it on the method is
`calculator-methodology-v6.2.0.md`. The thirty-fourth, `3.28` → `3.29`, carries no model bump:
under it the method is still `calculator-methodology-v6.2.0.md`. The thirty-fifth, `3.29` →
`3.30`, comes with the model `7.0.0`, and from it on the method is
`calculator-methodology-v7.0.0.md`. The thirty-sixth, `3.30` → `3.31`, comes with the model
`7.1.0`, and from it on the method is `calculator-methodology-v7.1.0.md`. The thirty-seventh,
`3.31` → `3.32`, and the thirty-eighth, `3.32` → `3.33`, carry no model bump: under them the method is
still `calculator-methodology-v7.1.0.md`. This document keeps the whole history so that a report
issued under any of these versions can be read against what it asserted.

**What changed is what the reports ASSERT.** Of the seventeen bumps under `5.2.0`, two remove
an assertion, nine add one, one corrects a citation, and five correct assertions the reports
made about themselves. The next three change what the engine computes, and what the reports
say about it. The twenty-first corrects what the reports said about themselves again, and the
twenty-second makes one of those assertions true without exception: every figure the reports
print states where it comes from. The twenty-third links a declared figure to its source, and
says so. The twenty-fourth lets the renewable sizing chapter price the PPA on the energy
produced, and states what the lowest point of that curve is and what it is not. The
twenty-fifth moves no sentence: it keeps a note inside the margin and gives every table one of two
widths. The twenty-sixth adds two sentences where a figure could be read as saying more than it does.
The twenty-seventh adds an origin a figure can have — the defaults of the author's firm — and a block
that says whose they are. The twenty-eighth stops the compliance chapter from calling an alternative
pathway that is not needed "not met". The twenty-ninth says when an internal review was stated by the
author of the calculation itself. The thirtieth prints the date of the evidence an author declares
without attaching it. The thirty-first prints which firm prepared a report, with its logo. The
thirty-second puts a page behind the cover of every report that restates what it answers and adds no
figure. The thirty-third changes what the engine computes again: a take-or-pay charges only what
the plant produced, and the reports say what a commitment above production is. The thirty-fourth
prints, in the report of a Monte Carlo run on the base case, the compliance assessments of the base
case, and says whose they are. The thirty-fifth changes what the engine computes: the DSCR is after
tax, a project without debt has none, the PERT is the standard one and the IRR does not get lost.
The thirty-sixth adds four optional project-finance inputs, and what a report prints when they are set.
The thirty-seventh asserts nothing new: it sets the reports in a quieter type scale and puts a space
between a currency code and its figure. The thirty-eighth asserts nothing new either: it sizes the logo of
the firm that prepared a report by what it shows.

## Why it exists as a separate file

The frozen document's filename derives from `model_version`, which has not moved. A
methodology bump under a stable engine therefore had nowhere to land, and for three
bumps it landed nowhere: reports issued since 16 Aug 2026 print
`Methodology version: v2.8`, `/verify` publishes that field, and no published document
declared anything past `2.5`. Measured and closed on 13 Sep 2026.

## 2.5 → 2.6 — 16 Aug 2026

The premium call-out stops ASSERTING a legal qualification and states whose assertion
it is. The figure it frames does not move; what moves is who is on the hook for the
claim.

## 2.6 → 2.7 — 18 Aug 2026

**The TEA report prints the stress test against the declared contract structure**, and
so begins to assert things it did not assert before: the minimum DSCR under price and
volume shocks, which clause absorbs each, and the two disclosures that bound it — two
of the seven factors in ET21, and that no threshold is applied.

**This is the one addition, and the method for it is NOT yet published.** This document
states that the test exists, what it asserts and where it is printed; the full
specification — the shock magnitudes, the order of application and the absorption
rules — lands in the next frozen document, at the next model bump. Until then, the
primary sources are in the engine at `src/lib/calculations/stress-disclosure.ts` and
`sensitivity-sweep.ts`, and a reader who needs the method before then should ask for
it rather than infer it from the printed figures.

## 2.7 → 2.8 — 20 Aug 2026

**Both reports stop adjudicating.** The Monte Carlo cover no longer says
"PROBABILITY ALL BANKABILITY CRITERIA ARE MET" — which asserted at once that these
three tests ARE the criteria of bankability and that 1.30x is the pass mark — and the
TEA glossary no longer says "lenders typically require Min DSCR >= 1.30x", an assertion
about third parties that no source sustains. In their place both state WHERE the 1.30x
comes from and that the three tests are not an assessment of bankability. The primary
sources are in `src/lib/calculations/screening-disclosure.ts`.

## 2.8 → 2.9 — 18 Sep 2026

**The three reports declare two things they did not declare before, and both are
omissions rather than results.**

**What the levelised cost excludes.** The cost does not include working capital. It
never did — `lcoh.ts`, `project-cf.ts`, `revenue.ts` and `timeline.ts` contain no
working-capital term, measured rather than assumed — but no report said so. Published
factorial guidance puts working capital at 10 to 20 per cent of fixed capital
investment (Towler and Sinnott, *Chemical Engineering Design*, chapter 7), recovered
when the plant stops and therefore carried as an annual charge on the funds rather than
amortised with the capital. No figure for it is computed or printed here, and none is
estimated in this document: stating a number for a line the engine does not model would
be exactly the kind of assertion this bump exists to remove.

**Which index aligns money years, and with what weighting.** Money years are aligned
with the Nelson-Farrar refinery construction cost index, weighted 60 per cent labour and
40 per cent materials. The reports already named the series; they did not name the
weighting, nor that the index's publisher — the *Oil & Gas Journal* — maintains 60:40
for continuity of the series while reporting that surveyed project composition has moved
towards 40 per cent labour, and publishes the series at five weightings so an evaluator
can match their own project. The index is a refinery construction index, accurate for
the US Gulf Coast; it is applied here to electrolysis capital. **No alternative weighting
is applied**, and choosing one is deliberately not part of this bump: it would move
published figures on the strength of a judgement of ours rather than of a source.

*Corrected in 3.6. This paragraph said that money years are aligned with the index and
that it is applied to electrolysis capital: no figure is escalated to another money year,
and none ever was. It also said that choosing another weighting would move published
figures: it would move one, the factor quoted on a report's money-year line for a year
inside the series. See 3.5 → 3.6.*

Each declaration lives in one place — `src/lib/calculations/cost-scope.ts` and
`src/lib/comparability/normalisation-note.ts` — and is printed by all three report
generators and by `/methodology`, so the page and the PDF cannot say different things.

Neither declaration changes a formula, a default or a printed figure. What changes is
what the documents assert about their own scope — the same criterion as the three bumps
above.

## 2.9 → 3.0 — 19 Sep 2026

The two reports with a parameter table print a **backing index** underneath it: how many
figures are declared with a supporting document, how many declared without one, how many
came from the catalogue, how many are platform defaults, and how many are printed **with
no stated origin at all** — named one by one.

**Why it needed a bump.** The "Where it comes from" column already said this row by row.
What it did not do is count, and nobody subtracts fifteen cells by eye. More importantly,
the index **prints even when the calculation declares nothing**, which is exactly the
report where every figure falls under "nobody said where this came from". Drawing it only
when something is declared would have been the byte-safe version and would have silenced
the uncomfortable answer.

**What it does NOT do, and this is a boundary and not an omission.** It invents no fifth
category. "Unbacked" is not one thing but three: a platform default carries no document
and is missing none — its origin is known and the platform can show it; a declared figure
without a document was signed for by a person; and only `entered, not declared` has
nothing behind it. Lumping them together would print a false accusation against half the
table. The index summarises the column above it and asserts nothing the column does not,
including its documented limit — an author who types by hand exactly the default value is
labelled as platform.

**A parameter declaration may now carry the sha256 of the document that backs it**, with
its filename. The platform does NOT store the document: the report cites it by hash, which
is what keeps a sealed report byte-deterministic. Because a declaration lives inside
`inputs`, that hash is covered by `content_sha256` — change the quote and the report's hash
moves. Nothing is verified by this: the block is still headed STATED BY THE AUTHOR, NOT
VERIFIED, and the wording is "backed by", never "verified by". The hash proves WHICH
document was invoked, not that it is true.

No formula, no default and no printed figure moves — the same criterion as the four bumps
above.

## 3.0 → 3.1 — 19 Sep 2026

**The origin column gains a fifth answer, and it is not a source: it is the absence of a
question.**

Until this bump, a parameter that the calculation did not carry fell into
`entered, not declared` — "someone put this number in and nobody said where it came from".
For one row that was false, and measurably so. `construction_months` entered the LCOH input
contract on 10 Aug 2026; the **182 LCOH calculations issued before that date do not carry it**,
because the form never asked. Re-downloaded today, those reports printed:

    Construction Period   0 months (interest during construction not capitalised)
                          entered, not declared

The figure is true — the model did run with a capitalisation factor of exactly 1 — but the
attribution was not. The report credited the author with a modelling decision they were never
offered.

Those rows now print **`not a field in v4.1.0`**, naming the model version that did not have the
field, so a reader can check the claim rather than take it. The count is 182 and no more: the 33
LCOH calculations issued since 10 Aug carry the field, and all 266 TEA calculations carry it in
both periods, because on the TEA side it has existed since 9 May 2026 — the field was born twice,
in two places, on two dates, and that asymmetry is the whole of the defect.

**How the distinction is made, and what it deliberately does not do.** The signal is a set
difference: a key the platform offers under the current defaults and did not offer under the
defaults of the calculation's own model version. It is **not** "this key has no default" — the
capex-scaling levers have no default in any version, and over those `entered, not declared` is
correct, because the author does type them. Conflating the two would turn a true cell into a
false one, which is worse than the defect being fixed here.

**The backing index counts it in a bucket of its own**, never folded into "no stated origin".
A figure with no stated origin is **missing** something; one that was not a field is missing
nothing, because there was no question to answer. Adding it to that total would print exactly
the accusation this bump exists to remove. The bucket is printed only when it is non-empty, so a
report issued under the current version is unchanged to the byte.

**What this moves.** A re-download of a pre-10-Aug LCOH report changes bytes — three cells stop
accusing the author, and the index gains a clause. Nothing else: no formula, no default and no
printed figure. `model_version` is untouched and no `content_sha256` moves, the same criterion as
the five bumps above. This version is the only thing on record that can say why two emissions of
identical declared composition have different bytes.

## 3.1 → 3.2 — 20 Sep 2026

**A figure that came from a public market is neither a platform default nor something the author
typed, and the reports now say so.**

Until this bump, an electricity price anchored to the Iberian day-ahead market fell into
`entered, not declared`. The report then contradicted itself on two consecutive rows: the price
row said nobody knew where the number came from, and the row immediately beneath it printed the
market, the averaging window, the capacity factor used and the licence citation. The backing
index closed the circle by listing that key among the figures stating no origin at all — an
accusation aimed at the only figure in the document that comes from a real market, computed by
the platform's own instrument.

Those rows now read **`anchored · OMIE ES`**, and the backing index counts them in a bucket of
their own: *anchored to a published market*, named key by key. It is not folded into the declared
counts either — nobody signed for it; a market did.

**The match is on the VALUE, not on the key.** If the author types over an anchored price, the
anchor no longer describes what is printed and the cell returns to `entered, not declared`. That
rule was paid for on 13 Sep 2026, when catalogue prefill recorded only which keys it had filled
and the report claimed `catalogue` over figures the author had since changed.

**What the anchor is, and what it is not.** It is price-following over a pinned window of
day-ahead market dates at the project's own capacity factor, with its coverage stated; the
provenance travels in full, so anyone can re-run the aggregation over the same window and get the
same number. It is not a delivered cost and not a contract: the report already carries that
disclosure beside the citation, and this bump does not soften it.

**And a font fix rides with it.** `sanitizeForPDF` did not know the rightwards arrow, so
`window 2026-08-21` to `2026-09-19` reached the page as mangled bytes — the two halves of a
UTF-16 code unit printed as characters. It was in the only row of the report that cites a market
and it had been there since the anchor existed, because that path is rarely exercised. Found by
looking at the paper, not by a test.

**What moves.** A report with no anchor is unchanged to the byte. A report with one moves: one
cell stops accusing the author, the index gains a clause, and the window stops printing garbage.
No formula, no default and no computed figure changes; `model_version` is untouched and no
`content_sha256` moves, the same criterion as the six bumps above.

## 3.2 → 3.3 — 20 Sep 2026

**The system boundary stops being a label that cannot be wrong.** Until today
`system_boundary` had one legal value, `plant_gate`. It was printed on page one as one of
the five declarations that say which question a cost figure answers — and it could not
answer anything, because no other figure could ever disagree with it. A dimension with a
single value does not discriminate; it decorates.

It now has two, and the second one is earned rather than added. `delivered` does **not**
mean this platform priced a delivery chain: it cannot, and the modules that could are a
reconstruction of a 2018 Australian case study in the source, not anybody's project. It
means the author DECLARED that the cost figures already include a downstream leg, and
declared which leg — through exactly the machinery every other declared figure uses. The
rule the enum was born with is intact: no boundary is offered that the platform would have
to invent a price for.

**What the contract now refuses.** A figure declared `delivered` with no delivery state is
rejected at the API, not carried. A `compressed` state without both pressures is rejected,
and so is one whose delivery pressure does not exceed its inlet pressure. These are
cross-field conditions, so they live inside the contract rather than in a wrapper a new
route could forget to apply.

**And one declaration is now checked against physics.** A `compressed` state asserts that
the specific consumption already includes the compression. The reversible isothermal work
of that compression — R·T/M · ln(P₂/P₁), from the two pressures the author declared — is a
floor no real compressor can go under, so it is added to the route's own electrical floor
and the declared consumption is refused below the sum. For 30 → 350 bar that floor is
0.811 kWh/kg; for 30 → 700 bar, 1.040 — at the module's own reference temperature of
288.15 K, which is where its published isothermal coefficient of 1.1877 MJ/kg comes
from. Both figures are pinned by a test against the function that computes them, so
this document cannot drift from the code. It is a floor and it is not a cost: a real
compressor consumes more, and its capital and O&M are not in it. The platform does not say
what compressing costs. It says which declarations are impossible.

**What moves.** Nothing already sealed. `delivery` is optional and the shipped default does
not carry it, so a calculation without a declared leg produces the same payload it always
did, keeps its `content_sha256`, and prints the same five rows — the delivery row appears
only when there is a declaration to print, the same criterion the backing index uses for
its buckets. The reference case and the frozen base do not move. `model_version` is
untouched, for the reason this block was put inside `inputs` in the first place: two
calculations with different boundaries already hash differently, so the discriminator needs
no version to announce it.

## 3.3 → 3.4 — 20 Sep 2026

**The report states what it did NOT evaluate, instead of leaving it blank.**

This report has eight blocks that draw nothing when they have no data to print — compliance,
sizing, third-party screening, the conventional-fuel comparison, internal review, the backing
index, the declarations block and catalogue provenance. That contract is deliberate and it is
what lets an already-issued report re-download byte for byte. But it was never a decision
about what the READER sees, and to a reader these three are indistinguishable:

- the analysis was **not run** — nothing was attached to evaluate;
- the analysis **was run and found nothing wrong**;
- the analysis **does not apply** to this project.

In a forensic document silence reads as "not applicable", which is an assertion nobody made.
A committee that does not see a compliance chapter does not conclude that it was skipped.

**What is added.** A note, after the analysis and before the reference material, listing every
block that stayed silent, with what would have to be attached for it to appear. It is
CALCULATED from the report itself: each block reports whether it drew by returning its cursor
unchanged, so the note repeats none of their conditions and cannot drift from them. Three of
the eight are registered as NOT printable, each with its written reason — their silence is
already counted elsewhere on the page, and saying it twice inside one document is the defect
this report exists to avoid.

The same principle the contract already applies to a field: `undeclared` is the honest default
and not a hole. This extends it from fields to chapters.

**What moves.** No formula, no default, no printed figure. A report whose blocks all have data
prints nothing new and does not change by a byte. `content_sha256` covers inputs, outputs,
model version and timestamp — never the PDF binary — so no stored calculation moves and
`model_version` is untouched.

**What this bump does NOT cover, stated rather than implied.** The TEA and Monte Carlo reports
have conditional blocks of their own and are unchanged: this note is issued by the LCOH report
only. And the note reports SILENCE, not quality — a block that drew something is outside its
scope entirely.

## 3.4 → 3.5 — 20 Sep 2026

**A citation is corrected.** Nothing is computed differently, no default moves and no figure
printed in any report changes. What changes is **whose convention** the platform says it
follows when it reports the LCOH gross of subsidy.

**What the published methodology said.** That computing the LCOH gross of subsidy was the
"NREL ATB / IEA / EU Hydrogen Observatory convention". The same attribution appears in §6
of `calculator-methodology-v5.0.0.md`, `v5.1.0.md` and `v5.2.0.md`. Those three documents are
sealed and are **not** edited: this section is the correction, and it is the one a reader
should rely on.

**What the three bodies' own documents say**, checked on 20 Sep 2026:

- **EU Hydrogen Observatory** — its LCOH calculator carries subsidies **inside the formula**:
  `Total LCOH = CAPEX + Electricity cost + Other OPEX + Grid fees + Taxes + Subsidies +
  Oxygen revenues` (*Manual — LCOH calculator, Update 2025, v3.1*). Only the default value
  is zero. **It documents the opposite convention.**
- **IEA** — the *Global Hydrogen Review 2025, Assumptions Annex* does not address subsidies,
  grants or tax credits. **It does not state the convention.**
- **NREL ATB** — its *R&D Only* financial case "excludes effects of tax reform and tax
  credits" (*ATB 2024, Definitions*). It states it **for tax credits, not capital grants**, and
  it also publishes a *Market + Policies* case that includes them.

**The sources that do state it, and are now cited:**

- **IRENA**, *Renewable Power Generation Costs in 2025, Annex I*, p. 2 — its cost analysis
  "excludes the impact of government incentives or subsidies".
- **US DOE Hydrogen Program Record 24005**, *Clean Hydrogen Production Cost: PEM
  Electrolyzer*, p. 2 — "untaxed and unsubsidized costs associated solely with hydrogen
  production". The only one of the five specific to hydrogen, and it puts the exclusion in
  the label of the figure.

**How to compare with the EU Hydrogen Observatory**, because that is the tool a European
committee will reach for: its formula subtracts subsidies when a user enters them, so compare
this platform's LCOH against the Observatory's **default** figure, not against a subsidised
run of it.

**What moves.** The methodology page states the corrected citation, with a dated erratum saying
what it stated before. Reports print `Methodology version: v3.5`. `methodology_version` is not
part of `content_sha256` and `model_version` does not move: the only change to the engine source
is a comment, and the program with comments removed is byte-identical to `3.4`.

## 3.5 → 3.6 — 21 Sep 2026

**An assertion the reports made about themselves is corrected.** Nothing is computed
differently, no default moves and no figure printed in any report changes.

**What the reports and the methodology page said**, from 2.9 to 3.5, in the box *What this
cost excludes, and the money-year index*: that "money years are aligned with the
Nelson-Farrar refinery construction cost index", that the index "is applied here to
electrolysis capital", and that "the figures above use 60:40 as published".

**What the platform does.** No figure is escalated to another money year, and none ever was.
Measured in the code and in its history: the two functions that could escalate a figure,
`normalise()` and `compareNormalised()` in `src/lib/calculations/normalisation/normalise.ts`,
have never had a caller outside that file; the escalation factor is read in one place,
`moneyYearNote()` in `src/lib/comparability/normalisation-note.ts`, which quotes it and states
that it is not applied; and the comparator, given two money years, says that no normalisation
has been applied. The money-year line of every report that prints one said "unadjusted".

**What the index does, all of it.** When the declared money year falls inside the series
(1946 to 2017; the input contract accepts years from 1990), the money-year line quotes the
factor that escalating to 2018 money would apply, and states that it is not applied. For a
later year (every year from 2018, the platform default among them) it states that the series
does not reach it and that the figure is carried as declared.

**What the 2.9 section above also got wrong.** It said that choosing another weighting "would
move published figures". It would move one: the factor quoted on the money-year line, for a
year inside the series. Choosing a weighting remains open, and is not part of this bump.

**The corrected note**, printed by the three reports and by `/methodology`:

> No figure is escalated to another money year: this model version applies no cost index to
> any figure it computes or prints. When the declared money year falls inside the
> Nelson-Farrar refinery construction cost index series, which runs from 1946 to 2017 with
> 2018 as its base, the money-year line of the comparability block states the factor that
> escalating to 2018 money would apply, and that it is not applied; for a later year it
> states that the series does not reach it. That factor uses the index with its published
> weighting, 60 per cent labour and 40 per cent materials. That weighting is the one its
> publisher, the Oil & Gas Journal, maintains for continuity of the series; the same
> publisher reports that surveyed project composition has moved towards 40 per cent labour,
> and publishes the series at five weightings so an evaluator can match their own project.
> The index is a refinery construction index, accurate for the US Gulf Coast and described
> as suited to petroleum and petrochemical work, not an electrolysis index. No alternative
> weighting is applied.

**What moves.** The text of that box in every report issued or re-downloaded from 3.6, and the
methodology page, which also carries a dated erratum saying what it stated before. Reports print
`Methodology version: v3.6`. `methodology_version` is not part of `content_sha256`, and
`model_version` does not move: no formula, default or printed figure changes. The published
documents for 2.9 to 3.5 are sealed and are **not** edited: this section is the correction, and
it is the one a reader should rely on.

## 3.6 → 3.7 — 21 Sep 2026

**Three different figures were printed under one name, "total CAPEX". Each now says which it
is.** Nothing is computed differently, no default moves and no figure changes value.

**Two engine fields share a name and not a meaning.** Both engines publish `capex_total`:

- in the **LCOH** it is the physical CAPEX **gross of subsidy** — the LCOH has been gross of
  subsidy since 4.1.1, and the LCOH's output type says so;
- in the **TEA** it is the physical CAPEX **net of subsidy**.

Both reports printed the figure as "Total CAPEX". On a worked example — 150 MW at
1,179.49 EUR/kW with 30 % balance of plant and a 62.49 M grant — the LCOH printed 230.00 M and
the TEA would print 167.51 M under the same label; the difference is the grant. The comparator put the two side by side in one row, and the CSV export in one column.

**What §4 of `calculator-methodology-v5.2.0.md` says**, and that document is sealed: "CAPEX_net
= CAPEX_physical − subsidy → reported as capex_total". That describes the TEA's output. The
LCOH's output field of the same name carries CAPEX_physical. This section is the correction.

**A third figure also went by "total CAPEX".** The TEA report's methodology paragraph and its
glossary said the project cash flow starts, at Year 0, with "total CAPEX". It starts with the
capital raised: the gross CAPEX capitalised over the construction period, less the subsidy
(`capex_funded`, the base §7 of the sealed document already gives for debt and equity). The
order matters and it is the engine's: the gross figure is capitalised and the subsidy is
deducted after it, so the subsidy is not capitalised. With 18 months of construction at a 7 %
WACC the engine's capitalisation factor is 1.088725, and on the same example the capital raised
is 230.00 × 1.088725 − 62.49 = 187.92 M, against the 167.51 M of the "Total CAPEX" row: a reader
recomputing the NPV from the printed row was 20.4 M out. Capitalising the net figure instead
would give 182.37 M.

**What each surface now prints.**

| figure | engine field | printed as |
|---|---|---|
| physical CAPEX, gross of subsidy | LCOH `capex_total` | "Total CAPEX, gross of subsidy" |
| physical CAPEX, net of subsidy | TEA `capex_total` | "Total CAPEX, net of subsidy" |
| Year 0 of the project cash flow, and the base of debt and equity | TEA `capex_funded` | "the capital raised (gross CAPEX capitalised over the construction period, less the subsidy)" |

The units follow the figures they name. O&M is "% gross CAPEX/year", because both engines
compute it on the gross physical CAPEX; a subsidy entered as a percentage is "% of gross CAPEX",
because it is derived from the gross figure; and the debt share is "% of capital raised".

**The comparator compares like with like**: one row, physical CAPEX gross of subsidy, read from
each engine — `capex_total` for an LCOH, `capex_physical_gross` for a TEA. A TEA computed before
5.0.0 does not carry that field; it is reconstructed from its inputs, and exactly, because
capacity scaling and the itemised surcharges did not reach the engine before 5.0.0. **The CSV
export** replaces its `capex_total_eur` column with `capex_gross_eur` and `capex_net_eur`, each
empty where a row does not carry that figure.

**What moves.** Labels and units in both reports (the bytes of every re-download), the screens,
the TEA value in the comparator (now gross, like the LCOH's), and the CSV header. Reports print
`Methodology version: v3.7`. `methodology_version` is not part of `content_sha256`, and no
engine output moves.

## 3.7 → 3.8 — 21 Sep 2026

**What the reports and the forms said about inflation, set against what the engine does.**
Nothing is computed differently, no default moves and no figure changes value.

**The TEA report's methodology paragraph said "Cash flows are nominal (pre-inflation on
revenue; inflation applied to OPEX)".** The revenue is not pre-inflation: the H2 selling price
escalates each year after the first at the declared Price Escalation — 2 % a year by default —
or, in the years an offtake contract covers, at the contract's index rate within its floor and
cap. O2 revenue is flat. And what the inflation rate escalates is four named costs, not an
"OPEX" line. The paragraph now reads:

> Cash flows are nominal. Electricity, O&M, water and stack replacement are escalated at the
> declared inflation rate each year after the first; the H2 selling price escalates at the
> declared Price Escalation or, in the years an offtake contract covers, at the contract's index
> rate within its floor and cap; O2 revenue is flat.

**The discount rate is nominal, and nothing said so where it is typed.** Every flow the WACC
discounts is escalated, so the WACC has to include inflation. The TEA glossary called it the
after-tax WACC without saying nominal, and both forms asked for a "discount rate". On a worked
example — 150 MW at 1,179.49 EUR/kW with 30 % balance of plant, electricity at 87.65 EUR/MWh,
2 % inflation and a 7 % WACC over 20 years — the same cost of capital entered in real terms,
4.902 %, gives an LCOH of 7.69 EUR/kg instead of 7.88. The WACC now carries "% nominal" in its
unit, and the TEA glossary says after-tax and nominal.

**The electricity price is a first-year price.** Its help text asked for the "average
electricity cost over the project lifetime"; the engine takes the figure as the price of the
first operating year and escalates every later year. On the same example, 87.65 EUR/MWh taken
as the first-year price gives 7.88 EUR/kg; the same 87.65 held flat for the whole life would
give 7.10. The help texts of the prices and costs now say first year, and name the rate that
escalates each: the costs at the inflation rate, the H2 price at Price Escalation, O2 revenue at
none. In the TEA form the stack replacement help text also said "% of original CAPEX"; the
engine charges it on the electrolyser CAPEX, as its unit already said.

**What each surface now says.**

| surface | now |
|---|---|
| TEA report, methodology | the escalation of each flow, as quoted above; the after-tax WACC "applied as a nominal rate" |
| TEA report, glossary and the note under the cash-flow table | WACC after-tax and nominal |
| both reports, parameter table | WACC in "% nominal" |
| both forms and the parameter declarations | WACC in "% nominal"; prices and costs are first-year values, and each help text names the rate that escalates it |
| comparator, Monte Carlo editors, TEA reference case | "WACC (% nominal)" |
| Monte Carlo bias panel | the four escalated costs — it named three and left out stack replacement —, the nominal WACC, and the H2 price and O2 rules, with citations that point at those lines |
| `/methodology` | the prices and costs entered are first-year prices, so `i` is a nominal rate |

**Recorded late.** Earlier on 21 Sep 2026, under 3.5, two report texts were corrected without a
methodology bump. The LCOH report's methodology paragraph said the cash flows were "nominal
pre-inflation on the revenue side and inflation-adjusted on OPEX" — the LCOH engine has no
revenue side — and it now names the four escalated costs and states that the WACC is applied as
a nominal rate. And the footer of all three reports credited the IEA Hydrogen Projects Database
for project data; it now does so only in an LCOH report that carries a catalogue row. Reports
issued under 3.5 before and after that correction differ in those two texts. This section
records it.

**What moves.** The TEA report's methodology paragraph, glossary and cash-flow note, the WACC
row of both reports (the bytes of every re-download), and labels and help texts on screen.
Reports print `Methodology version: v3.8`. `methodology_version` is not part of
`content_sha256`, and no engine output moves.

**What this does not settle.** The LCOH is a levelised price over nominal costs discounted at a
nominal rate, and the report's comparability line states one money year for it. What a single
money year means for that figure is not settled by this bump.

## 3.8 → 3.9 — 21 Sep 2026

**What the money year on page one dates.** Nothing is computed differently, no default moves
and no figure changes value.

**The comparability strip on page one of the three reports printed the money year as if it were
the money of the figure above it.** On the worked example of 3.8 the line read "Money year: 2022
EUR, unadjusted", directly under an LCOH of 7.88 EUR/kg. That LCOH is a nominal levelised price.
Electricity, O&M, water and stack replacement are escalated at the declared inflation rate, and
every flow is discounted at the WACC, which is a nominal rate (see 3.8): the LCOH is the one price
per kilogram which, charged unchanged every year, recovers those costs. It is not a price in 2022
money unless the declared inflation rate is zero. On the same example, the same cost of capital in
real terms, 4.902 %, with nothing escalated, gives 6.73 EUR/kg, 14.6 % less than the 7.88 the
report prints.

**The line now says what the year dates, and what it does not.** For that example it reads:

> 2022 EUR inputs, unadjusted — the Nelson-Farrar series ends at 2018 and its source gives
> nothing with which to extend it, so these inputs are carried as declared. Levelised prices in
> this report, such as the LCOH, are nominal over the project life: electricity, O&M, water and
> stack replacement are escalated from the inputs at the declared inflation rate, and every flow
> is discounted at the nominal WACC. They are 2022 EUR figures only if the declared inflation rate
> is zero.

The condition is written out because it is true, not as a hedge: this platform's own cost index
and benchmark run at a zero inflation rate, and there the levelised price is a figure in the money
year of its inputs.

**What each surface now says.**

| surface | now |
|---|---|
| the three reports, comparability strip on page one | "<year> EUR inputs", followed by the sentence quoted above |
| the three reports, the note printed when a parameter declares a cost year of its own | "the cover states <year> EUR inputs" |
| both forms, summary line of the comparability panel | "<year> EUR inputs" |
| both forms, help text of the money year | the year dates the inputs, not the results; levelised results are nominal, and in that year's money only if the Inflation Rate is zero |
| comparator, table and PDF export | an "Inflation Rate (%/yr)" row, because two LCOHs at different inflation rates are not on the same basis |
| `/methodology` | the LCOH is a nominal levelised price, a figure in the money year of the inputs only if the inflation rate is zero |

**What moves.** The text of the comparability strip on page one of the three reports, and with it
the strip's height, so whatever follows it on page one starts lower; the vintage note; the panel's
summary line and help text; and one comparator row. Reports print `Methodology version: v3.9`.
`methodology_version` is not part of `content_sha256`, and no engine output moves.

**What this does not settle.** The engine still publishes the LCOH as a nominal levelised price.
Publishing it in constant money of the declared year, instead or beside it, changes an engine
output, and no methodology bump does that. Nor does the comparator refuse two calculations at
different inflation rates: it now shows the rate of each.

## 3.9 → 3.10 — 22 Sep 2026

**What the LCOH report says about the capital it charges at year 0.** Nothing is computed
differently, no default moves and no figure changes value.

**The LCOH report printed one capital figure and charged another.** On the worked example of
3.8 — 150 MW at 1,179.49 EUR/kW with 30 % balance of plant and an 18-month construction
period — page 4 printed "Total CAPEX, gross of subsidy EUR230.00M". The engine does not charge
that figure at year 0: it capitalises it over the construction period at the WACC, with the
disbursement profiles of Seddon's Table A7-1 — for an 18-month build, halfway between the
factors those profiles give for one and two years — and charges EUR250.41M, 1.088725 times as
much.
The report printed neither the factor nor the figure. Rebuilt from what the report printed, the
LCOH came to 7.74 EUR/kg instead of the 7.88 on its cover, and capex to 1.50 EUR/kg instead of
the 1.63 that page 4 stated. The TEA report has printed its capital raised and the factor since
12 Sep 2026; the LCOH report now prints the same factor row, and the capital it charges, under
the total CAPEX:

> Construction Capitalisation — 1.088725x over 18 months
> Capex charged at year 0 — EUR250.41M

They appear only when there is a construction period. Without one the two figures are equal,
and the table is as it was.

**The factor is printed to six decimals, in both reports.** At four, the printed figures did not
multiply to the printed result: 230.00 × 1.0887 gives 250.40 against the 250.41 of the LCOH
report, and 230.00 × 1.0887 − 62.49 gives 187.91 against the 187.92 of the TEA report's capital
raised.

**The discounting convention is stated.** Each year's costs and production are placed at the end
of that year and discounted at the WACC; the report did not say so. With the same capital,
mid-year discounting gives 7.82 EUR/kg on the same example. The methodology paragraph now reads:

> Electricity, O&M, water and stack replacement are escalated at the declared inflation rate
> each year after the first. Each year's costs and production are placed at the end of that year
> and discounted at the WACC, which is therefore applied as a nominal rate. Capex is charged at
> year 0 and is not escalated. Stack replacement is treated as an operating expense in the year
> it occurs.

and, when there is a construction period, it adds:

> The capex charged at year 0 includes the interest accrued over the construction period,
> capitalised at the WACC.

**What each surface now says.**

| surface | now |
|---|---|
| LCOH report, production summary | "Construction Capitalisation" and "Capex charged at year 0", when there is a construction period |
| LCOH report, methodology | the end-of-year convention, and the capitalisation when there is a construction period |
| LCOH report, note under the cost waterfall | "charged at year 0", the name the new row uses, instead of "t=0" |
| TEA report, parameter table | the construction capitalisation factor to six decimals |
| LCOH result screen, the gross CAPEX card | the capital charged at year 0 and the factor, when there is a construction period |

**Also corrected.** A TEA report built from an output that carries no construction
capitalisation factor — any calculation saved before model version 5.0.0 — failed to generate
since 12 Sep 2026: the two capitalisation rows were added whenever the factor was not exactly 1,
and a missing factor is not 1. They are now added only when the factor is a number other than 1.

**What moves.** The methodology paragraph of every LCOH report, and the note under its cost
waterfall where it is drawn; the production summary of every LCOH report with a construction
period; the factor row of every TEA report with one; and the result screen. Reports print
`Methodology version: v3.10`. `methodology_version` is not part of `content_sha256`, and no
engine output moves.

## 3.10 → 3.11 — 22 Sep 2026

**What three blind readers found the reports saying wrong, or not saying.** Nothing is computed
differently, no default moves and no figure changes value.

On 22 Sep 2026 three readers who had only the PDF of the sample report, T-HYNET Tarragona, rebuilt
its cover figure and listed what they could not read or could not trust. **Three sentences were
false.**

**The money year dated inputs that were not of that year.** The strip on page one said "2022 EUR
inputs", and the electricity price, 72.7 % of the figure, is anchored to 2026 market prices. It
went on to say that the levelized prices "are 2022 EUR figures only if the declared inflation rate
is zero", which with inputs from more than one year is false at any rate. The line now names the
inputs that are not in the declared year, an electricity price anchored to another year's market
and any parameter that declares a cost year of its own, and when there are any it says that the
levelized prices are not the money of any single year. For the sample it reads:

> 2022 EUR inputs except the electricity price, anchored to 2026 market prices, unadjusted — the
> Nelson-Farrar series ends at 2018 and its source gives nothing with which to extend it, so
> these inputs are carried as declared. Levelized prices in this report, such as the LCOH, are
> nominal over the project life: electricity, O&M, water and stack replacement are escalated
> from the inputs at the declared inflation rate, and every flow is discounted at the nominal
> WACC. With inputs from more than one year they are not the money of any single year, whatever
> the inflation rate.

Without such inputs it reads as in 3.9, spelled "Levelized" (see below):

> 2022 EUR inputs, unadjusted — the Nelson-Farrar series ends at 2018 and its source gives
> nothing with which to extend it, so these inputs are carried as declared. Levelized prices in
> this report, such as the LCOH, are nominal over the project life: electricity, O&M, water and
> stack replacement are escalated from the inputs at the declared inflation rate, and every flow
> is discounted at the nominal WACC. They are 2022 EUR figures only if the declared inflation
> rate is zero.

**The note on what was not evaluated described another calculation.** It said that "the contracted
renewable capacity behind these figures is the one entered", and neither an LCOH nor a TEA has that
input: their electricity is a number of operating hours and a price. It now says so.

**The Nelson-Farrar series ended in two different years.** Page one said the series "ends at 2018";
the box on the last page said it "runs from 1946 to 2017 with 2018 as its base". The published
table runs from 1946 to 2018, its base year; the 2018 row carries only an index and a factor, which
is why the platform's own rows stop at 2017. The box, printed by the three reports and by
`/methodology`, now reads:

> No figure is escalated to another money year: this model version applies no cost index to any
> figure it computes or prints. The Nelson-Farrar refinery construction cost index series runs
> from 1946 to 2018, its base year. When the declared money year falls before the base, the
> money-year line of the comparability block states the factor that escalating to 2018 money
> would apply, and that it is not applied; from the base year on, it states that the series ends
> there. That factor uses the index with its published weighting, 60 per cent labour and 40 per
> cent materials. That weighting is the one its publisher, the Oil & Gas Journal, maintains for
> continuity of the series; the same publisher reports that surveyed project composition has
> moved towards 40 per cent labour, and publishes the series at five weightings so an evaluator
> can match their own project. The index is a refinery construction index, accurate for the US
> Gulf Coast and described as suited to petroleum and petrochemical work, not an electrolysis
> index. No alternative weighting is applied.

**Nine things were read wrong, or were not said.**

| what the readers found | what the reports now print |
|---|---|
| the cover did not say that its largest cost is priced at a floor | a row in the comparability strip, when the price is anchored |
| the horizontal gridlines of the line charts fell between the axis labels | one gridline per label, in the LCOH operating-cost chart and in the TEA DSCR chart |
| the same cost component had different colours and names on pages 3 and 4 | one name and one colour per component |
| "Running operating cost" did not say what the line is, and "Cash-cost waterfall" named stacked bars | "Levelized operating cost to date", explained under the chart, and "Operating cost by component" |
| "Verifiable at /verify." was half a path, and `/verify` confirms a report's integrity; it does not re-derive its price | how the price can be re-derived |
| the construction capitalisation factor could not be rebuilt | where it comes from |
| how stack degradation is modelled | how it is modelled |
| what the sensitivity analysis moves and what it holds | what it moves and what it holds |
| 45V, a US tax credit, listed for a European project | each compliance module with its jurisdiction |

The strip row, for the sample:

> 72.7% of this figure is electricity, priced at the OMIE price-following average of 30 market
> days (2026-08-21 to 2026-09-19). Best-case wholesale floor — price-following assumes perfect
> price foresight, not a delivered cost.

The note under the price basis now ends:

> The zone, window and load factor printed with it are enough to re-derive it from public OMIE
> day-ahead prices.

The note under the operating-cost bars:

> The line is the operating cost levelized from year 1 to each year: discounted operating cost
> over discounted production to date. Capex is not in these series: it is charged at year 0,
> outside the years plotted, and adds EUR1.55/kg. The headline LCOH is EUR7.77/kg.

The methodology paragraph adds, when there is a construction period and when the stack degrades:

> The factor applies the construction spending profiles of Table A7-1 of Seddon, The Hydrogen
> Economy (2022), at the WACC; an 18-month build is interpolated halfway between the one-year
> profile and the two-year profile. Stack degradation is modelled as lost output: each year the
> production falls by the declared rate at the same electricity per kilogram, so the plant also
> buys less electricity, and a stack replacement does not restore it.

And under the sensitivity table, which had no note:

> Each row moves one input by ±20% and holds every other input at its base value. The stack
> replacement years do not move with Operating Hours, and the anchored electricity price is not
> re-anchored at the new load factor.

**Also in the report text.** "Levelised" is spelled "levelized", as in the cover headline, which
gives its reasons for the spelling; the declarations box prints "Subsidy (subsidy_eur)" instead of
the bare key; the stack interval row prints its dash as the rest of the table does; the cost
breakdown says so when its rounded shares do not add up to 100 %; and the height the reports
reserve for the comparability strip is measured by the function that draws it, not written by
hand.

**A correction to this document.** The 3.3 → 3.4 section says that "`content_sha256` covers
inputs, outputs, model version and timestamp". It does not cover the timestamp: the hashed payload
is `{type, inputs, outputs, model_version}`, as the last section of this document says. The
timestamp is in `hash_sha256`, the event hash printed on the cover of a report the product issues.

**And the worked example of 3.8 to 3.10.** Its figures, 7.88, 7.10, 7.69, 6.73, 7.74 and 7.82
EUR/kg, were the sample report's on 21 and 22 Sep 2026. That input counted availability twice: its
operating hours were already net of downtime, and a 95 % availability was applied on top. The
sample now declares 100 % and prints 7.77 EUR/kg. The quoted figures remain correct for the input
they were computed on, which is pinned in the test suite; they are no longer the sample's.

**What moves.** The comparability strip on page one of the three reports when the price is
anchored or a parameter declares its own year, and the strip's height; the note on what was not
evaluated; the index box; the line charts' gridlines; the colours and labels of the LCOH cost
charts; the notes under the price basis, the operating-cost bars and the sensitivity table; the
methodology paragraph of both reports; and the money-year help text of both forms and
`/methodology`, which now say that a levelized figure is in the declared year's money only if all
the inputs are. Reports print `Methodology version: v3.11`. `methodology_version` is not part of
`content_sha256`, and no engine output moves.

## 3.11 → 3.12 — 22 Sep 2026

**A declaration can say where its figure comes from, and the boxes stop reserving room their
text does not use.** Nothing is computed differently, no default moves and no figure changes
value.

**What a declaration could not say.** A parameter declaration recorded who states a figure — a
vendor quote, a published study, an internal estimate —, its cost year, and the hash of a document
that backs it. The sample's own records carry two more things that a consultancy works with every
day: the arithmetic behind a figure, and a web page with the date it was published, the date it
was read and the sentence that supports the figure. The reports could print neither, and three
blind readers read the sample's declared figures as figures with nothing behind them; two rebuilt
by hand where its electrolyser cost per kW came from. The input contract did not reject those
fields either: it dropped them without a word, so a report built outside the product could print
what the product would not store.

**What a declaration now carries.** Two optional fields: a basis of up to 400 characters, and a
web source — an https URL, its publisher, the date it was published if known, the date it was
accessed, and up to 300 characters quoted from it. A URL that is not https, a date that does not
exist, or an access date before the publication date is refused. Both travel inside `inputs`, so
both are sealed by `content_sha256`: a comma added to a basis moves the hash.

**What the reports print**, under each declaration that carries them. For the sample's
electrolyser CAPEX:

> Basis: EUR 230 M project investment / 150,000 kW / 1.30 = 1,179.49 EUR/kW. The source gives
> the investment for the project, with storage listed apart; the engine adds the 30 % balance of
> plant back, so the total CAPEX printed is the published EUR 230 M. One assumption: the 230 M
> includes the balance of plant.

> Source: Catalonia.com, published 2022-09-27, accessed 2026-09-21:
> https://catalonia.com/w/tarragona-will-have-the-largest-green-hydrogen-plant-in-spain-with-an-investment-of-230-million-euros
> - "The companies foresee an investment of 230 million euros in the project, with an additional
> 80 million for electrical storage facilities."

The box keeps its title, STATED BY THE AUTHOR, NOT VERIFIED, and its note: the platform does not
check the arithmetic or the quote. A web page is not cited by hash, because it changes without
notice; that is why it carries both dates and the sentence itself.

**The boxes stop reserving room their text does not use.** Four boxes advanced each line of text
by a hand-written step — 4 mm in the note boxes, 4.2 mm in the declaration, catalogue and
internal-review boxes — while jsPDF draws a block of lines 3.2456 mm apart in the small type they
use. In the sample, the box listing what the report did not evaluate was 88 mm tall for text
whose last line sits 69.4 mm down, so the 18.6 mm under that line were blank; the same box now
leaves 4.2. In the declaration box a row of two lines was followed by 5.15 mm of space and a row
of one line by 4.2. Every box now advances with the step jsPDF draws with, so the space under a
row or at the bottom of a box is the same whatever its number of lines; a declaration that
carries a basis or a source leaves 1.5 mm more under it, so the next one does not read as part
of it.

**What moves.** The declaration box of every report that declares a figure with a basis or a
source; the height of every note box, and of the declaration, catalogue and internal-review boxes,
in the three reports, so whatever follows them on a page starts higher (the bytes of every
re-download); and the input contract, which now keeps two fields it used to drop. Reports print
`Methodology version: v3.12`. `methodology_version` is not part of `content_sha256`, and no engine
output moves.

## 3.12 → 3.13 — 22 Sep 2026, with model 5.3.0

**The engine changes two things, and the reports say which model computed them.** The
method is specified in `calculator-methodology-v5.3.0.md`; this section says what the reports
now assert.

**How the stack degrades.** Every new calculation carries `stack_degradation_model:
efficiency_loss`: the stack draws the same power every year and produces less as it ages, so
each kilogram takes more electricity, and a stack replacement restores the output of year 1 from
the year after it — the replacement year itself still runs on the stack being replaced.
Until `5.2.0` production fell every year with no reset, at the same electricity per kilogram.
Three blind readers of the T-HYNET sample disputed that model; on the sample it gives 9.89
EUR/kg where the new one gives 10.09. The method paragraph of the LCOH and TEA reports prints
the sentence of the model the calculation used:

> Stack degradation is modelled as lost efficiency: the stack draws the same power every year
> and its output falls by the declared rate for each year since it was installed, so each
> kilogram takes more electricity; a replacement is charged in its own year, which still runs on
> the old stack, and the output of year 1 returns the year after it.

A report re-downloaded from a calculation stored before `5.3.0` prints the sentence of
methodology `3.11`, because that is what its engine did.

**How far the sensitivity moves each input.** The electrolyser cost now moves across the
accuracy band of the declared estimate class — ±40 % for a concept estimate — instead of ±20 %,
and the inflation rate is a new row, one percentage point either way. The table gains a column
that says how far each row moved its input, its headers name the two ends as the LCOH at the
low and at the high input, and the note under it is written from the rows:

> Each row moves one input and holds the rest at their base values: the electrolyser cost ±40 %,
> the wide end of the ±25-40 % accuracy band of a concept estimate, the inflation rate 1
> percentage point either way and the other inputs ±20 %. Operating Hours stops at 8760 h on the
> high side, the most the calculator accepts. The stack replacement years do not move with
> Operating Hours, and the anchored electricity price is not re-anchored at the new load factor.

On the sample the electrolyser cost row now spans 9.44 to 10.74 EUR/kg and the inflation row
9.43 to 10.82, against 10.03 to 10.16 for the WACC.

**Which hash is on the cover** (B10.85). The integrity box of the three reports said that the
cover's SHA-256 is a fingerprint of the inputs, outputs, model version "and timestamp". That is
true of every report a client downloads, whose cover carries the event hash. The T-HYNET
sample carries the content hash, which has no timestamp — that is what makes it reproducible —
and on it the sentence was false. The LCOH report now says which hash its cover carries; a
report printed with the content hash says:

> The SHA-256 hash on the cover is the content hash of this calculation: a cryptographic
> fingerprint of its type, inputs, outputs and model version. It carries no timestamp, so the
> same calculation always gives the same hash, and it is one of the two hashes under which
> /verify publishes a calculation registered in the GaugeH2 database. It does NOT cover the PDF
> binary itself. To verify a report: open the verification URL on the cover, then compare the
> figures shown there against the figures in this PDF. Any divergence indicates the PDF was
> modified after generation.

**What a sensitivity row may ask for** (B10.89). A row moved its input by its band without
checking that the value was one the input contract accepts. On the T-HYNET sample, at 7 463
hours, the operating-hours row asked for 8 955.6 hours in a year, and the report printed it as a
possible case. Every end now stops at the edge of what the contract accepts for that input —
read from the contract itself, with the floor the contract applies to the specific consumption —
in the LCOH and in the TEA. A row that stopped prints how far each side moved, and the note says
where it stopped:

> Operating Hours stops at 8760 h on the high side, the most the calculator accepts.

A TEA report adds the same sentences to its sensitivity note, and the title of its tornado adds
"or at the edge the calculator accepts" when one of its rows stopped. A report whose rows touch
no edge prints what it printed.

**What the second blind reading found** (B10.91, B10.92). Three new readers of the sample, who
had only the PDF, found three sentences the paper did not support; checking them against the EU
fiche — looked at rendered, not read as extracted text — found two facts about the sample that no
reader could see:

- the cover said the draft was generated on 20 Sep 2026 and cited a source consulted on 21 Sep.
  The draft now carries the time it is issued, as a product report carries the time of its row;
- the construction factor could not be rebuilt from the paper: the sentence named Table A7-1 of
  Seddon without its profiles. The LCOH and TEA reports now print the profiles they use — which
  share of the capital, how many years before start-up —, the factor of each at the WACC of the
  calculation and how they are interpolated:

> The factor applies the construction spending profiles of Table A7-1 of Seddon, The Hydrogen
> Economy (2022): each share of the capital accrues interest at the WACC from when it is spent
> until start-up. An 18-month build is interpolated halfway between the one-year profile, all of
> the capital one year before start-up (1.07 at a WACC of 7 %) and the two-year profile, 50 %
> two years and 50 % one year before start-up (1.10745): 1.088725.

- the backing index said the capacity and the technology stated no origin, and the fiche states
  both. They are now declared with it;
- the fiche is marked TERMINATED, updated on 9 Sep 2026. The sample declares its EU grant as 0,
  with a basis that says why;
- a footnote of the fiche gives the intensity of its CO2 figure, 6.84 t CO2e per t of hydrogen.
  With it the sample runs 7 463 hours a year, not 5 870, and its electricity price was anchored
  again at that load factor.

**Who the report is about, and at what price** (B10.97). A third reading of the sample, asked for
before signing it, found that the cover named the subject **nowhere**: the project's name appeared
on page 3, inside the name of the document backing six of its declarations. A calculation may now
carry one line about its subject, written by its author, and the comparability block of the three
reports prints it first, under the same words as every other declaration:

> Subject T-HYNET Tarragona (Repsol, Enagas Renovable, Messer). The EU Innovation Fund fiche
> behind six of these figures is marked TERMINATED, updated 9 September 2026. Stated by the
> author, not verified.

The same reading found that the anchored price asserted more than its sources support. The anchor
averaged the cheapest hours of each day at the project's load factor, which asserts that the plant
chooses when it buys; the sample's fiche states how many hours the plant runs, not which, and says
it will run continuously. The sample's price is now the average of **every** hour of the window,
and what the report says about it follows the rule that produced it, not the instrument:

> 83.6% of this figure is electricity, priced at the OMIE day-ahead average of 30 market days
> (2026-08-21 to 2026-09-19). Every hour of the window weighs the same - no choice of hours and
> no hedging assumed, and a market average is not a delivered cost.

A price anchored at a load factor below 1 still prints what it printed — the best-case floor and
the load factor it used — because there the sentence is true. With every hour averaged there is no
foresight to assume, no floor, and no load factor printed, so the re-derivation line names the zone
and the window alone. The row that carries this summary in the LCOH and TEA reports also gains its
own origin cell, `anchored · OMIE ES`, which was blank under a table headed "where each figure came
from", and a printed load factor now carries three decimals: at two, the sample's 0.85 rebuilt
7 446 hours against the 7 463 its own table declares.

**What moves.** Every new calculation, whose inputs carry the degradation model and whose
outputs carry the new sensitivity rows; the two reference cases; the T-HYNET sample, from 7.77 to
10.09 EUR/kg — on its new inputs the model alone moves it 9.89 → 10.09 EUR/kg, and the rest is
the inputs B10.91 took from its fiche; the method paragraph, the construction sentence and the
sensitivity section of the LCOH report; the method paragraph and the construction sentence of the
TEA report, and its sensitivity note and tornado title where a row stops; and the cover and the
integrity box of the sample. **What does not:** every
stored calculation, its figures and its hash, and every report re-downloaded from one, apart
from the layout of the sensitivity table; the index and the catalogue benchmark, which declare
no degradation model. Reports print `Model version: v5.3.0` and `Methodology version: v3.13`.

## 3.13 → 3.14 — 23 Sep 2026, with model 6.0.0

**The Monte Carlo TEA stops discarding the simulations that lose money.** A project IRR does
not exist when the unlevered cash flows never turn positive. Until `5.3.0` such a simulation
was discarded whole — with its finite, negative NPV inside — and counted as invalid, so every
published probability was a quotient over the survivors, and the survivors were the runs where
the project makes money.

Measured on 23 Sep 2026 with the T-HYNET sample and the hydrogen price drawn uniformly between
4 and 14 EUR/kg over 2,000 simulations: **1,163 discarded**, all 1,163 with a finite and
negative NPV, checked simulation by simulation. `prob_npv_positive` was published as **71.33 %**
over the 837 survivors; over the 2,000 simulations with a finite NPV it is **29.85 %**. With the
price between 4 and 6 EUR/kg every simulation was discarded and the run was stored and printed
as "0 valid simulations" with 0.0 % against every threshold — which reads as a measurement and
was the absence of one.

From `6.0.0` a simulation is discarded only when it produces no finite number. One without an
IRR counts in the NPV, the DSCR, the payback and the sensitivity regression, and is excluded
only from the IRR distribution; `runs_without_irr` publishes how many there were. For
`prob_irr_above_wacc` and `prob_all_bankable`, a missing IRR fails the condition instead of
leaving the sample. The method is §7.3 of `calculator-methodology-v6.0.0.md`.

Two more in the same bump. **`prob_no_payback` counted its denominator twice** — the valid
count already includes the simulations with no payback — and printed 12.72 % where the share
is 14.57 %. And **a run with no valid simulation now fails** with the two counts instead of
returning zeros, which is what the LCOH Monte Carlo has done since 23 Aug 2026.

**What moves:** every new Monte Carlo TEA run and its `content_sha256`, the two shipped
reference cases, and the version pair on every new report. **What does not:** every stored
calculation, its figures and its hash; the deterministic LCOH and TEA, field by field; the
LCOH Monte Carlo. Reports print `Model version: v6.0.0` and `Methodology version: v3.14`.

## 3.14 → 3.15 — 29 Sep 2026, with model 6.1.0

**The DSCR deducts a maintenance reserve.** Until `6.0.0` the stack replacement stayed out of
the DSCR numerator. On the reference case the cover read 1.64 in the year the equity holders
paid a 4.30 M€ replacement, and on the Galp Sines reconstruction of 13 Sep it read 1.48 in the
year they put in 84 M€. From `6.1.0` every replacement inside the debt tenor is funded in equal
contributions over the years of its stack and paid from that reserve, and the contribution is
deducted before the DSCR: the minimum on the reference case falls to 1.05, the NPV and the
project IRR do not move, and the equity holders pay the same total, sooner. The rule travels in
the inputs, `maintenance_reserve: funded_over_stack_years`, so a calculation stored before
keeps its DSCR and its report says the rule it was computed with. The method is §7.4 of
`calculator-methodology-v6.1.0.md`.

What the TEA report now asserts about it. The glossary defines the DSCR as:

> DSCR = (Revenue - Recurring OPEX - Reserve contribution) / Annual Debt Service. Each stack
> replacement inside the debt tenor is paid from a maintenance reserve funded in equal
> contributions over the years of that stack, and the contribution is deducted before the
> DSCR; a replacement after the tenor is paid from that year's equity cash flow.

The legend of the coverage page, after the stack mark, repeats the second sentence; until
`6.0.0` it said that the replacement "is excluded from the DSCR numerator", and a report re-issued
for a calculation stored before still says so. The annual table gains a `Reserve` column, marks
the replacement the reserve pays, and says under it:

> [S] = stack replacement year. [R] = paid from the maintenance reserve, not from that year's
> equity cash flow. Equity CF = Revenue - OPEX - Stack not marked [R] - Reserve - Debt svc - Tax.
> DSCR = (Revenue - OPEX - Reserve) / Debt svc.

and the parameter table names the rule: "Maintenance Reserve — Funded over each stack's years,
for replacements inside the debt tenor", with its origin.

**The LCOH is published in constant money beside the nominal figure** (§3.2): the same project
with nothing escalated, discounted at the real WACC. The headline box of the LCOH report, the
calculator's result and the TEA's metrics print it; on the T-HYNET sample:

> In constant money: EUR8.63/kg, the same project with nothing escalated and discounted at the
> real WACC of 4.90 %, in the money of the inputs. The figure above is nominal.

**The TEA sensitivity moves the capital cost across the band of its estimate class** (§3.1), as
the LCOH row has since `5.3.0`: ±40 % on a concept estimate, where it moved ±20 % while the first
page of the same report declared ±25–40 %. Every row prints its sweep, and the tornado's title
says which rows move by another band.

**The stress test is specified.** What `2.7` said was not yet published — the shock magnitudes,
the order of application and the absorption rules — is §7.5 of the frozen document. The primary
sources remain `src/lib/calculations/stress.ts`, `stress-disclosure.ts` and
`sensitivity-sweep.ts`, and a test ties each magnitude in §7.5 to the constant the code uses.
The note above the stress table now says the shocks use the magnitude of the selling-price row,
because since this version the sensitivity does not move every row by the same amount.

**Three assertions that are not the engine's.**

- **A source whose access date is in the future is refused.** The input contract rejects an
  access date after the day of the calculation, with one day of margin in UTC for an author
  writing ahead of Greenwich. Until 29 Sep 2026 such a date passed and was sealed in the hash.
  Shipped that day under `3.14`, which did not name it; this version does.
- **The note under the sensitivity said the anchored price "is not re-anchored at the new load
  factor" for every anchor.** That presumes an anchor derived from the project's own hours; the
  T-HYNET sample's averages every hour of its window, which the hours do not move. A report now
  prints the sentence of the anchor it carries; the sample's reads:

  > The stack replacement years do not move with Operating Hours, and the anchored electricity
  > price, an average of every hour of its window, does not depend on them.

  The 6.0.0 frozen document quotes the old sentence as method, and its §3.1 is corrected in the
  6.1.0 one.
- **The premium page said the minimum DSCR migrates to "the first year outside the premium
  window".** With the default form it migrated to the last, the weakest: the sentence now says
  "the weakest year outside the premium window", true under both degradation models. Shipped on
  29 Sep 2026 under `3.14`.

**What moves:** every new TEA and Monte Carlo TEA calculation — its DSCRs, its equity cash
flows, equity IRR and payback, its probabilities on the DSCR, and its `content_sha256`; every
new LCOH and TEA output, which carries the constant-money figures; the capital-cost row of every
TEA sensitivity printed from now on; the two shipped reference cases; and the T-HYNET sample's
hash, whose LCOH does not move. **What does not:** every stored calculation, its figures and its
hash; the LCOH, the NPV and the project IRR of any input; the LCOH Monte Carlo; the index and the
catalogue benchmark. Reports print `Model version: v6.1.0` and `Methodology version: v3.15`.

## 3.15 → 3.16 — 29 Sep 2026

The engine does not change. Two blind readings of the T-HYNET sample, on 22 and 23 Sep, left ten
things the report said too loosely or did not say; none was a false sentence and none left a
figure that could not be recomputed from the paper, so they were kept until after the sample was
signed. This version says them.

**"Declared" is kept for what an author declares.** The method sentence, the money-year line and
the degradation sentence called the inflation rate and the stack degradation rate "declared",
and on the sample both are platform defaults, printed as such in the input table. They now read:

> Electricity, O&M, water and stack replacement are escalated at the inflation rate each year
> after the first.

> [the stack's] output falls by the stack degradation rate for each year since it was installed

and the TEA's revenue sentence says "at the Price Escalation rate".

**The boundary says what is upstream.** The plant-gate boundary spoke only of what comes after
the plant, and all three readers asked about the EUR 80 M of electrical storage that the
sample's source lists apart from the capital cost. Upstream, the engine has no assets: it buys
electricity at the input price and charges the input capital cost. The label now reads:

> plant gate — upstream, only what the capital cost and the electricity price cover; no
> compression, storage or delivery downstream

**The electricity share and where its price holds.** The first page read "83.6% of this figure
is electricity, priced at the OMIE day-ahead average", which reads as if all of it were at that
price; at the first-year price electricity is 70.3 % of the figure, and inflation and
degradation make the rest. And the cover prints the platform region, "Southern Europe", while
the anchored price holds only in the MIBEL zone it comes from. The row now reads:

> 83.6% of this figure is electricity over the project life. Its first-year price is the OMIE
> day-ahead average of 30 market days for peninsular Spain (2026-08-21 to 2026-09-19), escalated
> at the inflation rate after that.

**The index's base is not its factors' base.** The note said the Nelson-Farrar series "runs from
1946 to 2018, its base year"; the index stands at 100 in 1946, and 2018 is the year its
escalation factors bring figures to. It now reads:

> The Nelson-Farrar refinery construction cost index series runs from 1946, where it stands at
> 100, to 2018, the base year of its escalation factors.

**Origin is not source.** The method paragraph said that each figure states its origin in the
declarations block "and a figure with no declaration has none", while the input page says that
every printed parameter states where it comes from. Both reports now say:

> each printed parameter states its origin in the input parameters table, and a declared one also
> cites its source in the parameter declarations block.

**The hash covers the declarations, and the integrity box says so.** The declarations page says
they are covered by the hash; the integrity box said "inputs" without saying that declarations
are inputs. It now says "inputs (the parameter declarations included)", for the event hash and
for the content hash.

**What the sensitivity note did not say.** Each row recomputes the figure with one input moved,
also when two inputs come from one reading of a source — on the sample, the consumption and the
hours both come from the fiche's 2.7 t/h. The inflation row leaves the nominal WACC where it is,
so the real rate moves the other way. The WACC row also moves the interest capitalised over
construction. Each end is computed from the exact inputs, and the impact range is the difference
of the two printed ends, so that the table adds up on a calculator. On the sample
the note now reads:

> Each row moves one input and holds the rest at their base values, even inputs read from the
> same source: the electrolyser cost ±40 %, the wide end of the ±25-40 % accuracy band of a
> concept estimate, the inflation rate 1 percentage point either way and the other inputs ±20 %.
> Moving the inflation rate holds the nominal WACC, so the real rate moves the other way.
> Operating Hours stops at 8760 h on the high side, the most the calculator accepts. The WACC row
> also moves the construction interest in the capex charged at year 0. The stack replacement
> years do not move with Operating Hours, and the anchored electricity price, an average of every
> hour of its window, does not depend on them. Each end is computed from the exact inputs and
> printed to the cent, and the impact range is the difference of the two printed ends.

The note of a calculation stored before `5.3.0` is kept as it was.

**One sentence is the author's.** The sample's subject line said the EU Innovation Fund fiche was
"behind six of these figures"; one of the six is a label and another is zero. It now says "the
fiche that six of the declarations cite". The line travels in the inputs, so the sample's draft
hash moves with it; its LCOH does not.

**What moves:** the text of every LCOH and TEA report printed from now on, the plant-gate label
wherever it is printed, and one sentence of `/methodology`. **What does not:** any figure, any
engine, any stored calculation and its hash. Reports print `Model version: v6.1.0` and
`Methodology version: v3.16`.

### As the reports print them from 3.16

Verbatim, so that a report issued under `3.16` can be read against this document.

The subject line of the T-HYNET sample, as its first page prints it:

> Subject T-HYNET Tarragona (Repsol, Enagas Renovable, Messer). The EU Innovation Fund fiche
> that six of the declarations cite is marked TERMINATED, updated 9 September 2026. Stated by
> the author, not verified.

Its electricity-price row:

> 83.6% of this figure is electricity over the project life. Its first-year price is the OMIE
> day-ahead average of 30 market days for peninsular Spain (2026-08-21 to 2026-09-19), escalated
> at the inflation rate after that. Every hour of the window weighs the same - no choice of
> hours and no hedging assumed, and a market average is not a delivered cost.

Its money-year row, which carries the exception of the anchored price:

> 2022 EUR inputs except the electricity price, anchored to 2026 market prices, unadjusted — the
> Nelson-Farrar series ends at 2018 and its source gives nothing with which to extend it, so
> these inputs are carried as declared. Levelized prices in this report, such as the LCOH, are
> nominal over the project life: electricity, O&M, water and stack replacement are escalated
> from the inputs at the inflation rate, and every flow is discounted at the nominal WACC. With
> inputs from more than one year they are not the money of any single year, whatever the
> inflation rate.

The money-year row of a calculation whose inputs are all of 2022:

> 2022 EUR inputs, unadjusted — the Nelson-Farrar series ends at 2018 and its source gives
> nothing with which to extend it, so these inputs are carried as declared. Levelized prices in
> this report, such as the LCOH, are nominal over the project life: electricity, O&M, water and
> stack replacement are escalated from the inputs at the inflation rate, and every flow is
> discounted at the nominal WACC. They are 2022 EUR figures only if the inflation rate is zero.

The method sentence of the LCOH report:

> Electricity, O&M, water and stack replacement are escalated at the inflation rate each year
> after the first. Each year's costs and production are placed at the end of that year and
> discounted at the WACC, which is therefore applied as a nominal rate. Capex is charged at year
> 0 and is not escalated. Stack replacement is treated as an operating expense in the year it
> occurs.

The two degradation sentences, lost efficiency since `5.3.0` and lost output before it:

> Stack degradation is modelled as lost efficiency: the stack draws the same power every year
> and its output falls by the stack degradation rate for each year since it was installed, so
> each kilogram takes more electricity; a replacement is charged in its own year, which still
> runs on the old stack, and the output of year 1 returns the year after it.

> Stack degradation is modelled as lost output: each year the production falls by the stack
> degradation rate at the same electricity per kilogram, so the plant also buys less
> electricity, and a stack replacement does not restore it.

The TEA report's sentence on inflation and revenue:

> Cash flows are nominal. Electricity, O&M, water and stack replacement are escalated at the
> inflation rate each year after the first; the H2 selling price escalates at the Price
> Escalation rate or, in the years an offtake contract covers, at the contract's index rate
> within its floor and cap; O2 revenue is flat.

The note on the money-year index, in the three reports and on `/methodology`:

> No figure is escalated to another money year: this model version applies no cost index to any
> figure it computes or prints. The Nelson-Farrar refinery construction cost index series runs
> from 1946, where it stands at 100, to 2018, the base year of its escalation factors. When the
> declared money year falls before that base, the money-year line of the comparability block
> states the factor that escalating to 2018 money would apply, and that it is not applied; from
> the base year on, it states that the series ends there. That factor uses the index with its
> published weighting, 60 per cent labour and 40 per cent materials. That weighting is the one
> its publisher, the Oil & Gas Journal, maintains for continuity of the series; the same
> publisher reports that surveyed project composition has moved towards 40 per cent labour, and
> publishes the series at five weightings so an evaluator can match their own project. The index
> is a refinery construction index, accurate for the US Gulf Coast and described as suited to
> petroleum and petrochemical work, not an electrolysis index. No alternative weighting is
> applied.

The integrity box, when the cover prints the content hash and when it prints the event hash:

> The SHA-256 hash on the cover is the content hash of this calculation: a cryptographic
> fingerprint of its type, inputs (the parameter declarations included), outputs and model
> version. It carries no timestamp, so the same calculation always gives the same hash, and it
> is one of the two hashes under which /verify publishes a calculation registered in the GaugeH2
> database. It does NOT cover the PDF binary itself. To verify a report: open the verification
> URL on the cover, then compare the figures shown there against the figures in this PDF. Any
> divergence indicates the PDF was modified after generation.

> The SHA-256 hash on the cover is a cryptographic fingerprint of the calculation inputs (the
> parameter declarations included), outputs, model version and timestamp registered in the
> GaugeH2 database. It does NOT cover the PDF binary itself. To verify a report: open the
> verification URL on the cover, then compare the figures shown there against the figures in
> this PDF. Any divergence indicates the PDF was modified after generation.

And the note under the sensitivity table of the sample:

> Each row moves one input and holds the rest at their base values, even inputs read from the
> same source: the electrolyser cost ±40 %, the wide end of the ±25-40 % accuracy band of a
> concept estimate, the inflation rate 1 percentage point either way and the other inputs ±20 %.
> Moving the inflation rate holds the nominal WACC, so the real rate moves the other way.
> Operating Hours stops at 8760 h on the high side, the most the calculator accepts. The WACC
> row also moves the construction interest in the capex charged at year 0. The stack replacement
> years do not move with Operating Hours, and the anchored electricity price, an average of
> every hour of its window, does not depend on them. Each end is computed from the exact inputs
> and printed to the cent, and the impact range is the difference of the two printed ends.

## 3.16 → 3.17 — 29 Sep 2026

The engine does not change. Under its input table the TEA report says that every printed
parameter states where it comes from, and fifteen of the rows it can print left their origin cell
blank: the five figures the model derives, the seven terms of an offtake contract and the three
rows of a verified subsidy scheme. The Monte Carlo report of the TEA published percentiles over a
base case it did not print, and the three reports printed an accuracy band, and the TEA report a
range of project lifetimes, without saying where they come from. This version closes the four.

**Every row of every input table states its origin.** The figures the model derives from the
inputs — the capital cost net of subsidy, the equity, the debt and, with a construction period,
the capital raised and the capitalisation factor — are not parameters and are not counted in the
backing index. Their origin cell now reads:

> computed by the model

The seven terms of an offtake contract are one parameter, `offtake_contract`, and its origin is
resolved like any other. The platform has no default contract, and a contract cannot yet be
declared with a document, so each term reads "entered, not declared" and the backing index counts
the contract once and names it. On a calculation whose other inputs are all platform defaults it
reads:

> Backing index — 31 parameters: 0 declared with a document, 0 declared without one, 0 from the
> catalogue, 30 platform defaults, 1 entered with no stated origin.
> 1 printed figure states no origin at all: offtake_contract.

The rows of a verified subsidy scheme read "verified · BDNS" beside the scheme and beside its
fingerprint, which are checked against the SNPSAP register, and "author's hypothesis" beside the
amount applied, which is the author's.

**The Monte Carlo report prints its base case.** It published percentiles of NPV, IRR and DSCR over
some thirty fixed inputs and printed only the ones it draws. Its second page is now the input table
of the TEA report — the same rows, labels and origin cells, resolved by the same rule, and the same
backing index — under this lead:

> The base case every simulation starts from. In each run the inputs listed under Stochastic
> assumptions are replaced by a draw; every other figure below is held as printed.

The terms of an offtake contract are printed there, with their origin. The table that repeated them
under the heading "Declared offtake contract" is removed, so that the same seven figures are not
called declared on one page and "entered, not declared" on another; the notes on how to read the
percentiles under a contract keep their own section when there are notes to give.

**The ranges it draws say what is known of them.** Under the stochastic assumptions:

> The ranges are the ones submitted with this simulation. The Monte Carlo panel proposes one for
> each variable and the author can change it; this report does not record which ones were changed.

**The estimate-class band cites its source.** The comparability block of the three reports reads,
for a concept estimate:

> concept — ±25–40 % on the capital cost, per appendix A9 of Seddon, The Hydrogen Economy (2022)

The four bands are the ones of that appendix, compared literally when they were introduced, and
§3.1 of the frozen document already cites it. The screen keeps the band alone.

**A sentence without a source is removed.** The TEA glossary said of the project lifetime that the
typical range for green hydrogen projects is 20 to 25 years. Nothing in the product or in its
documents sources that range, and finding a figure to hold it up would be inventing its source. The
entry now reads:

> Economic lifetime used in the DCF model. Cash flows beyond this horizon are excluded from NPV
> and IRR. Residual value assumed zero.

**What moves:** the text of every TEA and Monte Carlo report printed from now on, the comparability
block of every LCOH report, and the length of the Monte Carlo report, which gains the pages of its
base case. **What does not:** any figure, any engine, any stored calculation and its hash. Reports
print `Model version: v6.1.0` and `Methodology version: v3.17`. The sample on the landing page was
issued under `3.16` and is read against that version.

## 3.17 → 3.18 — 29 Sep 2026

The engine does not change, and no sentence the reports printed changes: one is added, and the
reports gain links. Until this version none of the three reports carried one. From an input to its
origin there was no step — the cell beside it states it — but from a declared input to its source,
the document, the account or the web page the author gave, the reader had to find its entry in the
parameter declarations block, on another page, by its raw key.

**The origin cell of a declared figure is a link to its entry in the parameter declarations
block**, in the input table of the LCOH and TEA reports and in the base case of the Monte Carlo
report, where the block is on the first page and the link goes back to it. **In the LCOH report,
the origin cell of a figure taken from the catalogue links to the catalogue provenance block**,
which states what was derived from the catalogue row. The linked cells are printed in the one
colour the reports use for what can be pressed. The other origins are not links: a platform
default, a market anchor and a figure computed by the model state their origin in their own cell
or in the row beside it, and there is nothing further inside the report to go to. Under the
backing index, a report with at least one linked origin says so, one sentence for each kind:

> Each declared origin links to its entry in the parameter declarations block.

> Each catalogue origin links to the catalogue provenance block.

**The verification URL on the cover is a link**, in the three reports, to the page that publishes
the registered figures, and is printed in that same colour.

**What moves:** the bytes of every report printed from now on — the links, the colour of the
linked cells and of the verification URL, and the added sentence. **What does not:** any figure,
any engine, any stored calculation and its hash. Reports print `Model version: v6.1.0` and
`Methodology version: v3.18`.

## 3.18 → 3.19 — 29 Sep 2026

The engine of the calculation does not change, and no figure of any calculation moves. What
changes is the renewable sizing chapter, which the LCOH report prints when a sizing sweep is
attached to its calculation. Until this version the sweep priced the PPA on the energy the
electrolyser consumes: spilled energy cost nothing, no step raised the LCOH, and the chapter said
the curve had no optimum. A sweep can now be priced the other way a PPA is written,
**pay-as-produced**: every MWh the contracted renewable capacity generates is paid at the PPA
price, whether the electrolyser uses it, spills it or is unavailable. The pricing on consumed
energy stays the default.

**How the bill is priced.** The sweep gives the engine a price and leaves the engine as it is.
Under the efficiency-loss degradation model — the only one the contract accepts since model
`5.3.0` — the engine buys the same electricity every year, E = electrolyser capacity × effective
operating hours × availability, and escalates its price with the declared inflation. A
pay-as-produced PPA bills the whole generation G of the contracted capacity at the PPA price P,
escalated the same way. Given the price P × G / E, the engine's electricity line equals the PPA
bill in every year, so the LCOH it returns is the pay-as-produced LCOH and not an approximation
of it. With no spilled energy and full availability, G = E and the price is P. Under the older
lost-output model the electricity bought falls as the stack degrades and the identity no longer
holds, so a pay-as-produced sweep on such inputs is refused rather than approximated. The sweep's
own version is `sizing 1.1`; under the default pricing its figures are those of `sizing 1.0`,
number for number.

**What a pay-as-produced chapter prints.** The heading of the scenario names the pricing:

> solar_pv - Southern Europe - hourly matching - PPA paid on produced energy - scenario 1a2b3c4d5e6f

After the spill knee, one line gives the lowest LCOH among the ratios swept, for example:

> Priced pay-as-produced, the lowest LCOH among the ratios swept is 6.067 EUR/kg, at a ratio of
> 2.2.

When that ratio is the first or the last one swept, the line goes on:

> It is at the edge of the swept range, so the curve may still fall beyond it.

The lowest point is not called an optimum and is not a recommended ratio: it is the lowest of the
ratios swept, under a synthetic generation profile, and nothing about the project decides it.
When the last step of the curve raises the LCOH, the line that states the span says so, instead
of calling the step a gain:

> LCOH moves from 8.098 to 6.354 EUR/kg across the swept range. The last step raises it by 0.063
> EUR/kg.

The note printed under the chapter is the one of this pricing, in the place of the saturation
note:

> Priced pay-as-produced: every MWh the contracted renewable capacity generates is paid at the
> PPA price, whether the electrolyser uses it, spills it or is unavailable. Spilled energy now
> has a cost, so past some ratio the next step costs more in unused energy than it saves in
> capital, and the curve can turn. Its lowest point is the lowest LCOH among the ratios swept;
> if it sits at the edge of the range, the curve may still be falling beyond it.

The first of the model limitations said that the figure does not capture the economics of
over-contracting; under this pricing their cost is what it captures, so for this pricing it
reads:

> Captures the CAPEX-dilution effect of lower electrolyzer utilization under the
> temporal-matching constraint, with the PPA priced pay-as-produced: the energy the electrolyser
> cannot use is paid and lost. It does NOT value surplus power sales, electricity storage or
> grid top-up.

The other limitations stand as they were.

**The saturation note stops saying the engine cannot do it.** Under the default pricing the note
said that an optimum appears only once the PPA is priced pay-as-produced, "which this engine does
not do". That is no longer true, and the sentence now reads:

> The curve can turn only once the PPA is priced pay-as-produced, on contracted rather than
> consumed energy — the sweep's other pricing.

A scenario saved before this version keeps the note it was saved with, and the chapter prints it:
a report reproduces what the scenario's own engine said.

**What moves:** the sizing chapter of a report whose calculation has a pay-as-produced sweep
attached, and the saturation note of a sweep priced on consumed energy and saved from this version
on. A scenario saved from this version records its pricing in its inputs, and so inside its own
`content_sha256`. **What does not:** any figure of any calculation, the chapter of a scenario
saved before this version, and any stored calculation or scenario and its hash. Reports print
`Model version: v6.1.0` and `Methodology version: v3.19`.

## 3.19 → 3.20 — 29 Sep 2026

The engine does not change, and no sentence the reports print changes. What changes is where two
things end on the page.

**A note that crossed the margin stays inside it.** In the TEA report, the note under the annual
cash-flow table that says how the table adds up with the maintenance reserve, added in `3.15`, was
broken into lines at the size of the table above it and printed at its own, larger size. Each line
came out about a seventh longer than it had been measured, and the first ended 17 mm past the right
margin, 3 mm from the edge of the paper. The note now breaks at the size it is printed in, and its
words do not change.

**Every table is a card or spans the page.** Six tables of the TEA and Monte Carlo reports ended
between 150 and 162 mm, short of the 170 mm of the section rule and of the charts above them; one of
them because the report's own code took the body of the page to be 160 mm wide. A table now takes
one of two widths: 110 mm for a card that pairs a label with its figure — the percentiles, the
screening probabilities and the DSCR by year — and the full 170 mm for everything else. The lender
declarations, the annual cash flow in both its forms, the sensitivity table and the stress table now
span 170 mm, and the screening probabilities become a card of 110 mm, like the percentile cards of
the same report.

**What moves:** the bytes of every TEA and Monte Carlo report printed from now on — the line breaks
of that note and the width of those six tables. **What does not:** any figure, any sentence, any
engine, any stored calculation and its hash, and the LCOH report except for the version it prints.
Reports print `Model version: v6.1.0` and `Methodology version: v3.20`.

## 3.20 → 3.21 — 29 Sep 2026

The engine does not change and no figure moves. Two sentences are added where a figure could be read
as saying more than it does.

**The LCOH in constant money says when its inputs are from more than one year.** Since `3.15` the
reports print, beside the nominal LCOH, the same project in constant money, "in the money of the
inputs". With inputs from more than one year that money is no single year's: the sample's inputs
are in 2022 money with the electricity at 2026 market prices, and the money-year row said so two
lines below, but the sentence did not. In that case it now reads, on the T-HYNET sample:

> In constant money: EUR8.63/kg, the same project with nothing escalated and discounted at the
> real WACC of 4.90 %, in the money of the inputs. The inputs are from more than one year, so
> that is not the money of any single year. The figure above is nominal.

With the inputs of one year the sentence does not change. The TEA glossary prints the same sentence
under the same rule, and so does the result on the calculator's screen.

**The comparison against conventional fuel says what its gap mixes.** When the note publishes a
gap, it sets the levelized cost against an incumbent price the author declares. It now adds:

> The levelized cost is nominal over the project life, escalated at the declared inflation rate,
> and the incumbent price carries no year: the gap sets a price over the life of the project
> against a price at one moment.

No figure of the comparison changes.

**The comparator shows the constant LCOH.** The comparator is not a report, and this is said because
it answers the same question: it printed each calculation's inflation rate beside a nominal LCOH and
did not use the constant figure. It now prints the row "LCOH in constant money", and, when the
calculations assume different inflation rates, says that part of the gap between their nominal
figures is the rate itself.

**What moves:** the constant-LCOH sentence of every LCOH and TEA report whose inputs are from more
than one year, and the conventional-fuel note wherever it publishes a gap. **What does not:** any
figure, any engine, any stored calculation and its hash. Reports print `Model version: v6.1.0` and
`Methodology version: v3.21`.

## 3.21 → 3.22 — 29 Sep 2026

The engine does not change and no figure moves. The reports gain an origin a figure can have — the
defaults of the author's firm — and a block that says whose they are.

**A firm's defaults, stated as the firm's.** A firm can set default values for its calculations: its
house criterion. It covers the values a firm standardises and a project does not — the WACC, the
inflation rate, the project lifetime, O&M, availability, the cost and consumption of water, the
balance of plant, the construction period, and, for the TEA, the tax rate, the debt share, the
interest rate, the debt tenor, the depreciation period and the price escalation. The cost and
consumption of the electrolyser, its degradation and stack, the electricity price, the capacity, the
hours, the selling price, the offtake and the oxygen are not in it: they depend on the technology,
the region or the project. Only an owner or an admin of the firm sets it. Every change is a new
version, with its values, the reason given, who set it and when, and no version is edited or
removed. The members of the firm start their calculations from it and can change any value for a
project.

When a calculation starts from the criterion, GaugeH2 reads that version from the firm's record and
seals it with the inputs — the firm, the version, its date, who set it, the reason and the values —
so it enters `content_sha256` like any other input. What the author's screen sends is which version
it applied, never the values. A calculation re-downloaded a year later prints the version it was
made with, whatever version the firm is on by then.

**Where each figure comes from.** A figure equal to the value that the sealed criterion sets reads,
in the parameter table:

> house criterion v3

A figure the author declared still reads as declared, and one fixed by a published market still
reads as anchored. The criterion sits above the platform defaults: a firm value that happens to equal
the platform's reads as the firm's, because the firm decided it for this calculation. A value the
author changed for the project stops being the firm's and reads as what it is. The backing index
counts the firm's figures in a bucket of their own, printed only when it holds any, before the
platform defaults:

> 3 from the house criterion of Consultora A (version 3)

**The house criterion block.** The LCOH and TEA reports of a calculation that carries a criterion
print a block headed "HOUSE CRITERION - THE FIRM DEFAULTS THIS CALCULATION STARTED FROM". It names
the firm; the version, the day it was set and who set it; the reason given; how many of its values
were adjusted for this project and which; and each value that applies to the calculation, with the
firm's value and the one used when they differ. A value the calculation does not have — the tax rate
in an LCOH report — is not printed. Each "house criterion" cell of the parameter table links to the
block.

**What is not covered.** The Monte Carlo report does not seal a criterion in this version: its cells
say what they are, platform default or entered. A member of more than one firm receives no criterion,
as a calculation of theirs receives no firm.

**What moves:** the bytes of the LCOH and TEA reports of calculations made with a house criterion.
**What does not:** any figure, any engine, and any report of a calculation without one, byte for
byte. Reports print `Model version: v6.1.0` and `Methodology version: v3.22`.

## 3.22 → 3.23 — 4 Oct 2026

The engine does not change, no figure moves and no stored assessment changes. The compliance chapter
stops calling an alternative pathway that is not needed "not met".

**Two pathways, one needed.** Under RED III, with grid electricity and a renewables PPA, additionality
is met through R2 or through R6, a low-carbon grid; without a PPA, through R5, a bidding zone above
90 % renewable, or through R7. The global verdict already resolved each pair: with R2 met, an
assessment reads "Consistent with the RFNBO criteria based on the data entered". The chapter, though,
printed the other rule on its own: R6 as "Criterion not met (based on the data entered)", the count
as "1 not met", and R6 again among the findings, in the class that heads the findings sheet. A
project that meets the criteria read, line by line, as one that does not. An external audit of the
platform found it on 2 Oct 2026.

**What the chapter prints now.** When one rule of a pair is met and the other is not, the other one
reads, in the table:

> Not needed: an alternative pathway to R2, which is met

It produces no finding, and the count names it on its own. For an assessment with five rules met,
two not applicable and R6 set aside:

> 8 rules assessed: 2 not applicable to this supply route, 5 met, 1 alternative pathway not used.

The rule's own verdict and its sentence do not change: R6 still says why the grid, on its own, would
not do, and the stored assessment, its verdicts and its `content_sha256` stay as they were. When both
rules of a pair are met, neither is set aside; when neither is met, both count, because then both
matter.

**What moves:** the compliance chapter of every report carrying an assessment where one pathway of a
pair is met and the other is not. **What does not:** any figure, any engine, any stored calculation or
assessment and its hash, and every other report, byte for byte. Reports print `Model version: v6.1.0`
and `Methodology version: v3.23`.

## 3.23 → 3.24 — 4 Oct 2026

The engine does not change, no figure moves and no stored calculation, review or emission changes.
The internal review block says when a review was stated by the author of the calculation.

**A review by its own author.** A member of the issuing firm can record an internal review of any
calculation of the firm, their own included. The platform's screens already told the author that
their review is not the second pair of eyes a review is for, and the platform's own assessment of a
project does not count it. The report printed it like any other — "Reviewed by X on D" — so a reader
took it for a second person's. An external audit of the platform found it on 2 Oct 2026.

**What the block prints now.** A review whose reviewer is the author of the calculation reads:

> Reviewed by Ana Ruiz, the author of this calculation, on 9 September 2026

and when at least one review is of that kind, the note of the block ends with:

> A review by the author of the calculation is not a second pair of eyes.

A review by another member of the firm reads as before, and so does the note. A review with no
reviewer account left — deleted after reviewing — is not the author's: the author's account cannot be
deleted while their calculation exists. And a line that does not fit the width of the block now wraps,
as the comment under it already did: with a long name, the line ran past the right margin.

**What moves:** the internal review block of every report carrying a review by the author of the
calculation, and of every report whose reviewer's name ran past the margin. **What does not:** any
figure, any engine, any stored calculation and its hash, any recorded review or emission, and every
other report, byte for byte. Reports print `Model version: v6.1.0` and `Methodology version: v3.24`.

## 3.24 → 3.25 — 4 Oct 2026

The engine does not change, no figure moves and no stored calculation changes. The parameter
declarations block prints the date of the evidence an author declares without attaching it.

**A dated declaration without its document.** A declaration says where a figure comes from: a vendor
quote, a published study, an internal estimate. Until this version it could carry the date of its
evidence only inside a document attached by its fingerprint. An author who holds a quote and does not
attach it could not say of when the quote is, and the platform's reading for a lender counted the
figure like one with no stated origin. An external audit of the platform found it on 2 Oct 2026.

**What the block prints now.** A declaration that states the date of its evidence, without a
document, reads:

> vendor quote · 2026 · dated 2026-03-03

A declaration with a document prints the document as before, with the document's own date when it
carries one. A declaration without a date prints as before.

**What it is not.** The date is stated by the author, like the rest of the block, whose title says so:
stated by the author, not verified. It travels in the calculation's inputs, so it is part of the
fingerprint of every calculation that carries it, and it cannot be added to a calculation already
stored.

**What moves:** the parameter declarations block of every report whose calculation declares a date
without a document, and the methodology version every report prints. **What does not:** any figure,
any engine, any stored calculation and its hash, and the rest of every report, byte for byte. Reports
print `Model version: v6.1.0` and `Methodology version: v3.25`.

## 3.25 → 3.26 — 4 Oct 2026

The engine does not change, no figure moves and no stored calculation changes. A report says which firm
prepared it.

**The firm's brand.** A firm on GaugeH2 is a group of accounts that share a plan. When an active member
of a firm whose plan is active makes a calculation, the platform seals two things with its inputs: the
firm's name, and the fingerprint (sha256) of the logo the firm had set that day, if any. The report prints
them. Under the title of the cover:

> Prepared by Ebro Hydrogen Advisory with GaugeH2

with the firm's logo at the right of GaugeH2's, and in the footer of every page:

> Ebro Hydrogen Advisory · GaugeH2 | Confidential - Investment Committee Use Only

A name too long for the footer is cut there with "..."; the cover prints it whole. The document's
metadata name the firm as its author; GaugeH2 stays as the tool that produced it.

**What is sealed, and what that means.** The name and the logo's fingerprint travel in the calculation's
inputs, so both are part of its fingerprints. Renaming the firm or changing its logo later does not change
a report already calculated: downloaded again, it carries the name and the logo it was sealed with. A
logo is stored once, by the fingerprint of its bytes, and is never rewritten. A report whose sealed logo
cannot be read is not generated at all, rather than generated without it.

**Who gets it.** Only a calculation made by an active member of a firm whose plan is active. A reviewer of
the firm, a personal account and a firm without the plan get no brand, and their reports read as before.

**What it is not.** GaugeH2 does not verify a firm's legal identity, its name or its logo: they are what
the firm's owner and administrators set on the platform. "Prepared by" states who made the calculation on
GaugeH2. It does not say that GaugeH2 audited the firm, nor that anyone reviewed the figures; the report's
internal review block says who did.

**What moves:** the cover, the footer and the metadata of every report calculated by a member of a firm
with the plan, and the methodology version every report prints. **What does not:** any figure, any engine,
any stored calculation and its hash, and every other report, byte for byte. Reports print
`Model version: v6.1.0` and `Methodology version: v3.26`.

## 3.26 → 3.27 — 5 Oct 2026

The engine does not change, no figure moves and no stored calculation changes. A report opens with a
page that says what it answers.

**The executive summary.** Behind the cover, every report has one page titled "Executive summary", in
six parts. The project: the subject the author declared, if any, and the plant. The result: the
headline figures of the report. The three financial screens: in a TEA report, the base-case figure and
whether it meets the screen; in a Monte Carlo report, the share of the simulations that do. What moves
the result most: the first three rows of the report's own sensitivity table, or of its contribution to
the variance, which come already ordered by their range. How firm the inputs are: the estimate class
and the backing index. And the reviews and analyses the report carries, by the title it prints them
under, with those it does not carry. An LCOH report has no screens, so its page has five parts. The
cover stands alone on page one; in an LCOH report the input parameters move to page three.

**What it adds: nothing.** Every figure on that page is printed elsewhere in the same report, in the
same format, and the page ends by saying so:

> This page restates figures printed elsewhere in this report and adds none of its own. What the author declared is stated by the author, not verified.

Whether a screen is met is the comparison the Monte Carlo engine makes in every simulation, applied to
the base case and strict: NPV > 0, Min DSCR > 1.30x, Project IRR > WACC. An IRR that does not converge
is not compared with anything. Under the screens the page repeats the note of the Monte Carlo cover:
three financial screens, not a bankability assessment. Which blocks a report carries is measured as
the report is drawn, not restated from what was attached to the calculation, so the page cannot name a
block the report does not print.

**From 3.27 only.** A report of a calculation made under an earlier methodology version has no summary
page, and downloaded again it reads byte for byte as it did.

**What moves:** every report of a calculation made under `3.27`, which gains the page, and the
methodology version every report prints. **What does not:** any figure, any engine, any stored
calculation and its hash, and every report of an earlier version, byte for byte. Reports print
`Model version: v6.1.0` and `Methodology version: v3.27`.

## 3.27 → 3.28 — 5 Oct 2026, with model 6.2.0

**A take-or-pay charges only what the plant produced and the buyer did not take.** Until
`6.1.0` the shortfall a take-or-pay charged was measured against the commitment alone, so a
plant that produced less than its minimum was paid for hydrogen it never made. An end-to-end
test of a consultancy's project found it on 5 Oct 2026: the NPV of its base case held positive
down to 1 094 operating hours a year, 77 % below the base, because cutting the hours bought
less electricity while the buyer kept paying the full minimum. From `6.2.0` the volume charged
is capped at what the plant produced that year, and the same case holds down to 3 929 hours,
18 % below. The rule travels in the inputs, `take_or_pay_basis: produced`, so a calculation
stored before keeps its figures and its report says the rule it was computed with. The method
is §7.1 of `calculator-methodology-v6.2.0.md`, and its §9 publishes the figures of the
reference case under both rules.

What the TEA and Monte Carlo TEA reports now assert about it. When the commitment is above
what the plant delivers, the note on it names the volume charged:

> The contracted minimum of 2,000,000 kg/year is above the 800,000 kg/year this plant delivers
> at the stated offtake share (40.0 % of the commitment), so the buyer pays 100 % of the price
> on the 200,000 kg/year the plant produces and the buyer does not take, every year of the
> contract, not only in a bad year.

When it is above what the plant produces, a new note says what happens to the excess:

> The contracted minimum of 2,000,000 kg/year is above the 1,000,000 kg/year this plant
> produces. A take-or-pay charges the buyer only for volume the plant made available, so the
> 1,000,000 kg/year it cannot produce earn nothing here. Under the contract they are the
> seller’s shortfall, which can cost the seller damages that this model does not compute.

The note on revenue that does not move with production, at a take-or-pay of 100 %, now says
it holds "while the plant still produces the committed volume", and is not printed when the
commitment is above production, where revenue is what the plant produces. The parameter table
prints the rule in its own row, with its origin, when the calculation carries it and declares a
take-or-pay:

> Take-or-Pay Rule — Charged only on volume the plant produced and the buyer did not take

A report of a calculation stored before prints its notes and its table as it did.

**What moves:** every new TEA and Monte Carlo TEA calculation with a take-or-pay whose
commitment is above what the plant produces in some year, and the `content_sha256` of every new
calculation, which carries the model version. **What does not:** every stored calculation, its
figures, its hash and its report; any calculation without such a take-or-pay; the LCOH of any
input. Reports print `Model version: v6.2.0` and `Methodology version: v3.28`.

## 3.28 → 3.29 — 6 Oct 2026

The engine does not change, no figure moves and no stored calculation changes. The report of a Monte
Carlo run on the base case of its project carries the compliance assessments of that base case.

**Why.** A compliance chapter printed the assessments attached to the calculation of the report, and
a Monte Carlo has none of its own: its compliance is that of the inputs it ran on. Run on the base
case, whose RFNBO assessment was saved, its report went out without a compliance chapter.

**The rule.** A Monte Carlo TEA carries them when the base case of its project is a TEA and the Monte
Carlo ran on that TEA's inputs: every numeric input of its two halves equals the TEA's, except the
two the TEA's route rewrites (an electricity price anchored to OMIE and a verified subsidy). It is the
same test by which the project header reads the probability of the Monte Carlo against the base case. Per
assessment set, an assessment attached to the Monte Carlo itself comes first; for a set it has none
of, the base case's is printed, and under its heading the block says so:

> Assessment of the base case, Refined base · TEA of 5 Oct 2026, on whose inputs this Monte Carlo ran.

The emission receipt lists those assessments as it lists any other, and accepts them for that Monte
Carlo only, and only when they belong to the author who issues it.

**From 3.29 only.** A Monte Carlo made under an earlier methodology version carries no assessment of
another calculation, and downloaded again it reads byte for byte as it did. Run again, it carries it.

**What moves:** every report of a Monte Carlo TEA made under `3.29` and run on its project's base case,
which gains the chapter when the base case has an assessment, and the methodology version every report
prints. **What does not:** any figure, any engine, any stored calculation and its hash, every report
of another calculation, and every report of an earlier version, byte for byte. Reports print
`Model version: v6.2.0` and `Methodology version: v3.29`.

**Carried with this bump, outside the method of the calculator:** the RFNBO ruleset in force becomes
`RED3@1.1.0`. Between 1 July 2027 and 1 January 2030, with the Member State's stance on early hourly
matching undeclared, temporal correlation (R3) is decided when both possible requirements give the same
outcome: hourly matching meets them, no matching fails them, undeclared matching needs that datum, and
monthly matching stays indeterminate. `RED3@1.0.0` stays frozen, so every assessment saved under it
reproduces its verdicts.

## 3.29 → 3.30 — 11 Oct 2026, with model 7.0.0

Travels with the engine. Four corrections, specified in `calculator-methodology-v7.0.0.md` §7, §7.3,
§7.4 and §7.6, with what moves and what does not in its §11:

1. **The DSCR is CFADS after the year's cash tax**: (revenue − recurring opex − maintenance-reserve
   contribution − tax) ÷ debt service. The reports and the screens said "pre-tax (engine
   convention)"; they now say the DSCR is after tax, like the net cash flow and the NPV. On the
   default case the minimum DSCR goes from 1.0537 (year 10) to 1.0141 (year 9).
2. **A TEA without debt has no DSCR.** The engine stores `null` where it stored 0; the reports and
   the screens print "no debt" or "n/a (no debt)" where they printed 0.00, the Monte Carlo report
   prints a note instead of a distribution of zeros, and the screening row for the DSCR reads "n/a
   (no debt)" instead of "not met". "All bankable" is NPV > 0 and IRR > WACC for a project without
   debt; it printed 0 %.
3. **The Beta-PERT is the standard one**, its shape taken from the mode and not from the mean. The
   bias panel of the Monte Carlo states the formula.
4. **The IRR falls back to bisection** when Newton's method does not converge.

**What moves:** every report of a calculation made under `7.0.0` with debt and tax, without debt, or
with an asymmetric PERT input; the methodology version every report prints. **What does not:** every
stored calculation, its figures and its hash, and every report of an earlier calculation, which
prints the version pair and the figures it was made with. Reports print `Model version: v7.0.0` and
`Methodology version: v3.30`.

## 3.30 → 3.31 — 11 Oct 2026, with model 7.1.0

Comes with the model `7.1.0` (`calculator-methodology-v7.1.0.md`, §7.7 and §11). Four optional
project-finance inputs of the TEA: LLCR and PLCR, a repayment sculpted to a target DSCR, a DSRA
in months of debt service, and the carry-forward of tax losses. A TEA report of a calculation
that sets any of them prints, under its financing assumptions, the options set and the min
LLCR, the PLCR, the DSRA funding, the sculpting flag and balloon, and the losses not offset; a
report of a calculation without them prints exactly what it printed under `3.30`.

Re-frozen on 12 Oct 2026, before any client calculation, with three more changes under the same
pair: the carry-forward also reaches the project (unlevered) NPV, IRR and breakeven, and the
report's annual table applies it; an optional external-heat cost (`heat_demand_kwh_kg`,
`heat_cost_eur_mwh_th`) — a report that declares it prints both rows and, under its input table,
the figures used instead of the SOEC note that heat is not costed, which a report without them
keeps; and the installed capex defaults of PEM (2 365 EUR/kW) and alkaline (1 819 EUR/kW), with
the BoP per technology, belong to `7.1.0` — a report of a `7.0.0` calculation resolves "platform
default" against the previous defaults.

**What moves:** the reports of calculations that set an option; the methodology version every
report prints. **What does not:** every stored calculation, its figures and its hash, and every
report of an earlier calculation. Reports print `Model version: v7.1.0` and
`Methodology version: v3.31`.

## 3.31 → 3.32 — 8 Nov 2026

The engine does not change, no figure moves and no stored calculation changes. The reports are set in
a quieter type scale, and a currency code stands apart from its figure.

**The type scale.** Measured on the cover of an LCOH report under `3.31`: the GaugeH₂ wordmark at
22 pt, the title at 22 pt, the headline figure at 28 pt and the section titles at 16 pt, over a body
of 9 pt. From this version the title is 18 pt, the section titles 13 pt, the block titles and the
introductory paragraphs 10 pt, a key figure 14 pt and the headline figure 20 pt. On the cover the
wordmark is 14 pt and the logo of the firm that prepared the report is at most 10 mm tall, where it
was 14 mm. The body text, the tables, the charts and the footer keep their sizes.

**The currency code.** A figure in euros prints `EUR 7.26/kg` and `(EUR 19.81M)` where it printed
`EUR7.26/kg` and `(EUR19.81M)`. The space costs a cell about 0.7 mm, so two tables divide their
170 mm again: the sensitivity table, whose three result columns now hold a five-digit figure in
millions — under `3.31` they already split a figure in two from 100 MW on the platform defaults,
in the middle of the number — and the annual cash-flow table of a project with a maintenance reserve.
Measured cell by cell on the platform defaults, no figure of either table splits up to 2 000 MW. At
5 000 MW, the largest plant the calculator accepts, six cells still split, all of them in the
cash-flow table and at the space, where `3.31` split twenty-eight across the two tables.

**From 3.32 only.** A report of a calculation made under an earlier methodology version is drawn in
the scale it was issued in, and downloaded again it reads byte for byte as it did.

**What moves:** every report of a calculation made under `3.32` — its type sizes, the space after a
currency code and the column widths of two tables — and the methodology version every report prints.
**What does not:** any figure, any engine, any stored calculation and its hash, and every report of an
earlier version, byte for byte. Reports print `Model version: v7.1.0` and
`Methodology version: v3.32`.

## 3.32 → 3.33 — 8 Nov 2026

The engine does not change, no figure moves and no stored calculation changes. The cover sizes the logo of
the firm that prepared a report by what the logo shows.

**The logo of the firm.** Under `3.32` the cover fitted the whole logo image into a box of up to 48 × 10 mm,
empty margin included. A logo uploaded as a square of 512 × 512 pixels with its drawing in a strip of
466 × 93 printed at 9 × 1.8 mm. From this version the cover reads which pixels of the logo are drawing —
neither transparent nor near white — and fits that part into a box of up to 36 × 9 mm; the empty margin
around it is left outside a clipping path. The image embedded in the report is the logo sealed with the
calculation, byte for byte: nothing is redrawn or resampled. A logo whose drawing cannot be read (a JPEG,
or a PNG this reading does not decode) is fitted whole into the same box.

**From 3.33 only.** A report of a calculation made under an earlier methodology version, downloaded again,
reads byte for byte as it did. A report without a firm logo is drawn as under `3.32`.

**What moves:** the cover of every report of a calculation made under `3.33` that carries a firm logo, and
the methodology version every report prints. **What does not:** any figure, any engine, any stored
calculation and its hash, and every report of an earlier version, byte for byte. Reports print
`Model version: v7.1.0` and `Methodology version: v3.33`.

## What a reader can check

| | where |
|---|---|
| the METHOD as of `7.1.0` / `3.31` to `3.33` | `calculator-methodology-v7.1.0.md`, with its published sha256 |
| the type scale of a report, and the space after a currency code, from `3.32` | this document, the section `3.31 → 3.32` |
| the logo of the firm sized by what it shows, from `3.33` | the report's cover, and this document, the section `3.32 → 3.33` |
| the project-finance options, from `3.31` | `calculator-methodology-v7.1.0.md` §7.7, and this document, the section `3.30 → 3.31` |
| the METHOD as of `7.0.0` / `3.30`, for every report issued under `7.0.0` | `calculator-methodology-v7.0.0.md`, with its published sha256 |
| the after-tax DSCR, the DSCR without debt, the PERT and the IRR, from `3.30` | `calculator-methodology-v7.0.0.md` §11, and this document, the section `3.29 → 3.30` |
| the METHOD as of `6.2.0` / `3.28` and `3.29`, for every report issued under `6.2.0` | `calculator-methodology-v6.2.0.md`, with its published sha256 |
| the take-or-pay of a contract, from `3.28` | the report's contract notes and its parameter table, and this document, the section `3.27 → 3.28` |
| the compliance of the base case in its Monte Carlo, from `3.29` | the report's compliance chapter, and this document, the section `3.28 → 3.29` |
| the METHOD as of `6.1.0` / `3.15` to `3.27`, for every report issued under `6.1.0` | `calculator-methodology-v6.1.0.md`, with its published sha256 |
| the pricing of a pay-as-produced sizing sweep, from `3.19` | this document, the section `3.18 → 3.19` |
| the house criterion a report started from, from `3.22` | the report's own house criterion block, and this document, the section `3.21 → 3.22` |
| an alternative pathway that is not needed, from `3.23` | the report's compliance chapter, and this document, the section `3.22 → 3.23` |
| a review by the author of the calculation, from `3.24` | the report's internal review block, and this document, the section `3.23 → 3.24` |
| the date of evidence declared without its document, from `3.25` | the report's parameter declarations block, and this document, the section `3.24 → 3.25` |
| the firm that prepared a report, from `3.26` | the report's cover and footer, and this document, the section `3.25 → 3.26` |
| the executive summary of a report, from `3.27` | the report's second page, and this document, the section `3.26 → 3.27` |
| the METHOD as of `6.0.0` / `3.14`, for every report issued under `6.0.0` | `calculator-methodology-v6.0.0.md`, with its published sha256 |
| the METHOD as of `5.3.0` / `3.13`, for every report issued under `5.3.0` | `calculator-methodology-v5.3.0.md`, with its published sha256 |
| the METHOD as of `5.2.0` / `2.5`, for every report issued under `5.2.0` | `calculator-methodology-v5.2.0.md`, with its published sha256 |
| what changed up to `3.33` | this document, with its published sha256 |
| which pair a given report was issued under | the report's own footer, and the `model_version` / `methodology_version` fields published by `/verify` |

`methodology_version` is not part of `content_sha256` — the hashed payload is
`{type, inputs, outputs, model_version}` — so none of these bumps moves the hash of any stored
calculation, and no report is ever retroactively recalculated. The model bumps to `5.3.0`,
`6.0.0`, `6.1.0`, `6.2.0`, `7.0.0` and `7.1.0` do not move them either: a stored calculation keeps its own
`model_version`, inputs and outputs.