[Bug] Coach treats historical-only metrics as absent and loses the active metric on follow-up

[lutzkind]

Summary

The Coach treats a metric as completely absent when all of its measurements fall outside the Coach's retrieval window, even when HealthLog contains valid historical data for that metric. A vague follow-up in the same conversation can then lose the active metric and pivot to unrelated recent health data.

This was confirmed with 1,597 imported FreeStyle Libre blood-glucose readings from 3–17 April 2024 on HealthLog v1.32.39 and HealthLog-iOS 0.17.0.

Environment

• Server: HealthLog v1.32.39
• Server build: 417288d3f572
• Client: HealthLog-iOS 0.17.0 (TestFlight)
• Deployment: self-hosted
• Measurement type: BLOOD_GLUCOSE
• Historical range: 2024-04-03 through 2024-04-17
• Reading count: 1,597

The CSV import itself is now fixed and the glucose readings are visible in HealthLog. This report is about Coach retrieval and conversation continuity, not CSV persistence.

Reproduction

1. Import historical glucose data older than one year.
2. Confirm that the readings exist in HealthLog and are visible on the glucose history/Insights surface.
3. Open a Coach conversation and ask about the past glucose numbers.
4. Observe a response such as:

I don't have any glucose data available right now.

5. In the same conversation, reply with a vague follow-up such as:

Check again

6. Observe that the Coach responds with unrelated recent metrics such as sleep, readiness and resting pulse instead of remaining focused on glucose.

Actual behavior

• Historical glucose is presented as if no glucose data exists at all.
• The Coach asks the user to paste values that are already stored in HealthLog.
• allTime does not provide all-time retrieval.
• A same-session follow-up can abandon the active glucose topic and pivot to unrelated recent metrics.
• The response does not explain that glucose exists but lies outside the current retrieval window.

Expected behavior

When the user explicitly asks about historical glucose, the Coach should either retrieve the requested historical period or clearly state that the data exists but is outside the current retrieval scope.

A follow-up such as Check again, what about those numbers?, or how were they? should preserve the active metric from the conversation and must not pivot to unrelated domains unless the user asks for a general overview.

A suitable fallback would be:

I rechecked your glucose data specifically. HealthLog contains readings from 3–17 April 2024, but my current retrieval window cannot access that period. I should not describe this as having no glucose data.

Confirmed code path

allTime is capped at 365 days

src/lib/ai/coach/snapshot-series.ts:

case "allTime":
  return 365;

The database query in src/lib/ai/coach/snapshot.ts then applies:

measuredAt: { gte: cutoff }

Measurements older than the calculated cutoff are excluded before the glucose block is built.

Historical-only glucose becomes structurally absent

src/lib/ai/coach/snapshot-blocks/glucose-block.ts filters glucose rows against glucoseCutoff. When none remain, the glucose section is omitted.

src/lib/ai/coach/tools/inventory.ts determines availability with:

present: has("glucose")

The inventory therefore reports glucose as absent even though older glucose measurements exist in the database.

src/lib/ai/coach/tools/executor.ts then returns:

{"present":false,"reason":"no_data"}

This conflates:

• no glucose data exists;
• glucose exists, but none lies inside the selected window.

Tool-mode prompt encourages an unrelated pivot

src/lib/ai/coach/tools/system-addendum.ts instructs the model:

When a tool returns { present: false } or an empty result, say plainly that you have no data for that metric and pivot.

That instruction encourages the Coach to switch to unrelated recent metrics instead of preserving the active topic and explaining the retrieval limitation.

Conversation history is intended to be present

The server loads prior messages by conversationId and includes them through buildCoachTurnContext() in:

• src/app/api/insights/chat/route.ts
• src/lib/ai/coach/chat-request-builder.ts

Therefore this does not appear to be simple conversation persistence loss. The failure is the interaction between historical availability, ambiguous follow-up resolution and the mandatory pivot instruction.

Proposed general fix

Historical availability and retrieval

• Distinguish no_data from no_data_in_window.
• Add all-time availability metadata per metric, including earliest date, latest date and total count.
• Support bounded historical retrieval, for example:

{
  "from": "2024-04-03",
  "to": "2024-04-17"
}

• Keep high-frequency reads bounded by aggregating to daily or weekly values before returning them to the model.
• Preserve the fixed trailing-30-day glucose clinical panel for current TIR/GMI/CV calculations.
• Treat historical summaries as historical context, not current clinical status.
• Either make allTime genuinely use historical rollups or rename its present 365-day behavior to lastYear.

Conversation continuity

• Resolve short follow-ups against the most recent active metric/domain in the same conversation.
• When the active metric has no_data_in_window, remain on that metric and explain the limitation.
• Do not pivot to unrelated domains unless the user requests a general overview or explicitly accepts alternatives.
• Consider returning a structured reason and available date bounds to the model, for example:

{
  "present": false,
  "reason": "no_data_in_window",
  "available": {
    "count": 1597,
    "earliest": "2024-04-03",
    "latest": "2024-04-17"
  }
}

Regression tests

1. Historical-only glucose older than 365 days is distinguished from truly absent glucose.
2. get_glucose_panel returns no_data_in_window plus availability bounds when appropriate.
3. A bounded April 2024 request returns aggregated historical glucose values.
4. The trailing-30-day clinical panel remains empty for old-only data and is not presented as current.
5. Conversation sequence:
   • user asks about old glucose;
   • Coach explains historical availability/retrieval status;
   • user says Check again;
   • Coach remains focused on glucose.
6. what about those numbers? and how were they? preserve the prior metric.
7. The Coach does not cite unrelated readiness, sleep or pulse figures after a glucose-specific follow-up.
8. A user with no glucose anywhere still receives the true no_data behavior.
9. Prompt/token budgets remain bounded for dense CGM histories.

Scope

This issue is separate from the resolved CSV-import defect in #640. The rows now import successfully; the remaining failure is the Coach's historical retrieval and follow-up routing behavior.

[MBombeck]

Confirmed on current main, @lutzkind, and both halves hold.

allTime returns 365, and the comment above it says so plainly: the same ceiling as lastYear sitting directly above, capped to keep the prompt budget bounded. So the name promises something the function was never going to do. Your April 2024 readings are outside it by about three months.

The second half is the one that makes it feel like the app is denying its own data. The tool returns reason: "no_data" for two entirely different situations — the metric was never recorded, and the metric exists but falls outside the window I looked at. Four call sites, one reason. The Coach cannot tell those apart because nothing downstream of that value can, so it says the honest-sounding thing for the wrong case and then, being told there is nothing there, moves on to something it can talk about. That is the pivot you saw.

So the fix is one discriminant at the tool boundary rather than a wider window. "I have 1,597 glucose readings but they are all from April 2024, outside the range I normally look at, do you want me to look there" is a completely different sentence from "I have no glucose data", and only one of them is true.

Two things I want to be straight about. Raising the cap outright is not the answer — the ceiling exists for a real reason and removing it would put multi-year histories into a prompt budget that cannot hold them. And a triage of the whole issue list this morning found the pivot instruction lives in two places, not one, so fixing the obvious one would have left the behaviour intact and looked like it worked.

Your three reports this week — this one, the health score, and the highlights request — turn out to share a root. The personalisation layer personalises the data and not the yardstick: the window, the score's targets, and the signal set are all fixed while the record they measure is not. You found three symptoms of it from outside without being able to see that. That is the more valuable observation and it is shaping what comes after the reliability work.

I will report back here when it ships. Leaving this open until you have had a chance to confirm.

[MBombeck]

Live in v1.33.0, @lutzkind.

The Coach can now tell "you never recorded this" apart from "you recorded it, but outside the range I looked at".

The cause was a single reason code covering both situations. Someone with 1,597 imported glucose readings from April 2024 was told there was no glucose data at all, and then the Coach changed the subject, because the instruction to move on fired on the same code. So the retrieval window and the topic change were one defect wearing two faces.

It now says what is actually true and offers to look further back.

Please try the question that produced the wrong answer for you. If it still stops short, tell me what it said and I will look at where the window ends.