Observed API gravity is the number an operator actually reads off a hydrometer floating in a sample, at whatever temperature that sample happens to be. It is a raw field reading, not a final answer, because the density that gravity expresses changes with temperature. To make it useful, the observed gravity is corrected to a common reference temperature, sixty degrees Fahrenheit, so that gravities measured on hot summer days and cold winter mornings can be compared and used in volume math. Understanding the difference between what you read and what you report is the whole point of this term, and it is where a lot of field measurement discipline lives.
Observed API gravity in one line: Observed API gravity is the hydrometer reading taken at the sample's actual, uncorrected temperature. It becomes usable only after being corrected to the standard 60F reference, so the observed value and the corrected value are two distinct numbers, and only the corrected one belongs in custody and net volume calculations.
In the field, determining gravity starts with drawing a representative sample into a clean cylinder and floating a hydrometer or thermohydrometer in it. The operator reads where the liquid surface crosses the hydrometer scale, and at the same moment records the temperature of the sample. That scale reading is the observed API gravity. It is entirely real, but it is tied to the temperature the sample was at when it was read, which might be ninety degrees off a hot pipeline or fifty degrees on a cold morning.
Because a warmer liquid is less dense and reads a higher API gravity, and a cooler liquid reads lower, two samples of the identical crude can give different observed gravities purely because of temperature. That makes observed gravity useless for comparison or accounting on its own. The fix is a temperature correction: using published conversion tables, the observed gravity and its observed temperature are converted to the gravity the same product would show at sixty degrees Fahrenheit, the industry standard reference. That corrected value is the API gravity that goes on the ticket.
This observed-versus-corrected distinction complements the broader idea of API gravity as a density scale. The general concept explains what API gravity is and how it relates to density; the observed reading is specifically about the field workflow, the moment of measurement, and the mandatory correction step that separates a raw dip from a reportable number. Confusing the two, or reporting an observed value as if it were corrected, is a real and consequential mistake.
Corrected gravity is not a nicety; it feeds directly into the money side of a custody transfer. Net volume calculations use gravity, via density, to convert measured volume to standard conditions and to correct for temperature, so the gravity value carries straight into the barrels billed. If someone records an observed gravity without correcting it, or applies the wrong temperature, the error propagates into the volume correction factor and shows up as a bias on the settlement. On a high-throughput lease, a persistent gravity error is real money moving the wrong way.
The observed reading also has to be defensible, which means both the gravity and the temperature it was read at have to be captured together. A corrected gravity written down without the observed value and temperature behind it cannot be checked or reconstructed. Good practice is to record the observed gravity, the observed temperature, and the corrected result, so an auditor can retrace the correction and confirm the right table entry was used. The observed number is the primary evidence; the corrected number is the derived result.
This is why custody procedures treat the observed reading as a controlled data point rather than a throwaway. Reading the hydrometer at eye level to the true surface, letting the sample settle to a stable temperature, and capturing temperature simultaneously all protect the observed value, and everything downstream inherits that care. A sloppy observed reading cannot be rescued by correcting it perfectly; the correction only preserves the accuracy that was there at the moment of the dip.
On automated systems, the manual hydrometer draw is increasingly replaced or backstopped by inline instruments. A sampler on a LACT unit builds a representative composite, and an inline densitometer or analyzer can determine density and effectively gravity continuously as product passes. Whichever path the raw measurement takes, the same logic applies: the instrument reads at line conditions, and the value has to be referred back to sixty degrees before it means anything for accounting.
In a SCADA-connected setup, that correction happens in software rather than on a printed table. The flow computer or the platform takes the measured density or gravity and the measured temperature, applies the standard correction, and carries the corrected gravity into the net volume math automatically. Merobix historizes both the raw and corrected values along with the temperature, so the corrected gravity that drove a ticket is not a mystery derived somewhere off system; it is stored next to the inputs that produced it.
That end-to-end record is what makes automated gravity trustworthy for custody. When the observed or line reading, the temperature, the correction, and the resulting corrected gravity all live in the same historized record, an operator or auditor can confirm the chain instead of trusting a single final number. It also lets the system trend gravity over time, so a slow drift, whether from a real product change or a fouling analyzer, becomes visible rather than hiding inside an already corrected value on a ticket.
Observed API gravity is the hydrometer reading taken at the sample's actual temperature, while corrected API gravity is that reading converted to the standard sixty-degree-Fahrenheit reference using conversion tables. The observed value depends on temperature and cannot be compared across samples, so only the corrected value is used on custody tickets and in net volume calculations.
Liquid density changes with temperature, so the same product reads a higher API gravity when warm and lower when cold. Correcting every reading to a common sixty-degree reference lets gravities measured under different field conditions be compared and used consistently in volume math. Without that correction, temperature differences alone would produce apparent gravity differences that are not real.
The raw measurement, whether a manual hydrometer draw or an inline densitometer reading at line conditions, is still the primary evidence behind the corrected value. A good SCADA setup historizes the raw reading, the temperature, and the corrected result together so the correction can be retraced and audited. Automating the correction changes where the math happens, not the need to capture and preserve the underlying observed data.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.