sports tech

i work on race management technology for a living, and i build stintlab ↗ on my own time because the problems are the same shape and the data is mine to publish.

what does this blog cover about sports tech?

the systems side of motorsport, from an engineer’s seat rather than a fan’s.

race strategy as a search problem — an exhaustive search over every pit lap and compound , and why brute force beats a clever heuristic once you actually count the search space. and stint data as a statistics problem — ordinary least squares by hand , where the interesting part is not the fit but the identifiability bug underneath it.

what makes this domain worth writing about is that it is unusually honest about time. a lap either happened or it did not, results get amended after the fact, and the rules change between seasons in ways that make a single schema with a year column quietly wrong. those are ordinary data-modelling problems — anyone with a decade of orders or prices has them — but motorsport makes them legible, because everyone can see when the answer is wrong.

what will never be here: anything from the day job that isn’t mine to publish. no internal architecture, no timing-system internals, no anything that identifies a system i work on. the engineering generalises; the employer’s details do not. that line is written down in the repo’s content guide, and i hold to it.

• brute-forcing the pit window: when 'just try them all' is the right call — an exhaustive search over every pit lap and compound to pick a race strategy — why brute force beats a clever heuristic at this scale, and the r-squared-as-confidence wart
• hand-rolling ols regression in rust, and the collinearity trap that ate my coefficients — multiple linear regression from scratch — normal equations, cramer's rule, and the identifiability bug a singular-matrix guard turned into an honest None

related

the implementations are rust , the numerical side is statistics , and the data modelling sits with postgres .