A transcript from working with Claude Cowork on the Races report.
That's my bug — I used Count in the Top-15 filter where the schema requires ItemCount. Let me check the actual schema rather than guess again.
Found the cause. I'll replace the fragile Top-N filter with a threshold filter whose JSON shape I've verified against a known-good example in your own report.
Power BI stripped the invalid contents when you clicked Continue, leaving an empty VisualTopN: {} — still invalid. Replacing it.
Now checking whether Power BI rewrote or stripped anything else in my files.
Fixed — my mistake. I used Count where the schema requires ItemCount on the Top-N filter, and Power BI stripped the whole block when you clicked Continue.
Rather than guess at the Top-N shape a second time, I swapped it for a plain comparison filter — NumRaces >= 4 — because I could verify that JSON shape against a filter already working in your own report. Same intent (only your repeat races), less schema risk. The chart title is now "Race Series Run 4 or More Times" and it shows 28 series (per RaceOrOrg-Export PBI.csv: 85 series have 2+, 53 have 3+, 28 have 4+, 20 have 5+).
To change the cut-off, edit one value in Races.Report/definition/pages/7cfba3be643e0f900b7c/visuals/53fe6d0a167b3b7d8c3f/visual.json — "Value": "4L" near the bottom. Or just drop the filter in Desktop and use the Top N filter from the UI, which is the reliable way to get a true top-15.
I also swept both new pages for other stripped blocks: no empty objects anywhere, all field references still resolve against the model, filter aliases are declared, and both pages remain in pages.json.
Two notes worth your attention: since Desktop rewrote the file when you clicked Continue, other visuals may have been silently adjusted too — worth a glance at both new pages once it opens. And if you'd already committed to git, this is exactly the "just in case" case you mentioned; if not, no harm, the current state is the fixed one.