Geotechnical Investigation Data Software Problems: The 7 That Delay Reports, and How to Avoid Them

Why does the scope failure of rebuilding log drafting happen so often?

Because the log is the visible output, so it is what everyone points at when describing the problem. Say the words geotechnical software to a developer who has not worked in the sector and they will look at a borehole log, see a document with columns and hatching, and quote a rendering engine. It seems tractable. It is not.

A log carries years of accumulated detail: hatching conventions per material, abbreviation lists that vary by client, symbol libraries, and layout rules for how descriptions wrap against depth. Bentley gINT and OpenGround encode that, and Datgel adds genuinely useful tooling on top of the same ecosystem. Reproducing it inside a first release is the fastest way to spend a budget on something you already own.

The scope that actually pays is upstream of the log. Schema first ingestion with validation, project profiles that express client specific requirements as configuration, sample chain of custody, and laboratory scheduling with turnaround visibility. Then treat gINT or OpenGround as an output channel and push validated data into it. If a proposal you are reading includes replacing log drafting in phase one, the person writing it has not understood what they are quoting, and the schedule slip will land on the part of the project that mattered.

What goes wrong with migrating historic borehole and laboratory data?

Budgets disappear here quietly, because migration sounds like a task and is actually a series of judgement calls. Data already in AGS transfers or in a gINT project converts reasonably well. Everything else does not. Spreadsheets from subcontractors carry local conventions with no key. Older records use superseded description standards. Scanned paper logs are images, and turning them into structured records is an interpretation exercise that needs an engineer rather than a script.

Then there are the values that break statistics silently. Results reported as below a laboratory detection limit are frequently keyed as zero, as the limit itself, or as text, and each choice corrupts summary statistics downstream in a different direction. Units drift between percentage and decimal fraction for the same test across two laboratories. Depths are recorded to different datums on the same site when a level was revised mid investigation.

Decide honestly how far back is commercially worth converting, and be willing to answer none for scanned paper. A defensible sequence is to migrate the last few years of AGS and gINT data cleanly, index older project folders so they remain findable, and treat scanned logs as a later phase justified by a specific commercial need such as a regional database for a city you keep working in. Handle detection limits and units as an explicit design decision with your technical lead, agreed in writing, because retrofitting a convention across a migrated dataset is worse than migrating twice.

Why do the laboratory and log drafting integrations break after launch?

Because there is no such thing as the laboratory format. Each laboratory returns results in its own structure, some as AGS, some as a spreadsheet whose column order changes when they update their template, some as a PDF. An ingestion pipeline built against two laboratories meets laboratory three when a project demands a specialist test, and if the pipeline was two bespoke parsers rather than a mapped path with a review queue, laboratory three becomes a development ticket.

The failure that costs most is a result arriving for a sample reference that does not exist in your system, usually because a driller renumbered after redrilling or because the laboratory applied its own internal numbering. If the import silently inserts it, you now have an orphan result that will surface in a summary table. If the import fails without telling anyone, the result is discovered missing a fortnight later. Neither is acceptable, and the correct behaviour is a quarantine queue with a defined resolution path and a named owner.

On the drafting side, the break is usually schema drift. A client mandates an additional group or a different abbreviation list, someone adds it as a one off in the log template, and the data store and the log stop agreeing. Push validated data into gINT or OpenGround from one source, never edit in both, and run a comparison that reports where the drafted log differs from the record it was rendered from.

What happens when validation at source and the sample chain of custody are not covered?

Everything reverts to the three week reconciliation, which is the cost the project was funded to remove. Validation at source means a driller's daily return is parsed against a defined structure the evening it is created, and rejected with errors that name the row, the field and the rule, back to the person who produced it. A missing water strike, an out of range value or a duplicated sample reference then gets fixed while the rig is still on site. A day later it is a phone call. A month later it is a caveat.

The design problem is not the validator, it is compliance. Small drilling subcontractors do not own geotechnical software and will not buy it for one client. If your system demands that they do, they will keep emailing spreadsheets and your validation will apply to the tidy half of your supply chain. Give them a simple upload form or a template that produces valid data by construction, and make using it easier than not using it.

Chain of custody is the second half. The sample has to be the persistent object: logged at the rig with location, depth, type and condition, transferred under a manifest, receipted by the laboratory, scheduled against a test suite, and results returned against the original reference rather than a laboratory internal number. Turnaround tracking falls out of that for free, which matters because laboratory delay is one of the most common causes of a late factual report and at present nobody can prove where the time went.

Should you build custom or configure what you already own?

Configure if you are a small or mid sized consultancy producing logs on a modest number of projects a year with conventional client requirements. gINT remains widely used, OpenGround is the current path, and Datgel adds tooling that covers a surprising amount of what teams assume needs custom work. Before commissioning anything, get someone to audit what your existing licences already do, because consultancies regularly build validation and reporting they were already entitled to.

Configuration reaches its limit in one specific place. These products assume the people producing data hold the same software, so when a large part of your data arrives from subcontract drillers and laboratories who do not, the workflow becomes reformatting, and reformatting is where your weeks go. That is a design assumption rather than a product flaw, and no amount of configuration removes it.

So build when two or more of these are true. You run large programmes across many subcontractors. Clients impose bespoke schemas your team satisfies by hand. You want validation at source with a field application, which changes the economics of the whole investigation. You cover geotechnical and contaminated land on the same holes and maintain the location register twice. Or you work repeatedly in one geography and want the accumulated ground data to be a queryable asset you can price against. Even then, build the ingestion and data layer and keep the drafting you already own.

How do hidden costs get into the quote?

Laboratory interfaces are the most reliably underestimated. Each laboratory is its own ingestion path, and the count is usually higher than the initial list because specialist testing pulls in laboratories nobody remembered. Price them individually rather than as a line called laboratory integration.

Then the field application. Offline capability on remote sites is not a setting, it is an architecture, and adding photographs and geolocation to it adds storage, sync conflict handling and device management. Continuous instrument data such as cone penetration testing is a different problem again, because the volumes and the processing bear no relation to discrete sampling and it should be scoped separately or deferred.

Client schema variation is the cost that arrives after launch. If every new client requirement is a development ticket, you will be behind within a year and your team will quietly go back to spreadsheets for the awkward jobs. Insist that project profiles extend a base schema through configuration, and treat that as an acceptance criterion rather than an aspiration.

Finally, historic migration, which was covered above and belongs in this list because it is the item most often left as an assumption. And the human cost of running the quarantine queue: somebody has to resolve rejected files and orphan results every week, and if that is nobody's job the queue becomes a backlog and the validation becomes advisory.

What separates a geotechnical data build that works from one that fails?

Ask what happens when a laboratory returns a result for a sample reference that does not exist. The right answer is a quarantine queue with a defined resolution and an owner. A silent insert or a failed import that somebody notices a fortnight later tells you they have not run one of these in anger.

Ask how project specific schema extensions are handled without forking the codebase, and expect configuration with versioned profiles rather than a development ticket per client. Ask whether they intend to replace gINT or feed it, and treat replace as a disqualifying answer in a first release.

Ask how they represent a value below a laboratory detection limit and how they handle units, because getting either wrong corrupts every summary statistic downstream and it will not be obvious until someone questions a design parameter. Ask how a small subcontract driller with no geotechnical software submits data, since the answer reveals whether they have thought about your actual supply chain or only about your office.

Then settle ownership before kickoff: the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. Ground data can be re examined in a dispute a decade after the investigation closed, so control of both the records and the system that validated them is a professional risk question rather than a commercial preference.