Recalculate history after a calibration change outside the visible data set, on a frozen range and with the configuration saved. Publish the new results only after passing checks for completeness, units, control values, and continuity. Publication should be atomic, and historical alarms should be disabled by default. Plan rollback separately, because atomicity is not the same as versioned rollback.
In short
- Do not correct raw measurements with a formula. Change the layer of calculated results while preserving the source and timestamps.
- Freeze the range, equations, coefficients, reference, and analysis profile at the start of the run. Otherwise, later batches may be created under different rules.
- Calculate into a hidden working area. An error in one batch must not leave users with a mix of old and new history.
- Before publication, compare count, time range, units, control points, gaps, and edge behavior at the range boundary.
- Do not trigger notifications for old exceedances. After publication, assess the current condition of the asset separately.
Changing a calibration factor looks harmless. One number in the equation, a “recalculate” button, and done. In real monitoring, that operation can change several years of results, maxima in reports, the position of series relative to thresholds, and conclusions already recorded by the engineer. The worst case is not even a wrong formula. It is when part of the chart shows old values, part shows new values, and nobody knows when the change happened.
If the data are meant to support a decision on asset use, acceptance of works, or a claim, “it recalculated without errors” is not an acceptance criterion. You need a process that can show what was calculated, under which configuration, over which range, and why the published data set is consistent. That is a separate discipline from the act of saving the equation that converts the raw reading to an engineering unit.
What recalculating history really changes
History recalculation is the controlled recreation of derived results from preserved source data according to an explicitly indicated configuration. Source data remain the point of reference. Derived results can include strain, displacement, stress, temperature-compensated value, displacement profile, or measures derived from a dynamic trace.
There are several reasons to start the operation. The manufacturer supplied a corrected coefficient. The laboratory showed a change in sensitivity. An equation contains a sign or unit error. The reference was changed in a way approved by the engineer. For vibrations, a different analysis profile was deployed or the axis gain was corrected. Each case affects the data differently, so the cause and expected effect must be named before the run starts.
First, separate four layers:
| Layer | Example | Recalculate | What to preserve |
|---|---|---|---|
| source | raw reading and UTC time | no | the original value and device identification |
| configuration | equation, coefficient, reference | changes the rule | value before and after, and the change author |
| derived result | µε, mm, kPa, RMS in a band | yes | range, rule version, and validation result |
| interpretation | alarm, report, human decision | not automatically | the historical decision context |
This separation protects against a common error: treating a newly calculated value as if it were knowledge available on the day of the earlier decision. Recalculation can improve the technical representation of the measurement, but it does not change the fact that the operator acted then on the basis of the previous configuration. That is why archived protocols and data used as evidence in a dispute should keep their context.
Three operations that must not be lumped together
“Recalculation” is used for different processes. Their inputs, tests, and alarm effects are not the same.
Recalculation of static measurements
This applies to regular readings such as temperature, strain, pore pressure, or inclination. Project equations create calculated channels from raw values and references. A safe run covers a defined time interval and selected devices, and the result replaces calculated records only for that range.
Recalculation of stored dynamic events
This applies to full vibration traces. A change in the analysis profile or axis calibration requires a new calculation of results such as RMS, band maxima, and envelope-based indicators. It is not a recalculation of a single number. Each event has samples, duration, sampling frequency, and metadata that must meet the requirements of the selected profile.
Retry of a failed analysis
A retry is used to complete a specific case that previously ended in error, according to the profile stored with the event. It should not silently switch the entire history to current settings. It is a corrective procedure, not a migration of the calculation model.
| Operation | Typical range | Configuration | Publication | Historical alarms |
|---|---|---|---|---|
| static measurements | time and devices | frozen equations and references | after the batch is complete | skipped by default |
| dynamics | complete stored events | snapshot of profile and calibration | whole generation together | disabled |
| analysis retry | one failed case | profile stored with the event | after a successful analysis | result enters the normal current process according to the event context |
This classification gives you the right acceptance question. For static data, ask about completeness of measurement instants. For dynamics, ask about completeness of events and axes, and profile consistency. For a retry, ask whether exactly that case was repaired without changing the rest of the history.
Safe workflow: from scope to atomic publication
In a database system, a transaction groups many changes into an “all or nothing” operation. PostgreSQL documentation also emphasizes another important property: intermediate states are not visible to other transactions. In monitoring, that translates into a simple rule. The user should not watch the chart change in batches.
The workflow can be written as a state diagram:
APPROVED RANGE
|
v
CONFIG SNAPSHOT -> QUEUED BATCHES -> WORKING RESULTS
|
+----------------+----------------+
| |
v v
VALIDATION PASSED ERROR / NO BATCHES
| |
v v
ATOMIC PUBLICATION OLD RESULTS STILL VISIBLE
|
v
POST-PUBLICATION ACCEPTANCE
1. Approve the scope and the reason
Record the change identifier, approver, devices, time interval, expected direction of the difference, and the rule for handling alarms. Do not use a moving end point such as “until now”. The last timestamp visible at the start should become the boundary of the run. New measurements arriving during the run belong to normal processing already.
2. Freeze the configuration
Every batch must use the same snapshot of equations, coefficients, units, references, and profile. If the administrator edits a setting during the operation, the change should go into the next run. Mixing two configurations under one run identifier takes away reproducibility.
3. Calculate into a working area
The working area, also called staging, is a hidden set of results prepared for validation. Each batch should be idempotent: if it is rerun after interruption, it must not duplicate records or change the range. An error is information about the run, not a reason to publish what happened to finish in time.
4. Verify the whole set, not a sample by eye
Start with machine tests: count, uniqueness, time boundaries, absence of forbidden values, units, and range consistency. Then take engineering samples covering the start, end, extrema, stable period, and the moment of a known event. Only both levels together provide a basis for publication.
5. Publish as one change
The visible data set should move from state A to B without a state of “A and half of B”. If publication fails, A remains. After success, a check of the user view is still needed, because a correct database transaction will not detect a physically incorrect calibration.
Acceptance tests before pressing “publish”
An acceptance test must have an expected outcome. “The chart looks fine” is not enough. The set below can be pasted into a maintenance procedure or supplier requirements.
| Test | How to perform | Acceptance condition |
|---|---|---|
| range | compare the first and last instant | exactly the approved boundaries |
| count | count unique instants or events | match with source and justified exceptions |
| continuity | detect gaps larger than the real cadence | no new gaps after recalculation |
| unit | trace the dimension of each equation | result in the declared unit |
| control value | calculate 3 to 5 points by hand | match within the agreed tolerance |
| extrema | compare minimum, maximum, and median | difference has the expected sign and order of magnitude |
| range boundary | compare the point before, within, and after the range | no duplicate and no unintended step |
| dependencies | verify channels that use other results | full calculation order, no cycle |
| dynamics | compare the number of events, axes, and bands | complete generation, one profile |
| alarms | watch the queue and notification history | no flood of messages for an old period |
Illustrative example. Assume the strain conversion factor was underestimated by 2 %. The range contains 105 120 measurement instants. You therefore expect the same number of timestamps, no new gaps, and a proportional increase in channels dependent on that coefficient. If the median rises by 2 %, but the maximum by 40 %, do not accept it as a “calibration effect”. Look for overflow, a unit error, a different reference, or an incomplete dependency.
Also select points with known physical meaning: zero reading, no-load period, load-test moment, temperature peak, and alarm instant. That way you test not only the arithmetic, but also the behavior of the model in situations an engineer can assess.
Alarms, audit, and the rollback plan after publication
A historical exceedance is not a new event. If, after a coefficient change, a value from two years ago crosses the threshold, sending an SMS today creates a false time context and may trigger a procedure that cannot be carried out sensibly. The safe rule is recalculation without backdated alarms, followed by a separate assessment of the latest condition under the approved configuration.
The audit should answer at least seven questions: who started the operation, when, why, which range it covered, which configuration it used, what the test result was, and when publication happened. The change log for the equation, with values before and after, is important, but by itself it does not replace the acceptance record for the run.
You also need to distinguish two meanings of rollback. Transaction rollback means that a failed publication leaves no partial changes behind. Business rollback means the ability to return to the previous, already published generation. For that, you need stored results, configuration versions, or a repeatable process that can recreate the previous state from raw data. Do not assume that this is possible without a test.
Checklist before recalculating history
- [ ] The reason has been described and the responsible person approved.
- [ ] A closed time range and device list have been defined.
- [ ] Source data have been preserved without modification.
- [ ] The equations, coefficients, units, references, and profiles used in the run have been recorded.
- [ ] Manually calculated control values have been prepared.
- [ ] Completeness criteria and acceptable exceptions have been defined.
- [ ] Historical alarms have been disabled and current-state control has been described.
- [ ] The rollback method has been verified after a successful but technically wrong publication.
- [ ] The acceptance owner and operating window have been defined.
- [ ] A check of dashboards, exports, and reports has been planned after publication.
How this works in Inclify
Inclify separates source measurements from calculated results. Recalculation of project equations can be limited by dates and devices. A run creates a persistent process with progress, speed, and estimated completion time. Batches write results into a hidden working area; the visible data remain unchanged until the full run is complete and published atomically. The default setting skips alarms during recalculation.
A separate run is used for stored dynamic signals. The platform takes a snapshot of the current analysis profile and calibration, recalculates complete events into the working area, checks that the number of results matches, and publishes the whole generation together. This operation does not trigger historical alarms. Retrying a single failed analysis is a different process and uses the profile stored with the event.
This separation matters for acceptance: the person performing the control does not compare data at a moment when part of the batch has already overwritten the view and part is still being calculated. Only the finished set becomes visible, so the test concerns one consistent version of the results.
Important limitation: the platform does not keep full copies of every published result generation and does not offer a button to restore the previous state. Configuration changes are audited, but the audit is not a data copy. That is why a rollback plan, a control export, and formal acceptance still belong to the organization’s procedure.
Limitations: what a safe workflow does not settle
Atomic publication guarantees technical consistency of the operation, not engineering correctness of the coefficient. A wrong formula can be calculated and published without any technical error. You need independent verification of the calibration document, units, axis sign, reference, and expected physical response.
Recalculation will not repair missing source data, a shifted clock, or faulty installation. It will also not change the meaning of an earlier decision made on the basis of the report available at that time. If the result has contractual or evidential significance, keep the earlier export and version description, and agree the correction display method with the person responsible for documentation.
For a major model change, a parallel calculation channel and a comparison period may be better than immediate replacement of the history. This applies especially to temperature compensation, new references, and models where the result of one channel feeds the next equations. In that case, first assess whether the change comes from temperature or from the structure, and only then migrate the history.
FAQ
Do you need to recalculate the entire history after every coefficient change?
No. The range should follow the period of calibration validity and the purpose of the analysis. If a new coefficient describes the sensor from the replacement date, applying it to earlier readings may be an error. If you correct an equation error that has been present from the start, the full range is often justified. Record the decision together with the boundary date and source document.
Is staging the same as a backup?
No. Staging stores hidden results for the current run until validation and publication. A backup is used to recover data after a failure or an incorrect change. The working area can be deleted after success, so it does not replace a versioned copy of the previous generation or a tested recovery procedure.
What should be done with an alarm that appears only after recalculating an old value?
Do not treat it as a new operational event. Mark it as the result of a historical correction, assess the scope, and determine whether it affects earlier conclusions. Then verify the latest state of the asset against the current thresholds. Automatic sending of old notifications mixes measurement time with calculation time and makes response harder.
How should control values for acceptance be chosen?
Take at least the start and end of the range, the minimum, the maximum, a stable period, and the moment of a known event. Add one point calculated manually from the calibration document and one point on the reference change boundary. For dynamics, choose events with different amplitudes and frequencies. The sample should cover model risks, not random rows.
Does configuration audit make it possible to automatically recreate earlier results?
No. Information about the old and new values helps recreate context, but it is not a ready recovery mechanism. To roll back, you need preserved source data, the previous configuration, a tool for recalculation, and a test showing that the process gives the expected result. In the case of Inclify, you should not promise a full rollback of a published generation.
Who should accept the history recalculation?
The administrator confirms execution, completeness, and absence of technical errors. The engineer responsible for monitoring approves units, reference, expected direction of change, and control values. For contractual data, the owner of the documentation process should be included. One person may perform several roles, but both types of control must be completed and recorded.
Sources and further reading
- PostgreSQL 18 – Transactions - atomicity, invisibility of intermediate states, and transaction rollback.
- NIST SP 1800-25 – Data Integrity - data integrity, controls, copies, secure storage, and audit logs.
- Google SRE, chapter “Data Integrity” - corruption detection, recovery, and the difference between a copy and an archive.
- ISO 18674-1:2015 – Geotechnical monitoring by field instrumentation - concepts of plan, system, acceptance, zero measurement, and reference data.
- JCGM 200:2012 – International Vocabulary of Metrology - terminology of measurement, calibration, and metrological traceability.
What next
If you are planning a calibration or profile change for an operating asset, do not start with a full run. Choose one limited range, prepare five control values, and carry out an acceptance trial together with an engineer. Book a conversation with the Inclify team if you want to go through scope, tests, and alarm risk before launching the operation across the full history.