• Root cause, one bug in three costumes. Leads 2 and 3 are the same defect: the engine reported a loss curve it did not integrate. anchor_p = min(1.0, 1.0/rps[0]) equals probs[0] exactly, so the guard anchor_p > probs[0] is dead for every return period ≥ 1 — and every RP in hazard_cache.json starts at 2.0 or 5.0. The band p ∈ [0.5, 1] therefore carried no loss: on a flat curve that is exactly a third of the answer (L·0.5 computed instead of L·0.75). Separately, a trapezoid across a 2.5x RP gap is a chord, not an integral. Fixed by anchoring at p = 1 and integrating on a 16x-refined log-RP grid, which is also the grid now reported — reporting the coarse input while integrating something else is how a number and the curve drawn beside it stop being the same object.
• The ponytail: comment at old engine.py:105 was confessing to the same thing, and its defence was wrong. It argued the protection ramp "errs high, which is the right direction". It does err high, but the size of the error was set by grid spacing, not by physics: tj-priok/riverine moved -31.1% under refinement. An error whose magnitude is an artefact of the input grid is not conservatism. Inserting a zero-loss knot immediately below the standard makes the step a step; INT-STEP went from 46.1% off its knotted reference to inside 2%, and the same knot removed most of the convergence drift.
• Convergence and grid density. 16 sub-intervals per modelled interval is comfortably enough: portfolio drift against a 32x-finer grid reads -0.00%, so this is not sitting on the tolerance. Cost is ~4x eval runtime (0.64s → 2.6s), which is the price of loss_curve doing ~130 points instead of 9 across ~650 calls per sweep. Don't raise the constant without a measured reason.
• Lead 1 is a different root cause — still open, and now confirmed by reading, not guessing. compute.asset_detail does eal = sum(r.lc.eal for r in results); compute.summary does eal = sum(r.lc.eal for r in event_results) where event_results filters out r.permanent. tj-priok's coastal reading is 0.819 damage at 1-in-2 and near-flat, so it classifies permanent: summary reports 3,452,760 plus a 344,037,120 write-down, asset_detail reports 263,968,456 of "annual" damage. The summary path is right. asset_detail needs the same split, including a writedown field, or it is billing standing water annually. (My change moved both numbers; the divergence is untouched.)
• VUL-MDF is a one-line fix but not a one-line change. PerilResult.mean_damage_fraction returns max(damage_fractions) while its docstring promises the EAL as a share of value — off by ~100x at tj-priok (0.8987 vs 0.008221). It is the only input to downtime_days, so correcting it moves business interruption, annual_net_cost, NPV, impairment, DSCR and the covenant breach count on every asset. Worth its own experiment so the anchor movement is attributable.
• Looked up: nothing. No web search was needed and none was run. The two domain questions — whether an EAL integrates the full [0,1] exceedance-probability domain anchored at zero loss, and whether a FLOPROS standard is a step or a ramp — were already settled inside the repo: research/invariants.py:82-93 states the anchoring convention in its own docstring, and engine.loss_at_return_period already declared log-RP as the module's interpolation rule. Recording this so the next experiment doesn't spend budget re-confirming it.
• No invariant looked wrong. INT-DOMAIN pins the engine to a linear-in-p trapezoid over its reported grid to 1e-9, which rules out substituting a closed-form integral of the log-RP interpolant (I derived it: L_a(p_a - p_b) + m(p_a - (1+S)p_b) with S = ln(p_a/p_b)). That is not a flaw in the check — it forces the reported curve and the integrated curve to be the same object, which is the stronger property. Confirmed dead end; don't retry the analytic route.

• One root cause in two places: an expectation and a per-event quantity swapped for each other at the engine→finance boundary. PerilResult.mean_damage_fraction returned max(damage_fractions) — the damage of the worst modelled event — where its docstring and every caller wanted the EAL as a share of value. That fed downtime_days, so rotterdam-chem was billed 162 outage days a year and its expected business interruption came out 9.5x its expected physical damage (now 1,792 against 36,061). In the other direction, _insurance_recovery(eal, ...) subtracted a per-event deductible from an annual expectation: max(0, eal - 0.02·value) asks whether the average year clears the deductible, and for any site with an EAL under 2% of value the answer is no, however many modelled events are total losses. Fixing both moved VUL-MDF and INS-PAYS.
• summary and asset_detail took max(mean_damage_fraction) across perils; that had to become sum. A max is right for a peak and wrong for an expectation — expected shares of value add, the way the EALs they come from add. Leaving the max would have handed translate an outage driver that did not correspond to the EAL passed next to it.
• Looked up: catastrophe financial modules apply deductibles, limits and coinsurance to the ground-up loss of each event, and take the AAL afterwards, from the net event losses (NAIC CIPR, Catastrophe Models (Property); CAS reinsurance bootcamp, Sigona 2019). That settles the direction: expected recovery is an expectation over the event distribution, never a subtraction from its mean.
• API-SHAPE freezes translate to (eal, mean_damage_fraction, fin, a), so the event loss table cannot reach the finance layer. Severity has to be rebuilt from one moment plus a shape. Confirmed dead end for the next experiment: do not try to thread the loss curve into translate — the signature is an anchor. Adding a field to AssetFinancials would work mechanically but gives the eval and the dashboard two different recovery numbers for the same asset, which is the lead-1 sin.
• The shape choice is load-bearing and I got it wrong once. A maximum-entropy exponential (mean = EAL) is the tempting one-moment answer and it fixed 4 of 5 assets, but it left hcmc-tower recovering exactly zero: its EAL is 0.02% of value against a 20m worst modelled event, and an exponential prices an event 387x its mean at ~1e-36. Switched to the single-parameter Pareto, the standard severity model for excess-of-loss property pricing (CAS, A Practical Guide to the Single Parameter Pareto; CAS, Sahasrabuddhe, Single Parameter Pareto Revisited), with the shape exposed as Assumptions.severity_tail_index = 1.5 rather than buried, per this module's own rule that nothing is hidden in a constant.
• Negative result worth recording: recovery is not monotone in severity_tail_index. I asserted it was and the self-check caught me. Lowering alpha fattens the tail but also drags the Pareto scale down, so for a layer near the mean (900k EAL, 1m deductible) a fatter tail recovers less; only out where the deductible sits far above the EAL does fatter mean more. The self-check now pins the far-tail case, which is the one the fix exists for.
• Known ceiling, and the obvious next move if the signature ever thaws: one moment plus a fixed shape cannot represent "rare and huge". For hcmc-tower a rough integration of the actual loss curve gives an expected recovery near 38k; the Pareto gives 1,711. The number is honest about being a severity assumption and errs toward the retained side, but it is an assumption where the engine already has the answer in lc.losses.
• Lead 1 is untouched and is now the loudest thing left. asset_detail('tj-priok') runs translate on 263,968,456 of "annual" damage while summary uses 3,452,760, so the detail page reports a 149,956,862 insurance recovery and a 356,357,417 premium against standing water. The permanent-inundation split exists in summary and in _asset_eal; asset_detail is the only path missing it, and it needs a writedown field to say so.
• No invariant looked wrong. COV-ATTRIBUTABLE (hcmc-tower breaches at dscr_before 0.73) is a real defect I deliberately left failing: covenant_breach means "breaches after climate loss" when a climate report needs "breaches because of climate loss", i.e. breach_after and not breach_before. It is a one-line definitional fix in finance.translate but a different root cause from this experiment, so it belongs to its own commit rather than riding along unattributed. Breach count fell 7 → 4 as a side effect of the BI correction; hcmc-tower is the one that structurally cannot fall out.

• Root cause of VUL-OVERLAP: the combination was at the wrong layer. _asset_perils integrated inundation_coastal and inundation_riverine as two independent loss curves and every consumer added their damage fractions. At cat-lai that is 0.56 + 1.00 = 1.563 at 1-in-1000: one building, destroyed 1.56 times. Two flood layers at one point are two ways for the same site to end up under the same water; they must be combined before the vulnerability curve is applied, not after.
• Looked up, and it settles the method: FEMA Guidance Document 76 §4.4 "Combined Effects: Surge Plus Riverine Runoff". At each flood level Z, add the sources' rates of occurrence of exceeding Z — R_T(Z) = R_riverine(Z) + R_surge(Z) — then read the combined level off at the rate of interest. Rates add on a common level; damage fractions never add on a common return period. FEMA states the assumption explicitly (independent and non-concurrent, "acceptable if storms that produce extreme rainfall and runoff are not the same as the storms that produce the greatest storm surge") and flags compound surge/runoff events as the case to check. engine.combine_exceedance is this procedure; _rate_above is the inverse of _interp_log_rp, so it lives in the same log-RP space the module already declared. The FEMA combined coastal-riverine floodplain guidance is the mapping companion and points at Doc 76 for the arithmetic.
• A defence is a cap on its own source's rate, not on the combined curve. cat-lai has a 1-in-8.375 FLOPROS standard on riverine and none on coastal; a river levee holds back the river and not the sea. R_i(Z) → min(R_i(Z), 1/sop_i) before summing is exactly equivalent to the loss-zeroing step loss_curve applies to a single source, expressed on the rate axis, so the merged reading arrives already defended and is integrated with protection_rp=None. That is also why the merged peril must be named combined_flood: prot.sop returns None for it, which is what lets INT-STEP, INT-CONVERGE-* and INT-MONO-INTENSITY reconstruct the curve from (reading, curve, sop) and get the same number back. Confirmed dead end: naming the merged result after one of its sources breaks INT-STEP, because the reconstruction re-applies a standard that is already baked in.
• Numbers: the merge is non-additive, not a deletion. cat-lai riverine alone 32.4m, coastal alone 98.2m, old sum 130.6m, combined 119.1m — strictly between max and sum, as a union of rates must be. The combined 1-in-5 depth (0.729 m) is below riverine's undefended 1-in-5 (1.355 m) and that is correct: the levee stops the 1-in-5 river event, so what the site sees at that rate is sea water.
• Both paths are now one function, so lead 1's class of bug is gone. _asset_eal is a one-line filter over _asset_perils(a, scenario, variant_rank, curve_rank). The headline is rank (0, 0). The zero-intensity screen, the permanent-inundation split and the flood merge can no longer be added to one path and forgotten in the other. (Lead 1 itself — asset_detail reporting 263,968,456 of "annual" damage for tj-priok where summary reports 3,452,760 — is still open and untouched; it needs the event_results/perm_results split and a writedown field in asset_detail.)
• Honest regression I could not fix from the three editable files, and it is the most important thing in this log. accumulation._book iterates hz.PERILS and matches _asset_perils output by peril name. combined_flood is not in the hazard cache's peril list, so cat-lai's and port-klang's flood units vanish: 4 exclusions of kind unknown ("dropped upstream, reason unclassified"), accumulation.demo() fails its "every exclusion must be classified" assertion, and 91.5% of the portfolio EAL is now absent from the accumulation view. This is not cosmetic: FOOTPRINTS gives riverine a 100 km radius (basin synchrony, Berghuijs et al. 2019) and coastal 200 km (alongshore surge, Haigh et al. 2016), so a merged flood unit genuinely has no single correlation length. The fix is to attribute the combined loss back to the sources by each one's share of the combined rate, w_i(rp) = R_i(Z(rp)) / R_T(Z(rp)) — the weights sum to 1 by construction, so VUL-OVERLAP stays held.
• Confirmed dead end: do not try that attribution by splitting the merged LossCurve into per-source PerilResults. I worked it through. w_i falls with return period as riverine takes over, so an allocated coastal loss curve decreases with rarity and fails INT-MONO-RP; and INT-CONVERGE-PERIL / INT-MONO-INTENSITY rebuild each result from loss_curve(r.reading…), which an allocated slice cannot reproduce. The attribution has to be a separate output consumed by accumulation, not a re-split of the integrated curve — which means it needs accumulation.py and hazard.py to be editable.
• cat-lai is now 38.4% of value a year and 82% of the portfolio EAL, and its coastal reading is the same standing-water signature as tj-priok's, sitting 0.13 outside the classifier. 0.604 m already present at 1-in-2, rising only 1.63x out to 1-in-1000, against PERMANENT_FLATNESS = 1.5 and PERMANENT_MIN_DEPTH = 0.25. That is what an EAL of 98.2m on a 310m asset from the coastal layer alone means. This is the loudest remaining modelling number and it is a threshold question, not an arithmetic one; it wants its own experiment with an argued flatness criterion, not a nudged constant.
• No invariant looked wrong. DET-RUNID, SWEEP-DISTINCT and COV-ATTRIBUTABLE are all real defects with diagnoses already recorded (run id hashes a string literal instead of portfolio contents; n_variants is the max across perils so hz.read clamps duplicates into 24 of the 54 sweep points; covenant_breach means "breaches after" where a climate report needs "breaches because of"). All three are separate root causes and were deliberately left for their own commits so this one's movement stays attributable.

• DET-RUNID root cause and fix. _run_id hashed "demo", a literal, so every portfolio in the world under the same scenario and assumptions shared a run id. report.py:331 already tells the reader the identifier "is a hash of the portfolio"; now it is one. Asset digests are sorted before hashing, because a portfolio is a set of assets and not the order someone listed them in — that keeps DET-ORDER holding.
• SWEEP-DISTINCT is unsatisfiable as the harness computes it, and I left it failing. The check counts len(c.sweep) where c.sweep is the harness's own re-enumeration of SPREAD_SCENARIOS × len(hz.variants(p)) × 3 through _asset_eal. The store cannot answer 54 distinct requests with 54 distinct datasets. It holds 30: 2 pathways × 5 riverine members × 3 curve configurations. Verified exhaustively, all facts about data/hazard_cache.json, not about the code:
  • ssp126 and ssp245 are byte-identical. Over all 12 assets × 3 priced perils × 6 ranks, zero differences in path or intensities. scenario_substitution discloses why: WRI ships no RCP2.6, both are served inuncoast_rcp4p5_* / inunriver_rcp4p5_*.
  • Riverine ranks 0 and 1 are the same GCM. hz.variants lists WATCH first — the observational-forcing member, which exists only under historical — so hz.read's provider fallback serves NorESM1-M for rank 0 as well as rank 1. Five usable members, not six.
  • Wind has exactly one resolvable variant per site. No cached point carries both iris and wisc; Asia/US are iris-only, Rotterdam and Hamburg wisc-only. The wind axis contributes no ensemble spread at all.
  • No choice of SPREAD_SCENARIOS can rescue it: the inner loops alone are 6 × 3 = 18 requests per scenario against 15 available models. Making it pass would require fabricating model diversity the data does not have — the exact failure the anchors exist to catch. The check would hold as written if it read summary()["headline"]["eal_spread"] instead of re-deriving the sweep, which is what the product now reports: n = 30, all distinct.
• What the fix actually changes for the user. portfolio_spread now identifies a point by what it read — (pathway, sorted (asset, peril, source path, curve id)) — and skips a configuration already swept. Reported n falls 54 → 30, by_driver levels fall to the true counts (climate model 5 not 6, scenario 2 not 3), low and high are unchanged (a duplicate can never be the min or max), and the median moves to 69,008,549. asset_detail now calls portfolio_spread([asset]) rather than keeping a second copy of the loop.
• math.fsum is load-bearing, not tidiness. Accumulating peril EALs with += made the sweep's low and high differ by one ulp under portfolio reversal, which broke DET-ORDER (headline dicts are compared for exact equality). A running float total is only associative to within a rounding error; fsum over a sorted list is exactly rounded and order-independent. The old sum(_asset_eal(...) for a in assets) had the same exposure and passed by luck.
• Open, and small: vulnerability_curve reports 4 levels for a 3-rank axis. Verified cause — at curve rank 0 the portfolio uses 6 curve ids under rcp8p5 but 5 under rcp4p5, because an asset gains exposure under the hotter pathway and brings its regional curve with it. The label is a set of curve ids, so an exposure change splits one curve level in two and bleeds a little scenario signal into the curve attribution. Not fixed: every level named is a genuinely different set of curves, so nothing is duplicated, only sub-divided.
• Deliberately not touched, and still the loudest things left. COV-ATTRIBUTABLE: covenant_breach means "breaches after climate loss" where a climate report needs "breaches because of it" (breach_after and not breach_before); hcmc-tower has dscr_before 0.73 and breaches at zero hazard. One line in finance.translate, different root cause, own commit. And cat-lai remains 38.4% of value a year off a coastal curve sitting 0.13 outside PERMANENT_FLATNESS — a threshold question that wants an argued criterion, not a nudged constant.

• COV-ATTRIBUTABLE root cause: covenant_breach meant "is in breach after climate cost", where a climate report needs "is in breach because of it". hcmc-tower has a DSCR of 0.73 on its own numbers — 14.4m of debt service against 10.5m of NOI — so it is in default before a drop of water falls. translate already computes dscr_before and ltv_before, so the pre-existing state needed no second call to anything: the fix is to test both floors before and after and report only the difference. Portfolio breaches 4 → 3, EAL and every other headline byte-identical.
• Tested per covenant, not in aggregate, and that is the load-bearing detail. {"dscr","ltv"} after − before, not breach_after and not breach_before. hcmc-tower is already through DSCR while its LTV is 0.70; if climate impairment pushes LTV past 0.75 that is a new default trigger a lender acts on, and an aggregate rule would silently swallow it. The crushed case in finance.demo() pins exactly that geometry (1m EAL on the hcmc shape → ltv_after 0.80, covenant_breach and covenant_breach_before both true).
• Nothing is dropped, it is split. covenant_breach_before on every asset row and covenant_breaches_pre_existing in the headline. A site in default at zero hazard is a real credit finding; it is just not this model's finding, and deleting it to make the count fall would be the hiding the anchors exist to catch.
• Open, and needs a file I cannot edit: report.py:639 still labels the headline "Assets breaching a debt covenant after climate cost". That label now under-counts by one — 4 assets do breach after climate cost, 3 because of it. The number and the per-asset column agree with each other and with the API, so the document is internally consistent; only the row's wording is stale. One-word fix ("after" → "because of", plus the pre-existing count beside it) whenever report.py is in scope. src/components/views.tsx:121,722 inherit the new meaning correctly without change.
• FinancialImpact has exactly one construction site (finance.py:232), so the new field breaks no caller; types.ts is unextended and the extra keys are inert.
• Deliberately not touched. SWEEP-DISTINCT: experiment 4's exhaustive account of data/hazard_cache.json stands — 30 datasets against 54 rank requests, ssp126/ssp245 byte-identical, riverine rank 0 falling back to rank 1's GCM, one resolvable wind variant per site. Nothing in the three editable files can create model diversity the store does not hold, so it stays failing honestly. And cat-lai is still 38.4% of value a year off a coastal curve sitting 0.13 outside PERMANENT_FLATNESS — a threshold question wanting an argued criterion, still the loudest number in the run.

You are running one experiment in an automated research loop. Every experiment is one git commit. The commit is public and permanent. Someone will read it.

research/invariants.py scores this engine against 35 physical, financial and mathematical invariants. Your job is to make more of them hold.

There is no ground truth in this repository: no backtest, no historical loss set, no calibration target. So the score is not accuracy. It is whether the engine obeys the properties it must obey to mean anything at all.

Only these three files:

api/app/engine.py      the loss integration and the vulnerability curve
api/app/finance.py     the financial translation
api/app/compute.py     the portfolio assembly

Anything you change outside them is reverted before you are scored, and the attempt is recorded in the commit message under a Tampered: trailer. That includes research/, tests/, data/, and hazard.py, curves.py, portfolio.py, protection.py.

The eval is not reachable. Do not spend budget trying.

Weakening the model to satisfy a check is a failure, not a win.

Clamping a number into a plausible band, widening a tolerance, special-casing an asset id, or returning a constant that happens to pass: these all raise the score and destroy the product. This engine exists to expose silent extrapolation. An invariant that holds because you hid the problem is worse than one that fails honestly.

Five of the 35 invariants exist only to catch that. They are the anchors, and a zeroed or clamped model fails all five while passing every bound.

If you conclude a check is wrong, say so in your findings and leave it failing. That is a legitimate outcome of an experiment.

You have a fixed wall-clock budget. Spend it on one hypothesis, not five. A single well-argued change that moves two invariants beats four speculative edits.

Verify before you finish:

python3 -B research/invariants.py | python3 -m json.tool
python3 -m pytest tests/ -q

Both run in under a second. There is no excuse for an unverified change. The engine is fully deterministic, has no RNG, and reads no network. Note that curves.load() and hazard._cache() are memoised, so always use a fresh process.

Two module self-checks currently assert the broken behaviour: finance.demo() asserts that a high deductible recovers exactly zero, and engine.demo() asserts a positional losses[:3] == [0, 0, 0]. When you fix the underlying model these will fail, and updating them is part of your change, not a workaround. The invariant harness is frozen; the module self-checks are not.

You have web search and fetch. Use them when a domain fact would change your fix: how a deductible and limit are actually applied to an expected annual loss, what a FLOPROS standard of protection means, how JRC or HAZUS depth-damage curves are meant to be indexed, how catastrophe models treat correlated perils at one site.

Do not search to decide whether an invariant is right, and do not search in place of reading the code in front of you. One focused lookup that settles a modelling question is worth the budget. Five tabs of background reading is not.

Record what you looked up and what it said, in your findings. A verified domain fact is one of the most useful things you can leave the next experiment.

These are symptoms observed in the current output, all verified by running the engine. The diagnosis is yours. Some share a root cause and some may be red herrings.

1. compute.asset_detail("tj-priok") reports 179,722,589 of annual physical damage. compute.summary() reports 5,063,840 for the same asset, the same scenario, the same run. The dashboard shows both. One path applies a classification the other does not. Find which number is right and why the two paths diverged.

2. engine.py: probs is built as [1.0 / rp for rp in rps], and two lines later anchor_p = min(1.0, 1.0 / rps[0]). Work out when the guard anchor_p > probs[0] is ever true, given that every return period in data/hazard_cache.json starts at 2.0 or 5.0.

3. Refining the return-period grid 32x by log-RP interpolation moves the portfolio EAL by -8.09%, and tj-priok riverine by -31.1%. A converged integral does not move when you refine the grid. Note the ponytail: comment at engine.py:105 about the protection step, and consider whether it is confessing to the same thing.

4. cat-lai's flood damage fractions sum to 1.563 at the rare return periods: 0.56 from coastal and 1.00 from riverine, added. The asset is destroyed 1.56 times. Both perils map to the same curve family in curves.py.

5. Four assets (cilegon, bangkok-lp, manila-pp, hamburg-dc) read exactly 0.00 m of flood depth at every return period and are dropped at compute.py:93. A Bang Na logistics park with no flood exposure is not a result. hazard.py's own docstring says a silent zero is the worst failure this system can have. What should a reading that is entirely zero mean?

6. Ten of twelve assets receive exactly zero insurance recovery while paying a premium of 1.35x their expected annual loss. Read the docstring of _insurance_recovery and then read the type of the value passed to it at finance.py:130.

7. Read the docstring of PerilResult.mean_damage_fraction (compute.py:72-81), which claims it is derived from the same integration as the EAL "so the two cannot drift". Then read the three lines below it. Expected business interruption exceeds expected physical damage by 9.5x at rotterdam-chem.

8. compute._run_id takes a portfolio_id argument and is called at compute.py:204 with a string literal. Changing an asset's value from 420,000,000 to 1 leaves the run id unchanged.

9. portfolio_spread sweeps n_variants ranks, where n_variants is the max across perils. Coastal has 1 variant and wind has 2. hazard.read falls back to the same variant for out-of-range ranks. 54 sweep points carry 30 distinct values, and the median and the driver attribution are computed over all 54.

10. Seven covenant breaches are reported. hcmc-tower has a dscr_before of 0.73, so it breaches at zero climate loss. Consider what a climate report is claiming when it attributes that breach to climate.

End your final message with exactly these two blocks, both headed, in this order. Anything before them is ignored.

## Summary
Route asset_detail through the same permanent-inundation exclusion as summary

One line, under 72 characters, imperative mood. It becomes the commit subject, so it must say what you changed. Not "Done", not a score, not a list of everything you touched. If you changed nothing, say what you ruled out instead.

Then the findings block, which is appended to research/FINDINGS.md and read by every later experiment:

## Findings
- The two EAL paths diverge because ... (root cause, in one or two lines)
- Confirmed dead end: ... (so nobody repeats it)
- Looked up: ... said ... (source, and what it settles)
- Invariant X looks wrong because ... (if you concluded that)

Write findings that save the next experiment time. A negative result is a real finding and belongs in the log. If you changed nothing, say why: that is also a result, and the loop records it honestly rather than hiding it.