Evaluate a 13-day luteal phase against measurement #56
Labels
No Label
P0
P1
P2
release-blocker
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: null/Privacy-Period-Tracker#56
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Filed rather than fixed, deliberately — see below.
What is true now.
FertilityEstimate.DEFAULT_LUTEAL_PHASE_DAYSis 14, the textbook convention, and every ovulation estimate is anchored to it (predicted period minus luteal phase). Large-scale studies of app-recorded cycles put the measured mean nearer 12.4 days with a spread of roughly 11-17, so 14 sits about a day and a half above the population mean. The constant is already named and overridable rather than buried in arithmetic, which is what makes this a one-value change if it is warranted.What to do. Evaluate 13 (or a history-derived value) with its own measurement before moving it: what changes on screen for a user with a stable cycle, what it does to the fertile window's placement, and whether the shift is defensible given the window already carries the forecast's uncertainty.
Why it is filed and not fixed. It moves what the fertility screen shows a user, which is a product change with its own evidence and its own QA, not a line inside a prediction-calibration change-set. Bundling it would mean a batch that tuned the engine also quietly moved everyone's ovulation date by a day.
Traps. §17 forbids implying a fixed day-14 rule is biologically exact — whatever value is chosen, the estimate stays a range and
MAX_USEFUL_UNCERTAINTY_DAYSstill declines rather than stretching. Do not change it without also updating the SCIENCE.md row that will record the current verdict.Verify: a decision recorded in docs/architecture/SCIENCE.md's luteal-phase row — either the constant changed with its evidence and FertilityEstimateTest updated, or the row states why 14 was kept.
Deferred, not fixed — recorded in docs/architecture/SCIENCE.md's luteal-phase row (
426f599), which states the verdict (needs a caveat: 14 sits above the measured mean of 12-13, per Bull 2019 and Lenton 1984), why it was not changed inside a calibration batch (it shifts what the fertility screen shows every user, a product decision with its own evidence and QA), and what protects the user meanwhile (the estimate is a window, and MAX_USEFUL_UNCERTAINTY_DAYS declines entirely when the forecast is too vague). Reopen when someone takes the measurement.