Key takeaway
A falling counter needs an event and a calculation rule; turning every drop into a rollover invents equipment usage.
Decide what the reading accumulates
A machine-hour export can look orderly while its cumulative counter is discontinuous. The reviewer’s task is to identify which transitions support a usage increment. A replacement can change the measuring device without resetting the asset’s lifetime history; a correction can alter a prior reading without representing any new operation. Those events should remain visible in a transition ledger.
First establish whether each record is a cumulative total or an interval increment, its unit, device identity, recording cadence and aggregation rule. Microsoft’s documented asset-maintenance preview configures an hours counter with a Sum aggregate and a default three-hour insertion cadence. That is one particular preview configuration, checked 11 October 2026. It illustrates why a column named Total does not describe its underlying measurement semantics.
Reproduce a confirmed rollover and replacement
This hypothetical meter displays integers from 0 through 9,999 and wraps after 10,000 hours. Device M1 reads 9,970 and then 20. The source maintenance event confirms exactly one wrap, so the increment is (10,000 − 9,970) + 20 = 50 hours. A later reading of 65 adds 45 hours. These invented readings assume an uninterrupted device history and no additional unobserved wraps.
M1 is then replaced by M2, whose commissioning baseline is 7. Both values are recorded at the same illustrative replacement instant. The new baseline contributes no operating time. M2’s next reading of 22 adds 15 hours. Supported usage across the displayed transitions is therefore 50 + 45 + 0 + 15 = 110 hours. Keep the asset key and the device keys separate.
| Transition | Event evidence | Calculation | Supported increment |
|---|---|---|---|
| M1: 9,970 → 20 | One confirmed wrap; modulus 10,000 | 10,000 − 9,970 + 20 | 50 hours |
| M1: 20 → 65 | Same device; monotonic | 65 − 20 | 45 hours |
| M1: 65 → M2: 7 | Confirmed replacement; new baseline | No elapsed use at replacement instant | 0 hours |
| M2: 7 → 22 | Same replacement device | 22 − 7 | 15 hours |
| Supported total | Stated assumptions only | 50 + 45 + 0 + 15 | 110 hours |
Hold an unexplained drop instead of choosing a convenient rule
If the device identifiers and replacement record were absent, the 65-to-7 transition would be unresolved. Subtracting produces −58 hours; taking the absolute value produces 58; assuming a wrap produces 9,942. None is supported merely by the two numbers. Add an exception status and request the maintenance or correction event. Later arithmetic cannot recover an event that the archive never retained.
A maximum display value of 9,999 is not the same as a 9,999-hour wrap modulus. The stated example has 10,000 possible integer states. Confirm the actual device convention and whether fractional values are possible before using any formula. Sparse readings may conceal several wraps; a single-wrap assumption requires evidence about elapsed time or another usage record. An unexplained discontinuity should not be presented as a verified lifetime total.
Record the calculation implementation
Preserve the original observations, event record, counter modulus, baseline, transformation version and corrected result. A historical IBM support APAR describes a reset/replace defect that affected rollover deltas and life-usage calculations in an older release. Its reported release and fix are historical evidence that software behavior matters. The passage does not establish a defect in a current installation or supply a universal formula.
For a real export, obtain the application version and the owner’s documented counter behavior. Compare one known rollover, one device replacement, one retrospective correction and one normal interval with the source application. If daily exports are aggregated again, check that interval increments are not summed twice and cumulative totals are not summed at all. Retain any prior output whose corrected value a downstream recipient might still use.
Approve a bounded usage series
The example supports 110 hours for the declared transitions. It does not establish the machine’s entire lifetime, utilization percentage, service condition or maintenance compliance. A useful owner package pairs the transition ledger with coverage dates, device replacement history and unresolved intervals. The recipient can then choose to use supported intervals, preserve exceptions or request the missing event evidence.
Inventory can describe counter history without exporting machine identifiers or maintenance notes. Due diligence can ask whether a proposed evaluation needs raw readings, supported increments or lifetime totals. Begin with a synthetic transition example. A named recipient’s permission to receive that description remains separate from permission for a real sample or a license covering machine records.