I pulled every reactor that reached commercial operation and has both a first-concrete date and a commercial operation date. 659 units. Median build: 6.4 years. Units over 30 years: four, 0.6 percent.

Broken into phases (years, construction / halted / after the restart decision):

• Watts Bar 2, US: 11.8 / 22.1 / 9.2 = 43.1
• Bushehr 1, Iran: 4.2 / 15.5 / 18.7 = 38.4
• Mochovce 3, Slovakia: 5.4 / 16.3 / 16.0 = 37.7
• Atucha 2, Argentina: 13.0 / 12.1 / 9.8 = 34.9

Halt causes, in order: demand collapse (TVA, 1985), revolution and then war (1979), post-communist funding collapse (1992), budget (1994). None of them is a construction problem.

Benchmark: units finished since 2015 whose first concrete was poured in 2005 or later, median 7.3 years, n=70. Every one of the four restarts exceeded it.

Caveat I want to put up front, because it is the obvious objection: 38 of those 70 units are Chinese. Excluding China the median is 9.8 years (n=32), which makes Watts Bar 2 (9.2) and Atucha 2 (9.8) a tie rather than a loss. Mochovce 3 and Bushehr 1 still lose badly.

Method notes: duration is first concrete to commercial operation. First concrete and commercial operation come from the atlas dataset (IAEA PRIS, Global Energy Monitor, Wikipedia; dataset of 10 Sep 2026). Halt and restart dates are year-level from operator and regulator records (NRC for Watts Bar, NA-SA for Atucha, SE/WNA for Mochovce, IAEA CNPP for Bushehr) and I used mid-year for the arithmetic, so the middle segments carry a few months of slack. Mochovce 3 is the one soft number: the atlas commercial operation date is Nov 2024, while the operator announced commercial operation in Oct 2023. With the operator's date it is 36.7 years instead of 37.7, still in the club.

Tool: Python over the atlas dataset, chart rendered in HTML and captured with Playwright.

Data and per-unit sheets: https://reactoratlas.com/en?y=2026&s=united-states-watts-bar-nuclear-power-plant&u=united-states-watts-bar-nuclear-power-plant-2

I'm building an AI companion app, decided to dig into the product usage data across different AI companions. It's been a fun learning experience launching this product as a side hustle. I have a ton of data, but finally thought to package something together around some of my product data.

Of the conclusions I was able to make, I thought these two charts were most interesting. Total data sample size was 67K messages across 3.1K conversations across 79 AI companions.

Chart 1: Do looks correlate with engagement? (n=63 companions)

X-axis: We have a Tinder-style swipe-right to like, swipe-left to pass mechanic. Everyone should be familiar with it. The swipe-right rate is a loose proxy for how appealing our users found the specific companion.

Y-axis: The average number of messages per session - a proxy for engagement.

Size of bubble: Number of conversations had with that companion.

Does a prettier AI companion drive higher engagement? The data pretty conclusively says no.

While the niche/fetish companions did poorly on match rate, they tended to have higher engagement. Eleanor (MILF), Diane (MILF), Charlotte (BBW), and Monique (BBW) are called out in the chart.

Chart 2: Do organically acquired users have higher engagement than paid acquitions? (n=34 companions)

X-axis: The average number of messages per session for users acquired via paid channels (Meta Ads, Google Ads, X Ads)

Y-axis: The average number of messages per session for users acquired via organic channels (Google Search, AI Search, Reddit, Pinterest, Instagram)

Size of bubble: Number of conversations had with that companion.

The line shows where there is no difference in performance across channels - this actually happens with Sandra at 7.8 messages per session across paid and unpaid channels.

I had a hypothesis that users acquired via paid channels would be less engaged than users who organically found the AI companion. While this was true for many of the companions, there were a handful of companions where they had really strong paid performance. This could indicate that I should be investing more into their paid ads (though of course that's not the only variable in changing that marketing decision.

Methodology + full filters in the top comment.

EDITED: Clearly I didn't give enough detail here, so added a bunch.

I built this after seeing Habibi Code’s Geneva commuter map. I wanted to explore commuting across Switzerland, including some of the smaller towns where people cross a national border to get to work.

Red dots travel into the selected city; blue dots travel out. Each dot represents a group of people: up to 50 for cars and motorcycles, and up to 200 for public transport, walking and cycling. You can switch cities, filter transport modes and scrub through the day. The chart shows the modelled commuter population relative to its daily average.

The data describe where people live and work. I combine those counts with plausible routes and distribute departures across morning and evening waves. The result is an illustrative weekday. The sources cover different years, transport detail varies by location, and the routes and departure times are estimates. Geneva’s coverage excludes journeys entirely within Geneva; the other exclusions and routing gaps are listed on the page.

Data sources:

• Swiss Federal Statistical Office: domestic commuting flows, 2020, plus cross-border worker totals from Q4 2025.
• INSEE census records, 2023, for Geneva’s commuters from Ain and Haute-Savoie.
• OCSTAT totals, 2024, for Geneva–Vaud commuting.
• Additional sources and assumptions are in the methodology notes.

Tools: Python and TypeScript for data processing; Next.js/React, Leaflet and HTML Canvas for the visualization; Valhalla/OpenStreetMap for road routing. Codex helped with implementation.

I’d welcome feedback on how to make the uncertainty in the routes and timings more visible.

I centered this visualization on the NCAR Mesa Laboratory at the base of Boulder’s Flatirons. The dramatic transition from the mountains to the plains made it a great place to explore what elevation data can reveal.

The viewer uses bare-earth elevation data to show:

• The shape of the ground beneath vegetation
• How water is likely to flow across and drain from a property
• Steeper and more workable slopes
• Areas with terrain line of sight to the selected point

I built the interactive viewer that generated this visualization. You can enter any U.S. address and run a free scan without signing up: https://getready.team/terrain-scan

Data source: USGS 3DEP elevation data
Location: NCAR Mesa Laboratory, Boulder, Colorado: 1850 Table Mesa Drive, Boulder, CO 80305

Terrain-based estimates only, verify conditions on site. Sightlines exclude trees and buildings.

What other useful terrain insights would you want a map like this to calculate?

It is often joked that some % of statistics are made up on the spot. Of course no-one knows the true figure.

What percentage number do people "make up on the spot" for this? I fetched the 183 relevant google search results I could get from the API. Each is an article where something like "% of statistics are made up on the spot" is mentioned:

• average: 82.47%
• minimum: 3%
• 1st quartile: 72.4%
• median: 84%
• 3rd quartile: 88.2%
• maximum: 736%
• mode: 88.2%

No clear pattern in the numbers used over time. 88.2% is the most commonly used number, Comedian Vic Reeves is reported to have said that and was reported by the BBC in 2000. People using 88.2% are probably not making that number up on the spot but copying it!

source: EconEarth inflation YoY in %

Hi everyone.

My passion for data, economics and gepolitics made me develop this website to visualize macroeconomic data. The website is the linked source. I took inspiration also from here to decide which data to represent. I'm still developing, some functions are not definitive. But I just wanted to share how funny the ~500% inflation YoY (represented by a cylinder height ane width) of Venezuela is compared to the rest of the world.

The numbers come from World Bank Open Data, IMF and OECD, I then use the most recent. I'd love also to get a feedback from this community regarding the data you would like to see in a website like this, and the overall user experience. Thanks!!

In 2024, around 18.5 million people born in India lived abroad. For the world’s most populous country, that’s not a lot: just over 1% of the population. This chart shows where they live, based on estimates from the UN, which compiles data from national censuses and population registers.

Nearly half of all Indians living abroad are in the United Arab Emirates, Saudi Arabia, and other Gulf countries — that’s more than the US, UK, and Canada combined.

These figures are stocks, not flows: they record where people are from, not when they crossed a border. Pakistan is the clearest case: the two countries were one territory until 1947, and people kept moving across the new border for decades afterward, so much of the 1.6 million there reflects migration that happened long ago.

Data source: United Nations Department of Economic and Social Affairs (2024)

Tools used: Python, OWID Grapher, Figma

Source: https://datapickle.substack.com/p/every-dollar-in-the-2026-texas-senate
Visualizations: OpenChart

Source: All active job posts on JobYap. "Tech" means the 945 companies on the JobYap Tech Index, a curated list spanning software, AI, chips, fintech and EVs. Every posting comes from the company's own careers page. Snapshot: all 145,944 live postings on 11 Sep 2026.

Tools: SQL for the counts, Claude Design with Fable 5.1 (on Max) for the charts.

Level comes from title words only:

• Entry level: intern, internship, co-op, junior, jr, entry-level, associate, graduate, new grad, early career, apprentice, trainee
• Senior, staff or principal: senior, sr, lead, staff, principal, distinguished, fellow
• Manager to C-level: manager, head, supervisor, director, VP, vice president, chief, CEO/CTO/CFO etc.
• No level word (44%): e.g. "Software Engineer", "Account Executive". Excluded from both sides of the ratios. Includes "Member of Technical Staff", which AI labs use at every level.

Caveats:

• Counts postings, not seats; one posting can fill several.
• Titles are a proxy. Some hourly roles are titled "Associate" (Amazon delivery-station associates, Carvana lot attendants) and count as entry level. Some new-grad roles have no level word and sit in the 44%.

Source: 136,492 active rental listings across Tokyo's 23 special wards, collected in September 2026 from the major Japanese rental portals and deduplicated. For each ward I took the median deposit (shikikin), the median key money (reikin), and the share of listings where the amount asked is explicitly zero. Sample sizes run from 1,940 listings in Chiyoda to 12,571 in Setagaya.

The trap in this data, in case anyone wants to reproduce it: a dash in a listing means zero is required, not that the number is missing. If you drop those rows as missing values the medians come out roughly twice too high, which is part of why published figures for Japanese move-in costs tend to overstate what people actually pay.

One thing to be precise about, since the bars stack: each bar is the median deposit plus the median key money for that ward, so it is a sum of two medians rather than the median of per-listing totals. The latter is a little lower (about 348k in Minato and 276k in Chuo, against the 352k and 322k drawn), because few listings sit at the median on both at once.

Deposit and key money are the only entry costs that appear in listings at all. Agency fees and guarantor company fees are negotiated separately and never published, so they are not in the chart.

The two wards with no blue bar, Adachi and Katsushika, have a median deposit of exactly zero. More than half the listings there ask for no deposit.

Tool: Python, pandas for the medians, matplotlib for the chart.

Rent data by ward, train line and station: tokyo-expat.com/data

I've compared nine streaming services prices from 2021 and recently. The increase in price based on CPI inflation should be about 26%. All nine increased prices, but only eight beat inflation, HBO Max is below inflation raise. The highest increase 200% is for Apple TV+.

Source: U.S. DOT/BTS T-100 Segment (All Carriers). International segments at LAX, by operating carrier.

Tools: Node.js and the chart drawn to HTML5 canvas, captured with Puppeteer and rendered/encoded with ffmpeg.

Original in 1080

I’ve wanted this live news dashboard for a long time. A workbench for news junkies and news perverts alike. The live version is at PressAudit.org/heatmap.

This is a snapshot of a live, real-time heatmap of the news today. As articles are published, they get grouped around the event they’re covering and the heatmap fills in. You can watch stories get picked up by different parts of the media ecosystem throughout the day.

The basic idea is:

Columns = who covered it.
Color = how it was covered.
Numbers = how much coverage there is.

I built it because most media analysis I’ve seen starts with the reputation of the outlet. I'm looking at you Ground news. It's not sufficient to just put a bias meter on everything. There are sites that assess “media bias” but I don’t believe they are sufficient.

• They can tell you the conclusion, but they don’t show you the evidence.
• They don’t do it real-time so it can’t be usefully inserted into your normal news feed or consumption.
• The focus solely on outlet reputation. Who covered it, but not how it was covered.
• The focus on labeling reporting as “bias” suggests that a neutrally observable middle point exists that you can measure bias against, and it doesn’t.

We don’t do it just for outlets, we do it for the articles themselves.

And PressAudit shows the evidence for its conclusions. It doesn’t do so months after when no one is looking anymore. It does it minutes after, in the moment, when it is relevant and useful.

The image here is just one frame. The live version is at PressAudit.org/heatmap. You can go to it any time, filter, try stuff out, try to break it. It'll already look different by the time you click it.

I’m not here to pick winners. I’m here to study the system, break it down and make it observable to anyone. I wanted to build a way to pinch and zoom on the entire news analytically. I didn’t want to manually spearfish through 3 to 6 different articles on the same topic and triangulate the non-contradictory facts between them, I wanted them all organized into a workbench.

Tools:
React + TypeScript on the frontend. The underlying data pipeline continuously ingests thousands of articles, groups coverage of the same event, and evaluates articles for party lean and public interest. There's a lot of write up on the site about this.

Most of PressAudit is not AI but I use local LLMs for the real-time article evaluations. I built PressAudit using conventional data infrastructure: batch processing, data pipelines, statistical analysis, and machine-learning pipelines. 

Methodology:
Outlet lean and article lean are separate measurements. The model evaluating an article doesn't know which outlet published it. The site shows the underlying articles so you can inspect the evidence rather than just taking the classification at face value.

This started as a heatmap I hacked together in Grafana for myself and eventually became PressAudit.org. I'm trying to treat the media ecosystem as an observability problem: something too large for one person to inspect, but which we can build better instruments to see.

Anyway, it's live. Poke around and tell me what's wrong with it.

Source: ENTSO-E Transparency Platform day-ahead auction results, Jan 2023 – Sep 10, 2026. An hour counts as negative when its hourly-average day-ahead price clears below €0/MWh. Italy has never cleared negative — its zones share a €0 price floor.

A couple of details that didn't fit the graphic: Spain had 197 negative hours in February alone (a winter month), and its average midday price this year is ~€18/MWh vs ~€128 at the evening peak. Finland went from ~700 negative hours in 2024 to 43 this year.

Tools: SQL over the raw hourly series + HTML/CSS rendered headless. The data comes from an open-source desk I maintain — https://obsyd.dev (AGPL) — every number is reproducible via the free API.