Insights: a steady 22 kg loss is reported as a 180-day plateau and as volatile

[ahmetabdullahgultekin]

The Insights screen can contradict itself: it reports a large, steady change at the top of the card and "no significant change" at the bottom of the same card, and it labels a perfectly smooth trend as volatile.

Reproducing it

No hardware needed — the project's own demo generator produces it:

About → Developer Tools → Scenario: Trend Progress, Time Range: Last 6 months → Generate Demo Data → Insights

What the card then shows, simultaneously:

Start / Now	100.21 kg → 78.10 kg (−22.11 kg)
Rate	−3.74 kg / month
Chips	short-term ↘ long-term ↘ volatile plateau 180 days
Summary	"No significant change for 180 days — your body may be adapting."

A 22 kg loss over six months is being described as a 180-day plateau.

Cause: both come from using the raw standard deviation on a trending series

1. Plateau — MeasurementInsightsUseCase.kt:178-193

val threshold = stdDev * 0.5f
for (i in dataPoints.indices.reversed().drop(1)) {
    if (abs(dataPoints[i + 1].second - dataPoints[i].second) > threshold) break
    plateauStartIndex = i
}

The step between two consecutive measurements is compared against half the standard deviation of the entire series. On a trending series those quantities have completely different scales:

series      181 points, 100.16 -> 78.05 kg
stdDev      6.42 kg
threshold   3.21 kg        (stdDev * 0.5)
largest consecutive step   0.22 kg
steps above threshold      0
=> loop never breaks, the whole series is reported as a plateau

The relationship is inverted: the stronger the trend, the larger the stdDev, the higher the threshold, and the longer the reported plateau. The cleanest weight-loss curve produces the longest "no change" message.

2. Volatility — MeasurementInsightsUseCase.kt:142-151

val stdDev    = stdDev(rawValues, mean)
val relStdDev = if (mean != 0f) stdDev / mean else 0f

On a trending series the raw stdDev measures the span of the trend, not variability around it:

relStdDev   6.42 / 89.15 = 7.20%
thresholds  STABLE < 1%, MODERATE < 3%
=> HIGH ("volatile"), for a visually smooth line

Any successful weight-loss run of more than ~3% of body weight is therefore labelled volatile — the users most likely to open Insights.

Suggested direction

Both need the trend removed before measuring spread:

• Plateau: derive the threshold from local step sizes (e.g. stdDev of consecutive differences) rather than from the spread of the whole series — or test the plateau window directly, i.e. "total change within the candidate window is below X".
• Volatility: measure residuals rather than raw values — stdDev of consecutive differences, or residuals from a linear fit.

A shared detrendedStdDev() helper would cover both.

I'd be glad to send a PR with a fix and unit tests in MeasurementInsightsUseCaseTest.kt — but this changes the behaviour of an algorithm you designed, so I'd rather ask first whether you want it, and in which direction.

Minor, same screen

The plateau chip truncates: it renders as 180 günlük durağ in Turkish (180 days plateau fits in English). Probably worth letting that chip wrap or shortening the string.

[ahmetabdullahgultekin]

Following up on my own report: the plateau/volatility defect is not isolated. The same root cause — measuring spread on a series without removing its trend — appears in five more places in this file. I verified each by reading the arithmetic and reproducing it numerically, and I'm listing only what I could demonstrate.

1. The weekday pattern is the trend, not a weekly habit — :398-399

val overallMean    = valuesByDay.values.flatten().average()
val deviationByDay = valuesByDay.mapValues { (_, vs) -> vs.average() - overallMean }

For a series falling d per day over whole weeks, weekday w (0 = the weekday the series starts on) has deviation exactly d·(3−w), independent of the number of weeks. Simulated at d = 0.1 kg/day:

span	deviation, day 0	deviation, day 6	spread
5 weeks (35 points)	+0.300	−0.300	0.600 kg
20 weeks (140 points)	+0.300	−0.300	0.600 kg
52 weeks (364 points)	+0.300	−0.300	0.600 kg

Ten times the data, identical artefact — it never averages out, and at 5 measurements per weekday it is stamped InsightConfidence.HIGH (:400-401). heaviestDay/lightestDay are then just "the weekday the user started on" and "six days later".

2. Anomaly detection switches itself off during weight loss — :490-493

mean and sd come from the trailing raw window, trend included. Same +1.5 kg one-off spike, two contexts:

series	window sd	expected (mean)	z	outcome
flat + noise	0.30	80.00	6.00	flagged
−0.3 kg/measurement	1.73	77.15	0.95	missed

The trend inflates sd and drags mean behind the current level, so the detector goes blind exactly while a user is actively changing. expectedValue = mean (:504) is also shown to the user, and is stale by the same amount.

3. Short-term trend compares a 30-day window against a 30-point window — :159-171

recentPoints is selected by date (:161-162), precedingPoints by count (:163-164). The comment says "preceding window of equal length"; it is equal cardinality. With 52 weekly weigh-ins followed by 30 daily ones, the "preceding" window spans 210 days against the recent 30 — so a perfectly flat last month can be reported as a downward trend.

4. "Best month" compares windows of different length — :195-208

monthDelta = pts.last() - pts.first() (:202), ranked by absolute value, never normalised by elapsed days:

• January: −1.0 kg over 2 days = −0.500 kg/day
• February: −2.5 kg over 27 days = −0.093 kg/day

February is reported as the best month, though January's rate was 5.4× faster. For equal rates, the month with the widest endpoint spacing always wins.

Two smaller issues in the same block: byMonth.size >= 2 (:200) means a user whose data sits in one calendar month gets no best period at all, and pts.size >= 2 (:201) silently drops a month holding a single weigh-in even if it was the largest real change.

5. ratePerMonth has no minimum-span guard — :173-176

Ten weigh-ins across 3 days with ordinary water fluctuation (−1.5 kg) yields −15.2 kg/month, labelled "on average", and confidence is HIGH because it depends only on point count (:132), never on elapsed days.

6. plateauStartDate can be non-null while plateauDays is null — :189-192

days is takeIf { it > 0 }, but the date is returned unconditionally. Two weigh-ins on the same calendar day at the tail produce plateauDays = null, plateauStartDate = <date>. The chip and the summary are correctly suppressed (InsightsScreen.kt:428, :439), but the tinted plateau band is still painted on the sparkline (InsightsScreen.kt:567-576). The two fields should be nulled together.

---

These are all one family, and a shared "remove the trend before measuring spread" helper would address 1, 2 and the original volatility issue together; 3, 4, 5 and 6 are independent and smaller.

I'd be happy to send a PR with fixes and regression tests — MeasurementInsightsUseCaseTest.kt currently has 4 tests against a single rising 6-point fixture, so none of the fields above are covered and there's room to add without disturbing anything. But this is your algorithm design, so tell me which of these you consider defects and which are intentional, and I'll scope a PR to that.

[oliexdev]

Thanks — good report, and thanks for asking first.

Your analysis of both causes is correct. Please go ahead with the PR.

One thing I'd ask: keep the change minimal. Only the two computations and the guard below — no refactoring of the surrounding code, no renaming, no reformatting of untouched lines. That keeps it reviewable and easy to reason about against the existing behaviour.

Concretely, what I'd like to see:

1. Plateau (MeasurementInsightsUseCase.kt:178-193) — I'd prefer the window-based criterion over the step-based one: "total change within the candidate window stays below X". That is what users actually mean by a plateau, and unlike a step-size threshold it doesn't get fooled by slow drift where every single step stays under the limit.
2. Volatility (:142-151) — residuals instead of raw values, as you suggested.
3. InsightsScreen.kt:438 — don't show the plateau summary when longTermTrend != STABLE. Cheap safeguard against the card contradicting itself, independent of the statistics.