Open a project folder and count the AGS files.
- BH_AGS.ags
- BH_AGS_v2.ags
- BH_AGS_final.ags
- BH_AGS_final_revised ags.
One sits in SharePoint. Another arrived by email. A third was transferred through a file-sharing service. Someone may also have a local copy on their desktop.
Then someone asks a question that should be simple: Which AGS file is current?
The team compares timestamps, filenames and email history. The laboratory is asked what it sent. The consultant checks what it downloaded. Reporting pauses while everyone works out which dataset should be used.
AGS gives geotechnical projects a structured way to exchange data. But a structured file format does not, by itself, create a shared approval workflow. The difficulty is not AGS. It is AGS file version control: how the project decides which submission is current.
A standard format does not automatically create one current dataset
On a site investigation programme, AGS data can pass through several organisations. A laboratory exports data. The site investigation (SI) contractor receives it. A consultant imports it for interpretation and reporting. The client may receive the same dataset as part of a wider delivery package.
That exchange can generate several legitimate revisions. A laboratory may correct a data entry, add newly completed tests, respond to a review comment or issue a wider package containing additional records. Each issue may be valid at the time it is sent.
The problem starts when the project relies on filenames and folders to explain the status of those revisions.
•A file called final may be superseded the next day.
•Newer timestamp does not necessarily mean the file has been reviewed or approved.
•One organisation’s SharePoint may differ from the copy held by another party.
•Emailed correction may never reach everyone using the earlier dataset.
At that point, “current” becomes something the team has to reconstruct rather than something the workflow defines.
Why the wrong AGS revision matters
For the consultant, the AGS dataset is an input to interpretation, engineering assessment and reporting. If the wrong revision is imported, time may be spent reviewing data that have already been corrected or superseded.
For the asset developer or client, the concern is governance. Decisions should be based on the dataset the project has accepted, not simply the copy with the most convincing filename.
For the SI contractor, uncertainty around the current AGS issue creates coordination work: confirming what the laboratory sent, what the consultant received and whether a later correction exists.
For the laboratory, it can mean repeated questions and repeated exports: “Can you resend the latest AGS?” or “Is this the file we should be using?”
The cost is not only the time spent searching. If different parties work from different revisions, the project can temporarily have several versions of the truth.
Current should be a status, not a filename
A filename is useful for identification. It is a poor substitute for governance.
A project should be able to establish the current AGS dataset from the workflow itself. That means being able to answer, without comparing folder names:
• Which dataset was submitted?
• Who submitted it and when?
• Was it reviewed and approved?
• Has it been superseded by a later submission?
• Which dataset should permitted stakeholders use now?
This is the difference between file storage and AGS file version control. Storage tells you what files exist. A controlled workflow tells you which state each submission is in and which one represents the approved project record.
“Current means approved, not renamed”
AGS version control needs approval and traceability
AGS datasets are not static during an active laboratory programme. New tests are completed, comments are resolved and corrections can be required. A current dataset today may legitimately be superseded tomorrow.
That is why the objective should not be to prevent revisions. The objective is to make the revision path clear.
If a later AGS submission replaces an earlier approved dataset, the project should retain the history rather than silently overwrite it. The previous issue, the new issue and the actions that moved the dataset from submission to approval should remain traceable.
This becomes particularly valuable later in the project, when a consultant, designer or client needs to understand which dataset was available at a particular point in time and why a later issue replaced it.
How LabHarmony changes the AGS handover
LabHarmony is geotechnical laboratory management software built around the geotechnical site investigation laboratory workflow. Instead of treating AGS as another disconnected file drop, the submission can sit within the same shared project environment used to manage tests, results and approvals.
Permitted stakeholders can work from a common workflow in which submission and approval are recorded actions. The current approved dataset is therefore identified by its project status, not by whether someone added final, final_v2 or revised to the filename.
The principle is simple:
AGS submitted → reviewed → approved → current shared dataset
Request a free LabHarmony demo
If a later issue is required, it follows the workflow again and the audit trail remains connected to the project record.
This does not replace AGS as an exchange format. It provides governance around the exchange: one place to see what was submitted, what has been approved and what is current for the people who are authorised to access it.
Different from approving an individual test result
The question “Which AGS file is current?” is related to result approval, but it is not exactly the same problem.
An individual laboratory test result may be reviewed and approved against a specific test. An AGS delivery can bring together structured data from many samples and tests into a wider exchange dataset. That package can itself be reissued as the programme progresses.
A project therefore benefits from both levels of traceability: clear approval of the underlying laboratory results and a clear record of which AGS dataset is the current shared issue.
Keeping those states visible reduces the need to infer project status from folders and filenames.
One approved dataset, one trail
When someone asks which AGS file is current, the answer should not require a search through SharePoint, email and local folders.
The project should be able to identify the current approved dataset and see the submission and approval history behind it.
With LabHarmony, AGS file version control become a workflow state rather than a naming convention.
One approved dataset. One audit trail.
If your site investigation programme still decides which AGS file is current by comparing filenames, see how LabHarmony can provide a clearer, traceable path from data submission to approved project dataset.
Request a free LabHarmony demo