App developers
Read “Orientation”, “Method families”, and “Evaluation” first. You need to know what can become a product route and what still belongs mostly to research.
Field Guide
This page builds the shared minimum foundation: what menstrual prediction is actually trying to do, how those questions become AI tasks, which signals are used, and why evaluation design can completely change the conclusion.
Read “Orientation”, “Method families”, and “Evaluation” first. You need to know what can become a product route and what still belongs mostly to research.
Read “Cycle basics”, “How medical questions become AI tasks”, and “Evaluation” first. The main job is to separate biological variability from modelling weakness.
Read “How medical questions become AI tasks”, “Method families”, and “Wearable signals” first. The main job is to connect labels, features, and outputs.
If you only need orientation, the glossary can be skimmed. Get the task framing, route comparison, and evaluation logic first.
The field mixes several related but non-identical tasks: predicting the next bleed, estimating ovulation timing, identifying the fertile window, and classifying cycle phase. These tasks share biology, but they do not share identical labels, metrics, or deployment constraints.
| Target | Typical label source | Common output | Main difficulty |
|---|---|---|---|
| Next menstruation onset | Self-tracked bleeding logs | Next date or days until onset | Strongly affected by follicular variability and logging quality |
| Ovulation day | Urinary LH, ultrasound, progesterone, or proxy rules | Single day estimate or error window | Operational definitions vary substantially across papers |
| Fertile window | Derived from ovulation or fertility-awareness rules | Binary daily probability or a start/end window | Highly definition-dependent and often clinically sensitive |
| Cycle phase | Calendar rules, hormone assays, or latent-state labels | Daily phase class | Phase boundaries may be operational rather than direct biological truth |
Clinical guidance and large observational datasets both reject the idea of a universally fixed 28-day cycle. The more important point is that variation is structured rather than random: ovulation is short, the follicular phase often drives most timing variability, and the luteal phase is usually more stable [1] [2].
| Phase | What happens | Relative stability | Why modellers care |
|---|---|---|---|
| Menstrual phase | Bleeding usually marks day 1 | Observable, though self-tracking is noisy | Often the easiest large-scale event to collect |
| Follicular phase | Pre-ovulatory follicle development and hormonal preparation | Usually most variable | A large share of onset error comes from here |
| Ovulation | Release of the oocyte, often anchored with LH tests | Short and hard to observe directly | Key temporal anchor for countdown-style tasks |
| Luteal phase | Post-ovulatory progesterone-dominant phase | Relatively more stable | Helps explain why menses prediction is often easier after ovulation |
Product logic cannot be built around a fixed cycle template without distorting risk framing, explanations, and user expectations.
Some error is biology, not model weakness. Baselines and subgroup analysis need to reflect that.
When AI papers talk about “error”, part of that number may describe real physiological variability rather than a pathology or a purely technical failure.
In medical language, people ask about menstruation timing, ovulation, the fertile window, or phase. In computational language, those become regression, event detection, sequence labelling, or window classification tasks.
When is the next bleed? When is ovulation? Which days are likely fertile? Which phase is this cycle in now?
Predict time-to-event, estimate a key event day, output a high-probability window, or classify daily state.
Menses onset often comes from self-report; ovulation often comes from urinary LH or proxy rules; phase labels may come from latent-state models.
The same clinical idea can be operationalized as very different ML tasks, so paper titles alone are not enough to judge comparability.
Predict “days until next bleed” or the next event date. Straightforward, but sensitive to label noise and individual variation.
Estimate whether a day is close to ovulation. Often paired with window metrics, but highly dependent on label definition.
Assign a state to each day. Good for expressing cycle dynamics, but phase boundaries are often operational rather than biological truth.
Frame the task as a high-likelihood interval. Useful for fertile-window tasks, but only if the derivation of that window is explicit.
Whether the product shows a date, a probability, or a window is part of the task definition, not only a UI choice.
The task framing must match label availability and deployment-time information, otherwise future leakage will creep in.
A model output is not automatically a clinical truth; it is often the best estimate of an operational label.
| Method family | Typical inputs | Best used for | Main limitation |
|---|---|---|---|
| Rule-based / calendar baselines | Past bleed dates, average cycle length | Transparent baselines and low-cost prototypes | Fragile for irregular cycles and cold start |
| Tabular models | Cycle statistics, symptoms, adherence features | Small-to-medium data and interpretable baselines | Limited temporal structure |
| RNN / LSTM / GRU | Daily or cycle-level sequences | Temporal dependence and multi-step prediction | Higher data demand and easier to misuse when labels are weak |
| Latent-state / generative models | Noisy longitudinal self-tracking data | Missingness, adherence, and hidden-state structure | Higher implementation and interpretation overhead |
Temperature, heart rate, HRV, sleep, and respiration are the most common passive signals in this field. They matter because they reveal cycle-related physiology, but they are not direct ground truth for ovulation or fertility.
| Signal | What it contributes | Common risk |
|---|---|---|
| Basal / skin temperature | Cross-phase thermal patterns | Different devices and body sites are not interchangeable |
| Resting / sleeping heart rate | Autonomic and metabolic shift information | Affected by activity, sleep, and vendor algorithms |
| HRV | Additional autonomic regulation signal | Large preprocessing and quality differences |
| Sleep / respiration / activity | Behavioral context and noise control | Can be mistaken for the main biological cause |
If the product uses wearables, it must express uncertainty instead of pretending the device directly “saw” ovulation.
Signal selection and preprocessing are as important as architecture choice, especially across devices and missingness patterns.
Wearable signals in these papers are best understood as proxy markers, not standardized clinical biomarkers.
In this field, a paper can look strong not only because the model is strong, but because the labels are looser, the cohort is easier, the split is weaker, or deployment-time information was silently leaked into offline evaluation.
| Evaluation issue | If done badly | Safer default |
|---|---|---|
| Random split vs subject-wise split | Patterns from the same person leak across train and test | Use subject-wise split when claiming generalization |
| Future information leakage | Offline performance looks unrealistically high | State exactly what is available at prediction time |
| Reporting only an average score | Failure in irregular groups stays hidden | Report subgroup performance and failure modes |
| Opaque label definition | Papers are not truly comparable | State rules such as LH onset, LH peak, or peak + 1 day |
Good-looking offline metrics do not guarantee reliable user experience. Deployment constraints belong in the experiment design from the start.
If split, label, and metric are unclear, the performance number itself has little comparison value.
To judge an AI paper, cohort definition, labels, and split strategy often matter before the model name does.
Many studies still treat irregular cycles as one coarse group instead of separating different types of irregularity.
We know wearables can help in some cases, but still need better answers to “for whom, when, and for which task”.
Especially for ovulation-related tasks, operational definition differences continue to block clean comparison and replication.
Many experiments still do not define the problem under realistic prediction-time constraints.
Long cycles, highly variable cycles, and shifted-but-stable cycles should not be treated as one modelling target.
The key comparison is not only average performance, but who benefits, for which task, and under which constraints.
Ovulation and fertile-window labels still vary widely across studies, which weakens reproducibility and fair comparison.
Studies should clearly restrict inputs to information available at prediction time, not future observations.
Personalization needs explicit design choices about trigger, representation, and subgroup fit, not only extra model complexity.
Report subgroup outcomes, label definitions, and deployment constraints together so results remain interpretable across disciplines.