Version Control and Asset Record Preservation

Version Control and Asset Record Preservation

A borewell asset record must remain usable through changes in equipment, operating duty, ownership and personnel. Version control identifies what changed and which issue was used for a decision. Preservation keeps the underlying evidence accessible and intact. Neither function should depend on one person remembering which file named “final” is the correct one.

The essential distinction is between a working file, an issued record and a superseded issue. Working files support preparation. Issued records support action. Superseded issues preserve history and must remain clearly distinguishable from current instructions. A reliable system makes the current instruction easy to find while retaining the evidence needed to understand earlier decisions.

Separate the types of records

Organise raw observations, corrected datasets, calculations, models, forecasts, equipment records and operating instructions as related but distinct objects. Each has a different reason to change. A new forecast month does not necessarily require changing the pumping-test dataset. A corrected flow scaling factor may affect several calculations while leaving the original field file untouched.

Use a short register to connect these objects. Record a stable identifier, revision, date, status, owner and dependencies. The register should show which dataset and method support an issued result. This avoids relying on folder proximity as evidence that two files belong to the same calculation.

Define a version rule that people can follow

A practical revision rule should distinguish issued changes from minor working edits. The exact naming convention can fit the organisation, but it must be consistent and documented. Include the stable asset or document identity and a revision marker. Avoid embedding so much descriptive text in a filename that it becomes difficult to use or is truncated by another system.

Record a meaningful change note. “Updated” is insufficient when the revision changes the permitted operating rate or a calculation method. State what changed, why it changed and which downstream decisions were reviewed. The change note is not a substitute for the full technical record, but it should direct the reader to the relevant evidence.

Version formulas as well as data

A spreadsheet can produce a different answer after a formula edit even when its input table is unchanged. Preserve the equation, units, cell or variable mapping, assumptions and test cases associated with an issued calculation. Where software is used, retain the relevant version and configuration information needed for reproducibility.

Do not assume that a protected sheet is a verified calculation. Protection can reduce accidental edits, but it does not establish that the formula or inputs are correct. Review the calculation logic and test it against independently calculated examples.

Version models separately from forecasts

A model describes relationships and assumptions used to estimate a response. A forecast applies a model or calculation to a future period and selected inputs. Several forecasts may use the same model version. Conversely, the same forecast period may be recalculated after a model change. Keep these relationships explicit.

When an issued forecast changes, preserve the previous issue and the reason for revision. This allows the organisation to evaluate the decision made at the time. Replacing the original forecast with a hindsight-adjusted version prevents meaningful performance review and can conceal whether the initial assumptions were reasonable.

Preserve configuration changes

A well’s physical identity may remain stable while the installed pump, intake depth, pipework, controls or instrumentation changes. Record the configuration and effective dates. Link maintenance and replacement work to the operating instruction that followed it. A trend across a configuration change should identify that change instead of presenting the entire series as a like-for-like comparison.

Capture as-found and as-left conditions when interventions affect performance. Preserve removed equipment identities where they explain historical records. A future reviewer may need the old pump curve or sensor scaling to interpret an earlier result. Deleting obsolete equipment information can make otherwise intact data impossible to understand.

Use integrity checks for the correct purpose

A cryptographic checksum can identify whether a file differs from a recorded reference. Store the algorithm and value in the package index where integrity checking is required. Recompute the checksum after a controlled issue and preserve it with that issue. Do not expect an old checksum to match a legitimately revised document.

Integrity checking does not prove authenticity of the engineering judgment, measurement accuracy or approval status. It answers a narrower question about file content. Combine it with controlled issue records, appropriate access and technical review. A preserved mistake remains a mistake; version control makes its history visible and supports a traceable correction.

Design access around responsibilities

Give personnel access appropriate to their tasks. An operator needs dependable access to current instructions and relevant records. An analyst may need working copies of datasets. The authority to issue a revised operating instruction should be defined separately from the ability to edit a file. This reduces the risk that a convenient local change becomes an unauthorised operating direction.

Keep access arrangements practical enough that staff do not bypass them by creating uncontrolled personal copies. Provide a clear route for requesting changes and reporting errors. Record who is responsible for maintaining the current index when personnel change. An access-control system without an accountable owner will become outdated.

Back up for recovery rather than reassurance

A backup is useful only if the required records can be restored and interpreted. Define which files, metadata and configuration information must be recoverable. Keep copies in arrangements appropriate to the organisation’s risk and retention needs, including separation from the failure that could affect the working copy. Avoid treating a synchronized deletion across devices as evidence of preservation.

Test restoration on a representative package. Confirm that files open, references resolve, datasets retain their meaning and the current issue can be identified. Record the result and any exceptions. A successful file transfer alone does not demonstrate that a complete operating record has been recovered.

Plan for format and software changes

Long-lived assets can outlast software versions and individual storage platforms. Preserve accessible representations of critical records alongside native working formats where appropriate. For example, retain readable reports, structured data and calculation documentation so future users are not dependent on one unsupported application.

Migration should be controlled. Compare record counts, identifiers, values and representative outputs before and after transfer. Preserve the original package and document the conversion. If a formula or visual element cannot be reproduced exactly, identify the limitation instead of declaring the migration lossless solely because the files were copied.

Handle conflicting copies

When two issued-looking files disagree, do not resolve the conflict by selecting the newest filesystem timestamp. File copying can change timestamps, and later editing may not have been authorised. Compare the internal revision, approval record, source dependencies and issue register. Retain both files until the responsible owner resolves their status.

Document the resolution and identify any actions taken using the wrong copy. Withdraw or clearly mark superseded operator instructions through the project’s controlled process. The goal is not merely to clean the folder; it is to ensure that the installation is being operated against the correct current instruction.

Fictional preservation exercise

A site must transfer its borewell records to a new maintenance contractor. The outgoing folder contains a current operating sheet, three historical test reports, raw logger exports, a correction log and a spreadsheet forecast. During a restoration test, the recipient can open the files but cannot identify which corrected dataset fed the operating sheet.

The transfer is therefore incomplete in a practical sense. The team adds the missing dependency reference and verifies one material calculation before acceptance. No technical values need to be invented or rewritten. The improvement is in the connection between existing evidence and the instruction that relies on it.

Define the issued package as a controlled object

Treat the issued package as a set of files with an index, not as a loose email attachment. Record the package identifier, issue date, revision, included files and intended recipient or use. This lets the team distinguish a complete issue from a partial collection copied later. The package can contain several native formats while still having one clear issue identity.

Identify which files are authoritative for operation and which provide supporting evidence. A historical report may remain valuable without being the current instruction. The index should make that distinction visible. Do not rely on folder order or file-modification dates to indicate authority.

When a revised package is issued, state whether it replaces the complete earlier package or only identified components. Partial updates can be efficient, but the recipient must know how to assemble the current set. An ambiguous update can leave a mixture of incompatible revisions in active use.

Use a meaningful change classification

Classify changes by their effect rather than only their size. A one-character unit correction can be more important than several pages of editorial improvement. Distinguish changes to technical values, assumptions, operating limits, equipment configuration, data treatment and presentation. Record which categories trigger review of dependent decisions.

An editorial correction may leave technical conclusions unchanged, but verify that it does not alter meaning. Replacing “maximum observed” with “maximum permitted” is not a cosmetic edit. The issue process should recognise that wording can change the apparent authority of a value even when the digits remain the same.

For each material change, identify the evidence and review. This allows the recipient to focus on what matters without comparing every line manually. The change record should be concise enough to read and specific enough to support action.

Establish retention according to purpose

Retention should consider operational life, contractual requirements, applicable obligations and the need to reconstruct material decisions. This article does not prescribe a universal retention period. The responsible owner should define the period and scope with appropriate advice for the project.

Distinguish routine working drafts from issued evidence and irreplaceable observations. Deleting redundant temporary files can be reasonable, but raw measurements and issued decisions may require longer preservation. The retention rule should be applied deliberately rather than through an automatic cleanup that cannot distinguish record value.

Record disposal where it affects the evidence available for future review. A later user should not interpret a missing file as proof that the work never existed or assume it remains recoverable. Transparent retention decisions support honest statements about what the archive can and cannot establish.

Test recovery after a realistic failure

Select a failure scenario relevant to the arrangement, such as loss of the working device, accidental deletion or loss of a user account. Restore the required package through the actual process. Confirm access to the index, current instruction, raw evidence and supporting configuration. The test should assess the records needed for operation, not only an easily restored sample file.

Measure whether the restored package is complete and usable. Check file integrity where applicable, but also test references and interpretation. A byte-identical dataset without its dictionary may still be unusable. Preserve the recovery result and any improvement action.

Repeat the test when the storage or access arrangement changes materially. A successful test on an old platform does not prove the new process. The scope and frequency should reflect the project’s risk and practical needs rather than an unsupported universal interval.

Preserve calculation environments selectively

For calculations that depend on software behaviour, record enough environment information to reproduce the result. This may include application version, relevant settings, macros, scripts or model configuration. The necessary detail depends on the method. A simple multiplication does not need the same environment record as a specialised numerical model.

Avoid preserving a complex environment without a readable explanation of what it does. Future users need both execution capability and technical understanding. Retain input definitions, method description and representative verification cases so the calculation is not a black box tied to one machine.

If the environment cannot be reproduced, state the limitation and preserve accessible outputs and evidence. Do not claim complete reproducibility merely because the final PDF remains readable. Plan a controlled reimplementation or specialist review where the calculation remains important to future decisions.

Review archive migrations as engineering changes

Moving an archive can change paths, permissions, filenames and metadata. Test these effects before retiring the original location. Compare the file inventory and verify that current references still resolve. Where paths must change, update the index and retain a mapping from the earlier arrangement.

For converted formats, compare content as well as file counts. A spreadsheet export may preserve values but lose formulas or comments; a document conversion may alter equations or tables. State which representation is authoritative and what the conversion preserves. Do not use the phrase zero loss without checking the relevant content.

Keep a recoverable copy of the pre-migration package until the migration is accepted under the owner’s process. This provides a practical rollback if a missing dependency or conversion defect is discovered. Record the acceptance evidence rather than relying only on the transfer tool’s success message.

Manage contractor access at handover

Confirm that the incoming custodian has access to the records and that the outgoing custodian’s responsibilities are closed explicitly. Transfer ownership of registers and current instructions through the agreed process. A shared link controlled by a departing individual can become inaccessible even though everyone believes the handover is complete.

Review which records may be shared and which contain sensitive customer or asset information. Provide the information needed for the authorised task without unnecessary exposure. Preserve technical meaning when preparing a redacted or public version, and keep the controlled internal source distinguishable from that derivative.

Ask the receiving custodian to demonstrate retrieval and version identification. This verifies that access and understanding have transferred together. The demonstration can also identify undocumented habits that need to become part of the formal record.

Archive closure questions

Can the current operating instruction be identified without opening every file? Can an earlier issued decision be reconstructed? Can the required package be restored after the chosen failure scenario? Can a corrected dataset be traced to its raw source and transformation? These questions test the archive’s practical function.

Where the answer is incomplete, assign a specific correction. The goal is a dependable asset record that survives personnel and platform changes. A large archive with uncertain authority is less useful than a well-indexed set of preserved records whose relationships are clear.

Questions about preservation

Should superseded files be deleted

Preserve issued history according to the project’s retention requirements while clearly distinguishing it from current instructions. Removing outdated field copies from active use is different from destroying the historical record.

Is cloud storage automatically a backup

Not necessarily. Recovery depends on the service configuration, retention, access and the failure being considered. Test the actual recovery process rather than relying on the storage label.

Can one master spreadsheet hold the whole project

It can be convenient, but it must still preserve identities, revisions, raw evidence and dependencies. A single editable file can become a single point of confusion if it mixes all record types without controls.

What demonstrates a successful handover

The recipient can identify the current issue, restore the required package, interpret the data and trace a material operating decision to its supporting evidence. Record the demonstration and resolve exceptions before closing the transfer.

Source notes

The benchmark attachment is a directory, not a recovered article body or measurement dataset.

Content-structure method attribution: Eugen Ullrich, eullrich.com, GEO Content Engineering, CC BY 4.0. No ranking or AI citation guarantee is implied.