At the end of a field day you’ve got muddy boots, a GPS full of waypoints, a stack of field notes (digital or paper), and a long drive home. The survey is done. Now comes the report.
In most industries, “the report” is administrative friction — annoying but manageable. In regulated archaeology under BC’s Heritage Conservation Act, it’s a different animal. The report is the compliance product. It has to be precise, it has to match permit conditions, it has to accurately describe what was found and where, and it has to satisfy the client, the local First Nation, and the provincial Archaeology Branch. Get something wrong — a traverse width that contradicts the permit, a First Nations file number transposed — and you’re rewriting it.
I’ve been doing this work for twenty years. The reporting process has not changed meaningfully in that time. It’s still largely manual, and it’s one of the real constraints on the industry — in BC there aren’t enough qualified archaeologists to meet current demand, and the reporting burden makes it worse. That bothered me. Not because the people aren’t good — they are — but because the bottleneck isn’t judgment. It’s assembly.
This is where automation can genuinely help — not to replace the judgment that good fieldwork requires, but to remove the assembly burden from people who should be spending that time in the field. Faster turnaround, higher accuracy, and ultimately more cultural heritage documented and protected.
The naive approach, and why it fails
The obvious move is to give the report template to an AI, give it the field data, ask it to write the report.
I tried this. It doesn’t work — at least not for documents where precision is a legal requirement.
The problem is hallucination. Large language models are very good at generating plausible text. Archaeological compliance reports require accurate text. Those are different things. Ask a model to describe a survey area and it will produce fluent, professional-sounding prose. Some of it will be wrong. A fabricated distance to a water feature. A permit condition that sounds right but wasn’t in the actual permit. A Borden number that’s close but not the one on file.
In a blog post, that’s an embarrassing error. In a document that gets submitted to a regulatory body and shapes decisions about heritage protection, it’s a problem with real consequences.
So the naive approach is out. But the bottleneck is still real. What’s the right architecture?
Separating facts from language
The insight that made this tractable was realising that a compliance report has two fundamentally different types of content.
The first type is data-derived: dates, crew names, permit numbers, GPS coordinates, site identifiers, measurements. This content has to be exactly right. Right now it lives in PDFs, folder structures, and field files scattered across computers — extracting it reliably is part of the problem we’re solving. The end goal is a structured database that feeds this directly into the report engine. Until then, the pipeline requires a human in the loop to verify the inputs.
The second type is templated language: the stock phrases that appear in every report of a given type. The methodology section. The standard impact assessment language. The HCA warning paragraph. The First Nations notification statement. These sentences were written by experienced archaeologists, reviewed by the Archaeology Branch, and appear — nearly verbatim — across hundreds of approved reports. They’re not creative writing. They’re regulatory boilerplate that has been tested and accepted.
Once you see that distinction, the architecture becomes clear. You don’t ask the AI to write the report. You build a template library from real approved reports, parameterise the variable parts, and fill them from the database. It’s closer to mail merge than to generative AI — deliberately so.
The system I built works like this:
- A structured data contract — a JSON schema that defines exactly what information a report requires: client details, survey crew, BEC zones, previously recorded sites, field observations, archaeological potential assessments, photo metadata. This schema is the interface between the field data and the report engine.
- Validation before generation — before any text is generated, the incoming data is checked against project parameters. A permitted assessment requires a permit number. An unpermitted reconnaissance can’t include subsurface testing. Photo directions have to be present. The validation layer catches structural problems early, before they propagate into the document.
- Template-based assembly — the report sections are assembled by selecting the right template for each situation (single AAP vs multiple, clearance outcome vs avoidance recommendation, on-site field director vs remote) and filling in the parameterised fields from validated data. The model doesn’t write these sentences. It selects and fills them.
- A document builder — the assembled content is passed to a separate builder that generates a Word document matching the client’s exact formatting requirements. Column widths, font sizes, table styles — these matter to the people reviewing the output and they have to be right.
The AI’s role in this system is orchestration and judgment: deciding which templates apply to a given data set, handling edge cases, and generating the genuinely narrative sections — terrain descriptions, vegetation observations — where the field data has enough structure to constrain the output but not enough to fill a fixed template.
What’s actually hard
The template architecture reduces the hallucination problem. It doesn’t solve everything.
There are two tracks of work still ahead. The first is the report engine itself — template coverage for edge cases, the references section, and the narrative sections that still need a qualified archaeologist’s eye before anything is submittable. These are drafts, not finished documents.
The second is the data pipeline. The system is only as good as the data flowing into it. Right now, field observations still live on duck’s-back paper, Excel spreadsheets, and GPS devices. Getting that information into a structured database — consistently, completely, and in a format that maps cleanly to the report schema — is an operational problem, not a technical one. It requires workflow changes on the ground, not just software.
Both tracks matter. Most compliance automation projects talk about the engine. The pipeline is where the real effort is.
Where this sits today
The system generates draft reports from structured JSON input. The template library covers the two main report types used in BC forestry archaeology. Validation catches common errors before they reach the document. The output is a formatted Word document that matches what a reviewing archaeologist would expect to see.
It’s not a finished product. It’s infrastructure in active development working toward a data pipeline that makes the whole thing operational at scale.
What I find interesting is how the architecture generalises. The same pattern — structured data contract, validation layer, template-based assembly, constrained LLM for judgment — applies anywhere you have regulated document generation. Environmental assessments. Legal filings. Health and safety compliance. Any domain where the language has to be right and the facts have to be accurate.
If you’re working on similar problems, or building tools for compliance-heavy industries, I’d like to hear from you. That’s why I’m writing this.
Patrick McCashin is a professional archaeologist and the founder of Green Spring Research. He has 20 years of fieldwork experience in BC and is currently building AI infrastructure for compliance-heavy industries.