Consider the asymmetry at the heart of ground engineering. Site investigation typically accounts for 0.2% to 1.5% of a project's total cost, yet the US National Research Council has observed that unforeseen ground conditions "can, and often do, raise costs by 10 percent or more" (National Academies). A peer-reviewed study of 67 UK highway contracts found an average cost overrun of 28%, with earthworks and ground conditions among the leading drivers (Amadi, Research Leap).

The instrument that manages that risk is one of the oldest deliverables in the profession: the boring log or borehole log, depending on which side of the Atlantic you drill. Every geotechnical engineer knows how to create one. The steps have been stable for decades, taught the same way in every firm.

Which is exactly why it's worth asking a harder question. If the steps of soil and borehole logging are so well understood, why does ground data still fail projects so often? The answer, in our experience across thousands of investigations, is that logs don't break inside the steps. They break in the handoffs between them.

What are the main steps involved in creating a soil boring log?

Creating a soil boring log involves six steps: setting up the borehole record (location, coordinates, elevation), logging drilling progress and observations, sampling and in-situ testing, describing and classifying each stratum to a standard, recording groundwater and well construction, and transcribing the field record into the final log deliverable.

In practice:

1. Set up the borehole record
   Project, hole ID, coordinates and coordinate system, ground elevation, rig, crew, drilling method, date. Get the position wrong here and every layer beneath it is wrong too.
2. Log the advance
   Depths drilled per run, drilling observations, casing, water losses- the running diary of the hole.
3. Sample and test in situ
   Recover samples at intervals, record SPT blows per foot (and refusal where the criterion is met), recovery percentages, RQD and TCR in rock, CPT or other in-situ tests where specified. Label every sample.
4. Describe and classify each stratum
   Soil and rock descriptions to the governing standard- USCS and ASTM in North America, BS 5930, EN ISO 14688/14689, or a national standard such as NBR elsewhere- with layer boundaries by depth.
5. Record groundwater and well construction
   Water strikes, standing levels, and how the hole is completed: pipe, screens, bentonite, gravel pack.
6. Produce the log
   The field record is checked, transcribed into the office system, and rendered as the final boring log- the document the client, the designer, and, years later, the claims consultant will all read.

Nothing in that list is controversial. The trouble starts when you look at what happens between the numbers.

Where borehole logging actually breaks

Between the field and the office: the transcription tax.

On most sites, steps one through five still happen on hand logs- paper forms from drillers and subcontractors that the office then processes and re-enters. Cross-industry research puts manual data entry error rates at 1% to 4% (DigiParser), and a boring log runs that gauntlet more than once: field notes to office log, office log to report, report to whoever needs the data next. Each pass is a chance to turn 100/6 blows into something else, shift a layer boundary by a foot, or attach a lab result to the wrong sample. The cost of the error grows with distance from the borehole: at the rig it's a correction, in design it's rework, in a claim it's the dispute file.

Between the sample and the lab: lost custody.

A sample jar labeled in marker in the rain has to survive the truck, the storage shelf, and the lab bench with its identity intact. Every mislabeled or ambiguous sample silently corrupts step four, the classification the whole log rests on.

Between the crew and connectivity: the office assumption.

Much of the current generation of logging software quietly assumes the field has signal- "offline supported" frequently means offline-after-sign-in. Boreholes are drilled where the infrastructure isn't. A logging tool that degrades without connectivity isn't a field tool; it's an office tool that travels.

Between the log and the future: the report dead-end.

The final failure is structural. Step six usually ends in a PDF, and the structured data behind it dies there. The next phase re-keys it; the next project can't find it; ten years later a designer is recreating boreholes from a PDF appendix the same firm produced. The industry already proved the alternative works- the AGS electronic data transfer format has been used across the UK, Australia, Hong Kong, Singapore, and New Zealand for more than 30 years precisely because structured digital transfer reduces re-keying errors (AGS). That lesson has been absorbed for data exchange. It still hasn't been absorbed at the point of capture, where the errors actually enter.

What software options are available for soil boring log analysis?

Software for soil boring log creation and analysis falls into three broad categories, and the differences matter more than the feature lists suggest:

• Field logging apps digitize steps 1–5 at the borehole. The good ones validate data at entry and output structured records; the weaker ones are electronic paper- faster forms that still end in a document.
• Geotechnical data management systems hold the logs as database objects- boreholes, layers, samples, test values- and drive the analysis: log plotting, cross-sections, parameter plots, lab data management, standards-compliant reporting, and exchange formats like AGS.
• General-purpose workarounds- spreadsheets and CAD- which every firm has used and every firm eventually outgrows, because a boring log in a spreadsheet is a drawing of data, not data.

Whichever tools you evaluate, the criteria come straight from the failure points above: validation enforced at the point of entry, not the office; full capability offline, with no prior sign-in; sample traceability bound to the record at capture; structured output a database can ingest without re-keying; and data that lands in infrastructure your firm owns.

How GeoDin Onsite and GeoDin close the handoffs

GeoDin Onsite is a Windows field application for tablets, laptops, and desktops, designed around exactly those handoffs.

The field-to-office handoff becomes a validation gate instead of a transcription step. Compulsory fields are color-coded red; conditional logic enforces acceptable value ranges; auto-population removes the classic re-keying errors- the next interval's from-depth carries over from the prior row, to-depths calculate automatically, and defaults like foreman, rig, crew, unit system, and coordinate system fill themselves. A form cannot be exported or published as final until it passes validation, and draft PDFs carry a visible draft watermark. Behind the forms sits a geo-data standard schema- five supported field standards, including BS 5930 and EN ISO 22475 SEP 3- so what reaches the office is a standards-compliant boring log, not a form to be deciphered.

The sample-custody handoff is fixed the moment the sample exists. Onsite prints QR-coded labels- unique sample ID, project, location, depth- on ZPL thermal printers such as the Zebra ZQ600 series, with a second configurable printer for red hazardous-material labels. Scanning a label in the lab pulls the sample's record straight up so photos and results attach to the right sample. Position is recorded against an EPSG coordinate code at entry, with external Bluetooth RTK receivers supported where survey-grade accuracy is required.

The connectivity assumption is removed entirely. Onsite is offline-first field data capture. Forms fill with no connection, save automatically on close, and back up on a timer with multiple retained versions. Every form behaves like a single piece of paper- owned by one person at a time, published to a shared shelf or handed in as final- so two crews can never silently overwrite each other's logging.

The report dead-end is where the second product takes over. Onsite publishes a structured GeoDinML file that imports directly into GeoDin, the geotechnical data management software, where boreholes, layers, samples, and test values become permanent database records- driving the log plots, cross-sections, and parameter analysis, plus AGS export, for the life of the firm, not just the project. GeoDin stores that data in Microsoft Access or SQL Server, or in Postgres or Oracle for fully air-gapped deployments, and the firm decides where it lives: on-premise, private cloud, or local.

What that looks like in numbers: Fugro Brazil

Fugro Brazil's geotechnical investigation team is the clearest evidence that fixing the handoffs fixes the pipeline. Their starting point was candid: "We didn't have a metric before of how long it took us from finalizing the field work until it reached the client's hands," says Luana Barbosa, Supervisor of the Reports Team.

The team paired GeoDin Onsite for field capture with GeoDin as the central hub. "Data from the field is already integrated into GeoDin. We receive the field information in PDF and importable file formats, which allows us to bring all the data directly into GeoDin," Barbosa explains- manual transcription eliminated, with CPT calculations, recovery percentages, soil classification, and geological hatching automated to the Brazilian NBR standard.

Delivery time from field completion to the client fell from 41 days to 5- an 83% reduction, roughly 36 days per project, measured from a late-2023 baseline to December 2024. Rework was eliminated, and the team's hours moved from data entry to analysis and QC. "With GeoDin, we eliminated rework and accelerated delivery with better quality," Barbosa says.

Why GeoDin Onsite stands apart

Most field logging tools on the market solve one handoff and leave the rest open. Field-only apps produce a faster report- and the data still dies in it. Cloud-first platforms handle sync- until the crew is on a site with no signal and an app that won't start without one. Generic forms apps capture forms- not validated engineering objects a geodatabase can use.

GeoDin Onsite is different because it was never designed as a standalone app. It is the field end of a geotechnical data platform: truly offline-first, validating against real geo-data standards at the point of entry, binding sample identity to the record the moment it exists, and delivering structured data straight into GeoDin - a database your firm owns, on infrastructure your firm chooses.

Curious what a boring log looks like when it never gets re-keyed? Try GeoDin Onsite in the field on your next investigation- or get in touch with our team if you'd like to learn more first.