How to structure exploration data so it doesn't rot

Exploration data doesn’t go bad because someone entered a wrong number. It goes bad because there’s no structure holding the pieces in relationship — so over time the claims, the assays, the holes, and the reports drift into separate islands that no longer agree. Here’s the structure that keeps them honest.

Model the entities, not the files

The mistake is organizing around files (a folder per year, a spreadsheet per campaign). Organize around entities and their relationships instead. For a typical exploration portfolio, the core objects are:

• Projects — the top-level container (name, jurisdiction, ownership, status).
• Claims / tenure — with geometry, current status, expiry, and a link to the project.
• Drill holes — collar location, orientation, depth, linked to a project.
• Assays / intervals — from-to depths, element, value, linked to a hole.
• Geophysics / geochemistry — surveys and results, spatially located.
• Documents — reports and filings, each linked to the project (and ideally the specific holes or zones they discuss).

The value is in the links. “Show me every assay over X g/t within this claim, and the report it came from” is trivial when holes belong to projects, intervals belong to holes, and documents are tied to both. It’s an afternoon of manual work when everything lives in separate files.

Put geometry in the database, not in shapefiles

Claims, holes, and surveys are spatial. Keep the geometry in the database (PostGIS), not scattered across shapefiles and geodatabases. That’s what lets tenure reconcile against the map automatically — because the map and the tenure record are the same data, queried two ways.

Store provenance, always

Every value should carry where it came from: which report, which campaign, which lab, which date. Provenance is what makes the data defensible under diligence and what lets you retire an old number without losing the trail. A source reference and a timestamp on every record costs almost nothing and saves you constantly.

Let one model drive everything

Once the entities and geometry live in one PostGIS database, the internal dashboard, the data room, and the public investor map all read from the same place. Update a claim boundary or a result once, and every surface reflects it. That single property — one source of truth — is the whole game. It’s the difference between data that compounds in value and data that rots.

This is the architecture behind our mining GIS systems. If your exploration data is already scattered, the fastest way to a plan is an Exploration Data Diagnostic — an inventory, the target model, and a fixed-price path to get there.