Community#

TideTracker's predictions get better when divers report back. That's not a marketing line — it's how the math works. The correction engine is designed around user observations, and without them, the app is only as good as NOAA's decades-old subordinate station offsets.

This page explains what to report, how the system uses it, and what it means to participate.

Why your reports matter#

The correction engine compares what the app predicted against what divers actually saw. When enough reports accumulate for a site, the IQR-filtered math separates the reliable middle from the outliers and derives an applied delta — a site-specific correction layered on top of the NOAA offset. Every diver who pulls up that site after sees a sharper prediction because of the reports that came before.

You can watch this happen in the app. A site with fewer than 10 reports shows no confidence badge at all — the briefing reads "No correction data yet" at zero, or "Correction pending: n/10 required" between one and nine. Once a site crosses 10, the correction goes live with Low confidence (10 to 19 reports), the applied delta still settling. Between 20 and 49, confidence rises to Moderate: the correction is meaningful but still tightening. At 50 or more, the site reaches High confidence, where the applied delta is well-established and stable. Your report is one more data point on that trajectory, and at sites still pending or in Low confidence, it counts for considerably more than at sites that have already crossed into High.

A few things follow from this that are worth stating directly:

No single report can break a site's correction. The IQR filter is built to handle outliers. One weird entry — even a wildly wrong one — won't skew a site that has a healthy report history.
The engine improves with scale. A site with 3 reports has a rough correction. A site with 30 has a good one. A site with 300 starts approaching the accuracy of a dedicated sensor.
You don't need to be a scientist. The system assumes honest imprecision, not laboratory precision. A rough slack time from a real dive is more useful than nothing, and more useful than a guess fabricated to sound authoritative.

What to report#

When you log a dive at /dashboard/log (sidebar: Log a dive), you'll fill in:

Slack timing — planned slack auto-fills from the prediction; observed slack is what you actually saw. The signed delta (e.g. "+6m late") is what gets aggregated. Even "slack was about 15 minutes later than predicted" is useful.
Current strength — a categorical reading on a five-step scale: None / Mild / Moderate / Strong / Dangerous. Compares your felt experience against the NOAA station's predicted magnitude and is one of the most useful signals for shore divers, where raw velocity numbers often undersell what a site is actually doing.
Plan accuracy — a one-to-five-star rating of how well the briefing matched the dive. Quick to submit, surprisingly useful in aggregate.
Conditions vs plan — a coarse better / as-predicted / worse comparison.
Notes — free-text observations about anything the numbers missed: surface chop, unexpected direction shifts, visibility anomalies. Always private to your record.

Of those, the slack delta is what currently feeds the correction engine. Current strength and plan-accuracy ratings are persisted on your dive log today, but the engine doesn't aggregate them yet — wiring those signals in is on the roadmap. They still show up on your own slack-analysis page and history, so logging them isn't wasted; the data is queued for when the engine grows to use it.

The form is designed to be fast. If logging a dive takes more than a minute or two, something's wrong with the design — let me know.

Dive logs vs. the Send feedback form#

Dive logs are the structured signal: slack delta, observed conditions, current strength, rating. The Send feedback button at the bottom of the sidebar is a separate surface — it's for everything that isn't a per-dive observation: bug reports, station-pairing concerns, predictions you saw go wrong but don't have a logged dive for, missing sites, or anything you'd tell me about in person. Both go to me; only dive logs feed the correction engine.

Where your reports have the most leverage#

Not every report moves the engine equally. If you're trying to maximize the impact of your reporting time, prioritize:

Pending and Low-confidence sites. Sites with fewer than 10 observations don't have an active correction yet — every new report at those sites moves them closer to activation. Sites at Low confidence (10 to 19 observations) still have a settling applied delta. Each new report at either tier has more weight in the engine than reports at well-established sites.
Stale sites. Any site flagged as having corrections older than 12 months. A stale flag means the applied delta is well-established but no longer actively maintained — a fresh report restarts that maintenance cycle.
Sites the briefing got noticeably wrong. The whole point. If a prediction was off and you can describe how, that report is exactly what the engine needs.

You don't have to plan around this. Reports from any dive at any site are useful. But if you find yourself diving a low-confidence or stale site and wondering whether it's worth the two minutes to report — yes, more than usual.

What not to worry about#

Newer divers sometimes hesitate to report because they're worried about being wrong, being judged, or messing up the data. A few reassurances:

Reports aren't publicly attributed. Other users see aggregated corrections, not who submitted what.
Mistakes don't compound. The IQR filter does exactly what it sounds like — catches the anomalies, keeps the signal.
There's no wrong answer to "how did this dive feel?" Perception is a real signal. A report that says "felt stronger than predicted" from someone who dives a site monthly is genuinely useful information.

Other ways to contribute#

Reporting dives is the most direct way to make the app better, but it's not the only one. TideTracker is built and maintained by one developer in between dives, and as the project grows, there's real room for help from divers who want to contribute beyond their own reports.

A few areas where contributions would be genuinely useful:

Code and maintenance. If you write software and want to work on a Next.js app that exists to make local diving safer, get in touch. Bug fixes, feature work, code review, infrastructure — all on the table.
Documentation. These docs you're reading were drafted to be useful to experienced PNW divers, and they'll stay accurate only if people who actually use the app help keep them honest. Corrections, suggestions, and rewrites are all welcome.
Site knowledge curation. Local experts who can vet how the app is mapping a site to its NOAA stations, or flag where the default station mapping is wrong, are exactly the kind of input that makes the difference between an app that works in theory and one that works in practice.
Sensor deployment and recovery (future). The remote sensor network on the roadmap will require divers willing to deploy and recover hardware at specific sites. When that work comes online, divers familiar with the deployment locations will be the first people I reach out to.

If any of this sounds like something you want to be part of, the in-app feedback form is the way in. Tell me what you'd like to work on, what you bring to it, and whether you're aiming at a specific contribution or just want to be on the list when the right thing comes up.

This is also the right channel for diving organizations, instructors, or shops who want to coordinate on something more structured. TideTracker exists to serve the community that uses it — that includes being open to working with the institutions that already serve it.

How reports are used#

Every report goes through the same pipeline:

Attached to its site and station context. The report knows what was predicted at the time of the dive, what stations the briefing drew from, and what correction (if any) was already in play.
Added to the correction history for the relevant site.
Filtered through IQR bounds. Outliers are flagged and excluded from the active applied delta but retained in the history for audit.
Reflected in future predictions at that site. Corrections update on the next scheduled refresh, and the site's confidence tier and "last updated" timestamp move accordingly.

Every stage of that pipeline is traceable. If a prediction at a site you dive regularly changes meaningfully, you'll be able to see what changed and why.

The trust model#

A system driven by user reports has to be honest about how it handles bad-faith input. The short version: the math handles most of it automatically, and the parts it can't handle are flagged for review.

Statistical defense. The IQR filter is the first line — it catches reports that fall outside the distribution without needing to know anything about the reporter.
Pattern detection. Reports from accounts showing anomalous patterns (e.g., reporting from sites never actually visited, reporting at impossible frequencies) are flagged for review.
Moderator tools. As the app grows, trusted local divers may be invited as moderators with the ability to flag or weight reports at sites they know well. This is on the roadmap, not shipped.

The goal is a system where a good-faith diver can report freely, confident that their input is being used well, and where bad-faith input doesn't meaningfully affect what anyone else sees.

When to use Send feedback instead#

Not every kind of input belongs in a dive log. Log a dive is for structured per-dive observations that feed the correction engine. Send feedback (bottom of the sidebar) is for everything else: bug reports, station-pairing concerns, sites missing from the list, predictions that seem systematically off but you don't have a specific logged dive to attach the report to, feature requests, or anything you'd tell me about in person. Those messages go directly to me. Use the form that matches the input — a station-pairing concern doesn't belong on a dive log, and a slack delta from yesterday's dive doesn't belong in Send feedback.