Category: Artificial Intelligence

Your data, your prescription? What Google’s personal health agent tells us about AI-driven activity prescription

For more than a decade we have been collecting data from wearables at an incredible rate: steps, heart rate, heart rate variability, sleep, GPS traces, training sessions. Yet the step that matters most has always been the hardest one: going from numbers to a decision. What should this person do next week, given their data, their health history and their life? In high-performance sport we solve that problem with teams of people. For the general population, that team simply does not exist.

A paper just published in Nature by Heydari and colleagues at Google Research, “The anatomy of a personal health agent” (21 October 2026), is the most serious attempt I have seen so far to build that team in software. It is worth reading carefully, both for what it shows and for what it does not show, because it gives us a realistic preview of AI-generated, personalised activity prescriptions based on our own data.

What they built

The authors started from users rather than from technology. They analysed 1,370 real consumer health queries from search, Gemini and the Fitbit forum, surveyed 555 people using an experimental Fitbit Labs chatbot and ran a workshop with 14 experts. Four types of need emerged: general health knowledge, interpretation of personal data, wellness advice, and symptom assessment. These needs require very different skills — numerical precision and code for data questions, factual grounding for knowledge and symptoms, empathetic open-ended dialogue for coaching — and the team found that a single large language model struggled to balance them.

Their solution is a modular, multi-agent system — the Personal Health Agent (PHA) — built on Gemini 2.0, made of three specialists coordinated by an orchestrator:

  • A data science agent that turns a vague question (“am I getting fitter?”) into an explicit analysis plan, then writes and runs Python code on the user’s wearable time series, including comparisons with population percentiles by age and sex.
  • A domain expert agent that reasons over wearable data, blood tests and health history, using tools such as NCBI literature search, web search and population statistics to ground its answers.
  • A health coach agent built around motivational interviewing: it identifies goals first, explores constraints, asks for feedback and only then offers a SMART recommendation.

The orchestrator decides which agent leads and which ones support, rewrites a targeted sub-question for each, checks the combined answer for coherence (and to avoid asking the user for data it already has), and keeps a memory of goals, barriers and preferences across turns.

What the evaluation shows

The evaluation is large: 11 benchmark tasks, more than 7,000 annotations and about 1,350 hours of work from end users and experts, grounded in the WEAR-ME study (1,165 Fitbit users with blood tests and questionnaires). A few results stood out for me.

Data analysis. The data science agent’s analysis plans scored 75.6% against 53.7% for the base model. The most striking gain was in checking whether there was enough data to answer the question in the first place: 66.5% of plans did so, against just 5.3% for the base model. Anyone who has worked with wearable data knows that missing days, non-wear periods and artefacts are where most bad conclusions come from. Its code passed 75.5% of expert-written unit tests at the first attempt (58.4% for the base model), rising to 79% with self-correction.

Health knowledge and context. On more than 2,000 board-style questions in endocrinology, cardiology, sleep medicine and strength and conditioning, the gain over the base model was small (83.6% vs 81.8%). Much bigger differences appeared when personal context mattered: end users rated 96.9% of the domain expert’s personalised answers as trustworthy against 38.7% for the base model, and five clinicians judged 65% of its multimodal health summaries useful against 30%.

Coaching. Users preferred the coach agent on five of six coaching themes, and expert coaches preferred it on all six. Interestingly, both groups gave the plain baseline a slight edge on progress measurement — a weakness the authors then addressed in the integrated system.

The integrated agent. In live multi-turn conversations, 45 users role-playing real WEAR-ME profiles ranked the orchestrated PHA first 46.7% of the time, against 28.9% for a parallel multi-agent design and 24.4% for a single agent. The experts were far more decisive: the PHA was ranked best in 66.7% of conversations, roughly five times as often as the single agent, with an overall quality score of 72.8% against 64.3% and 54.4%.

Why this matters for activity prescription

What struck me most is that the architecture mirrors how a good performance support team works. Someone looks at the data properly, someone interprets it in the context of the person’s health and history, and someone turns it into a plan the person will actually follow. Exercise prescription needs all three. Frequency, intensity, time and type are not chosen from a guideline table alone; they depend on where the person is starting from, what they can safely tolerate, and what they are willing and able to do.

Seen through that lens, the near-future pipeline is easy to imagine:

  1. Baseline from your own data: real habitual steps, active minutes, resting heart rate, HRV and sleep — computed, not guessed, and checked for missing data.
  2. Comparison and context: where you sit relative to people of your age and sex, and what your blood markers and conditions mean for what is safe.
  3. A negotiated dose: a first step that fits your constraints and motivation rather than a generic “150 minutes a week”.
  4. Progression: memory of what was agreed and what actually happened, so the next prescription builds on the last one.

The example conversation in the paper’s extended data shows this already. A user with type 2 diabetes, a BMI of about 36, around 5,500 steps per day and a recent hospital admission asks how to get back to 10,000 steps. Instead of prescribing the target, the agent explores why it matters to her, picks up symptoms that suggest possible sleep apnoea, recommends speaking to her doctor, and agrees on several short 10-minute walks per day as a starting point. That is, in essence, a graded prescription with a red-flag screen built in. Another example I liked: asked whether more activity leads to more deep sleep, the data science agent reported a correlation of about 0.14 and said plainly that the relationship was weak — exactly the kind of honest answer a good analyst gives and a lot of consumer apps do not.

The real opportunity is scale. One practitioner cannot review thousands of people’s data every day and adjust their plan. A system like this could make the first layer of individualised prescription and follow-up available to anyone wearing a device, and free human experts to focus on the people and decisions that need them.

The risks we should not gloss over

The authors are refreshingly upfront about limitations, and they describe the PHA as a research prototype rather than a clinical tool. Still, for anyone tempted to treat this as a ready-made prescription engine, these are the issues I would keep in mind.

  • Safety at scale. In the expert safety review of the clinical summaries, 83% carried no or minimal potential for harm, but 15% were judged mildly harmful and 2% moderately to severely harmful. Two per cent sounds small until it is multiplied by millions of users.
  • No outcome data. Everything measured is conversation quality and short-term task performance. There is no evidence yet that people change behaviour, get fitter or become healthier. For an activity prescription, the only test that ultimately matters is the dose–response over weeks and months.
  • Data quality and generalisability. The data come from one device ecosystem (Fitbit), and consumer estimates of sleep stages or HRV have their own validity limits. Even the improved agent checked data sufficiency in only two-thirds of its plans, so one-third did not.
  • Simulated users. In the live studies, participants role-played personas matched to their own profiles rather than seeking help for themselves, and parts of the evaluation relied on LLM-based autoraters. Both are reasonable research choices, but neither is the real world.
  • Training load is not in scope. The system was not evaluated on periodisation, load management, injury risk, environmental stress such as heat, or athletic populations. Extending it to performance settings needs its own validation.
  • Evidence quality. Open-web retrieval can surface weak or conflicting evidence. The authors themselves suggest restricting retrieval to curated sources and showing provenance next to every recommendation.
  • Privacy, equity and cost. Real deployment needs proper privacy and security controls, fairness checks across populations, languages and literacy levels, and a cheaper architecture: the PHA averaged 6.5 model calls and about 205 seconds per response, against 3 calls and 36 seconds for a single agent.
  • Who built and judged it. The work was funded by Alphabet, most authors are Google employees, and the system runs on Google models and Fitbit data. That does not invalidate the findings — and releasing the code and benchmark is a genuinely good step — but independent replication will matter.
  • Coaching versus prescribing. The coach agent sometimes declines to give a concrete number and steers the user to decide for themselves. Good motivational practice, but people asking for an exercise prescription often need a clear, specific dose — and someone accountable for it.

What I would want to see next

Before trusting an AI-generated activity prescription, I would want to know four things: whether it checked the quality of the data before drawing conclusions, whether its evidence comes from curated sources it shows me, whether it recognises red flags and hands off to a clinician rather than reassuring, and whether its prescriptions are reviewed against what actually changed over time. The next generation of studies should be prospective, longitudinal and outcome-based, with people using the system for themselves, across devices and populations, and with clinicians and coaches in the loop.

Bottom line

This paper does not show that AI can prescribe exercise better than a qualified professional. It shows something more modest and, I think, more important: that splitting the job into data analysis, domain expertise and coaching, and orchestrating them carefully, produces answers that experts judge to be substantially better than a single general model. Personalised activity prescriptions built from our own data are no longer a distant idea. The challenge now is to prove that they are safe and that they actually change behaviour and health — and to make sure the humans who are accountable for those decisions stay firmly in the loop.

Reference: Heydari, A. A. et al. The anatomy of a personal health agent. Nature (2026). https://doi.org/10.1038/s41586-026-11161-8 (open access). Code: Google-Health/consumer-health-research.

We can all build our own tools now: what Claude and GPT-6 Astra mean for researchers (and some apps worth a look)

Back in March 2011 I wrote a short post about Google Labs’ anatomy tool. At the time, being able to rotate a 3D human body in a web browser felt like science fiction, and it had taken one of the biggest technology companies in the world to build it. Fifteen years later, a single developer released an open-source anatomy explorer that takes the human body apart into 2,234 individually selectable pieces — two days after the AI model she used to build it became available.

That, in one sentence, is what this post is about.

Over the summer I have written here about the tools I have been building with AI: a lactate threshold analyzer, a ten-year triathlon heat-strain study run end-to-end with AI, a systematic review on lactate supplements and a rebuilt football injury dashboard. None of them needed a development team. What has changed in the last couple of weeks is that it is no longer just me, and no longer just one company’s tools. Researchers, clinicians and educators everywhere are shipping genuinely useful applications, and some of them are very good indeed. So I wanted to pull together what has happened with the models, show you a few of the apps that caught my attention, and be honest about where I think we need to be careful.

How it used to work

For most of my career, getting a bespoke tool built followed the same script. You wrote a specification. You found a developer, or a budget, or both. You waited. You tested what came back and discovered the developer had misunderstood the science. You waited again. Many good ideas never made it past the specification stage, and many of the tools that did were abandoned the moment the grant ran out or the developer moved on.

That script has been torn up. The distance between “I wish I had a tool that did this” and a working link you can send to colleagues is now measured in days, sometimes hours.

What changed this summer

On the Anthropic side, the Claude 5 generation arrived one tier at a time rather than in a single big launch: Claude Opus 4.8 at the end of May, Claude Fable 5 and Mythos 5 on 9 June, Sonnet 5 on 30 June, Opus 5 on 24 July, and Fable 5.1 and Mythos 5.1 on 1 September. Opus 5 is what I used for the lactate review, and the combination of its price and a one-million-token context window is what makes it practical to keep a whole codebase, a dataset and a protocol in view in a single working session.

Fable 5.1 and Mythos 5.1 are the same underlying model with different safeguards: Fable is available to everyone, while Mythos is restricted to vetted cybersecurity and life-sciences organisations. The number that caught my eye was on Terminal-Bench-Science, a benchmark of agentic scientific research tasks, where Fable 5.1 scored 52.6% against 24.7% for Fable 5 only three months earlier. These are vendor-reported benchmarks, so treat them as such, but a doubling in a quarter is not nothing. Cache reads also became 75% cheaper, which sounds boring but matters a lot when an agent spends a long build session re-reading the same files.

The models are only half the story, though. Claude Code, Cowork, Claude Design and artifacts that can store data mean the output of a conversation is no longer a chunk of code you have to assemble yourself — it is a working tool you can open, test, share and keep improving.

On the OpenAI side, GPT-6 Astra was released on 3 September, first to a limited set of organisations and then to ChatGPT Plus, Pro, Business and Enterprise users and the API over the following days. OpenAI pitches it as state of the art for computer use, coding and scientific work. It is also the first OpenAI model to reach the “Critical” cybersecurity threshold in its own Preparedness Framework, which is why the rollout was staged — more on that later. The other piece worth knowing about is ChatGPT Sites, in public beta since July, which builds a web app from a conversation and publishes it straight to a live chatgpt.site address with the hosting included. At launch it was not available in the EEA, the UK or Switzerland, so not everyone reading this will have it yet.

Summer 2026: frontier model releases and the tools built with themAnthropic (orange) and OpenAI (teal) releases, May–September 2026, against examples of tools shipped in the same windowFable 5 / Mythos 5access paused(US export controls)Frontier model releasesTools shipped (examples)Claude Opus 4.8Claude Fable 5& Mythos 5Claude Sonnet 5Claude Opus 5Claude Fable 5.1& Mythos 5.1GPT-6 AstraLactate ThresholdAnalyzerTen-year triathlonheat-strain studyLactate supplementsystematic review(Opus 5)Football injurydashboard rebuildTesla Model Xexploded view(Astra)Human Atlas2,234 meshes(Astra)Model release → public 3D anatomy app: 2 daysJun 2026Jul 2026Aug 2026Sep 2026

The summer in one picture: model releases on top, tools shipped underneath. The gap between GPT-6 Astra becoming available and a public, open-source 3D anatomy explorer built with it was two days.

The cost of trying an idea has collapsed. The cost of being wrong has not.

Four tools worth a look

Human Atlas: the body in 2,234 pieces

human-atlas-seven.vercel.app · code on GitHub

This is the one I opened this post with. Developer Ashe Magalhaes had just used Astra to build an “exploded view” of a Tesla Model X in 334 pieces, and then, after joking online about whether it would be weird to do the same with a body, did exactly that. Human Atlas takes the BodyParts3D adult male reference apart into 2,234 selectable meshes across 15 anatomical systems, with 3,432 searchable named structures. You can rotate the body, isolate a single structure, switch systems on and off, and spread the whole thing out into an inventory of every visible piece. It is built with React and Three.js, the code is MIT-licensed, and the anatomy data keeps its own CC BY 4.0 licence.

What impressed me most, though, was not the rendering. It was the README. It tells you what was validated (mesh data, search, layouts on desktop and phone screens, tap-versus-drag handling), what was not tested (performance on physical devices and real multitouch hardware), and that it is an educational explorer, not a diagnostic or surgical tool. That is exactly the standard I would like to see from anyone publishing an AI-built tool.

Human Atlas: 2,234 BodyParts3D meshes in an exploded view, running in the browser with nothing to install.

Immediately after, another developer deployed the female model.

Someone else today deployed the skeleton

Portal Tau: clinical research methods made interactive

investigaciontau.com · Portal Tau

Tau: Investigación Clínica y Epidemiológica is Dr Joshuan J. Barboza’s Spanish-language platform for training researchers in systematic reviews, research methods and scientific publishing. Its companion Portal Tau shows what one researcher-educator can now put online. There is a Journal Match tool that scores how well your manuscript fits across 32,193 journals using Scimago, DOAJ and OpenAPC data; an explorer comparing the publication fees journals advertise with what institutions actually paid; a ten-module evidence-based medicine calculator; and a clinical trials simulator.

The simulator is the piece I would use in teaching. It runs phase I dose-escalation designs participant by participant — BOIN, Keyboard, CRM, the classic 3+3 and accelerated titration — as well as phase II designs (Simon, Gehan, Bayesian and randomised), and then simulates thousands of trials with Monte Carlo methods. Anyone who has tried to explain to a room of students why the 3+3 design is inefficient will know that running a thousand simulated trials in front of them does more than any slide ever will. And the whole suite sits on free static hosting: no server bill, no IT department.

The clinical trials simulator in Portal Tau: designs that usually live in textbooks, made interactive.

Shoulder Atlas: the examination in motion

shoulder-mechanics-atlas.geraldmd.chatgpt.site

If I had to put one of these in front of physiotherapy and sports medicine students tomorrow, it would be this one. Shoulder Atlas animates 12 clinical examination tests on a 3D right shoulder: empty can (Jobe’s), full can, Neer’s, Hawkins–Kennedy, painful arc, resisted external rotation, lift-off (Gerber’s), belly-press, Speed’s, Yergason’s, cross-body adduction and passive external rotation.

Each test plays out in stages. For the empty can, you watch the arm elevate in the scapular plane, the thumb turn down, and the examiner apply resistance, with live readouts of arm elevation, humeral rotation and elbow flexion. Separate overlays show passive guidance, examiner resistance and patient effort, and the target structures light up — supraspinatus and the subacromial region, in this case. Alongside the animation you get how to perform the test, what it loads, what counts as a positive finding and how to interpret it, with links to Stanford Medicine 25, the AAFP and ShoulderDoc.

Two things make it a particularly good example for this post. The first is where it lives: a chatgpt.site address, which is where ChatGPT Sites hosts what it builds, so it went from conversation to public link without anyone configuring a server. The second is its “About the model” panel, which is a small masterclass in honest scoping. Bones and muscle surfaces come from BodyParts3D; the bursa, capsule and tendon paths are simplified overlays; scapular movement is illustrative; there is no collision, force, tissue-strain or pain solver; and the angles describe the animation, not measured patient motion. It calls itself a teaching prototype, not a validated diagnostic simulator, reminds you that no single test confirms a diagnosis, and says plainly that instability and labral tests are not in this first version. I have seen commercial products that are a lot less candid.

Shoulder Atlas: Tests can be animated.

What these tools have in common

The hard part is no longer the code. In everything I built this summer, getting something to render was never the problem. The work was deciding which method to use, what to label as an estimate rather than a measurement, and what the tool should refuse to tell you. The science lives in the specification. Someone who understands why a modified Dmax threshold differs from a fixed 4 mmol·L⁻¹ one will write a far better specification than a developer who does not — and now that person can build the tool themselves.

Open data is doing a lot of quiet heavy lifting. Human Atlas and Shoulder Atlas both exist because BodyParts3D is openly licensed. Portal Tau works because Scimago, DOAJ and OpenAPC publish their data. The models get the headlines, but without open datasets they would have very little that is useful to build on.

The expert can build exactly what their practitioners need. A commercial product is designed for the average user. A tool built by someone in the field can encode the exact protocol, the exact caveats and the exact outputs a particular group needs — and be fixed the same afternoon someone spots a problem.

Being honest about limits is becoming the marker of quality. When building is cheap, the tools worth trusting are the ones that tell you what was checked, what was not, and what they are not for.

Where I would be careful

I am enthusiastic about all of this, but it would be a strange post from me if it did not come with caveats.

  • Plausible is not the same as correct. In the lactate review, the AI produced a chemistry figure showing the wrong mirror-image form of the molecule, and it looked perfectly fine. Apps fail in exactly the same way: a chart that renders is not a chart that is right. Every calculation in a tool should be checked against values worked out independently, by hand if necessary.
  • Educational is not clinical. The moment a tool is used to inform the diagnosis or treatment of a specific patient or athlete, it is in regulated territory. The best examples above say explicitly that they are for education. That line needs to stay bright.
  • Data protection does not get faster just because development does. Identifiable athlete or patient data should not go into a quickly deployed web app, or into a prompt, without the same governance you would apply anywhere else.
  • Security matters more, not less. The same capabilities that let a model build an app let it find the weaknesses in one. OpenAI staging Astra’s release because of its cyber capabilities, and the safeguards Anthropic layers on its Mythos-class models, should remind us that something deployed in an afternoon has probably not been hardened.
  • Tools that are easy to build are easy to abandon. Dependencies change underneath you — my own football dashboard showed a blank page for some people until I stopped it relying on an external charting library. Access to the models can change too: in June, Anthropic suspended access to Fable 5 and Mythos 5 for around three weeks to comply with US export controls before restoring it. Keep your code, your data and your exports somewhere you control.

In conclusion

A year ago, most of the tools in this post would have needed a team, a budget and several months. Now they need a researcher with a clear idea, a good specification and the discipline to test what comes back. And this is true whether you work with Claude or with ChatGPT — the capability is no longer tied to one company.

I do not think the people who benefit most will be those who build the most apps. It will be those who specify carefully, validate against known answers, write down what they have not tested, share their code, and keep themselves firmly in the loop. So my encouragement to colleagues is simple: build the tool you have always wished existed, put it online, be honest about its limits, and invite people to break it.

And if you have built something along these lines in sports science or sports medicine, send it my way. I would love to feature a few more.


Links mentioned in this post

Model release dates and benchmark figures come from Anthropic and OpenAI announcements and contemporaneous coverage; benchmarks are vendor-reported. Tool descriptions are based on the public sites and repositories as of 11 September 2026. I have no affiliation with any of the third-party tools mentioned. This post was drafted with the help of Claude and edited by me.

Rebuilding the Football Injury Dashboard: Adding Transfermarkt Data for the 2026/27 Season

The 2026/27 season is a few matchdays old, which is exactly the point in the calendar when injury counts start climbing. It seemed a good moment to go back to the European football injury dashboard I put together earlier in the year and deal with something that had been bothering me about it.

The original version had a structural weakness. Its month-by-month figures were not measurements. The Howden Group Men’s European Football Injury Index — the best free source covering the top five leagues — publishes one total per season, not one per month. To draw a monthly curve I had been distributing those annual totals across the year using the seasonal distribution reported in the UEFA Elite Club Injury Study. That gives a defensible shape, but every individual month was an artefact of the model rather than a count of anything. If you had asked the chart whether September 2023 was worse than September 2024, the answer would have been decided by the annual total, not by what happened in September.

So I added a second dataset alongside it, and let the reader choose which one they are looking at.

Two datasets, two different questions

The dashboard is here: footballinjuries.tiiny.site. A toggle at the top switches between the two sources. They answer genuinely different questions, and I have tried to make the distinction obvious rather than burying it in a footnote.

  • Season pattern — estimated monthly counts across seven leagues and five seasons, showing when in the year injuries cluster. Good for shape, approximate for magnitude.
  • Injured right now — a real count of every player listed as injured on a given date, from Transfermarkt. Good for who is actually missing, useless as a season total.
Line chart showing estimated monthly injury counts across seven European football leagues for the 2026/27 season, peaking in September
The seasonal view. The September peak is the most consistent feature in the whole dataset — players return from the summer break, fixtures arrive quickly, and bodies that have not been at match intensity for weeks are asked to perform. A second, smaller rise comes in April as accumulated load tells.

The Transfermarkt layer

The new view collects every player listed as injured on Transfermarkt‘s injury pages for the Premier League, Bundesliga, La Liga, Serie A, Ligue 1, Eredivisie and Liga Portugal. On 28 August 2026 that came to 257 players. These are individual records — a named player, his club, and what is reported to be wrong with him — not a figure derived from anything.

Stacked bar chart showing players currently injured across seven European leagues on 28 August 2026, coloured by injury type
Players injured across the seven leagues on 28 August 2026. You can click into any league to see it club by club.

The Bundesliga stands out with 66 players out, against 15 in Ligue 1 — though before reading anything into that, note that squad sizes, fixture load and how much press attention a league receives all feed into these numbers. That last factor matters more than it might appear, and it leads directly to the caveats.

Where this data is weak, and why I have said so on the page

Transfermarkt injury records are compiled from press reports, not club medical records, and that has consequences worth stating plainly.

A snapshot over-represents severe injuries. A cruciate ligament rupture stays visible on the page for months; a grade one hamstring strain disappears within a fortnight. The injury mix in the chart is therefore more severe than the mix of injuries a league actually sustains. This is straightforward survivorship bias and it cannot be corrected without incidence data.

Roughly a third of records name only a body part. “Knee injury”, “ankle problems”, or simply “unknown injury”. I could have forced these into a category and produced a tidier chart, but that would be inventing precision that is not in the source. They appear as Not specified instead. In the Eredivisie this accounts for 32 of 56 records — a striking difference in reporting practice rather than in injury patterns, and one that is itself interesting.

These are counts, not rates. There is no exposure denominator — no adjustment for minutes played — so none of this is comparable with the injuries-per-1000-hours figures the epidemiological literature reports. For that you need the UEFA Elite Club Injury Study or club data, and this dashboard is not a substitute for either.

The Eredivisie and Liga Portugal are also absent from the Howden report entirely, so their seasonal estimates lean on published injury-rate research for comparable leagues and should be treated as softer than the other five.

Other changes

Two smaller things. The dashboard is now written for a general reader rather than for me — plain-language injury categories, an explainer at the top, and a summary underneath the chart that rewrites itself as you change the selection. It also now states honestly how solid each season is: 2022/23 to 2024/25 are confirmed by Howden, 2025/26 has finished but is awaiting the December 2026 report, and 2026/27 has barely started and is labelled as a projection rather than a record.

The other change is invisible but was the reason several people saw a blank page: the chart previously loaded its plotting library from a CDN, and if that request failed — restricted network, content blocker, poor connection — the result was an empty rectangle with no explanation. It now draws its own SVG with no external dependencies at all. Nothing is loaded from anywhere. It works offline.

What next

The obvious next step is real month-by-month history rather than estimates. Transfermarkt does hold this — every individual injury record carries a start date — but assembling it means collecting player-level histories across seven leagues and several seasons, which is an overnight job rather than a page fetch. I have the pipeline written using the worldfootballR package; it is a matter of running it and validating what comes back. If it holds up, the estimated monthly figures get replaced with counted ones and the weakness I described at the top of this post disappears.

As with the triathlon dashboard, this is a living project and I would rather it be scrutinised than taken on trust. Have a look at the dashboard and tell me what is wrong with it, or what you would want to see next.

Seasonal estimates derived from the Howden Group Men’s European Football Injury Index (2024/25 edition, published December 2025) and the UEFA Elite Club Injury Study. Current-injury figures collected from Transfermarkt on 28 August 2026 and filtered to clubs competing in each league. Injury classification from free-text labels is approximate. These are counts without an exposure denominator and should not be read as incidence rates.