Skip to main content

Tyre Specifications

Tyre Specifications declare which wear parameters apply to a given compound or manufacturer. They drive the Wear Sheet tab on the Tyres screen and make the wear-data form per-compound aware (a control-tyre Hoosier R7 form should look different from a Pirelli P Zero DH slick).

Find the admin at Admin → Tyre Specifications. Route: /admin/tyre-specifications. API: /tyre-specifications.

What a spec contains​

Each spec is keyed by compound (or compound + manufacturer if you want to disambiguate). The body looks like a Definition spec:

  • parameters — typed scalar wear fields (e.g. BlockHeightLeft, BlockHeightCenter, BlockHeightRight, IRTempInner, IRTempMid, IRTempOuter, Pressure)
  • mathParameters — derived fields (e.g. WearRate = (NewBlockHeight - BlockHeightCenter) / Mileage)
  • dimension / defaultUnit per parameter

The admin​

Master/detail:

  • Left — spec list grouped by compound
  • Right — same parameter / math-parameter / collection editor as the Definitions admin (a thin wrapper to keep the surface familiar)

How the spec flows through the app​

When a tyre set is created with a given compound, the Wear Sheet tab on the Tyres screen looks up the matching spec (by compound) and renders one input per parameter. If no spec is found, the wear sheet falls back to a generic 4-corner template.

What you can do today​

  • Author one spec per compound
  • See it drive the Wear Sheet tab automatically when a tyre set uses that compound
  • Override units / defaults / precision per parameter

What's coming​

  • Manufacturer-aware fallback — fall back to manufacturer defaults when the exact compound isn't authored
  • Lifecycle parameters — declare "max heat cycles" / "max mileage" so the Tyre screen can flag end-of-life sets
  • Wear rate auto-calc — derive a wear-rate channel from successive wear measurements