Argo Data Quality Control Guide: QC Flags and Adjusted vs. Raw Data

Every Argo profile comes with more than measurements. It also comes with quality-control flags, a data mode, and, often, a second set of “adjusted” values next to the raw ones. If you have opened a NetCDF file and wondered which numbers you are actually supposed to use, you are not missing something obvious. Argo’s quality system is genuinely a layer of information on top of the data, not a footnote.

If floats, cycles, and profiles are still unfamiliar, begin with What is Argo Float? A Complete Guide to Ocean Observation Data before working through the quality fields.

This guide explains what Argo QC flags mean, the difference between real-time and delayed-mode data, when to prefer adjusted values over raw ones, and how OceanGraph applies these rules automatically so you can see already-filtered profiles.

If you want the broader file structure first, read Argo NetCDF Format Explained for Beginners, which introduces QC and adjusted variables at a high level. This guide goes one level deeper into how to actually use them.

Why Argo Quality Control Matters

Argo floats are autonomous instruments operating for years at sea. Sensors drift, some measurements are affected by biofouling or calibration issues, and communication can introduce errors. Argo’s quality system exists to flag and, where possible, correct these issues, so that a value’s numeric reliability is documented alongside the value itself.

Skipping this system does not make your analysis simpler. It just means you are treating unverified and verified data the same way, which can quietly bias results, especially when working across many floats and years.

What Argo QC Flags Are

Every core variable, including pressure, temperature, and salinity, has a matching QC flag variable (PRES_QC, TEMP_QC, PSAL_QC). Position and time also have their own QC flags (POSITION_QC, JULD_QC).

The flag scale is not binary. It ranges from “no QC performed” to categories such as good data, probably good data, and bad data, plus a distinct flag for values that were estimated rather than directly measured. This is why filtering on “good” data means selecting a specific set of acceptable flag values, not just excluding an obvious “bad” flag.

OceanGraph’s own filtering illustrates one product-specific rule. Only profiles with JULD_QC and POSITION_QC values of 1, 2, or 8 are used. Pressure rows also require PRES_QC in that set, but a temperature or salinity cell that cannot be used is kept as an explicit missing value on the shared pressure axis. Derived calculations use only the finite inputs they require.

Real-Time vs Delayed-Mode Data

Argo data reaches users in more than one stage, identified by a DATA_MODE value:

• Real-time (R): available within about a day of the observation, checked with automated tests only
• Real-time adjusted (A): real-time data that has already received an automated adjustment
• Delayed-mode (D): reviewed later by a human expert through delayed-mode quality control (DMQC), which can catch sensor drift and calibration issues that automated checks miss

DMQC takes considerably longer than automated checks, and Core Argo delayed-mode files are typically not released until roughly one to two years after the observation was collected, sometimes sooner. This creates a practical trade-off: real-time data is available sooner but has had less scrutiny, while delayed-mode data is more reliable but arrives much later.

When both are available for the same cycle, delayed-mode data is preferred. OceanGraph applies that preference to core D versus R profiles and to synthetic SD versus SR profiles. It reads BGC variables from the selected synthetic profile rather than replaying separate B-files.

Adjusted vs Raw Values: Which Should You Use?

Alongside the raw variable (for example TEMP), Argo files can carry an adjusted counterpart (TEMP_ADJUSTED) with its own QC flag (TEMP_ADJUSTED_QC). The adjusted value reflects corrections such as sensor calibration or drift adjustment.

A practical selection rule is:

1. Use the adjusted variable when it, along with its matching QC flag, is present and contains valid data.
2. Fall back to the raw variable and its own QC flag only when the adjusted variable is missing or entirely invalid.
3. Never pair a raw value with an adjusted QC flag, or an adjusted value with a raw QC flag. QC flags describe the specific variable they are attached to.

For a full profile to use adjusted core values, all three of PRES_ADJUSTED, TEMP_ADJUSTED, and PSAL_ADJUSTED need to be present and valid together, not just one or two of them. This “all or nothing” rule for the core trio, used by OceanGraph’s own processing, keeps pressure, temperature, and salinity internally consistent within one profile rather than mixing adjustment states across variables.

BGC Parameters Follow the Same Logic, Per Parameter

Biogeochemical (BGC) variables such as dissolved oxygen, chlorophyll, and pH select adjusted values first and fall back to raw independently for each parameter. A single profile can therefore use adjusted data for one BGC parameter and raw data for another. OceanGraph then masks QC 4 (bad data), QC 9 (missing value), and values outside the selected source’s configured range. Masking does not restart source selection, and no BGC profile-level QC ratio is applied. Other in-range QC codes remain and require interpretation. Argo’s own guidance for non-experts is to avoid using raw BGC values directly in scientific work; when the data mode is A or D, treat the adjusted value as the more reliable choice.

A Practical Example: Choosing Data for One Profile

Imagine you have opened one Argo core profile.

1. Check DATA_MODE. If it is D, delayed-mode review has already happened for this cycle.
2. Check whether PRES_ADJUSTED, TEMP_ADJUSTED, and PSAL_ADJUSTED are all present and valid. If so, use them together with PRES_ADJUSTED_QC, TEMP_ADJUSTED_QC, and PSAL_ADJUSTED_QC.
3. If any adjusted core variable is missing, use the raw PRES, TEMP, and PSAL together with their own QC flags instead.
4. Confirm that, for each of pressure, temperature, and salinity independently, at least 80% of that variable’s QC flags across the whole profile are 1, 2, or 8. A profile that fails this check for any one of the three variables is excluded entirely, before any individual layer is selected.
5. Keep the finite, acceptable-QC pressure rows. Before TEOS-10 conversion, mask temperature outside -2.5–40.0 °C and practical salinity outside 2–41 without rerunning the earlier 80% profile check. Calculate potential temperature from the remaining temperature-salinity pairs and Absolute Salinity from valid salinity rows. Unavailable derived values remain null; no second range is applied to them.
6. Select adjusted or raw values independently for each BGC parameter, then mask QC 4, QC 9, and values outside that source’s range. Keep the remaining finite cells with their QC meaning, and do not reselect raw data after masking.

This sequence is the core of what “using quality-controlled Argo data” actually means in practice.

How OceanGraph Applies These Rules For You

OceanGraph’s data pipeline applies this filtering logic automatically before a profile ever appears in search results:

• When both real-time and delayed-mode files exist for a cycle, the delayed-mode file is used.
• Adjusted core variables are used only when all three of pressure, temperature, and salinity adjustments are complete and valid; otherwise the profile falls back to raw values.
• Only profiles with acceptable JULD_QC and POSITION_QC are included.
• A profile is excluded entirely unless pressure, temperature, and salinity each independently have at least 80% acceptable QC flags; this whole-profile check runs before any individual layer is selected, and failing the threshold for even one of the three variables excludes the profile.
• Within a profile that passes that check, acceptable finite pressure rows define the shared coordinate. Missing temperature or salinity remains missing instead of deleting unrelated parameter values at that pressure.
• Source-range and QC masks are applied cell by cell. Missing and masked cells remain null rather than being interpolated in Profile JSON, and a profile is omitted if no finite temperature, salinity, or BGC value survives. The 0–2000 dbar pressure guard remains separate, and derived temperature and salinity receive no second numeric range.

Even after this filtering, a passing QC flag is not a guarantee that every value is scientifically unremarkable. The image above shows a real case: a position that passes POSITION_QC but still stands out from the surrounding trajectory enough to warrant a second look before relying on it. Passing QC narrows the field to usable data; it does not replace your own judgment about a specific observation.

Common Mistakes When Working With Argo Quality Information

Treating any non-zero QC flag as “bad”

The scale includes multiple acceptable categories, not just one. Filtering out everything except a single flag value can discard usable data unnecessarily.

Mixing adjusted and raw variables within the same profile

Pairing TEMP_ADJUSTED with PSAL and its raw QC flag, for example, breaks the internal consistency that the “all or nothing” adjustment rule is designed to preserve.

Assuming real-time data is unreliable and delayed-mode data is perfect

Real-time data has had less review, but that does not make it unusable, especially for time-sensitive applications. Delayed-mode data has had more review, but “reviewed” is not the same as “immune to every possible issue.”

Ignoring missing values as if they were low or zero values

A missing value after QC filtering, or a value masked by its selected-source limit, is not the same as a genuinely low or zero measurement. Treating them the same silently distorts any statistics computed afterward.

The Traditional Workflow: Manually Filtering NetCDF Files

A common approach is to download raw and adjusted NetCDF variables together with their QC flags, implement the adjusted-first fallback logic yourself, apply flag-based layer filtering, and repeat this consistently across every float and cycle you plan to use.

This is the right approach for a fully custom research pipeline, but it is a meaningful amount of infrastructure to build correctly before you have looked at a single profile.

If you pass those QC decisions on to your own tools or screens, the values need to travel with their units, their missing-value distinction, and the rules that were applied. Preserving the Meaning of Ocean Data in Web Apps describes how to carry that context across each boundary.

A Better First Step: Explore Pre-Filtered Profiles in OceanGraph

If your first goal is to understand what a region’s Argo data actually looks like, it can help to start from profiles that have already passed this filtering:

• Search by region, date, and WMO ID
• Trust that the returned profiles already reflect delayed-mode preference and the adjusted-first fallback rule
• Inspect an individual profile’s trajectory and position context before drawing conclusions from any single value
• Move to a custom, fully manual QC pipeline later, once you know which floats and periods are actually worth that investment

Useful follow-up pages are:

• Data Filtering Policy
• Argo NetCDF Format Explained for Beginners
• Search and Bookmark

Explore Quality-Controlled Argo Data in OceanGraph

If you want to skip building QC and adjusted-value filtering logic from scratch, OceanGraph is a direct way to start from data that already reflects it.

OceanGraph applies the delayed-mode preference, adjusted-first fallback, and flag-based filtering for you, so you can focus on interpreting profiles rather than re-implementing Argo’s quality rules.

Frequently Asked Questions

What do Argo QC flags actually mean?

They describe the reliability of a specific value, ranging from unflagged, through good and probably good, to bad, plus a distinct flag for estimated values. Acceptable flags depend on the analysis, but 1, 2, and 8 are a common practical selection for general use.

Should I always use delayed-mode data over real-time data?

When both exist for the same cycle, delayed-mode data is preferred because it has had additional expert review. If only real-time data is available, it can still be usable, particularly for applications that need the most recent observations.

Should I always use adjusted values instead of raw values?

Use adjusted values when the adjusted variable and its QC flag are present and valid. For the core trio of pressure, temperature, and salinity, this decision should be made together for all three, not variable by variable.

Can a profile pass QC and still deserve a closer look?

Yes. Passing QC means a value met the criteria Argo’s quality system checks for; it does not mean every value is free of any scientifically relevant peculiarity. Use QC as a starting filter, not a final judgment.

Do I need to implement this filtering myself to use Argo data?

Not necessarily. If your goal is exploration and interpretation rather than building a custom pipeline, you can start from a source, such as OceanGraph, that has already applied consistent QC and adjusted-value rules.

Conclusion

Argo’s quality-control system, real-time vs delayed-mode data, and adjusted vs raw variables exist to document how reliable each value is, not to make the data harder to use. Once you understand the flag scale, the delayed-mode preference, and the adjusted-first fallback rule, “using quality-controlled Argo data” becomes a specific, repeatable procedure instead of a source of uncertainty.

For most learners, the fastest way to start is with profiles where this filtering has already been applied, so you can focus on the oceanography. That is where OceanGraph helps.