What we measure, and where every number comes from.

What a quality check grades

A quality check reads your observation file and reports measurements, of which five are graded against fixed thresholds. Each graded metric comes back as Pass, Watch or Fail. Pass means the file meets the threshold. Watch means it is short of it but close enough that the data is usually still workable. Fail means it is below the level at which the measurement stops supporting a reliable result. A metric the file does not contain enough information to compute is not graded at all: it is left out of the table rather than counted as a pass, and when nothing can be graded the overall status is Unknown. The thresholds below are the same constants the report generator applies, in the direction each measurement runs: completeness, observations per cycle slip and signal to noise are better when higher, multipath when lower.

Thresholds: shared/config/qc-methodology.v1.json, pinned to the report generator.

How the verdict is decided

A score tells you how good a file is. It does not tell you whether the crew has to drive back to the point, so every quality check also returns one of three verdicts. The rule table is fixed and nothing in it is composed at run time: every reason carries the numbers that produced it, so a report can always point at the threshold behind its verdict.

• "usable": process the file as observed. Nothing that was graded came back short.
• "reprocess": the observations are there, and different processing settings can still recover them. Frequent cycle slips, signal interruptions concentrated on one observation code, a header that disagrees with the data, or a metric sitting on Watch all land here.
• "reobserve": nothing in processing recovers what was never recorded. Failing completeness, failing multipath, failing signal to noise, or interruptions that are whole satellites dropping out all land here.
• Precedence: any reobserve reason decides the verdict; if none fired, any reprocess reason decides it; otherwise the verdict is "usable" with no reasons. A Watch is only reported as a reason when nothing stronger fired.
• Tracking loss is claimed only when a constellation has at least 100 interruptions and at least 50% of them are whole-satellite losses. Below that count the share means nothing, so no reason is emitted.
• A single observation code is blamed only when the constellation tracks at least 3 codes, that code carries at least 50 interruptions, and it accounts for at least 60% of the constellation's signal-level interruptions.
• Both completeness measurements (epoch_completeness and data_completeness) describe data that was never recorded, so a Fail on either produces the same reason.

Reason codes: 8 fixed codes, listed in shared/config/qc-methodology.v1.json.

The processing settings a quality check applies

A quality check uses an elevation cutoff of 10 degrees unless the submission sets one, and every graded metric above is computed above that cutoff. Raising the cutoff removes low-elevation observations, which usually improves multipath and signal to noise and can reduce the observation count: two files graded at different cutoffs are not comparable, so a report states the cutoff it used. A submission can also choose the sampling interval and the constellations to grade, and the report states what it used, so two reports compare only when those agree as well.

What each precise positioning solution accepts

Precise positioning is published as solutions, not as software. Each row states what a solution will take as input, which orbit and clock product grades it will use, and how far it has actually got: what we claim it supports, whether it has been validated against an independent result, and whether the current deployment will accept a job for it. A solution that is supported is not automatically a runnable one, and the workspace, not this page, is authoritative about what your account may run right now.

Solutions: the public projection of the capability manifest, regenerated by the build.

Limits on the tools that need no account

The quick check on the home page and the conversion tools on the landing pages run without an account, so they are capped per IP address rather than per plan. Quick Check accepts 10 files per IP per day, up to 100 MB for an uncompressed file and 20 MB for a compressed one. The anonymous conversion tools accept 10 files per IP per day, up to 20 MB each. An anonymous Quick Check result is readable for 86400 seconds (24 hours) and an anonymous conversion output for 3600 seconds (1 hour), after which both are gone and cannot be recovered. These are the defaults the server ships with; a deployment can tighten the daily allowances, and the conversion-tool caps and lifetime, by environment variable.

How long results are kept, and when they are deleted

Results belonging to an account are kept for a period that depends on the plan: 30 days (Free), 90 days (Pro), 365 days (Business). Pay-per-use keeps results for 90 days and Enterprise for 365 days. A sweep runs on a fixed schedule (daily 04:45 UTC) and removes the tasks whose retention has expired, together with the files they hold, so the deletion of a result happens within a day of its period ending rather than at the instant it lapses. A Quick Check upload is deleted when the result exists: that file does not wait for the sweep.

Retention: the plan table the server enforces; sweep schedule: the retention job cron.

What this page does not tell you

• The build of each processing binary. It is pinned by the deployment, not published, so no reader should cite a version number for it. If you need to know whether a specific fix is live, ask us and we will answer for the deployment you are on.
• Which solver produces a given positioning solution. Solutions are published by what they take in and what they return; the identity of the software behind one is not a public fact, and the same display solution can be produced by more than one of them.
• An accuracy figure. We publish no accuracy specification per solution, because the number that matters is the formal uncertainty your own run reports, computed from your session length, your antenna calibration and your data.
• A live success rate. The status page carries those, over a rolling 30-day window, and it is the only place they appear so that a figure baked into a static page can never go stale.

For AI agents

An agent does not have to read this page to learn what the platform does. Two endpoints answer without an account and without a key, and both are read only. https://posflow.ai/api/v1/public/agent-snapshot returns one JSON document: the operating figures the status page publishes, the positioning solutions with the input envelope and state of each, the facts behind this page, and the scores of the curated sample stations. https://posflow.ai/api/v1/public/mcp speaks JSON-RPC 2.0 over POST and offers read-only tools named operating_status, capabilities and sample_station_score. A GET to that same address describes, in plain text, how to call it.