The Document That Is Not Data
A PDF boring log is not data. It is a picture of data - formatted and frozen at the moment the drafter clicked export.
That distinction costs firms nothing on a clean, single-phase investigation. The PDF ships, the client accepts it, the project closes. But Phase II environmental site assessments rarely work that way, and neither does geotechnical investigation. Scope expands. New borings get authorized. Lab results come back anomalous and require a supplemental push. The project you quoted is not the project you finish.
Every mid-project change triggers the same sequence when logs exist only as PDFs: pull the original field notes, re-enter the data, rebuild the figure, regenerate the cross section, recheck the QA. The PDF contributes nothing to that chain. It is a record you must walk around.
The Revision Multiplier
The first pass at a boring log has a cost most firms can estimate: field hours, drafting hours, QA review. What rarely gets calculated is what happens when the project loops back.
A 20-boring Phase II investigation that runs one round of client revisions and one supplemental boring program is not a 20-boring job. It is closer to a 26-boring project with partial rework on 20 existing records. Except when logs live only in PDFs, the rework is never partial. The original data must be re-entered. Cross sections must be rebuilt. Site figures drafted in AutoCAD or Corel Draw must be reopened, revised, and reexported. Each revision cycle runs the full drafting clock regardless of how many borings actually changed.
That is the revision multiplier. One additional boring program does not add one round of drafting work. It compounds against every deliverable produced from frozen data.
Where the Problem Lives
The PDF is the symptom. The actual problem is that most log workflows produce a document as the primary artifact rather than a structured record that can be updated and connected downstream.
Whether the document is a PDF, an Excel sheet formatted for printing, or an AutoCAD-drafted log matters less than whether the underlying data is accessible. When the deliverable and the data are the same file, every downstream operation becomes a manual translation step. Cross sections do not update when the log changes. The 3D model does not know a new boring was added. The site map requires a separate editing session in a separate application.
A significant portion of the environmental consulting and geotechnical industry currently builds logs using software already on their computers - Excel, Corel Draw, Adobe Illustrator, AutoCAD - because purpose-built log software has historically meant upfront license fees and per-machine installation. The workaround functions for producing the first deliverable. It fails at the revision.
Each of those tools handles a different piece of the deliverable. None of them share a source record. Revision becomes a file management problem rather than a data problem, and file management problems scale with every change request.
What Changes When the Log Is a Record
When logs exist as structured records rather than static files, the revision cycle shrinks because the work becomes additive rather than repetitive.
One of our clients, a managing partner at an environmental consulting firm, told us: "LOGitEASY software has allowed us to quickly generate custom boring logs in USCS format along with associated cross sections. We had a few template customization requests which LOGitEASY was willing to make promptly, allowing us to most accurately depict the subsurface conditions."
The cross sections in that account are not a separate deliverable produced in a second tool. They generate from the same underlying record as the log. Add a boring and the cross section updates. Correct a blow count and the figure reflects it. The log and the figure are two views of the same data, not two files that need manual coordination to stay synchronized.
This does not eliminate revision work. It bounds it. The revision hours go to the new data, not to rebuilding every downstream deliverable that was already correct before the scope changed.
The Archive Problem
There is a second version of the PDF problem that longer-established firms carry: years of archived boring logs that exist only as static files. Investigation records from prior Phase II programs, subsurface data from completed projects, historical site characterization work - all of it frozen in documents that cannot be computed against.
That archive has real value for subsequent investigations, due diligence reviews, expanded site characterization, and liability defense. As PDFs, it is inaccessible for any computational purpose. The data cannot be pulled into a 3D model, driven into a cross section, or queried spatially. It can be read and printed, and that is the limit of its utility to any future project.
PDF boring log import, now available, addresses this directly: upload legacy boring log PDFs and the platform extracts structured data that can then drive cross sections, 3D models, maps, and reports without manual re-entry.
The firms that moved to structured data five years ago are not rekeying their archived records. The firms that stayed with PDFs are.
Going forward, the bi-weekly is moving to LinkedIn. Releases, blog drops, and notes from the field will publish there first as our primary channel. Email will stay for the longer pieces.
Going forward, the bi-weekly is moving to LinkedIn. Releases, blog drops, and notes from the field will publish there first as our primary channel. Email will stay for the longer pieces.
Follow LOGitEASY on LinkedIn
2026-06-12
