When your period app and sleep tracker disagree, and writing data between apps doesn't fix it
A common complaint shows up in wearable and cycle-tracking communities: "my flow app always seems to be way off in terms of night waking compared to my Oura ring." Same night, same person, two different numbers. It reads like a bug. It usually isn't. Two apps that each compute sleep from a different signal path will produce conflicting data across tracking apps by design, and no amount of copying one app's output into the other resolves that. This is a structural fact about how tracking apps are built, and it points at a different fix than most people try first.
Why a flow app and a ring can show different night-waking numbers for the same night
A ring or wearable and a cycle-tracking app usually disagree on night waking because they aren't measuring the same thing: the wearable infers sleep and wake directly from motion and heart-rate-variability signals on your body, while a period app's sleep number is often imported, estimated, or manually entered through a different path entirely.
A device worn on the body, like a ring, collects raw signal continuously through the night: small movements, heart rate variability, sometimes skin temperature. Its sleep-staging algorithm turns that raw signal into a sequence of stages and wake events, and every manufacturer's algorithm makes its own tradeoffs about how much movement counts as a wake event, how it smooths noise, and where it draws the line between light sleep and being briefly awake.
A period or cycle app that also displays a sleep number is rarely doing that work itself. It's more commonly pulling a summary from a phone's health platform, importing an export from the wearable, or in some cases relying on what the user typed in by hand. Each of those paths has its own rounding, its own definition of "night waking," and its own lag between when the wearable finalizes a reading and when the cycle app receives it.
So two apps end up applying two different algorithms to two overlapping but non-identical views of the same night, and they land on two different numbers. Neither app is necessarily wrong. They're answering slightly different questions and labeling both answers "night waking."
Why writing one app's data into another doesn't resolve the mismatch
Manually moving a number from one app into another doesn't resolve a disagreement between them, because you're copying an already-processed output, not the underlying signal, and the receiving app still re-labels or re-derives that number under its own logic the next time it displays it.
This is the instinct behind a question that comes up often: "has anyone found an app that allows writing Oura data to Garmin Connect?" The goal makes sense. If two apps agree, the confusion goes away. But a sleep score or a night-waking count is the end product of an algorithm, not a raw measurement. When you type that end product into a second app, or route it through an export, you're handing that app a number it didn't compute and doesn't fully understand the provenance of. If the second app has its own display logic, rounding, or re-classification step, it will still bend that number toward its own conventions.
There's a second problem underneath the first: once you've manually copied a value, you now have two copies of "one" data point living in two places, and they diverge the moment either source updates. In principle, a wearable could revise a night's classification after the fact, for instance adjusting a wake event once more data comes in, the kind of correction an algorithm makes as it reconciles the full night's signal. If that happens, the original app reflects the correction. The copy you typed into the other app does not, because nothing tells it the number it's holding has gone stale. Now the two apps don't just disagree for a structural reason, they disagree because one of them may be looking at outdated data nobody remembered to fix.
This is also why the broader question people ask, whether to log everything in one wearable app, in a specialty cycle app, or just let a platform like Apple Health auto-aggregate everything, doesn't have a clean answer as long as each option leaves data split across multiple apps that each compute their own version of the truth. Auto-aggregation moves the copying problem into the background, but it doesn't remove it: the platform is still reconciling numbers that were generated by different algorithms in the first place.
What one shared log removes instead of patching around
A single shared log removes the need to decide which app's number is correct, because there's only one record of the night being interpreted, not two separately-computed scores that have to be reconciled or kept in sync by hand. That's a different kind of fix than better copying: it removes the second interpretation instead of trying to correct it after the fact.
The problem described above isn't really about accuracy. It's about two systems that each only see part of the picture, each drawing their own conclusion, and a person stuck in the middle trying to make those conclusions match. Manually writing data between them treats the symptom. It doesn't touch the reason the symptom exists.
Trophos is built around the idea that sleep, cycle data, training, mood and everything else someone logs are facets of one underlying record, not outputs from separate apps that each compute their own version and hand you a number to reconcile. When there's one log instead of several, there's nothing to copy between apps and nothing to keep in sync by hand, because the disagreement that comes from two independent computations simply doesn't get created in the first place.
To be direct about what this does and doesn't claim: a shared log doesn't make sleep detection itself perfect, and it isn't a promise that every number will be exactly right. What it removes is the specific, structural problem in this piece: two apps independently computing two different answers about the same night and leaving you to sort out which one to trust.
Trophos is currently in closed beta for iOS and Android, so the only thing to do today is join the waitlist. There's no store link yet and no date to promise, just a place to log all of this in one system instead of several.