At the prover, an operator does not accept a meter factor from one pass. They make several consecutive runs and check that the factors those runs produce sit within a tight band before adopting their average. Proving run repeatability tolerance is that band - the maximum allowed spread across the required number of runs - and it is the practical pass-or-fail gate the operator applies right there at the prover.
Proving Run Repeatability in one line: Proving run repeatability tolerance is the maximum spread allowed among the factors from a set of consecutive proving runs before the average is accepted as the meter factor. A required number of back-to-back runs must agree within a tight band, such as a small fraction of a percent, or the set is rejected and repeated. It is the operator's mechanical accept or reject rule at the prover.
The mechanics are concrete. A proving requires a set number of consecutive runs, commonly five, though the exact count comes from the governing standard, the prover type, and the contract. Each run yields its own factor, and the operator computes the spread of the set - the difference between the highest and lowest factor across the runs - usually expressed as a percentage of the values. If that spread is within the tolerance band, often a small fraction of a percent, the set qualifies and its average becomes the accepted meter factor. If the spread exceeds the band, the set fails.
The word consecutive is load-bearing. The runs must agree back-to-back, not be cherry-picked from a larger pool of attempts. If run four lands outside the band relative to the others, the qualifying set is broken; the operator cannot simply keep the best runs and discard the outlier. In practice the count restarts from a fresh sequence of runs that hold together within the band. This is what gives the accepted factor its meaning: it says the meter, prover, and process were stable across a genuine unbroken sequence, not that a few lucky passes happened to align.
The tolerance band is a spread limit, and it is worth being clear about what spread means here. It is the range across the whole qualifying set, so tightening the band forces every run in the set closer together, which demands more stable conditions to achieve. The band and the run count work together: more runs required at a tighter band is a stricter test than fewer runs at a looser one. The specific numbers are set by the standard and contract in force, so the operator's job is to apply whichever band and count govern that meter, not to choose them on the day.
Sometimes an operator runs set after set and the spread simply refuses to fall within the band. This is a real and common situation at the prover, and the correct response is emphatically not to loosen the tolerance until the set passes. A wide, non-converging spread is telling you something: the conditions or the equipment are not stable enough to establish a trustworthy factor, and forcing an acceptance by relaxing the rule just buries that problem inside a factor you cannot rely on.
The productive move is to treat non-convergence as a diagnostic and work the likely causes. Unstable flow rate during the runs is the most frequent culprit, so confirm the flow is steady and within the meter's and prover's proper range. Entrained gas or air in a liquid prove scatters the runs badly, as do temperature swings between runs, a sticking or hesitating prover detector switch, and valve leakage on the prover that lets fluid bypass. A meter that is beginning to fail mechanically will also refuse to repeat. Each of these leaves the spread wide, and each is fixable once identified.
So the workflow when runs will not converge follows a clear symptom-to-cause-to-action shape. The symptom is repeated sets failing the repeatability tolerance. The likely causes are unstable flow, entrained gas, temperature swings, a sticking detector, prover valve leakage, or a failing meter. The diagnostic steps are to stabilize and verify flow first, check for gas and let the system settle, confirm the prover detectors and seals are sound, and only then suspect the meter itself. Persistent inability to repeat, after conditions are confirmed stable, is itself strong evidence that the meter or prover needs attention before any valid factor can be established.
The repeatability check is arithmetic on run factors that must be done correctly every time, and doing it by hand at the prover invites both errors and the temptation to fudge. A cloud SCADA platform can read each run's factor from the proving flow computer, compute the running spread across the consecutive set as runs come in, and show in real time whether the set is holding within the tolerance band and whether a qualifying set has been reached. That gives the operator an unambiguous, live accept-or-reject readout instead of a manual calculation under time pressure.
Just as important, the platform preserves the record of which runs were made, which set qualified, and which sets were rejected. Because the acceptance rule depends on runs being genuinely consecutive, a permanent record that shows the accepted set was a real unbroken sequence - not a hand-picked selection - is what makes the resulting factor defensible after the fact. Merobix records every run and its factor alongside the meter's measurement data, marks the rejected sets, and keeps the accepted set with its spread, so the proving report shows exactly which runs counted and why.
The division of responsibility is the usual one. The certified prover and flow computer perform the runs and produce each run's factor; the cloud SCADA does not perform the proving arithmetic that establishes the factor itself. What it adds is the real-time application of the repeatability tolerance across the set, the flagging of out-of-band runs, and the durable record of the whole sequence. That turns the run-count-and-band mechanics from an error-prone manual step into a monitored, auditable one, which is exactly what you want standing behind a custody factor.
A commonly required set is five consecutive runs, but the exact count comes from the governing standard, the prover type, and the contract in force for that meter, so it is not universal. The runs must be consecutive rather than cherry-picked, and their factors must agree within the specified tolerance band before the average is accepted. The operator applies whatever count and band govern that particular meter.
You do not loosen the tolerance to force an acceptance; a spread that will not converge is a signal that conditions or equipment are not stable enough for a trustworthy factor. Work the likely causes instead: confirm flow is steady, check for entrained gas, rule out temperature swings, and inspect the prover detectors and seals before suspecting the meter. Persistent non-convergence after conditions are stable is itself evidence that the meter or prover needs attention.
Requiring consecutive runs prevents an operator from selecting the closest few results out of many attempts, which would make a shaky proving look repeatable. Back-to-back agreement within the band shows the meter, prover, and process were genuinely stable during that unbroken sequence. If any run falls outside the band the set breaks and a fresh consecutive sequence must hold together, which is what gives the accepted factor its credibility.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.