How to read the performance dashboard

Purpose of Dashboard

PitchCopilot's /performance is not a promotional page, but a research record page. It puts published reports, settlement results, core configuration performance, Brier scores, hit definitions and model versions under the same perspective, allowing readers to go back and check whether the model is stable. For quantitative research in sports, public performance is more important than individual hits, because any model may look perfect in a small number of events, or it may suffer from noise in the short term.

The core ethos of the dashboard is complete record keeping. Hits, misses, unresolved, insufficient samples and version switches all need to be visible. This kind of transparency allows FPL players to know whether certain conclusions are credible, and also allows creators to have a traceable basis when citing them. If you are not familiar with the basic concepts, you can first read /guides/market-implied-pricing and /guides/settlement-hit-definitions.

Look at the sample first, then the percentage

Hit percentage is most easily misinterpreted. Eight out of ten games and one hundred and twenty out of two hundred games represent completely different levels of stability. When reading the dashboard, look at sample count, time window, and model version first, before looking at hit rate or virtual point results. PitchCopilot will separate core configurations from secondary configurations to avoid mixing different confidence levels.

Brier scores are used to measure probabilistic calibration. If the model says there is a 60% chance of an event, is the long-term outcome closer to 60%? This is more nuanced than simply guessing right or wrong. Calibration curves can reveal whether the model is overconfident, overly conservative, or systematically biased in certain leagues. If you want to learn more about this part, you can further read /guides/brier-calibration.

Core configuration and virtual points

Virtual point studies in dashboards compare different configuration assumptions in a standardized way. It does not represent real assets, does not promise returns, nor is it any operation instruction. PitchCopilot uses the concept of a virtual fund pool to allow the model's confidence, dispersion and risk exposure in each event to be quantified.

The core configuration usually represents a research direction with consistent models, data and pricing differences; the secondary configuration represents a signal but does not necessarily reach the main threshold. When reading, don't just look for the highest number, but ask: Which version does this result come from? Is it concentrated in a few leagues? Has it been affected by one or two extreme results? For related concepts, please refer to /guides/core-vs-secondary-config and /guides/asset-weight-allocation.

Manual review and publishing time

Every public report is manually reviewed before publication. Administrators check sources of data, strength of conclusions, legal presentation, internal links and readability. This process makes the dashboard not just a stack of model outputs, but an edited and published repository of research. When the event is settled, the hit definition will be applied according to the pre-existing rules and will not be changed based on the outcome.

Model version is also an important clue. If an upgrade changes weights, calibration methods, or release thresholds, the dashboard will let readers distinguish between old and new samples. You can see how version transparency can help with long-term evaluation at /guides/model-version-transparency.

Three levels of reading order

A three-tiered order is recommended for reading performance dashboards. The first level is data integrity: confirming the number of samples, time range, whether the event has been settled, and whether the model versions are consistent. The second level is the quality of the results: comparing core configurations, secondary configurations, Brier scores and virtual point fluctuations. The third level is interpretation quality: go back to the original report and check whether the market-implied pricing, Divergence and manual review reminders at that time can explain the results.

Reading this way avoids two common biases. One is to only look at recent highs and regard short-term fluctuations as long-term capabilities; the other is to only look at single misses and deny the entire version. PitchCopilot hopes that readers will form a research habit by using public performance: every number must be put back into the context of samples, versions and methods. If the virtual point study performs well in a certain period of time, also check whether it comes from a few extreme events; if the Brier score improves but the hit rate is mediocre, it may mean that the probability calibration is getting better, but more samples are needed for directional sorting.

Authors should also avoid truncating single numbers when referencing dashboards. A better way to write it is to state "how the core configuration performs under a certain version as of a certain window" and attach a link to a how-to page or guide. This allows readers to check back on their own rather than having to accept second-hand summaries.

FAQ

Is the higher the hit rate, the better?

uncertain. Sample size, confidence levels, Brier scores and virtual point fluctuations all need to be looked at together.

Will missed reports be removed?

Won't. The value of making performance public is to keep a complete record so readers can evaluate model limitations.

Can I quote the dashboard?

Yes, but it is recommended to include a /performance link and describe the sample window and model version.

This translation is for convenience only; the Traditional Chinese version prevails.