Measurement sources
Where BS&W, API gravity and observed temperature come from, the precedence rule that decides which one is used, and how provenance is recorded on every computed volume.
BS&W, API gravity and observed temperature can each arrive from three places. The platform accepts all three and applies one stated precedence.
The precedence rule
Most specific wins:
- A value recorded with this gauge — a shakeout, a hydrometer reading, a thermometer reading taken at the tank at the time of the observation.
- A current lab result on file for that tank.
- The configured default for that tank.
That order is not configurable, because the point of it is that everyone reading a volume knows how it was chosen.
Provenance is recorded, always
Every computed volume records which source each of its inputs actually came from.
An NSV resting on a configured tank default is visibly different from one resting on a shakeout taken that morning. Neither is wrong. Presenting them identically is.
In the interface, each input carries a mark identifying its source. The mark is a shape — circle for this gauge, square for a lab result, diamond for a tank default — so the distinction survives greyscale printing, colour-blindness and a phone screen in direct sun.
Stale lab results
A lab result has an effective date and can go stale.
A stale result is used only if nothing more specific exists, and when it is used, the resulting volume is marked as resting on stale input. It is not silently treated as current, and it is not discarded in favour of a default either — a three-month-old measurement of that tank is usually still better evidence than a configured constant.
When nothing supplies an input
If no source at any level supplies a required input, the volume is not computed with an assumed value.
Instead:
- the reading is stored
- the derived volume is reported as unavailable, naming the missing input
- the interval is marked incomplete
This is the same discipline applied everywhere else in the platform. A gap produces a stated gap, not a plausible number.
Correcting an input after the fact
A lab result that arrives late, or a temperature that was mis-keyed, is handled by the correction path rather than by editing:
- the original record is retained
- the correction is a new record referencing it, with author, time and reason
- every derived volume that depended on the input recomputes
- anything that changed is flagged as restated, not silently replaced
See gauge sheets for the correction rules in full.
Why this is one feature and not three
It is tempting to treat BS&W, gravity and temperature as three separate configuration problems. They are one problem: take the data as it really arrives, be explicit about what was used, and never let a default masquerade as a measurement.
That principle is what the rest of the platform runs on. This is the same rule applied to the three inputs that decide what a barrel is worth.