Start Updated 2026-08-22 View as Markdown

Concepts

The terms below appear throughout the documentation, the product and the tool descriptions. Several of them mean something specific here that they do not mean generally.

Ledger

The daily tracking table. One row per date, one column per tracked thing. Called a ledger rather than a log because the framing is confirmation — you are affirming what you did against what you committed to, not journaling.

Metric

A single tracked quantity, identified by a canonical id such as whoopHrv or pushUps. Every metric is declared once in the metric registry, which is the shared source of truth for the tracking table, the API, the correlation engine and the AI tools. The metric reference is generated directly from it.

A metric has a value type (binary, number, select, time, text, date, or list), an optional unit, a set of aliases so hrv and push-ups resolve correctly, and — if it participates in analysis — a domain, a role and a purpose.

Derived metric

A metric computed from other fields rather than stored. _exercise is true when a real workout is logged or any reps were done. _sleepHours is the sum of the WHOOP sleep stages. _healthyEating grades the day's logged meals. They have no column in the table but are first-class for analysis. Derived ids are prefixed with an underscore.

Purpose

What a metric is for, which is separate from whether it can be analysed. Three values:

  • analytical — a real signal, and the default. Almost every metric is this.
  • display_only — tracked for your benefit rather than as a modelling input. WHOOP's own weight reading is the current example: it duplicates the weight column you maintain by hand, so it is worth showing and not worth correlating.
  • retired — kept so history stays readable, no longer tracked going forward.

This exists to answer one question honestly: when a metric has no correlations, is that because nothing was found, or because it was never meant to be modelled? Without the distinction both look identical, and "no relationship detected" is a much stronger claim than "never tested". list_metrics returns the purpose for exactly this reason.

Purpose is independent of the discovery scan. A metric can be analytical and still sit outside the nightly scan — see the metric reference for why the two catalogs differ in size.

Behavior and outcome

Every metric in the analytical catalog is tagged as one or the other, or both. A behavior is something you do — vitamins, reading, training time, sleep consistency. An outcome is something that happens to you — recovery, HRV, weight, resting heart rate.

The distinction drives correlation direction. "Does X affect Y" only makes sense when X is a behavior, and the engine will not present an outcome-to-outcome association as though one caused the other.

Custom column

A metric you define yourself. It gets an id, a label and a description. The description matters more than people expect: it is what the coach reads to understand what the column means, and it is what fuzzy matching searches when you ask about "alcohol" and the column is called "Dry January".

Check-in frequency

How often you sit down and confirm. Set it to daily and each row is a day, navigated month by month. Set it to weekly and each row is a week, navigated by quarter. Set it to monthly and each row is a month, navigated by year.

This changes the row granularity of the whole ledger, not the display density of one column, and it also sets the period the AI summarizes over.

Data-quality gating

Some values arrive with caveats attached, and the platform reads the caveats rather than only the numbers.

A WHOOP recovery score produced during the calibration period is not a measurement, and sleep stages from a night the strap spent an hour off your wrist are a partial record, not a short night. Both are suppressed for analysis while remaining visible in the table exactly as WHOOP reported them. Correlating either as if it were clean data manufactures relationships that are not there.

Feature store

A precomputed daily matrix: every metric normalized to a number, plus its z-score against a trailing 30-day baseline. It is what the correlation engine reads and what get_daily_features returns. Keeping it separate from the raw ledger means analysis never has to re-derive the same normalization on every query.

Correlation graph

Relationships between metrics stored as edges rather than prose. Each edge carries the correlation coefficient, the partial correlation after controlling for confounders, the lag, the p-value, the sample size, a confidence tier and its provenance.

Because it is a graph, it can be traversed: depth 1 gives the edges touching a metric, depth 2 gives one-hop chains through an intermediate — sleep to recovery to next-day strain capacity — which is how a mechanistic story gets assembled instead of asserted.

Confidence tier

How much weight an edge deserves. Every edge in the graph carries exactly one of four tiers:

Tier What it survived
robust Multiple-testing correction, confounder controls, and a split-half stability check, on enough days for that check to mean something
probable Ordinary significance and a real partial correlation, but not the full robust bar
hypothesis Consistent with the data, and nothing more. A relationship computed on demand for a pair nobody precomputed is always this, no matter how strong the coefficient looks
confounded The raw correlation looked real and then collapsed once time trend and sleep were controlled for. The association exists; the direct effect does not

confounded is the tier most worth understanding, because it is a finding rather than a failure. It says the two metrics do move together and the reason is something else — usually that both drifted over the same months.

Prior status

Not to be confused with a tier. A status is the verdict on a relationship the platform already expected to find, from known physiology: sleep should drive recovery, strain should suppress it. Confirmed means it held up in your data. Contradicted means it did not, which is often the more useful result, because it is the one no textbook could have told you.

A tier grades the statistical confidence of an edge the engine discovered. A status grades a prediction the engine went looking for. Filtering the graph for confirmed finds nothing, because confirmed was never a tier.

Provenance envelope

A { asOf, n, confidence, tier, source } block attached to quantitative tool results. It exists so a model weighing two numbers can tell that one rests on 90 days and the other on six, rather than treating every figure as equally solid.

Learnings

Insights the coach extracts from conversation and keeps. "Travels for work most of March." "Responds badly to being told to push harder." "Shoulder flares up on overhead press."

Learnings are categorized, scored for confidence, embedded for semantic retrieval, and reinforced when you mention them again. They also decay — an insight that stops being mentioned loses weight and is eventually pruned — and they consolidate, so five near-identical observations merge into one rather than crowding out everything else. There is a hard cap per user, which is what keeps memory from becoming noise.

Mission Statement

A structured declaration of intent: one goal, three commitments. Distinct from the profile, which describes your situation. The platform tracks progress against the goal and analyzes whether the three commitments are actually the behaviours moving it — which is a question it can answer, because it has the correlation graph.

Context Engine

The layer that assembles what the coach knows before it answers. Temporal awareness (what day and time it is for you), momentum (whether you are building or slipping), lifecycle stage (whether you are new enough that the honest answer is "not enough data yet"), and which parts of your profile are still blank.

Smart payload

The mechanism that decides how much to spend on a question. It classifies the query, then picks the model, the reasoning effort and the amount of history to load. "What did I weigh Tuesday" and "why has my recovery been declining since April" should not cost the same or read the same amount of your record.

Summaries

Narrative rollups written ahead of time by the summarization pipeline: weekly, monthly, quarterly and yearly reviews, lab interpretations, mission analysis, personal records, and the cross-module correlation narrative. Retrieval searches these alongside individual days, so a question about a period finds the period rather than reassembling it from ninety rows.

Embedding and hybrid retrieval

Every day and every summary is embedded as a vector. A question runs both vector search and full-text search, the two result sets are fused, and the survivors are reranked before anything reaches the model. Vector search alone misses exact terms; text search alone misses paraphrase. Running both and fusing them is what makes "that week I was sick in February" findable.