The morning scramble

Update, October 30, 2026: Readiness grew into Lineup Card, a one-page morning card built from force plate, GPS and wellness data. This article describes Readiness as it was when published.

Before a session, the work can start in several places. A force-plate export. A wellness sheet. An HRV report. The previous day’s training load.

Someone has to reconcile the athletes, check what arrived, and give the staff a useful read before training starts. Collecting the data is only part of the job. Preparing it for a conversation takes work too.

That is the problem behind Readiness: a working, synthetic demonstration of a morning review brief.

Start with the workflow

A team may already have an athlete-management system that handles this well. Check that first.

Where a gap remains, I want to make the last step easier: a short message that shows which measurements changed, what is missing, and which athlete needs a closer look. The source readings and calculation should be easy to inspect when someone asks why.

The brief starts the discussion. The staff owns the decision.

What the demo does today

The Readiness demo runs on invented athletes and generated readings. Its Python engine compares wellness, HRV, and jump measurements with each athlete’s own baseline. Training load travels alongside the results as context.

You can explore two examples: a morning with changes to review, and the same squad after the feeds stop arriving. Open an athlete to see the readings, baseline, and rule behind the status. Download the sample brief to see the output a colleague would receive.

These are fixed examples produced by the engine, not a live team feed. Vendor adapters, team access controls, and scheduled delivery need separate implementation and testing.

The calculation has to be checkable

The engine computes the baselines, z-scores, and review statuses. It uses unrounded values for threshold decisions and rounds the values only for display.

The current rules use a twenty-eight-day baseline with at least ten prior values and measurable variation. HRV uses a seven-day rolling mean. A single response domain at or below z −2.0 triggers review, as do two domains at or below z −1.2. A smaller single-domain change or a qualifying decline trend can trigger monitoring.

Those are explicit prototype rules. They are not validated clinical cutoffs, and a team would need to evaluate them against its measurement protocols and intended use.

Load does not set the status. It also does not prove what caused a change.

Missing data must stay visible

A blank reading is not a reassuring result.

An athlete should stay in the brief when data is stale or there is not enough history to build a baseline. Partial coverage should remain visible even when another domain triggers review.

The same principle applies before the calculation starts. Invalid numbers, conflicting duplicates, and ambiguous identity mappings should stop the pipeline with a clear error, rather than silently change who or what gets assessed.

“Within range” means all three response domains are assessable and none triggered the configured rules. It does not mean fully recovered, safe to train, or medically cleared.

AI is optional, and its role is small

The runner uses local templates by default. It works without a model key.

When explicitly enabled, the model selects from wording that code has already authored. Unrecognized output falls back to a local template. That is a narrower, more checkable role than asking a model to freely interpret measurements and hoping a number check catches every mistake.

A correct number can still sit inside an incorrect claim. The wording needs a boundary too.

Tokens are not anonymity

Names are replaced with tokens before optional model use. Code reconnects the names locally afterward.

That is pseudonymization. It does not make performance data anonymous or remove the need for an approved data-handling process. A real deployment still needs identity and access controls, retention rules, appropriate agreements, and review of any model provider.

The public demo accepts no athlete uploads. It is a place to evaluate the workflow before discussing real data.

The next useful test

I have not measured time savings or athlete outcomes in a team pilot. The next step is a small workflow evaluation with a staff member who owns the morning review.

Start with one input format and one recipient. Agree what a useful brief contains. Check preparation time, discrepancies against the source data and configured rules, staff relevance, visible data gaps, and whether someone follows up.

If the existing platform already solves that problem, use it. If a small missing step keeps getting in the way, that is the part worth building.

See Lineup Card, or discuss your morning workflow.