Spočítal jsem z veřejných dat, kolik peněz protéká posledním rokem života českých seniorů – zdravotní péče plus důchod – a co s tím podílem udělá stárnutí populace za 10, 20 a 30 let. Odpověď na moji otázku je dole pod výsledky.

Výsledky

Poměr pracujících na seniora sedí na tisíciny s oficiální Eurostat projekcí (OLDDEP3) a odpovídá i projekci ČSÚ 2023-2100.

Co to znamená, bez ekonomštiny

Stát za každého člověka platí dvě velké věci: zdravotní péči a ve stáří důchod. Zdravotní péče není rozprostřená rovnoměrně – zdaleka nejdražší je poslední rok života, kdy se koncentrují hospitalizace a intenzivní léčba. U seniora 65+ stojí poslední rok života zdravotnictví průměrně 349 tisíc Kč (běžný rok téhož seniora: 85 tisíc). Když k tomu přičtete roční důchod (~248 tisíc Kč), protečou posledním rokem života jednoho seniora zhruba 597 tisíc Kč veřejných peněz – asi dva roky odvodů průměrného zaměstnance.

Teď to vynásobte demografií. Silné ročníky stárnou, takže seniorů přibývá a lidí v produktivním věku ubývá. Dnes se na jednoho seniora skládají necelí tři pracující, v roce 2053 to budou necelí dva. Peněz do rozpočtu tedy přiteče méně, a zároveň bude umírat víc lidí ročně (113 tisíc dnes, ~192 tisíc v 2053 při dnešní úmrtnosti). Obě nůžky se rozevírají proti sobě – proto podíl posledního roku života na rozpočtu vzroste na dvojnásobek, aniž by se cokoliv zdražilo. V celém výpočtu jsou záměrně zafixované dnešní ceny, dnešní důchody i dnešní odvody na hlavu; mění se jen to, kolik je komu let.

Jedna věc, která mě překvapila: poslední rok života člověka 85+ je o něco levnější než průměr 65+ (340 vs. 349 tisíc Kč). U nejstarších se léčí méně intenzivně – méně JIP, méně agresivní terapie.

Odpověď: stačí to na dřívější důchod?

Skoro přesně na jeden rok. Počty na jednoho člověka 65+:

• Poslední rok života s běžnou trajektorií („léčení”): 349 tisíc Kč.
• Poslední rok života doma: běžná péče jako u přeživšího seniora (85 tisíc Kč) + mobilní hospic (45 tisíc Kč, průměrná úhrada pojišťovny na pacienta) = 130 tisíc Kč.
• Úspora: ~219 tisíc Kč. Rok důchodu stojí ~248 tisíc Kč => úspora pokryje ~0,9 roku důchodu navíc.

Takže rok dřív do důchodu: zhruba ano. Dva roky: ne. A jeden háček – když jdete o rok dřív do důchodu, stát nepřijde jen o rok důchodu navíc, ale i o váš rok odvodů (~304 tisíc Kč). V plné fiskální logice úspora pokryje jen ~5 měsíců. Fér verze odpovědi tedy zní: umírání doma s hospicem zaplatí přibližně rok důchodu, nebo necelý půlrok, pokud byste ten rok jinak ještě pracovali.

Ve prospěch hospice ale hraje ještě jedna položka: bez ventilátorů a JIP člověk umře o něco dřív – intenzivní terminální péče typicky prodlouží život o bolestné měsíce na ventilátoru. Každý takový nevyplacený měsíc důchodu je dalších ~21 tisíc Kč, takže reálná úspora je ještě o kus vyšší než počítám (a záměrně to nechávám jen jako kvalitativní bonus – prodloužení života na JIP nikdo v ČR neměřil).

Druhý háček: nejde to naplánovat pro každého. Část úmrtí je náhlá, část trajektorií (demence, dlouhá křehkost) domácí péči neumožní bez obrovské zátěže rodiny – a ČR je v dostupnosti domácí péče druhá nejhorší z 22 zemí OECD (stojí 668 % mediánového příjmu důchodce, bez veřejné podpory). Přesto je tu reálný přesah: dnes v nemocnici umírá 64 % Čechů, druhý nejvyšší podíl v OECD, a přání většiny je opačné.

Metodologie ve třech vrstvách

Vše je spočítané z veřejných, stažitelných dat. High level: vzal jsem oficiální tabulku ČSÚ „výdaje zdravotních pojišťoven na obyvatele podle věku”, rozdělil ji na náklady přeživších a náklady umírajících pomocí skutečné úmrtnosti každé věkové skupiny, a výsledek přepočítal na populační strukturu z oficiální evropské projekce. Podrobnosti jsou v rozbalovacích blocích.

Zdroje

Hlavní vstupy: ČSÚ Zdravotnické účty (tab. T3.1), Eurostat demo_magec/demo_pjan/proj_23np (EUROPOP2023), Pavloková 2010, Prague Economic Papers, French et al. 2017, Health Affairs, MFČR (výdaje rozpočtu 2024), ČSSZ/MPSV (důchody). Celý výpočet je reprodukovatelný Python skript nad stáhnutelnými CSV.

A wedding cake topper sits on the cake for about forty minutes. Then it sits on a shelf for the next few decades. It is one of the very few things from the whole expensive day that you actually keep — and, if it’s made to look like the two of you, one of the few that becomes genuinely irreplaceable.

So it’s strange how painful it still is to get a good one.

Ordering a custom topper today: pay a stranger, wait months, hope

Search “custom wedding cake topper” and you land in a beautiful, slightly terrifying aisle. The work can be lovely. But the transaction is stuck in 2010: you describe your faces to a stranger in a text box, pay in full up front, and then wait — sometimes for months — for a box to arrive, with no real idea whether it’ll look like you until it’s on your doorstep.

We ordered eight of them before we built anything

Before writing a line of product, we became customers — and I mean that literally: I’m getting married myself, so I went looking for our own topper first. We ordered eight custom toppers from across the market — marketplace sellers and factory-direct shops, in Europe, the US and China — about $2,000 in total, all shipped to one address (mine), and we logged every step: the ordering flow, every reply, the wait, and what actually showed up.

The results were a gift, because they were so consistently bad:

• 0 of 8 arrived both intact and on time.
• 7 of 8 blew past the delivery window they’d promised.
• Two sellers ghosted us completely after a single message.
• The one that did arrive within its window failed on quality — our notes from unboxing it just say “looks horrible.”
• The most expensive order ($529) is the one that never shipped at all.

We scored every vendor on the dimensions a couple actually feels — not on a spec sheet, but on the stuff that decides whether the experience is delightful or miserable. Then we set our own target one notch above the best score in the field on every single axis at once.

Scores 0–10, triangulated from our own orders placed April 2026. "Quality delivered" is filled in only after a piece physically arrived; the gap between what was promised and what arrived is the whole story. Competitor names withheld — these are mostly small studios doing sincere work, and the point isn't to pillory anyone, it's that the format is broken.

The pattern jumped out immediately: even the strongest competitor only led on one or two dimensions, and every one of them made you pay before you could see the result. Nobody was good at the whole thing at once.

So that became the rule for Conjure, and it’s a little obsessive: be at least one notch better than the entire field on every dimension that a couple actually feels — at the same time. Not “best in the world.” Just provably ahead of everyone else on ordering, communication, quality, speed, and price, together.

So we inverted the one thing everyone gets wrong

Here’s the core idea, and it’s almost embarrassingly simple: the moment you buy should not be the moment you pay.

Every other custom topper makes you pay first and pray. We turned it around. With Conjure you design first, for free, and only reach for a card once you’ve approved the exact thing — rotated it, zoomed in, checked the likeness from every angle.

At a high level, the flow is:

1. Upload a photo or two of the two of you (pets and all).
2. Our system sculpts you both and renders a real 3D model — in minutes, not weeks, with no human artist to brief and re-brief.
3. It loads right in your browser. Spin it, change the style, the size, the finish — redo it as many times as you like, free.
4. Pay only when it’s unmistakably you. Production starts the moment you approve, and the price you see is all-in: worldwide shipping and customs included, nothing waiting at the door.

(I’ll keep the how-it-actually-works under the hood to ourselves — but the part that matters to you is all above the surface, and you can poke at it right now.)

Try the real thing, right here

This is the same designer that runs on our site — drop in a look, set the size and finish, and watch the price and delivery update live. Pick a style and see the same couple re-rendered three completely different ways from one photo:

Live preview · pick a style

Step 1 · your photo  →  Step 2 · choose a look

Pixar Origami Rubber duck ＋ your own

---

Step 3 · size & finish

Size 12 cm

10121416

Single-colour $50Sculptural, one colour, porcelain-like. Four-colour $60Skin, hair, dress, suit — built into the material. Most couples chooseFull-photo colour from $200Photographic, full-colour surface — lace and embroidery legible up close.

Price $230 all in — shipping & duties included

Delivered by — free re-make if it doesn't match your 3D

Design yours for real →

That widget is a faithful copy of the flow on the Conjure studio; the live version adds a true drag-to-rotate 3D model instead of a still, and runs on your own photos.

Why doing it in the browser wins

When the computer does the sculpting and the browser does the showing, the whole experience changes shape. Every one of these is a place we set out to beat the field by at least a notch:

• See it before you pay. No more buying a description. What you approve in 3D is what you unbox.
• Minutes, not months. No artist queue, no “Delivery Month: December.” The design exists while you’re still on the page.
• Infinite revisions, free. Wrong pose, wrong style, wrong vibe? Redo it as many times as you want — it costs nothing because no one’s hand-sculpting each attempt.
• One honest price. $50 to $350, all-in — scaled honestly by colour and size (and tracking our actual costs), with worldwide shipping, customs and tax already included. No second invoice at the door.
• Every couple. Any height, any body, same-sex couples, pets sized to scale, cultural dress from a hanbok to a sherwani — because it’s generated for you, not pulled from a shelf of stock figures.
• The 3D file stays yours. Re-order it in ten years for an anniversary. The keepsake doesn’t expire.

A topper is on the cake for forty minutes and on the shelf for sixty years. The least we can do is let you see it before it’s yours.

I wanted one honest answer to a question every recipient actually asks — “if I earn 100 Kč more, how much of it do I keep?” — plus a transparent breakdown of where the money comes from. The result is a single-page calculator (in Czech, because its users are Czech). This post is about the hard part, which was not the UI: it was getting the math exactly right when the rules are split across five laws and the only binding implementation is a government web form nobody published the source of.

Open the calculator → (the app itself is in Czech)

The problem: the law is not the ground truth

The statute — Act 151/2025 Sb. plus its sibling laws and decrees — defines the benefit in prose. But prose is ambiguous, and the place where ambiguity gets resolved is the Úřad práce (Labour Office), which runs everyone’s application through one official calculator at mpsv.gov.cz. Whatever that calculator outputs is what a household receives. So for a tool that claims to predict real payouts, the ground truth is not my reading of the statute — it is the MPSV calculator’s behaviour.

The two disagree in places. The clearest example is the housing component. A strict reading of §23 and §28 suggests recognised rent should be min(actual rent, normative cap). The MPSV calculator does something else: it recognises a flat 80% of the normative rent and ignores your actual rent entirely (even when your real rent is lower). I couldn’t resolve that from the text — only by watching the calculator.

graph LR;
  LAW[Five laws and decrees]:::src --> AMBIG[Ambiguous prose rules];
  MPSV[Official MPSV web calculator]:::src --> ORACLE[Scrape 21 million answers];
  AMBIG --> ENGINE[Reimplement the engine in JavaScript];
  ORACLE --> ENGINE;
  ENGINE --> VAL[Validate exact match 99.98 percent]:::ok;
  VAL --> APP[Self-contained explainer app]:::app;
  classDef src fill:#3d8fc4,color:#fff;
  classDef ok fill:#1a7f5a,color:#fff;
  classDef app fill:#e6a817,color:#3a2a00;
  classDef step fill:#eef2ff,color:#1e293b,stroke:#94a3b8;
  class AMBIG,ORACLE,ENGINE step;

The approach: treat the government form as an oracle

If the calculator is the source of truth, then the way to reproduce it is to treat it as a black-box oracle and fit an implementation to it. I drove the official form across a grid of inputs — net work income, other income, rent, energy cost, housing type, municipality size, number of adults, children by age band, alimony, asset test, vulnerability flags — and recorded its answers. By the current version that’s 21,023,897 verified computations.

Then I wrote a clean-room engine in plain JavaScript and tuned it against that dataset until it stopped disagreeing. Where I had a curated golden subset, it now reproduces 603,658 / 603,658 rows. Across the full 21M scrape, my engine agrees with MPSV on the exact koruna in 99.98% of cases; the residual 0.02% are households where the benefit comes out to 0 Kč either way, so the disagreement never changes a real payout.

That number — 99.98% match against 21M of the government’s own answers — is the whole credibility argument for the tool, so it sits in a badge at the top of the page rather than buried in a footnote.

The formula, four components

Under the hood the benefit is a sum of four independent components, with no global cap:

DSSP = S_housing + S_subsistence + B_children + B_work

graph TD;
  DSSP[Superdavka DSSP total]:::root --> H[Housing component]:::c;
  DSSP --> S[Subsistence component]:::c;
  DSSP --> C[Child bonus]:::c;
  DSSP --> W[Work bonus]:::c;
  H --> HN[80 percent of normative rent minus 30 percent of income];
  S --> SN[Living minimum minus 70 percent of income];
  C --> CN[500 to 1000 Kc per child by income ratio];
  W --> WN[40 percent of income then tapered];
  classDef root fill:#2d3748,color:#fff;
  classDef c fill:#3d8fc4,color:#fff;
  classDef leaf fill:#eef2ff,color:#1e293b,stroke:#c7d2fe;
  class HN,SN,CN,WN leaf;

Everything keys off two quantities: P, the household’s decisive net monthly income, and ŽM, the household’s living minimum (the sum of each member’s statutory minimum). The component thresholds are all multiples of ŽM — 1.43× ŽM is where the subsistence component and the “addressed vs. flat-rate” energy rules switch; 1.6× ŽM is where the work bonus stops growing and starts tapering. The repeated coefficients (0.30 of income toward housing, 0.40 work-bonus rate, 0.80 rent recognition) are spelled out term by term in the app’s “Explanation with formulas” section, each linked to its paragraph in the law.

The app’s “Skladba superdávky” chart: how each component fades in and out as income rises. The dashed line is the pre-2026 system, so you can see exactly where the new benefit overtakes or undershoots the old one.

The quirks you only find by watching the oracle

The interesting part of reverse-engineering is the behaviour that isn’t in any plain reading of the statute. These are the choices baked into the official calculator that I had to replicate to hit 99.98%:

• Housing is indexed by the number of adults, not people. The normative-rent table is looked up on adult count, not household size. This single detail moves the housing component by thousands of koruna for families with children.
• Only 80% of normative rent is recognised, and your real rent is ignored above that floor. The app ships an MPSV-faithful mode by default but offers a “strict reading of the law” toggle that applies min(actual, normative) instead — so you can see both the lawful-on-paper number and the one you’ll actually get.
• A discontinuity exactly at P = 3× ŽM. The child bonus drops to 0 Kč precisely at that point and immediately returns to ~1,000 Kč — an unfilled seam in the algorithm. It’s un-triggerable in practice (your income would have to land on the exact koruna), but the engine reproduces it because the oracle does.
• Self-employment imputes a phantom income. For a person on self-employment as their main activity (OSVČ hlavní), §12 floors the counted income at 39,173 Kč/month (80% of the average wage) even in a month they earned nothing. This is the single biggest reason some households are dramatically worse off than under the old system.
• Auto-imputed alimony of 2,500 Kč for the “separated, amount not set” case, and banker’s rounding to the nearest 100 Kč that matches Python’s round() — both small, both necessary for exact agreement.

The design choices in the explainer

Matching the oracle is necessary but not the point; the point is making the result legible. The choices I made there:

• Lead with the marginal koruna. The headline isn’t the benefit amount, it’s “for every extra 100 Kč you earn, you take home X Kč.” That’s the number that tells someone whether picking up more hours is worth it, and the benefit’s tapers make it genuinely non-obvious.
• Show the exact amount, not MPSV’s rounding. The official form rounds to 100 Kč, which makes the figure jump between 0 and 100 on tiny income changes. I display the precise koruna so the curves are smooth and the marginal effect is readable.
• A “?” on every term, in plain Czech, because the legal vocabulary (rozhodný příjem, normativní nájemné, zranitelná domácnost) is exactly what trips people up.
• An honest “MPSV mode vs. strict law” switch, so the tool never pretends the calculator and the statute are the same thing.
• Built-in tests. Appending #test to the URL runs the engine’s golden tests against stored MPSV oracle values right in the browser — the validation isn’t a claim, it’s runnable.

Who wins and who loses

Because I had a fast, exact engine, I could also do the comparison the reform’s own materials are vague about: I ran both the old four-benefit system and the new DSSP across ~9,300 typical households.

The pattern is consistent. Working families with children and a net wage around 25–40k Kč gain (up to +5,400 Kč/month); single working parents and low-wage workers in big cities mostly gain modestly. Very-low- and zero-income households lose — typically −1,000 to −6,000 Kč/month — for three structural reasons the calculator makes visible: the near-universal child allowance was replaced by a smaller, income-capped child bonus; the housing normative is now indexed by adults rather than people; and the old housing supplement (doplatek na bydlení), which topped up uncovered real costs, is simply gone. The starkest case is a self-employed person with zero turnover, hit by that §12 phantom income — a swing of −26,000 Kč/month in one of the worked examples.

How it’s built

The whole thing is a single self-contained index.html — vanilla JavaScript, hand-drawn <canvas> charts, no framework, no build step, no backend, zero external requests. That’s deliberate: the engine was validated offline against the scraped oracle, so the deployed artifact has no dependency that could drift, it loads instantly, it’s trivial to archive, and anyone can read the entire model by viewing source. It deploys as a static page and that’s the entire ops story.

Caveats

The calculator is orientational. It doesn’t model §37 (individually raised living needs — care plans, public service, prescribed diets), and for self-employment it applies only the lower 0.80× average-wage floor. The fine-grained vulnerability categories of §7 (age 68+, disability grade II/III, pregnancy, single parent, …) are collapsed into a single per-person “vulnerable yes/no” flag you set yourself. For a binding figure, file through the official Jenda portal or the MPSV calculator. This is an independent project and is not endorsed by MPSV.

Legal basis

• Act 151/2025 Sb. — on the social-assistance benefit (DSSP), in force 1 Oct 2025
• Act 152/2025 Sb. — amending act
• Government Decree 361/2025 Sb. — living and subsistence minimum
• MPSV Communication 526/2025 Sb. — normative rent for 2026
• Act 110/2006 Sb. — on the living and subsistence minimum

Open the calculator → (in Czech)

Open the interactive map →

What data we use, and where

Every pixel on the map comes from one of three kinds of source, and the kind decides how much you can trust it. Think of it as a precision hierarchy — from real airborne-pollen measurements down to a season computed from satellite and climate data:

• Highest precision — measured station networks. Two regions are anchored on real airborne-pollen measurements. Europe comes from the EAN [European Aeroallergen Network] climatology, published as the ContaminationMapEurope widget on polleninformation.at. The US (CONUS) [contiguous United States] comes from PECM 2.0 [Pollen Emissions for Climate Models] — a 1995–2014 measured pollen-emission climatology (Zhang & Steiner 2022). We download each, decode it to weekly pollen levels, and spatially interpolate between stations.
• Medium precision — literature & monitoring-network calendars. The other populated regions — East Asia, Oceania (via the TERN/ACEAS [Australian ecology monitoring network]), the Middle East, the rest of Asia, Latin America, and Africa (via SAPNET [South African Pollen Network]) — have no continuous gridded measurements. Instead we take seasonal pollen calendars from peer-reviewed studies and monitoring networks (when each taxon flowers, at a few cities) and spatially interpolate them across the region.
• Computed — satellite + climate model. Everywhere else on Earth — and the empty voids inside the regions above — the season is computed, not measured. We derive it from NASA MODIS [satellite vegetation phenology] greenness timing plus ERA5-Land [Copernicus reanalysis climate] temperature. This claims timing only (roughly when a taxon flowers), never intensity, and large stretches with no defensible estimate are masked out entirely.

graph TD;
  ALL[All pollen-season data]:::root --> M[Measured station networks - highest precision]:::real;
  ALL --> L[Literature and network calendars - medium precision]:::lit;
  ALL --> C[Satellite plus climate model - computed timing only]:::model;
  M --> EU[Europe - EAN climatology]:::real;
  M --> NA[US CONUS - PECM 2.0]:::real;
  L --> EA[East Asia]:::lit;
  L --> OC[Oceania - TERN ACEAS]:::lit;
  L --> ME[Middle East]:::lit;
  L --> AS[Rest of Asia]:::lit;
  L --> LA[Latin America]:::lit;
  L --> AF[Africa - SAPNET]:::lit;
  C --> REST[Everywhere else on Earth]:::model;
  C --> VOID[Empty voids inside the regions above]:::model;
  classDef root fill:#2d3748,color:#fff;
  classDef real fill:#1a7f5a,color:#fff;
  classDef lit fill:#3d8fc4,color:#fff;
  classDef model fill:#e6a817,color:#3a2a00;

At a glance: green regions are measured station networks, blue are literature/network calendars, amber is the computed timing-only model, and grey is masked out (no defensible estimate). The rest of this post digs into how the blue and amber tiers are built.

Digging deeper: how the rest of the map is computed

Outside the two measured anchors, the map is built by re-computing and imputing the season — interpolating sparse calendars and, where even that runs out, modelling timing from satellite and climate data. Everything below follows from one honest constraint.

The one rule: claim WHEN, never HOW MUCH

The whole design follows from a single honest constraint. Where we have real measurements (Europe, North America, East Asia, Oceania), the map shows interpolated measured / literature pollen levels. Everywhere else, a satellite-and-climate model fills the gaps — but it only claims the season window (roughly when a taxon flowers), never the intensity. Satellite greenness correlates with airborne-pollen concentration at Spearman ρ ≈ 0 [rank correlation ≈ zero], so modelled areas get a single flat, conservative in-season level, sit in the lower confidence tiers, are aggressively masked where indefensible, and carry a visible confidence indicator. That honesty is the methodology.

Two composition guarantees hold everywhere:

• Override-never-overwrite — the model only fills confirmed no-data voids; real and literature data are byte-verified to never change (0 pre-existing data pixels altered in every region apply).
• Honest masking — where no defensible estimate exists (Sahara, Amazon/Congo interior, ice, ocean), the pixel stays transparent. Africa masks 84.3% of its voids; Oceania 99.2%.

End-to-end pipeline

Three source pipelines feed one on-disk format, which feeds the WebGL app. (See the two data branches for how measured and modelled data compose.)

graph LR;
  S1[Measured pollen stations]:::real --> T1[IDW spatial interpolation];
  S2[Literature pollen calendars]:::real --> T1;
  S3[NASA MODIS plus ERA5-Land climate]:::model --> T2[B0 void-fill model];
  T1 --> M[Override-never-overwrite merge];
  T2 --> M;
  M --> E[Encoding-B PNG atlas];
  M --> C[conf.png confidence raster];
  E --> APP[WebGL world map];
  C --> APP;
  classDef real fill:#1a7f5a,color:#fff;
  classDef model fill:#e6a817,color:#3a2a00;

Two branches, one merge

The left branch carries real signal; the right branch is the global model. Both emit identical Encoding-B strips, then merge in priority order so the model only shows through where nothing better exists.

graph TD;
  A[Measured stations Hirst-trap counts]:::real --> B[IDW interpolation per region];
  A2[Peer-reviewed pollen calendars]:::real --> B;
  B --> MERGE{Compose higher tier wins};
  D[NASA MODIS plus ESA WorldCover plus ERA5-Land]:::model --> E[B0 void-fill model];
  E --> A4[A4 quality-floor mask];
  A4 --> MERGE;
  MERGE --> OUT[Encoding-B level strips];
  MERGE --> CONF[conf.png per-pixel tier];
  classDef real fill:#1a7f5a,color:#fff;
  classDef model fill:#e6a817,color:#3a2a00;

Inside the B0 model

The void-fill model (we call it the B0 model [satellite+climate void-filler]) ingests NASA MODIS phenology (MCD12Q2 greenup) [satellite green-up timing] and MODIS land cover (MCD12Q1) [plant functional types] from NASA Earthdata, plus ERA5-Land 2 m air temperature from the Copernicus Climate Data Store. It derives a per-taxon flowering onset via three paths, then sets a flat conservative intensity. Crucially, growing-degree-day accumulation starts from each pixel’s local thermal-year origin (its coldest week), so the Southern Hemisphere is seasonally correct by construction — no hemisphere-flip hack anywhere.

graph TD;
  G[MODIS MCD12Q2 greenup DOY]:::in --> PA[Path A: greenup plus per-taxon offset];
  T[ERA5-Land 2m temperature]:::in --> PB[Path B: GDD from local thermal-year origin];
  L[MODIS MCD12Q1 land cover]:::in --> RANGE[Range and PFT gating];
  PC[Path C: fixed-photoperiod weeds AMBR ARTE]:::in --> ONSET[Per-taxon flowering onset];
  PA --> ONSET;
  PB --> ONSET;
  ONSET --> FLAT[Flat conservative intensity capped at level 2];
  RANGE --> FLAT;
  FLAT --> Z[Calibrated season window];
  classDef in fill:#e6a817,color:#3a2a00;

• Path A — trees & grass (primary): onset = MODIS greenup + a per-taxon offset.
• Path B — GDD fallback [growing-degree-day thermal model]: used where phenology QA is poor; accumulates heat from the pixel’s local coldest week, thresholds frozen to priors.
• Path C — photoperiod weeds: ragweed (AMBR) [Ambrosia] and mugwort (ARTE) [Artemisia] flower on a fixed solstice-relative photoperiod, so they are hemisphere-aware by definition.

Intensity is a single per-taxon constant taken from the Europe + North America median (e.g. EU grass in-season mean ≈ 2.04 → level 2) — a flat plateau, not a per-pixel gradient and not a bell curve.

Calibration is the whole point

The model is fit and validated against the decoded real ordinal data for Europe and North America — the precision anchors. The test is timing, not intensity.

Two consequences make the honesty concrete. First, the most universal allergen — grasses (POAC [Poaceae]) — flips PASS→FAIL on held-out data (onset/peak error 3.4 / 3.2 wk, just past the ≤ 3.0 wk gate), so grass ships synthetic everywhere in the void-fill. Second, the literature cross-check (K-LIT) is the only test inside the true extrapolation domain (arid / tropical / Southern Hemisphere), and only AMBR + ARTE clear it — which is why the entire model tier is just ragweed + mugwort in two regions. Everything else that survives masking is synthetic.

The confidence ladder

Every pixel carries one of five tiers, recorded in a separate conf.png raster that reuses the same byte ladder as the level strips (the two rasters share the numbers {0,64,…} but must not be conflated). A higher tier always wins the merge.

graph LR;
  M255[Measured byte 255 station IDW]:::t1 --> L192[Literature byte 192 pollen calendars]:::t2;
  L192 --> MO128[Model byte 128 K-LIT-anchored season]:::t3;
  MO128 --> S64[Synthetic byte 64 biological-prior season]:::t4;
  S64 --> N0[No-data byte 0 masked transparent]:::t5;
  classDef t1 fill:#1a7f5a,color:#fff;
  classDef t2 fill:#3d8fc4,color:#fff;
  classDef t3 fill:#e6a817,color:#3a2a00;
  classDef t4 fill:#c46e2d,color:#fff;
  classDef t5 fill:#c0c0c0,color:#333;

The Encoding-B format

Each taxon ships as 4 PNG strips × 13 weekly slices = 52 ISO weeks, grayscale-8, with bytes drawn from a 5-value ladder {0, 64, 128, 192, 255} mapping to pollen levels 0–4. Composition happens at extraction time, so the PNG already encodes the merged result — the app just samples it.

graph LR;
  TAX[One taxon for one region]:::h --> ST[4 PNG strips];
  ST --> SL[13 weekly slices each];
  SL --> W[52 ISO weeks total];
  W --> BYTE[Byte ladder 0 64 128 192 255];
  BYTE --> LV[Levels 0 1 2 3 4 none to very high];
  classDef h fill:#3d8fc4,color:#fff;

The eight regions

All facts below are read directly from each region’s shipped manifest (region, dims, nAllergens, confidence/confidenceFloor, provenance.sources). The 52-week temporal structure is fixed by the Encoding-B format (confirmed in the app and methodology, not stored as a manifest field). Europe and North America carry no tier field in their manifest — they are the highest-quality measured anchors and are described qualitatively below.

The five fill regions are dominantly literature but floor at synthetic because their void-fill is mostly biological-prior. Verified void-fill outcomes from the apply reports: Middle East 7,605 voids filled (8.2%, 91.8% masked, ARTE the only model-tier taxon); Asia-rest 163,985 (41.6%, 58.4% masked, zero model pixels); Oceania 2,806 (0.76%, 99.2% masked, zero model); Africa 149,309 (15.68%, 84.32% masked, zero model); Latin America 366,106 voids filled with just 8 model pixels (AMBR/ARTE within 5° of a Southern-Hemisphere anchor). Africa, Oceania and Asia-rest have zero model pixels — the entire model tier is AMBR + ARTE in two regions.

Explore it yourself on the interactive map →

Data & sources

Here is everything the map draws on, grouped by what it does. Attribution strings are reproduced verbatim from the region manifests.

Measured pollen data

• Europe — EAN climatology. Pollen-load climatology published as the ContaminationMapEurope widget on polleninformation.at, produced with the European Aeroallergen Network (EAN), Medical University of Vienna (© 2012 EAN).
• North America (CONUS) — PECM 2.0 (CC BY 4.0). Pollen-emission climatology, 1995–2014 historical average. Zhang & Steiner (2022, Nature Communications, doi:10.1038/s41467-022-28764-0). Data: doi:10.7302/628t-r416.

Literature & network pollen data

• Oceania — TERN / ACEAS (CC BY 4.0). Pollen monitoring network (portal.tern.org.au), 9 AU/NZ stations.
• Africa — SAPNET (CC BY 4.0). Two-year South African pollen monitoring network report (PMC10620116), 7 cities, 2019–2021.
• Middle East (CC BY 4.0). Qatar / Arabian Peninsula calendar, PLoS ONE 2022, doi:10.1371/journal.pone.0270975; Turkey NE Anatolia (Posof/Ardahan), Scientific Reports 2025, doi:10.1038/s41598-025-05867-4; Turkey SE Anatolia (Siirt), Biology 14(7):841, 2025, doi:10.3390/biology14070841.
• Latin America (CC BY 4.0). Toro et al. (2015, PLoS ONE, doi:10.1371/journal.pone.0123077), Santiago, Chile.
• East Asia & rest of Asia. Open-access regional pollen-calendar literature (China / Korea / Japan / Pakistan / SE-Asia / Russia studies), CC BY or equivalent.

Satellite & climate inputs

• NASA MODIS MCD12Q2 V061 [satellite green-up timing] (LP DAAC): Friedl, Gray & Sulla-Menashe (2022), doi:10.5067/MODIS/MCD12Q2.061.
• NASA MODIS MCD12Q1 V061 [satellite land cover] (LP DAAC): Friedl & Sulla-Menashe (2022), doi:10.5067/MODIS/MCD12Q1.061.
• ERA5-Land (Copernicus Climate Change Service): “Generated using Copernicus Climate Change Service information [1950–2024]. ERA5-Land monthly averaged data from 1950 to present (doi:10.24381/cds.e2161bac). Neither the European Commission nor ECMWF is responsible for any use that may be made of the Copernicus information or data it contains.”
• ESA WorldCover 2021 v200 (CC BY 4.0): “© ESA WorldCover project 2021 / Contains modified Copernicus Sentinel data (2021) processed by ESA WorldCover consortium.”
• WorldClim 2.1: Fick & Hijmans (2017), Int. J. Climatology 37(12):4302–4315, doi:10.1002/joc.5086.
• GALORE global modern pollen (CC BY 4.0): Pound & O’Keefe (2024), doi:10.5281/zenodo.14161411 — pipeline-internal range-gate prior only.
• GBIF species occurrences (CC BY 4.0): per-download DOI — pipeline-internal range-gate prior only.

Basemap & reference

• Basemap tiles by OpenFreeMap (OpenMapTiles schema), © OpenStreetMap contributors; land mask from Natural Earth (public domain).

Not endorsed by ESA, Copernicus/ECMWF, NASA, TERN, SAPNET, PLoS ONE, or any data provider. This is a research project explaining a modelled product — the void-fill claims a season window and presence at the stated confidence tier, never a measured pollen concentration.

AI’s economic uplift will be 3x regular computing

BEA pins the US digital economy at $2.6T. For a global supply chain that's a US-only proxy — global ICT-driven frontier productivity, ex EM catch-up, lands in roughly the same $2-4T/yr range (Jorgenson-Stiroh ICT-TFP attribution; OECD frontier productivity). Apply 3×, 20.0% vendor capture, and the implied annual vendor pool at maturity (~2035) is $1.56T, split across 22 verticals.

e_i        = 0.5 + 1.5 × (d8_score_i / 10)         # m-elasticity per vertical
c_layer_i  = 0.05 + 0.30 × (d4_score_i / 10)        # layer-specific capture (D4)
c_blend_i  = 0.5 × c + 0.5 × c_layer_i              # flat-vs-layer 50/50 blend
raw_i      = share_i × B × c_blend_i × m^e_i        # raw per-vertical
implied_i  = raw_i / Σraw × (B × m × c)             # renormalize to headline pool

Eight axes the v1 ranking ignored

Each vertical gets eight 0-10 scores, one per dimension. The strongest pair (D3 supply elasticity vs D8 Jevons demand) hits |r| = 0.642, below the 0.7 merge threshold. All eight survive.

D1 Already-rallied penalty

5-year total return, inverted. 10 = least rallied. A 200% rally on the same story leaves less juice.

Top: nuclear-SMR (priced for the rally) | Bottom: lithography (post-EUV run)

D2 Premise-implied TAM headroom

Premise-implied 2035 AI revenue (§1) minus today, log-scaled and rank-percentiled. Only forward-revenue axis.

Top: copper-rare-earth (premise_gap_log = 1.36) | Bottom: ai-accelerators (already monetised)

D3 Supply elasticity / bottleneck severity

Lead times to add a unit. Long = inelastic = pricing power. EUV ~18 mo. CoWoS 12-24. Copper 5-15 yr. SMRs 5-10. Transformers 18-48 mo.

Top: nuclear-SMR 9.51 / copper-rare-earth | Bottom: model-labs-software (instant scale)

D4 Value-capture intensity

Gross margin × moat width. Where the dollar lands inside the value chain.

Top: eda-ip 9.48 (80%+ GM duopoly) | Bottom: nuclear-SMR 0 (capex-heavy, fragmented)

D5 Substitution risk

Probability the dominant solution gets displaced in 10 years. CPO over pluggable; ASICs over GPUs; SMR over gas peakers; liquid over air.

Top: nuclear-SMR 10 (no baseload substitute) | Bottom: ai-accelerators 1.25 (rack-level ASIC risk)

D6 Capex × cycle position

Capex / forward revenue × cycle stage. Early-cycle premium, late-cycle penalised. D3 correlation r = 0.37.

Top: datacenter-reits 10 | Bottom: eda-ip 0

D7 Geopolitical exposure

Revenue / supply / customer exposure to friendly jurisdictions. Higher = safer.

Top: copper-rare-earth 10 (CHIPS-funded caveat) | Bottom: ic-substrates 0 (JP/TW/KR + PRC)

D8 Jevons elasticity

10x inference-cost drop -- demand elastic (high) or flat (low)? Demand mirror of D3.

Top: hyperscalers-cloud, model-labs-software 10 | Bottom: copper-rare-earth 0

Equal-weight rank, top to bottom

Unweighted mean of the eight scores. Top of the table: infrastructure picks-and-shovels (hyperscalers-cloud 6.97, copper-rare-earth 6.81, industrial-gases-water 6.72). Bottom: already-priced AI silicon plus speculative optics. Only power-semis-vrm gains rank under both premise-tilt and contrarian-tilt -- the cleanest asymmetric pick in the matrix.

Top-5, equal weight

Bottom-5

Nuclear/SMR jumped 16 places vs v1

v1 saw a 4.2x rally and called it "priced_in". v2 reads four more axes -- supply, substitution, geopolitics, headroom -- all pointing the same way.

Where this is still wrong

Eight axes beats three numbers, but it isn't the truth. Premise-level weaknesses listed in the five caveats above (3× upper-tercile, 20.0% blended capture, $2.6T US-only baseline, annual-vs-NPV horizon, flat P/S). Method-level weaknesses below: fragility on top-decile names, a judgement-call allocation split, substitution risk scored from notes not markets, and n=22.

References & further reading

AI’s economic uplift will be 3x regular computing

BEA pins the US digital economy at $2.6T. For a global supply chain that's a US-only proxy — global ICT-driven frontier productivity, ex EM catch-up, lands in roughly the same $2-4T/yr range (Jorgenson-Stiroh ICT-TFP attribution; OECD frontier productivity). Apply 3×, 20% vendor capture, and the implied annual vendor pool at maturity (~2035) is $1.56T, split across 22 verticals.

allocation_share_i = 0.5 * A_i + 0.5 * B_i
A_i = ai_revenue_today_i / sum_j ai_revenue_today_j
B_i = (vertical_revenue_i * sqrt(ai_share_i)) / sum_j (vertical_revenue_j * sqrt(ai_share_j))

Eight axes the v1 ranking ignored

Each vertical gets eight 0-10 scores, one per dimension. The strongest pair (D3 supply elasticity vs D8 Jevons demand) hits |r| = 0.642, below the 0.7 merge threshold. All eight survive.

D1 Already-rallied penalty

5-year total return, inverted. 10 = least rallied. A 200% rally on the same story leaves less juice.

Top: nuclear-SMR (priced for the rally) | Bottom: lithography (post-EUV run)

D2 Premise-implied TAM headroom

Premise-implied 2035 AI revenue (§1) minus today, log-scaled and rank-percentiled. Only forward-revenue axis.

Top: copper-rare-earth (premise_gap_log = 1.36) | Bottom: ai-accelerators (already monetised)

D3 Supply elasticity / bottleneck severity

Lead times to add a unit. Long = inelastic = pricing power. EUV ~18 mo. CoWoS 12-24. Copper 5-15 yr. SMRs 5-10. Transformers 18-48 mo.

Top: nuclear-SMR 9.51 / copper-rare-earth | Bottom: model-labs-software (instant scale)

D4 Value-capture intensity

Gross margin × moat width. Where the dollar lands inside the value chain.

Top: eda-ip 9.48 (80%+ GM duopoly) | Bottom: nuclear-SMR 0 (capex-heavy, fragmented)

D5 Substitution risk

Probability the dominant solution gets displaced in 10 years. CPO over pluggable; ASICs over GPUs; SMR over gas peakers; liquid over air.

Top: nuclear-SMR 10 (no baseload substitute) | Bottom: ai-accelerators 1.25 (rack-level ASIC risk)

D6 Capex × cycle position

Capex / forward revenue × cycle stage. Early-cycle premium, late-cycle penalised. D3 correlation r = 0.37.

Top: datacenter-reits 10 | Bottom: eda-ip 0

D7 Geopolitical exposure

Revenue / supply / customer exposure to friendly jurisdictions. Higher = safer.

Top: copper-rare-earth 10 (CHIPS-funded caveat) | Bottom: ic-substrates 0 (JP/TW/KR + PRC)

D8 Jevons elasticity

10x inference-cost drop -- demand elastic (high) or flat (low)? Demand mirror of D3.

Top: hyperscalers-cloud, model-labs-software 10 | Bottom: copper-rare-earth 0

Equal-weight rank, top to bottom

Unweighted mean of the eight scores. Top of the table: infrastructure picks-and-shovels (hyperscalers-cloud 6.97, copper-rare-earth 6.81, industrial-gases-water 6.72). Bottom: already-priced AI silicon plus speculative optics. Only power-semis-vrm gains rank under both premise-tilt and contrarian-tilt -- the cleanest asymmetric pick in the matrix.

Top-5, equal weight

Bottom-5

Nuclear/SMR jumped 16 places vs v1

v1 saw a 4.2x rally and called it "priced_in". v2 reads four more axes -- supply, substitution, geopolitics, headroom -- all pointing the same way.

Where this is still wrong

Eight axes beats three numbers, but it isn't the truth. Premise-level weaknesses listed in the five caveats above (3x upper-tercile, flat 20% capture, US-only baseline, annual-vs-NPV horizon, flat P/S). Method-level weaknesses below: fragility on top-decile names, a judgement-call allocation split, substitution risk scored from notes not markets, and n=22.

References & further reading

For a wider, full-screen layout with no sidebars, open the standalone version.

Supply-chain stack

%%{init: {'themeVariables': {'fontSize': '16px', 'fontFamily': 'system-ui'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 30, 'rankSpacing': 36}}}%%
flowchart TB
classDef lag fill:#dff5e2,stroke:#1f7a36,color:#0a3b18;
classDef pin fill:#fbe2e2,stroke:#a02323,color:#5b1414;
classDef fair fill:#eeeeee,stroke:#555,color:#222;
  subgraph row_inputs_u[" "]
  direction LR
  copper_rare_earth_u["Copper & Rare Earths"]
  industrial_gases_water_u["Industrial Gases & Water"]
  end
  subgraph row_ip-tools_u[" "]
  direction LR
  eda_ip_u["EDA & Silicon IP"]
  lithography_u["Lithography"]
  wfe_deposition_etch_u["WFE: Deposition, Etch, Implant, M…"]
  end
  subgraph row_silicon_u[" "]
  direction LR
  foundry_logic_u["Foundry — Logic"]
  hbm_dram_u["HBM & DRAM"]
  ic_substrates_u["IC Substrates"]
  end
  subgraph row_packaging_u[" "]
  direction LR
  advanced_packaging_u["Advanced Packaging"]
  end
  subgraph row_chip_u[" "]
  direction LR
  ai_accelerators_u["AI Accelerators"]
  end
  copper_rare_earth_u --> eda_ip_u
  eda_ip_u --> foundry_logic_u
  foundry_logic_u --> advanced_packaging_u
  advanced_packaging_u --> ai_accelerators_u
  class lithography_u,ai_accelerators_u,foundry_logic_u,wfe_deposition_etch_u,industrial_gases_water_u lag;
  class ic_substrates_u,eda_ip_u,advanced_packaging_u fair;
  class copper_rare_earth_u,hbm_dram_u pin;

%%{init: {'themeVariables': {'fontSize': '16px', 'fontFamily': 'system-ui'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 30, 'rankSpacing': 36}}}%%
flowchart TB
classDef lag fill:#dff5e2,stroke:#1f7a36,color:#0a3b18;
classDef pin fill:#fbe2e2,stroke:#a02323,color:#5b1414;
classDef fair fill:#eeeeee,stroke:#555,color:#222;
  subgraph row_chip_d[" "]
  direction LR
  ai_accelerators_d["AI Accelerators"]
  end
  subgraph row_interconnect_d[" "]
  direction LR
  silicon_photonics_optics_d["Silicon Photonics & Datacom Optics"]
  networking_switching_d["Networking — Switching, Retimers,…"]
  power_semis_vrm_d["Power Semiconductors — VRM / Vert…"]
  end
  subgraph row_facility_d[" "]
  direction LR
  datacenter_cooling_thermal_d["Datacenter Cooling — Thermal Mana…"]
  electrical_equipment_d["Electrical Equipment"]
  datacenter_reits_d["Datacenter REITs"]
  end
  subgraph row_power_d[" "]
  direction LR
  power_transformers_grid_d["Power Transformers & Grid"]
  gas_turbines_d["Gas Turbines"]
  nuclear_smr_uranium_d["Nuclear — SMR & Uranium"]
  utilities_merchant_power_d["Utilities & Merchant Power"]
  end
  subgraph row_consumers_d[" "]
  direction LR
  hyperscalers_cloud_d["Hyperscalers & Cloud"]
  model_labs_software_d["Inference-Consuming Software / Ap…"]
  end
  ai_accelerators_d --> silicon_photonics_optics_d
  silicon_photonics_optics_d --> datacenter_cooling_thermal_d
  datacenter_cooling_thermal_d --> power_transformers_grid_d
  power_transformers_grid_d --> hyperscalers_cloud_d
  class datacenter_reits_d,ai_accelerators_d,datacenter_cooling_thermal_d,hyperscalers_cloud_d lag;
  class networking_switching_d,gas_turbines_d,model_labs_software_d,power_semis_vrm_d fair;
  class utilities_merchant_power_d,electrical_equipment_d,power_transformers_grid_d,nuclear_smr_uranium_d,silicon_photonics_optics_d pin;

Interactive joint chart

Summary table

Methodology critique

gap_revised = 1.0·z(total_return_3y) + 1.0·z(total_return_chatgpt)/2
             − 1.0·z(ai_share_today_pct)
             − 0.5·z(log(tam_uplift_multiple))

Per-vertical detail

Hover any ticker chip for company info; click a card to expand.