Garmin Predicted 48 Minutes. My MetricBraid Was Less Optimistic.

Garmin predicted I could run 10K in 48:18. My personal best was 57:14.

Ahead of the ASICS LDNX 10K at Wembley on 11 October, I decided to test something I'd been building.

MetricBraid is an open-source framework I built to help AI make better sense of data from multiple wearables. Rather than simply feeding Garmin and Oura data into a language model and hoping for a sensible answer, it applies rules about where measurements come from, which sensors are reliable for what, and how much confidence the AI should place in the results.

I wanted to see whether it could help me plan a race.

I asked Codex to analyse my recent training through MetricBraid and suggest a realistic 10K strategy. It estimated around 57 minutes, with a working range of 56–59 minutes, and proposed targeting 56:45.

Strava predicted 54:50 the day before the race.

I finished in 55:47, improving my PB by 1 minute 27 seconds. The course was considerably hillier than I'd expected, and I was still recovering from a flu-like illness.

Naturally, I wanted to write about how well my system had performed.

Then I checked the numbers.

Strava was closer. Comparing it with my pacing target produces a one-second difference, but a target and a prediction aren't quite the same thing.

The predictions were also captured on different dates, so this wasn't a controlled comparison.

Still, the experiment had produced a useful estimate. And I was more interested in understanding how it got there than trying to claim a victory over Strava.

What actually happens when I ask MetricBraid a question?

The first thing to clarify is that MetricBraid isn't itself a language model or a race prediction engine.

In my setup, I use Codex as the agent. It reads MetricBraid's instructions and accesses Garmin and Oura through MCP, which provides a standard way for AI applications to interact with external tools and data.

When I ask something like "Based on my recent training, what should I aim for in Sunday's 10K?", the agent can retrieve relevant activities, performance estimates, sleep and recovery measurements.

But connecting an LLM to multiple sources of data introduces a problem: just because the agent can retrieve a number doesn't mean that number is trustworthy, or even that it represents a distinct observation.

That's what MetricBraid is designed to address.

Its rules guide the agent through several decisions before it uses an observation in its analysis.

First, which source should govern each measurement?

This isn't simply a question of whether Garmin or Oura is better.

MetricBraid routes observations according to measurement capability rather than brand. A deliberately recorded run is different from passive activity tracking. And even within a single workout, the best source can depend on what you're measuring.

For example, my Garmin watch might record a run's GPS distance and pace, while an external heart-rate monitor measures my heart rate. Garmin stores the activity, but that doesn't mean its wrist sensor produced every measurement.

MetricBraid distinguishes the recording device from the sensor behind each signal.

Second, are two records describing the same event?

If both Garmin and Oura contain records of the same run, I haven't suddenly completed two workouts.

MetricBraid uses deduplication rules to identify overlapping records and preserve the relevant measurements without counting the activity twice.

It also avoids a tempting shortcut: averaging conflicting numbers. If two sensors disagree, taking the middle value doesn't necessarily make the result more accurate. Sometimes one source is more appropriate; sometimes the disagreement needs to remain unresolved.

Third, how confident should I be in the measurement?

This is probably the distinction I'm most interested in.

MetricBraid separates routing confidence from measurement confidence.

Routing confidence concerns whether the right source has been selected. Measurement confidence concerns how reliable the measurement itself is.

I might be completely confident that Garmin is the source of a particular calorie estimate, while having much less confidence in the accuracy of that estimate.

Those are two different things.

The framework uses structural rules and published validation research to inform these decisions. Its evidence library covers general sensor limitations as well as findings specific to particular devices, with attention to what each study actually supports.

A result validated on one device generation shouldn't automatically be applied to another. And an unvalidated measurement isn't necessarily inaccurate; it means there isn't sufficient applicable evidence to establish its accuracy.

I've written more about the research and design decisions in Teaching an AI when not to make a claim.

Finally, MetricBraid requires provenance: a record of where the observation came from, what captured it, why it was selected, what evidence supports it and what uncertainty remains.

The framework includes a schema for representing these routed observations. In principle, that makes it possible to trace a claim in the final answer back to the measurements used to support it.

It doesn't guarantee that the LLM will reason correctly. But it gives me a much better basis for checking what the model is doing.

So how did it calculate my predicted time?

This is where it's important to distinguish the framework from the model's judgement.

MetricBraid doesn't currently contain a trained race prediction model. There's no fitted equation combining sleep, HRV, training load and threshold pace into a finish time.

Instead, the LLM evaluates my recent training and performance data, guided by MetricBraid's rules about evidence quality and interpretation.

For this race, the analysis considered several observations:

• My July 10K chip time of 58:15.
• My September half marathon, approximately 2:08 according to my watch.
• Recent longer runs, providing context about endurance.
• Garmin's estimated threshold pace of roughly 5:36/km.
• Garmin's much more optimistic 48:18 prediction.

The recent performances gave the agent a reasonable basis to expect a modest improvement. They provided much less support for an improvement of nearly nine minutes.

The analysis settled on approximately 57 minutes, then suggested a more ambitious pacing target of 56:45.

That target translates to an average pace of 5:40.5/km.

The arithmetic is simple:

56 minutes 45 seconds ÷ 10 km = 5 minutes 40.5 seconds per kilometre.

The harder part is choosing 56:45 in the first place.

That wasn't the output of a validated statistical model. It was the LLM's judgement, informed by the performance evidence it had retrieved.

I can inspect the inputs and the reasoning it provided. I can't claim the estimate is statistically calibrated, or that another runner with comparable data would receive an equally accurate prediction.

The 56–59-minute working range was a coaching estimate, not a calculated confidence interval.

It's a meaningful limitation, but one I'm comfortable being explicit about. MetricBraid is currently intended to improve how the agent handles evidence, not to replace specialised forecasting models.

Then I told it I was still ill

The original estimate hadn't accounted for something fairly important: I was still recovering from a flu-like illness.

When I mentioned that I wasn't fully recovered, the analysis changed its recommendation. Rather than encouraging me to chase the PB, it advised me to skip the race.

I ran anyway.

What's interesting is that my wearable data had been rather encouraging.

Oura gave me a race-morning readiness score of 82. Garmin's morning training-readiness score, which synced later, was 98.

They're different proprietary scores calculated in different ways, so I wouldn't treat them as directly comparable. But both suggested favourable readiness despite how I felt.

Neither score could establish that I was fully recovered.

And that's where the limits of wearable data become particularly obvious. A device can accurately report the signals available to it while missing something relevant to the decision.

When I supplied new information about my symptoms, the agent changed its recommendation.

That was arguably a more important test of the framework's intended behaviour than whether it had predicted my finish time within a minute.

Of course, running a PB doesn't mean the advice to skip was wrong. It only tells me what happened after I decided not to follow it.

What the race data revealed afterwards

Wembley was much hillier than I'd anticipated.

Garmin recorded approximately 109 metres of ascent, compared with 36 metres at my previous PB race.

The early hills were hard, and some of the later climbs felt particularly nasty. I tried to recover time on the downhills.

When I looked at the lap data afterwards, my slowest GPS kilometre coincided with a substantial net climb. Faster kilometres followed, suggesting the slowdown was related to the terrain rather than the beginning of a sustained fade.

But the pre-race analysis hadn't verified a course elevation profile.

I can't give MetricBraid credit for anticipating something it didn't anticipate.

Nor can I subtract an arbitrary amount of time to declare what I would have run on a flat course.

What I found more useful was comparing the pacing with my previous PB race.

I started slightly slower this time, but sustained my pace considerably better.

That's a much more concrete observation than speculating about a hypothetical flat-course finish time.

It's also the kind of comparison I want MetricBraid to support: bringing together historical performances, identifying meaningful changes and making the underlying evidence available for inspection.

What worked, and what didn't

I think the experiment was encouraging, but it exposed some obvious gaps.

The estimate was realistic, and the reasoning behind it was inspectable. The agent didn't simply accept Garmin's optimistic prediction, and it revised its recommendation when I supplied new information.

But it also initially used my July 10K result before I pointed it towards my older PB. Its working range missed my actual finish by 13 seconds. It didn't verify the course elevation, and Strava's prediction was closer.

None of those issues disappeared just because I'd connected the relevant data sources and written rules for handling them.

MetricBraid can help decide which measurements are appropriate for an analysis, but the agent still needs to retrieve the right records, interpret them correctly and make reasonable judgements.

Those are separate things to evaluate.

For the next race, I'd like to capture all predictions on the same day, include course elevation and conditions before the analysis, and define how I'm going to assess the estimates before seeing the result.

I'd also like to understand whether changes to MetricBraid's rules actually improve the analysis over repeated tests. A single successful estimate can't establish that.

The bigger lesson for me is that having access to more data isn't the same as having better evidence, and having better evidence isn't the same as making a better prediction.

MetricBraid is my attempt to work on that first problem, so that an AI has a more defensible starting point for the second.

For this race, it gave me an estimate I could inspect, a strategy that was broadly realistic, and a recommendation that changed when the information changed.

I ignored part of that recommendation and got a PB.

I'm pleased with the result. But for MetricBraid, I'd rather keep collecting examples of what it got right, what it missed and whether the rules made a difference.

That's considerably more useful than declaring it the winner after one race.

More writing on behaviour, product and AI →