Geotechnical Software: Keep Field Logs, Samples, and Design Inputs Traceable

Geotechnical software supports work with ground investigation data, engineering models, or both. One tool may manage borehole logs and laboratory results, while another analyzes a foundation, slope, or excavation. Choosing well starts with identifying which part of that workflow your team needs to improve.

This article focuses on geotechnical data management and its handover to analysis. It covers field records, samples, lab results, units, coordinates, review, exchange formats, migration, and reporting. It also explains how to keep observed facts distinct from engineering interpretation and selected design inputs.

Separate ground data management from analysis

A data platform organizes what staff observed, sampled, tested, and reviewed. An analysis application uses selected inputs and assumptions to examine an engineering question. These tools may connect, but they serve different roles.

For example, a borehole record can describe a location and sequence of observations. An engineer may use that evidence alongside other information to build a ground model. The model is an interpretation, not a duplicate of the raw log.

Bentley’s OpenGround overview illustrates a platform for collecting, managing, and sharing geotechnical data. Use it as a category example. Confirm specific modules, exchange versions, and connected workflows against your project needs.

Also write a clear scope before procurement. A data migration project should not quietly expand into replacing every analysis tool in the office.

Use stable identifiers through the investigation

Give each project, location, sample, test, and monitoring record an appropriate identifier. Preserve the parent-child links so staff can trace a result to its source.

A laboratory sample reference may differ from the field reference. Keep the mapping explicit rather than asking reviewers to match names manually. The same applies when a subcontractor uses its own project code.

Next, test a renamed location. Its identifier should preserve the history while the display name changes. Creating a second location record can split related samples and reports.

Also define duplicate rules. Two rows with similar descriptions may represent valid separate observations. A duplicate check should use the right keys and route uncertain cases for review.

Record coordinates and depth references clearly

A location needs more than a pair of numbers. Record the coordinate system, relevant reference information, source, and review state. The project team should confirm the appropriate basis.

Likewise, depth and elevation are different concepts. The software should preserve the reference used for each value. A field observation and a later model surface should not silently share one ambiguous field.

Also distinguish measured values from estimates. If staff use an approximate location during planning, keep that status visible until the project confirms a better source.

During a demo, import a dataset with mixed or missing references. The system should flag the uncertainty rather than place every point confidently on a map.

Make field capture work with incomplete information

Field teams may need to record observations before all details are available. The software should support a clear draft and review process. Do not force users to enter invented values to finish a record.

Use controlled lists where they improve consistency, but allow the notes and detail that the approved logging process requires. A short picklist should not erase important context.

Also test offline capture if your work needs it. Create records without a connection, then reconnect and inspect the synchronization. Confirm how the system handles conflicts and repeated uploads.

For general field evidence principles, Anomoz’s guide to inspection checklist apps explains useful capture and review controls. Apply them within the geotechnical team’s actual logging methods.

Connect samples and laboratory testing without orphan records

A sample should link to the location and relevant depth or collection reference. A test result should link to the correct sample and method. These relationships matter when files arrive from several organizations.

Keep the requested test and returned result distinct. A planned laboratory schedule does not prove that the lab completed the work or that the project accepted the output.

Next, test a revised result and an unmatched sample reference. The import should preserve the source file and route the exception. Attaching a result to the closest-looking record can create a misleading report.

Anomoz’s article on laboratory information management explains the broader sample and test workflow. Define the handover so the project and laboratory agree on identifiers, units, and correction rules.

Keep observations, interpretations, and design values distinct

Observed ground descriptions and test results provide evidence. Interpretations organize that evidence into a view of ground conditions. Selected design values add another decision layer.

Store those roles separately where the workflow needs them. A later engineering interpretation should not overwrite the original field description merely to make the report look consistent.

Also record who selected an input, the supporting evidence, and the intended analysis. A value suitable for one model or location may not apply elsewhere without review.

This separation helps the team revise its understanding when new information arrives. Staff can update the interpretation while preserving the source record that supported the earlier decision.

Use data exchange formats as structured handovers

An exchange format defines how records and fields move between organizations. It does not guarantee that the content is complete, correct, or suitable for design.

The British Geological Survey’s AGS data guidance describes checks for formatting, identifiers, parent records, duplicates, and other submission details. Its specific coordinate requirements relate to that receiving service, so confirm the requirements of your own client and project.

When a contract specifies AGS or another format, agree the version and required content. Then test the actual exported file with the receiving team.

Also preserve null values honestly. Missing data should not become zero merely to satisfy a numeric field. The exchange should carry the correct meaning as well as a valid structure.

Review imports before they enter issued outputs

Load new data into a review area where staff can inspect mapping, units, references, and exceptions. A successful import is only the first step.

Use targeted validation rules. These may check missing keys, overlapping intervals, unknown codes, or unmatched samples. Each message should identify the affected record and next action.

Also distinguish a format error from an unusual but valid observation. The system should not discard important field evidence simply because it falls outside a common pattern.

After review, record the release decision. Issued logs and reports should identify the accepted data version rather than draw from an uncontrolled mix of drafts and final records.

A worked example: a corrected sample depth

Consider an illustrative investigation where a laboratory result links to a field sample. During review, the team discovers that the sample’s recorded depth needs correction.

First, preserve the earlier value and source record. Route the correction to the authorized reviewer and record the reason. Next, identify the logs, reports, and exported datasets that use the sample.

After approval, update the current record and regenerate the affected draft outputs. Keep the revision trail so another reviewer can see what changed.

If the team already issued a report, follow the project’s document correction process. Do not silently replace the file while leaving the recipient unaware that an input changed.

Finally, review any analysis handover that used the sample. The responsible engineer should decide whether the correction affects the selected inputs or conclusions. The software can flag the dependency without making that judgment on its own.

Control logs, templates, and report versions

A log template controls how data appears, but it should not hide missing information or change the meaning of a field. Have the relevant technical reviewer approve important template changes.

Also test units, symbols, legends, and long descriptions. A report that looks correct on one tidy borehole may truncate or misplace information on a more complex record.

Anomoz’s guide to document revision control explains related approval and history principles. Apply them to issued logs, templates, and project reports.

Keep the source data version and template version with the issued output where practical. This helps the team reproduce the report later, even after the live database changes.

Plan migration around meaning, not just row counts

Old projects may use different codes, units, schemas, and report libraries. Map those differences before bulk conversion. Matching the number of imported rows does not establish that the records kept their meaning.

Choose a sample with several project types and known difficult cases. Compare locations, intervals, samples, results, attachments, and report output against the original.

Also retain a usable archive or source copy under the team’s policy. Some legacy detail may need a separate treatment rather than a forced conversion into the new schema.

Finally, test a complete export from the new system. The team should understand how it will retrieve structured records, relationships, and supporting files if it changes platforms later.

Choose geotechnical data management software with a full pilot

Include field staff, data managers, laboratory contacts, report authors, and analysis users. Give each group a small acceptance checklist based on its actual handover.

1. Define records, identifiers, units, and references.
2. Capture field data and import laboratory results.
3. Resolve an unmatched reference and an approved correction.
4. Issue a log and test a structured data exchange.
5. Trace selected analysis inputs back to reviewed evidence.

Measure re-entry, import corrections, time spent producing logs, and effort to assemble a review package. Compare these with a baseline and inspect any remaining private spreadsheets.

Review license modules, migration, configuration, training, support, storage, and integrations. Confirm the exact exchange versions and export rights the proposed plan includes.

Start with one representative project. Expand once staff can follow a result from field record through review and report without guessing which file is current.

Make access work across project partners

Ground investigation data may pass between consultants, contractors, laboratories, and clients. Give each party the access it needs for its role, while preserving a clear owner for the accepted project record.

For example, a laboratory may upload results without changing field observations. An external reviewer may need to inspect issued data without editing drafts. Test those roles with ordinary accounts rather than only an administrator.

Next, inspect attachments and exports. Restricted screens do not establish a complete boundary if a shared download exposes unrelated projects. The same access rules should apply to the supporting evidence.

Also plan project closeout. Decide who retains access, who receives the final structured export, and which files form the issued archive. A live database and a handed-over project package may serve different purposes.

Finally, test the receiving party’s experience. Ask them to open a log, locate a sample, inspect the relevant result, and identify its review state. A technically successful transfer is less useful if the recipient cannot understand the record without repeated clarification.

Choose a traceable route from ground record to design input

Useful geotechnical software preserves evidence while supporting clear interpretation and handover. Test a project with corrections and external data. Then choose the setup that helps every reviewer explain where a value came from and how the team used it.