AW at Wolverhampton Today Detailed race cards

[spenctr]

RaceProfile Reports
What they are, what they’re based on, and what I’m trying to achieve

These RaceProfile reports are designed to turn raw racing data — especially sectional timing information — into practical, repeatable insights about:

How a race is likely to be run (pace/shape)

Which horses are suited by the likely setup

Which horses repeatedly do “too much too early” and fade

Which horses consistently finish strongly and can capitalise when others weaken

Whether a horse has trip (distance) preferences that show up in the data

The intention is to reduce guesswork and subjective “eye test” opinions by measuring the same behaviours repeatedly, across many races, and summarising them consistently.

1) What the RaceProfile report is

A RaceProfile report is a race-day “cheat sheet” combining:

A) Today’s race context

This sets the scene for the race the horse is running in today, such as:

Field size band

Race pace label (fast/standard/slow race, based on the data)

Track layout type (sharp / stiff / undulating, etc.)

(Optionally) draw/pace indicators and model figures if included by the script

The key idea is that the same horse can behave very differently depending on conditions, field size, track geometry, and pace.

B) Horse behavioural profiles

For each horse, the report summarises their typical behaviour in three phases:

Early pace / run style
Where the horse tends to sit early in the race relative to the field:

Led / Prominent / Midfield / Held up / Backmarker
Plus summary shares like:

On-pace % (Led + Prominent)

Patient % (Held up + Backmarker)

Mid-race behaviour
What happens in the middle section of the race:

Does the horse tend to gain ground mid-race?

Does it lose ground mid-race (comes under pressure)?

Is it repeatedly affected by traffic/pocket risk?

Finish strength (late speed / kick)
How well the horse finishes:

late-speed / finishing metrics (LSR, KickIndex, finishing strength z-score)

an interpreted label such as:

Strong finisher / Finisher

Weak finisher / Fader
Plus a short “reason” style explanation when the pattern is clear.

2) What the reports are based on (data sources)

The system is built on two databases:

A) horseracing.db

This contains runner-level sectionals-style data, typically stored in a table like ProcessedSectionals (or similar, depending on the pipeline).
Each row represents one horse in one race, and includes fields such as:

Race date (stored as date only, no time)

Distance

Field size and early pace rank

Mid-race movement metrics (e.g., rank change, time/length deltas mid-race)

Finish metrics (late-speed, kick/finishing measures)

This is the raw, detailed data layer.

B) PaceData_SQLite.db

This contains the horse-level profile tables that are built from the runner-level data:

Horse_Pace_Profile

Horse_Mid_Profile

Horse_Finish_Profile (alias of end/finish profile)
And corresponding breakdown tables:

…_ByDist (split by distance band)

…_ByContext (split by context such as field size band + race pace label + track layout)

This is the derived “profiles & lookups” layer used by the reporting scripts.

3) How the horse profiles are created

For each horse, all historical runs are aggregated into summary metrics using:

A) Recency weighting

Recent runs matter more than older runs, using an exponential half-life weighting (default in the build script is 365 days).
That means the profile adjusts as a horse changes or improves.

B) Clear, consistent aggregation

The profile outputs contain:

Runs (raw number of runs)

RunsEff (effective sample size after weighting)

LastRaceDate and RecentBias indicators
All numeric outputs are rounded to 2 decimals and all dates are stored as YYYY-MM-DD (no time component) to prevent date/time join issues.

C) Split views (overall vs by distance vs by context)

The profiles are built and stored in three levels:

Overall (all runs combined)

By distance (e.g., 5f / 6f / 7f / 10f etc, in 0.5f bands)

By context (split by field size band, race pace label, and track layout)

This allows the report to say things like:

“This horse is fine overall, but fades at 7f”

“On sharp tracks it overdoes it early”

“In slow races it finishes better (or worse)”

“In bigger fields it behaves differently than in small fields”

4) Trip (distance) hints and confidence

The system also produces “trip lean” hints for mid-race behaviour and finishing behaviour.

If the distance effect is strong and consistent, it can flag trip dependent behaviour (strict flag).

If it is weaker but still noticeable, it can produce a lean with a confidence label (Weak/Medium/Strong).

This is not a “magic” distance selector; it’s an evidence-based hint that becomes more reliable with more runs at a trip (higher RunsEff).

5) What I’m trying to achieve with these reports

The goal is to build a race-reading framework that answers:

A) How will today’s race unfold?

Who is likely to lead / press the pace?

Will the pace be strong, standard, or slow?

Which horses are likely to be positioned well or poorly early?

B) Who improves or weakens in the middle of the race?

Horses that “travel strongly and move mid-race”

Horses that repeatedly lose ground when pressure rises

Horses that look disappointing on paper but were repeatedly compromised by traffic

C) Who finishes best?

Horses that consistently finish strongly and can run down leaders

Horses that repeatedly fade late (vulnerable if they commit too early)

Horses that need the right setup (strong pace vs steady pace)

D) Where does a horse’s trip preference show up?

A horse might show strong early pace but fade late at certain distances

Another might be fine mid-race but lack finishing kick unless the trip/pace suits

These patterns become clearer when looking at ByDist and ByContext summaries

6) What the reports are and what they are not
What they are

A behavioural profile based on real race data, especially sectionals-derived metrics

A consistent way to interpret performance beyond the finishing position alone

A tool to spot the difference between:

horses helped by the setup

horses harmed by the setup

horses that can be upgraded/downgraded based on repeatable patterns

What they are not

Not a single-number “speed rating” replacement

Not a guarantee of outcome

Not intended to override all form reading — but to improve it by adding measured pace and finish evidence.

7) Practical use (how I apply it)

In practical terms, the report helps identify:

Front-runner types who weaken late (often lay candidates if pressured)

Strong finishers (upgrade if pace collapses)

Horses needing a patient ride vs horses that need to be handy

Trip suitability signals (especially where finish metrics deteriorate at a trip)

Context dependencies (sharp tracks, undulating tracks, big fields vs small fields, fast vs slow races)

The overall aim is to make decisions based on repeatable evidence rather than one-off impressions.

[Author]

Posts