# geoDB guide (full text) > Every published topic of the geoDB guide, in reading order. geoDB is a hosted database for mineral-exploration data: drill holes, samples, assays and QA/QC, logging, claims, maps and 3D. How to connect an AI assistant: https://geodb.io/llms.txt --- # Setting up a project > Four wizard steps — name, coverage area, coordinate system, elevation — and your dashboard tracks where you are. Source: https://geodb.io/guide/topic/project_setup/ · Category: Getting set up A project is the working unit of geoDB: one deposit, one property, one campaign — your call. Everything you import, map, log and share happens inside a project. ## Use the setup wizard The **project setup wizard** walks you through four steps: the project's **name and reference CRS**, its **coverage area** (upload landholdings or draw one), the **working coordinate system**, and **elevation data** for the area. You don't have to finish in one sitting — your dashboard shows a setup card with your progress and takes you back to the next step whenever you're ready. ## The two decisions worth a minute of thought - **Coordinate reference system (CRS).** Tell geoDB what grid your incoming coordinates are in — a UTM zone, a state plane, or plain latitude and longitude. geoDB keeps your original values exactly as imported *and* a converted copy for maps and 3D, so nothing is ever lost — but the import can only be right if the declared grid matches the data. The *Coordinate systems* topic below covers this properly. - **Units.** Metres or feet, for depths and elevations, set in project settings. Pick what your logging and survey data actually use. Both can be revisited later in project settings, but getting them right on day one means never wondering why holes plot in the wrong hemisphere. ## After the wizard The dashboard fills in as data arrives. Three early wins worth doing next: bring in your **land holdings**, request **topography** for the project area, and **invite your team** — each has its own guide topic below. --- # Land holdings — claims, leases and boundaries > Bring in claims and lease boundaries from GIS files and see them on every map. Source: https://geodb.io/guide/topic/landholding/ · Category: Getting set up Land holdings are the polygons your ground position is made of — lode and placer claims, leases, licenses, patented ground. Once they're in, they draw on the interactive map, the 3D scene, and any dataroom or map you share. ## Getting boundaries in The fastest path is a GIS file you already have: a zipped shapefile, a GeoPackage, or a KML/KMZ straight from your claim-staking software or a government download. Drop it on the **importer** — geoDB recognises land polygons, maps the attribute columns (claim name, type, status, recording info) and validates before anything is saved. Files that arrive as boundary *lines* rather than polygons are closed into polygons automatically where possible. You can also add a single holding by hand from the land holdings page when there's just one lease to sketch. ## What the records carry Each holding keeps its geometry plus the paperwork fields that matter: claim or lease name, type, status, dates, and any custom fields your project defines. The map colours holdings by status, so "active claim" versus "dropped" is visible at a glance. ## Keeping it current Land positions change — new stakes, drops, amendments. Re-importing an updated file matches on claim names and updates what changed rather than duplicating. Your originals stay untouched in the file you imported from. --- # Topography and elevation (DEM) > Request elevation for your project area once — 3D terrain and automatic elevations follow. Source: https://geodb.io/guide/topic/topography_dem/ · Category: Getting set up A digital elevation model (DEM) gives your project a ground surface. With one in place, the 3D viewer drapes real terrain under your drillholes, and records that arrive without an elevation can take one from the surface automatically. ## Requesting elevation data Open the **elevation page** and request coverage for your project area — geoDB fetches public elevation data for the extent you choose and processes it in the background; you'll see the dataset appear in the list when it's ready. Larger areas take longer; you don't need to keep the page open. ## Bringing your own Have a better surface — a LiDAR-derived DEM or a drone survey? Upload the GeoTIFF instead. Project files accept large rasters, and the 3D viewer uses the highest-resolution surface available. ## What uses it - **The 3D viewer** — terrain under traces, collars and geology. - **Elevation fill-in** — collars and samples imported without an elevation value can be assigned one from the surface. - **Sections and strip logs** — anywhere depth meets the ground surface. One request, early in the project, and you never think about it again. --- # Inviting your team > Invites, roles and what each person can see and touch. Source: https://geodb.io/guide/topic/inviting_team/ · Category: Getting set up geoDB is built for teams — loggers at the core shack, a database manager, consultants, investors peeking at a dataroom. Access is by invitation, and what each person can do is set by their role. ## Sending an invite From the **company page**, enter an email address, pick a role, and send. New people get an email link to create their account; existing geoDB users get the company added to their switcher. You can scope someone to the whole company or to specific projects only. ## Roles, in plain terms - **Owner / manager** — run the company: billing, members, everything below. - **Admin** — full data control on their projects: create, edit, delete, configure. - **Contributor** — can add records and edit the records they created — right for loggers and field crews; they can't alter anyone else's data. - **Viewer** — read-only. Right for investors, JV partners and reviewers. ## What an invited person sees Only what they're given: the companies and projects on their invite, and nothing else. A viewer sees the same dashboard, maps and data pages you do — minus every edit button. If you're the one who was *invited* and you're reading this: the guide's collaborator path (on the guide home page) walks you through your first look around. ## Contractors Drilling contractors deserve a narrower window — there's a dedicated contractor role in drill program monitoring that shows a contractor only their own rigs and shift reports. That's covered in the *Running your program* topic. --- # Staking new claims — the claims door > Lay out or upload a claim block on your project map — geoDB handles staking, location notices and filing. Source: https://geodb.io/guide/topic/claim_staking/ · Category: Getting set up Don't have claims yet — or adding more ground? The **claims door** turns a layout on your project map into a filed claim block without leaving geoDB. ## Three ways in - **Lay it out.** The claim layout toolbench places standard 600′ × 1500′ lode claims you can move, rotate, snap and rename until the layout is right, then save as a block. Turn on the land layers — claim density, PLSS sections, land status — to see what ground is open while you work. - **Upload it.** Already laid out in other software? Upload the file (KML, KMZ, GeoJSON, GeoPackage or a zipped shapefile) and each polygon becomes a proposed claim. - **Ask us.** Rather we did the layout? The request form takes the area, roughly how many claims and anything we should know; our claims team plans it and quotes you first. Either way, the claims land as a **claim block** — a named batch like "Bear Creek Phase 1" — on your own project. ## What a claim block is A block is the unit our staking service works in: your proposal, then one package of staking, location notices, county recording and BLM filing. You'll get an email when the block is created and as it moves; the **claim blocks page** shows every block's status and its claims. ## What happens next Our claims team reviews every block before anything is staked — checking the layout against land status, ownership and terrain, and producing the authoritative claim geometry for filing. Your uploaded or laid-out layout is the proposal; the reviewed version is what gets staked on the ground and filed. Pricing and invoicing are confirmed with you before work begins. --- # Coordinate systems — reference vs working grid > Two CRS settings, what each controls — and why your original coordinates are never touched. Source: https://geodb.io/guide/topic/coordinate_systems/ · Category: Getting set up geoDB has two coordinate-system settings, and they answer different questions. Knowing which is which saves real confusion. ## The reference CRS — "what grid does my data arrive in?" When you create a project you declare a **reference CRS**: the grid your incoming coordinates are usually in — a UTM zone, a state plane, or plain latitude/longitude. It's the default the import screens assume, and each imported record also remembers the grid it was actually declared in, so mixed-grid projects work fine. ## Your original coordinates are never touched Import keeps your coordinate values **exactly as you entered them**, in the grid you declared — for a UTM import that means an **easting and a northing**. This is why your data tables label the columns **"Lon/Easting"** and **"Lat/Northing"**: the pair carries whatever your declared grid uses, and holds true degrees only when that grid is plain latitude/longitude (WGS84). The converted WGS84 copy lives separately and is what maps and 3D read. Nothing is overwritten, so there is nothing to "fix": if data was imported with the wrong grid declared, re-import it with the right one — never edit the coordinate values themselves. ## The working grid — "how should 3D and exports lay things out?" The **coordinate-system page** (Project Settings → Coordinate System, or step 3 of the setup wizard) sets the binding local grid: the projected CRS, origin and rotation used for drill-hole desurveying, local coordinates, the 3D scene, and Blender/QGIS/Leapfrog exports. Three ways to set it: - **Auto-calculate** — picks the right UTM zone from your data's location and a tidy southwest origin. Its "coordinate range" check reads point features (collars, samples); a project whose extent is polygons-only will honestly say it can't judge the range — the CRS and origin are still valid. - **Manual entry** — choose the CRS with the searchable picker and set the origin and rotation yourself. - **Mine grid calibration** — for historic data recorded in a pre-GPS local mine grid. Provide at least three control points known in both the mine grid and GPS, and geoDB computes the transformation; data imported as "Local Mine Grid" re-projects through it. ## Why skipping it bites Setting the working grid also computes your project's **coverage bounds**. Skip it and desurveying, local coordinates and 3D stop working — and the elevation step can't run ("no coverage area defined") until you come back to it, from the dashboard's setup card or project settings. --- # Finding your way around > The rail, the dashboard, the project switcher, and where Petra lives — two minutes of orientation. Source: https://geodb.io/guide/topic/finding_your_way/ · Category: Getting set up Whether you just created your first project or you were invited into someone else's, geoDB always has the same shape. Two minutes here saves an hour of poking around. ## The rail The icon rail on the far left follows you everywhere. Top to bottom it holds the pages you'll live in: the dashboard, import, the map, the 3D viewer, the canvas — and near the bottom, the **Guide icon** that brought you here and the **Petra diamond** that opens a chat with your assistant from any page. ## The dashboard The dashboard is home base for the **active project** — the project named in the switcher at the top of the page. Everything on the dashboard is scoped to it: data counts, recent activity, things needing your attention, and the guide card. If the numbers look wrong, check the switcher first — you may simply be looking at a different project. ## Switching projects and companies You can belong to several companies, and each company holds projects. The switcher changes your active company and project; every page follows it. People invited to just one project see just that one — nothing leaks between projects or companies. ## Petra Petra is the chat assistant in the bottom corner. She can answer questions about your data, import files you hand her, build charts and summaries, and walk you to the right page when you're lost — she offers buttons, and you do the clicking. She's grounded in this same guide, so "how do I…?" questions get the documented answer, not a guess. ## Light and dark The theme toggle lives in the menu under your avatar (top right). Every page — including this guide — works in both. --- # Importing data — the magic importer > Drop any file at /import/ — geoDB detects what it is and pre-maps the columns. Source: https://geodb.io/guide/topic/import_magic/ · Category: Getting data in Getting data into geoDB starts at one place: the **magic importer** at `/import/`. Drop almost anything onto the upload zone — CSV, Excel, zipped shapefiles, GeoPackage, KML/KMZ, even lab certificate PDFs — and geoDB works out what kind of data it holds. You never have to say "these are drill collars" first. ## What auto-detection does When you click **Analyze & Import**, geoDB reads your file's headers and a sample of rows, scores it against every data type it knows (drill collars, samples, surveys, lithology, assay certificates, water data, land holdings and more), and picks the best match with a confidence score. High confidence goes straight to the right import wizard; medium confidence asks you to confirm; low confidence lets you choose the type yourself. ## The import wizard The wizard opens with your columns already mapped — geoDB matches your header names against its own field names, common industry synonyms, and any custom column names your project has configured. You review the mapping, fix anything it wasn't sure about, and it validates every row before anything is saved: type checks, coordinate checks, foreign-key lookups (does that hole ID exist?), and duplicate detection. Nothing lands in your database until validation passes and you confirm. ## Other ways in - **Through Petra** — upload a file straight into a Petra chat and she'll read it, propose the import, and land it with your approval. Best when the file is messy or you want to talk through what it is. - **Direct wizards** — if you know exactly what you have, each data type has its own import page; the magic importer is just the door that picks the right one for you. --- # Importing data — through Petra > Hand Petra the file in chat — she reads it, proposes the import, and lands it with your approval. Source: https://geodb.io/guide/topic/import_petra/ · Category: Getting data in The second door for data is a conversation. Open Petra — the diamond in the bottom corner of any page — and drop your file straight into the chat. ## How a chat import goes 1. **She reads the file.** Headers, a sample of rows, coordinates, lab formats — and tells you what she thinks it is, in plain words. 2. **She proposes.** Which data type, how your columns map, what looks odd (a date column that parses two ways, a hole ID that doesn't exist yet). You talk it through — "those depths are in feet", "skip the last two columns" — and she adjusts. 3. **You approve, she lands it.** Anything that writes to your database shows you an approval card first. Nothing is saved behind your back. ## When to choose the chat over the magic importer - The file is **messy** — stray header rows, merged cells, two tables on one sheet, a lab certificate PDF. - You want to **check before committing** — "how many of these holes already exist?" is a one-line question in chat. - You have **a pile of mixed files** — hand her a ZIP and she'll work through it file by file, asking only when genuinely unsure. Batch imports run in the background and report as they go — watch it live on the canvas, or ask her how it went. For a clean, obvious CSV, the magic importer's wizard is just as fast — use whichever fits the moment. Both roads end in the same validated import; the chat is not a side door around the checks. --- # How assays are stored > Sample → assay → certificate → method → lab: how lab results are stored and why. Source: https://geodb.io/guide/topic/assay_data_model/ · Category: Understanding your data Lab results in geoDB are **normalized** — every measured value is stored once, with its full lab context, instead of as a flat spreadsheet. It's the single most important idea in the data model, and the reason QC checks, method comparisons and clean exports work later without hand-editing. ## The chain, one link at a time - A **sample** is the physical material — a drill interval sample or a surface point sample — that you sent to the lab. - An **assay** is that sample's appearance on one lab job: it links the sample to a **certificate**. - A **certificate** is the lab job itself — everything the lab returned together, and a record of which analytical methods were used. - Each measured value is an **assay unit**: one element, one value, one unit — measured by exactly one **method**. - A **method** (Au-AA24, ME-ICP61, a lab's own code) belongs to a **laboratory** and carries its detection limits. The spreadsheet the lab emailed you is a *presentation* of this chain — one row per sample, one column per element. geoDB unpacks it into the chain on import and can re-flatten it any time you export. ## Why bother? Three payoffs **The same element, analysed two ways, never collides.** A fire-assay gold value and an ICP gold value live side by side — each tied to its own method. Your project's **merge settings** decide which method wins when a single number is needed: on exports, strip logs, and the 3D display. You can change that preference any time without touching the stored data. **"Less than detection" is never a fake zero.** Below-detection results are stored as a −1 marker plus the method's detection limit. Averages, statistics and exports can treat them properly — a real 0.00 and a "below 0.005" are different facts, and geoDB keeps them different. **QC rides for free.** Standards, blanks and duplicates go through the same chain as ordinary samples, so every certificate can be judged — did the standards read back their certified values? were the blanks clean? — without any re-keying. That judging happens on the QC pages, covered in the next topic. ## Where you see the pieces Certificates, methods and labs each have their own pages under your project's data section — useful when a lab renames a method mid-program or a certificate needs its paperwork checked. Day to day you'll mostly meet assays already flattened: on sample tables, strip logs, and exports. --- # Choosing drill-intercept boundaries > intercepts are nested — sweep scales, never a cutoff Source: https://geodb.io/guide/topic/drill_intercept_boundaries/ · Category: Understanding your data An intercept table is **nested** because mineralisation is nested — a broad low-grade envelope, higher-grade zones inside it, and a peak sample or two inside those. That is the parent / `and` / `incl.` shape you see in every published release. Choosing where those intervals start and stop is **judgement, not arithmetic**. Real intercepts routinely open and close *below* their own internal peak and swallow internal waste. An intercept averaging ~0.08 g/t Au can legitimately open and close on samples below its own average, and carry a quarter of its length as below-detection material. No grade cutoff reproduces that grouping, which is exactly why geoDB's `composite()` helper deliberately takes no cutoff parameter. ## How a geologist does it by hand Substitute below-detection values (half the detection limit is the usual convention, and it is what your project's Assay Merge Settings already apply), put grade in a column next to depth, and turn on Excel **data bars**. The column becomes a downhole profile you read vertically. You are looking for where mineralisation *thickens* — not where it crosses a number. ## The multi-scale sweep Petra reproduces that eye with a sweep across several scales at once. A single rolling window cannot work: one wide enough to see a 130 m envelope smears out a 6 m zone, and one narrow enough for the zone is blind to the envelope. At each scale, Petra computes a length-weighted rolling mean of grade and keeps the contiguous runs that exceed the hole's own length-weighted mean: | scale | window | multiplier | finds | |---|---|---|---| | envelope | 100 m | 1.3× | the broad swell — the parent row | | zone | 30 m | 1.5× | `and` rows | | shoot | 10 m | 2.0× | `incl.` rows | | peak | 3 m | 3.0× | tight high-grade | The tightest `incl.` rows are then taken as **individual samples**, not from a window — a half-metre of high-grade sitting inside a multi-metre shoot is not a statistical feature, and no amount of smoothing will find it. Enrichment is always measured **relative to that hole**, never against an absolute cutoff, because grade populations differ from hole to hole and deposit to deposit. ## What it is and is not Benchmarked against a hand-built reference table, the sweep matched about two-thirds of the intervals closely — including the broad envelopes that simpler single-window methods miss entirely, and several boundaries to the metre with identical grades. It still misses isolated shallow hits that sit far from any envelope. So these are **candidate boundaries offered for review**, not answers. Petra will tell you which scale produced each row. Move any of them and it will recompute; give it your own boundaries and it will use those instead. --- # QC insertion protocols — setting the rules > How often a standard, blank or duplicate goes in — and how a project runs more than one set of rules. Source: https://geodb.io/guide/topic/qc_protocols/ · Category: Understanding your data [QC itself](https://geodb.io/guide/topic/qc_system/) is about *judging* numbers after the lab reports them. A **protocol** is the other half: the rules for what goes into the sample stream in the first place, and how often. ## What a protocol holds - **Intervals** — insert a standard every N samples, a blank every N, a field duplicate every N. Each type can be enabled or left off. - **Insertion mode** — *Independent* (each type counts on its own), *Staggered* (each type starts at an offset, so they don't all land on the same sample), or *Round robin* (one interval, rotating through the types). - **Counter scope** — whether counters reset per drill hole / per sample programme, or run continuously across the project. - **A default standard** — the CRM to reach for when a standard is due. ## A project can hold several Real programmes aren't uniform: an RC campaign and a soils grid want different QC rates. So a project holds **many protocols**, listed across the top of the protocol page. Click one to edit it; the settings below always belong to the protocol you have selected. Exactly one protocol is the **project default** — the one used wherever a drill cutsheet or sample programme doesn't name a different one explicitly. Promoting another protocol to default demotes the current one automatically, so you can never end up with two, or none. **Programme type** (Drilling / Soils) is a *label*. It titles the protocol and seeds sensible starting intervals when you create one, and it picks honest wording for the counter-scope options — a soils grid has no drill holes. It never decides which protocol applies. That decision is always either "the plan named this one" or "fall back to the default". ## Where the rules are used The intervals drive the QC reminders on drill cutsheets and sample programmes, and the field app reads the project default. A cutsheet remembers the protocol it was planned with, so re-opening an old one shows the rules it was actually built under rather than whatever the default happens to be today. --- # The QC system — trusting your numbers > Standards, blanks and duplicates — and the verdict pages that judge every certificate. Source: https://geodb.io/guide/topic/qc_system/ · Category: Understanding your data Quality control is how you *earn* the right to use your assay numbers — in a resource estimate, a press release, or just a drill-hole decision. The idea is old and simple: slip known quantities in among your samples, and check what the lab says about them. ## The three checks - **Standards** — pulps with certified element values. If the lab reports a standard well outside its certified range, every number on that certificate deserves suspicion. - **Blanks** — barren material. Any real grade in a blank means contamination or sample-swap somewhere between the splitter and the instrument. - **Duplicates** — splits of the same material submitted twice. They measure repeatability; wildly different pairs point at nugget effect or lab precision problems. The lab never knows which samples are the tests — that's the whole point. ## Where verdicts live: the QC pages geoDB judges these automatically, **certificate by certificate**, on your project's **QC pages** — charts of standard performance against certified limits, blank results over time, duplicate scatter, and a verdict per certificate. When something fails, the failure is visible and attributable: *this* certificate, *this* standard, *this* much out. One habit worth building: **the QC pages are the one place QC verdicts come from.** Ad-hoc checks in a spreadsheet — or a quick statistical look you ask Petra for — are fine for exploring, but the verdict of record is the QC page, and Petra will point you there rather than re-derive one. ## Getting QC data in Nothing extra to do on the way *in*: QC samples arrive with your ordinary imports. When a certificate lands, geoDB recognises standards, blanks and duplicates (from your sample naming and the reference-standards library), attaches them to the certificate, and the verdict pages update. Your project can pre-select which certified reference materials it uses, so loggers pick from a short list instead of the whole catalogue. How often QC samples *go in* — every N samples, and which types — is set separately, in a **[QC insertion protocol](https://geodb.io/guide/topic/qc_protocols/)**. A project can hold several (an RC campaign and a soils grid want different rates), with one marked as the default. --- # Sampling passes & composites > Two samples over one interval? Passes: Au bags + ICP composites, both real Source: https://geodb.io/guide/topic/sampling_passes/ · Category: Understanding your data # Sampling passes & composites Open a hole and you may find **two samples over the same depths** — say a 0–5 ft bag and a 0–10 ft one that covers it. Nothing is wrong. They are two **sampling passes**: the hole was sampled twice, on purpose. ## Why a hole gets sampled twice The usual design is cost control. Gold is nuggety, so you assay **Au on every 5-ft bag**. The pathfinder and lithogeochemistry suite (a 48-element ICP package) varies slowly downhole, so you run it on **10-ft composites made from the pulps** of two bags — half the bill for a signal that does not need the resolution. The composite goes to the lab as its own sample: its own sample ID, its own certificate, often a different lab a week later. So a composite is **a real physical sample**, not a duplicate and not QC. It is also **not something geoDB could calculate for you** — averaging two gold values does not give you an ICP result — and deleting it to "clean up the overlap" throws away every value on its certificate. One project we work with holds 4,260 of them. ## The one rule **Within one pass, in one hole, sample intervals must not overlap. Across passes, anything goes.** Sample names stay unique across the whole project regardless — a lab ID names one physical bag, whichever pass it belongs to. Every drill sample belongs to exactly one pass. A project starts with a `default` pass and every existing sample sits in it; a pass carries a kind (primary, composite, metallurgical / bulk, re-split, historic, other) so its label is honest. ## Who reads which pass Some surfaces need **one clean downhole sequence** — an interval table cannot carry overlaps. Others just **list rows**. geoDB keeps the two apart on purpose: | Needs ONE sequence → reads ONE pass | Lists rows → shows EVERY pass | |---|---| | Leapfrog / the ODBC interval table · the 3D viewer and grade shells · map drill traces · compositing and intercept tables · Quick Log start-depth auto-fill | the Drill Samples grid (a **Pass** column) · CSV / XLSX exports (a `sample_set` column) · the Quick Log roster (each row badged) · the API list · strip-log sample tracks (with a pass filter) | The one-sequence surfaces read the project's **export pass** — set it under *Project settings → Data Export & ODBC → Drill Sample Set*; left blank, they read the default pass. Passes are **never merged**. A 3D or map drill layer can pick a different pass of its own. This is why an ODBC table can have fewer rows than the grid: the table serves one pass, the grid lists them all. ## Importing a second pass Import a composite file over a hole that already has its 5-ft bags and the importer **stops and asks** before writing anything: how many rows overlap the target pass, in which holes, with sample pairs. Three ways through: 1. **Name a new pass** for the file (with its kind) — created when you confirm. 2. **Pick an existing pass** that is not the default. 3. **Fix the file**, if the overlap really is a mistake. Rows that re-use an existing interval under a new sample name ask the same question — a re-split is a pass too. A `drill_sample_set` column in the file names the pass row by row; an unknown name is refused rather than created silently. In Petra, the same question arrives as a card; answer it by telling Petra what the pass is and it re-lands the file into it. ## Managing passes - **Create, rename or archive a pass:** the *Drill Sample Sets* page. - **Which pass exports:** *Project settings → Data Export & ODBC*. - **Which pass new Quick Log samples land in:** the *Pass:* picker on the Quick Log's Samples tab — it also decides where start-depth auto-fill continues from. It never hides rows; every pass stays listed. - **Per-layer:** the 3D drill-hole setup and the map's drilling configuration each carry a pass picker. ## Composites that are already in your project If your composites were imported before passes existed, they sit in the default pass and the validator counts every one as an overlap (on one real project: 8,652 pairs). Moving them out is a **reviewed proposal, not an automatic fix**: support runs a dry run that finds rows containing two or more others in the same hole, reports which naming convention each matched, and writes a CSV for a person to read before anything is applied — with a snapshot and a revert. Rows with no naming signal are left alone: on one real project a single "composite" spans 740 m over 36 samples, which is a logging error, not a composite. Ask Petra, or support, to start that review. --- # Soil programmes — planning QC for a surface grid > Group a surface grid into a programme, then plan its CRM, blank and duplicate bags before the crew goes out. Source: https://geodb.io/guide/topic/soil_programme_qc/ · Category: Understanding your data Drill QC and surface QC are planned differently, and this is the surface half. ## A programme is the container A **sample programme** groups surface samples by their sequence-number prefix — `SS-001`, `SS-002` … all belong to the `SS` programme. It's the unit you plan QC against, assign to a crew, and print pull lists from. You rarely create one by hand. **Push a grid from QGIS and the programme appears by itself**, named from the prefix. If you push `SS-001`…`SS-156`, you get one `SS` programme holding 156 planned samples. Import through Petra does the same thing. Three similar words worth keeping straight: - **sample programme** — the *field* batch, grouped by prefix. This page. - **submittal** — the *lab shipment* a sample was sent in. - **package** — the physical *box* at the lab. ## Planning the QC Open a programme and choose **Plan QC**. You tell it which bag numbers to draw from (your sample series), and it applies the project's [QC protocol](https://geodb.io/guide/topic/qc_protocols/) — or a different one if this programme runs to its own rules. What comes back is a **preview, not a commitment**: the CRM and blank bags it would insert, with their numbers, plus any warnings. Commit it and those rows are created as planned QC, ready for the pull list. **Standards and blanks get numbers. Field duplicates don't.** A duplicate is taken in the field, from material you're already collecting, so it can't be pre-numbered off the shelf — the planner *forecasts* how many you'll need and at what cadence, and you carry spare bags. That asymmetry surprises people the first time; it's deliberate. ## After the crew goes out Collected samples come back, get submitted to the lab, and the certificate lands like any other. From there the ordinary [QC verdict pages](https://geodb.io/guide/topic/qc_system/) judge the results — planning and judging are separate halves, and the verdict pages remain the answer of record. --- # Blank thresholds > supplier limit, then your limit, then an opt-in DL floor Source: https://geodb.io/guide/topic/qaqc_blank_thresholds/ · Category: QAQC When does a blank "fail"? The common conventions, in rough order of use: - **10× detection limit** as the single failure line (the most common); - **5× DL warning, 10× DL failure** as a two-tier compromise; - **≥90% of blanks below 5× DL** as an aggregate form; - CIM sets **no numeric threshold at all**. Two important refinements beat any DL multiple: - **A certified blank is not a zero.** CDN-BL-10S certifies Au **<0.01 g/t** — a bound, with a method. OREAS 21e is a "blank" with real certified values for Cu, Fe and Li; OREAS 24c carries 138 ppm Ni. For a certified blank, **use the supplier's prescribed limit**, not a DL multiple. - **Economic significance can override.** For a 0.5% Cu deposit, failing a blank at 10 ppm Cu is pointless — 10 ppm is economically meaningless there; ~200 ppm would be a sensible limit (Bloom). Mass ratio matters too: carry-over into a 500 g blank reads ~10× stronger than the same contamination into a 5 kg sample. ## In geoDB geoDB resolves a blank's threshold through a **ladder**, stopping at the first rung that answers: 1. **The certified blank's supplier limit** — if the QC sample is linked to a certified blank whose certificate states a `<` bound for that element, that bound is used. This is the industry default above, applied automatically. 2. **A warning limit you configured** on the project for that element (optionally scoped to one method). Element casing no longer matters — an `au` limit row covers an `Au` reading. 3. **A detection-limit multiple**, *if* you have set one on the project's QAQC protocol (`blank_dl_multiple`). This is **empty by default** and staying empty is a legitimate choice. 4. **Nothing** — the reading is reported as **"unknown"**: shown on the page, excluded from the pass rate, never counted as a pass. The page tells you **which rung produced the number** in the *Limit source* column, because the three rungs are different claims — a supplier bound is the CRM vendor's, a warning limit is yours, and a DL multiple is a convention. **Set a DL multiple deliberately, not reflexively.** It is a floor, not a recommendation. On a multi-element ICP scan it is meaningless for the rock-forming elements a barren blank legitimately contains — a silica or carbonate blank really does carry percent-level Na, Ca, Fe and Mg, which sit thousands of times above their detection limits without any contamination at all. Configure limits for the elements your blanks are actually there to police. If your blanks page shows a lot of "unknown", that is the honest reading: no limit exists for those elements yet. Warning limits are managed from the QC pages. --- # Blank types > coarse tests prep, pulp tests assay; order matters Source: https://geodb.io/guide/topic/qaqc_blank_types_and_placement/ · Category: QAQC Blanks answer *where contamination happens*, and the two kinds answer different halves: - A **coarse (field) blank** — barren, **unpulverised** rock — goes in before prep. It tests the crusher and pulveriser, where most contamination actually occurs. - A **pulp (fine) blank** — already pulverised — tests the **assay** step and instrument carry-over. **Placement is the whole point.** A blank after barren samples tests nothing; insert blanks **after mineralised samples**. Simón's ordering refinement: after a high-grade interval, **fine blank first, then coarse** — that way the fine one is *assayed* right after the high-grade sample and the coarse one is *prepared* right after it. A blank at position 1 of a batch is equipment cleaning, not QC. (Caveat worth knowing: some labs alternate two pulverisers, which can defeat placement logic entirely — Bloom's fix is submitting high-grade samples as a separate batch.) ## Material pitfalls - *"Bricks are not an acceptable barren material!"* (Bloom) - **Wrong matrix defeats the assay silently** — limestone in a fire assay flux designed for volcanics may under-recover gold, so the blank reads clean when it isn't. - **Too fine** (won't test prep) or **too small** (100 g won't clean a 1 kg pulveriser bowl). - **Not verified barren** — Rainy River's local-intrusive blank read >3× DL in ~15% of results; marble garden stone brought that to 0.7%. ## In geoDB geoDB's QC types distinguish field-inserted blanks from lab blanks, and coarse from pulp where you record it — so log the blank *kind* correctly when inserting. geoDB does not evaluate placement or material; those are field-protocol decisions this topic exists to inform. What geoDB *does* do with a blank once the lab reports it is judge it against a threshold ladder — see [Blank thresholds](qaqc_blank_thresholds). Worth knowing here: a blank whose element has no resolvable threshold reads **"unknown"**, not "pass". A page full of "unknown" blanks is a configuration gap, not a clean result — and it is not evidence the blank material or its placement worked. --- # Certificate SD fields > 1SD/CI/tolerance/EU are not interchangeable Source: https://geodb.io/guide/topic/qaqc_certificate_sd_fields/ · Category: QAQC A CRM certificate carries several dispersion numbers, and **they are not interchangeable**. An OREAS certificate has a Table 1 (`Certified Value | 1SD | 95% Confidence | 95% Tolerance`) and separate Performance Gates (`1SD | 2SD | 3SD | …`). Two of those are **explicitly disqualified from QC use**, in the certificate's own words: > "95% Confidence Limits **should not be used as control limits** for > laboratory performance." — "tolerance limits pertain to the homogeneity > of the CRM only and should not be used as control limits." The **1SD** is the correct control-limit field. Confidence intervals and expanded uncertainty **shrink as more labs certify the CRM** — so using them gives a *better-characterised* CRM *tighter* false gates. The error is silent and always in the failing direction. ## Vendor traps to know by name - **OREAS (Feb 2026 onward):** Table 1 dropped 1SD for *95% Expanded Uncertainty* (half-width ≈ 1×SD). Read it as 2SD and every gate is ~2× too tight. - **CDN (current):** the column **titled "Two Standard Deviations" contains 1SD** (verified arithmetically). Older single-line CDN certs genuinely are 2SD. Same vendor, opposite conventions. - **Rocklabs:** sanctions **no** certificate field as a control limit at all — build limits from your own lab's data. - **AMIS:** the headline ± is the control-chart SD, not the between-lab SD. And two structural traps: **certified values are per-method** (OREAS 254c certifies Au four different ways — analyte alone is not a unique key), and **`IND`/`nr` must be parsed per-cell** — a row can have a valid SD next to an `IND` tolerance. ## In geoDB geoDB stores certified values **per method** — the QC engine matches a standard's certified value to the analytical method on the certificate, which is exactly the discipline the per-method trap requires. Standards imported from the built-in OREAS/CDN library carry vetted 1SD values. When you enter a standard by hand from a certificate PDF, this topic is the checklist: find the true 1SD, not the headline ±. --- # The 2SD/3SD rule > multiple 2SD OR one 3SD fails; a single 2SD warns Source: https://geodb.io/guide/topic/qaqc_crm_2sd_3sd_rule/ · Category: QAQC The standard CRM acceptance rule — printed verbatim on OREAS certificates — is **asymmetric**, and most people misremember it: > "warning or rejection for **multiple 2SD outliers**, or rejection for > **individual 3SD outliers**… their precise application should be at the > discretion of the QC manager concerned." **A single result between 2SD and 3SD is a warning, not a failure.** Under normality ~4.6% of results land outside 2SD by pure chance — failing each one would mean rejecting good batches constantly. Failure comes two ways: 1. **One result beyond 3SD** — outright rejection (random odds ~0.3%). 2. **Multiple 2SD outliers** — especially on the same side of the mean, which signals systematic bias rather than noise. Note that the "multiple outliers" half is a **pattern across results**, not a property of any single result — a per-sample verdict can never express it. That is what trending rules are for (see the consecutive-outlier topic). Some practitioners do treat ±2SD itself as failure, and Geostats recommends 3SD as the only gate — both are defensible conventions. Know which one your project uses. ## In geoDB geoDB judges each standard **individually**: within 2σ passes, 2–3σ shows a warning, beyond 3σ fails — exactly the individual half of the rule. The "multiple 2SD outliers" pattern half is not evaluated automatically; use the control charts on the QC pages to spot it by eye, or ask Petra for a trend analysis. --- # Choosing CRMs > bracket the deposit; few CRMs with many results Source: https://geodb.io/guide/topic/qaqc_crm_selection/ · Category: QAQC Which standards you insert matters as much as how many. - **Grades must bracket the deposit.** The classic failure (Simón's survey): one CRM, sometimes at below-cutoff or near-detection grade, monitoring an ore-grade program. Recommended: **three** CRMs — near cut-off, near average grade, near the 95th percentile (Snowden Optiro says four, adding a similar-but-different matrix). - **But too many CRMs defeats the purpose.** Rainy River used 48 unique gold CRMs over twelve years, and many "yielded small datasets, and their performance over time cannot be evaluated." **Few CRMs with many results beats many CRMs with few** — you cannot see a bias trend on a standard with six data points. - **Keep them anonymous.** Letting the lab identify your standards — or telling them the expected values — is textbook poor practice. Analysts are human; known values get special care. - **Mind the over-range blind spot.** If your highest CRM doesn't trigger the lab's overlimit method, your most economically important samples are running unmonitored (Rainy River found exactly this). - **A CRM can itself be wrong.** Systematic low bias across *projects* on one standard is the CRM's problem, not your lab's. The discriminator is cross-project performance. ## In geoDB geoDB ships a built-in **standards library** (OREAS, CDN and others, with vetted certified values) — import the standards you use rather than re-typing certificates. geoDB does not currently check whether your CRM grades bracket your deposit's grades; that judgment stays with you, and the multi-element grade statistics on your project are the input. --- # Duplicates near DL > near DL, RPD is noise — use an absolute test Source: https://geodb.io/guide/topic/qaqc_duplicate_detection_limit_floor/ · Category: QAQC A pair of repeats at **0.01 and 0.02 ppm** gold is a **100% relative difference** — and if the detection limit is 0.01 ppm, it is also completely meaningless: that is instrument noise, not imprecision. Near the detection limit, relative statistics like RPD lose their meaning, and judging them anyway *"can skew our perception of the precision"*. ## The convention Pick a practical floor — **a good rule of thumb is 10× the analytical detection limit**, commonly called the **"line of significance"** — and plot it on your precision charts. Bishi states it as protocol: repeat values proximal to the detection limit are **"not considered failures."** The implementable two-regime shape (from a production QC system, EarthSoft EQuIS): | Regime | Test | |---|---| | both results ≥ 5× DL | relative test (RPD/HARD) vs the normal threshold | | either result < 5× DL | **absolute** test: flag only if \|a−b\| > 1–2× DL | **Do not simply discard sub-threshold pairs** — that hides real contamination and real sub-sampling failure at low grade. Switch the statistic; keep the data. (Physical basis: precision degrades asymptotically toward the DL; it is optimised around ~50× DL.) ## In geoDB geoDB applies the two-regime test: - **both results ≥ 5 × the detection limit** → RPD against the normal threshold for that duplicate type; - **either result below it** → the pair is judged on **absolute difference**, and fails only if the two results differ by more than **one detection limit**. The 5× boundary is per-project (*Project settings → QAQC protocol → duplicate detection-limit floor*); set it to 0 to judge everything on RPD. Two things worth knowing: - **The pair is re-judged, never dropped.** A near-DL pair that genuinely disagrees still fails — the floor removes noise, not evidence. - **The floor can only ever rescue a pair.** Where the absolute test would be harsher than RPD, the RPD verdict stands, so raising the multiple can never manufacture a failure. Every duplicate row says which test judged it, in the **Judged by** column and in the chart hover; near-DL points plot as diamonds because the RPD threshold line does not apply to them. (Pairs where a value is *below* detection are handled separately: both-below counts as agreement, one-below is not evaluable and is reported rather than judged.) --- # Duplicate measures > RPD = 2× HARD; tolerances widen up the chain Source: https://geodb.io/guide/topic/qaqc_duplicate_measures/ · Category: QAQC Two precision statistics dominate duplicate QC, and **mixing them up silently doubles or halves every threshold**: - **HARD** = |x₁−x₂| / (x₁+x₂) × 100 - **RPD** = |x₁−x₂| / mean × 100 — **exactly 2× HARD** A "10% pulp criterion" means opposite things depending on which statistic is meant. Always label which one a chart or threshold uses. ## The tolerance ladder Precision degrades up the sampling chain, so tolerance widens with it: | Duplicate type | Typical tolerance (RPD) | What it monitors | |---|---|---| | Field / twin | **30%** | sampling + prep + analysis + geology | | Coarse / prep | **20%** | prep + analysis + geology | | Pulp / lab | **10%** | analysis only | ## The better form: population rules Per-pair pass/fail on nuggety mineralisation generates meaningless failures. The population form ranks pairs by HARD and asks what fraction beat the line: **pulp 90% under 10%, coarse 80% under 10%, field 70% under 10%** — the "90/80/70" ranked-HARD rule. Aggregate variants ("no more than 10% of pairs outside tolerance") serve the same purpose. For precision as a function of grade, the **Thompson–Howarth** method (pairs sorted by concentration, grouped in 11s, median-based regression) is the standard chart — use robust regression, never ordinary least squares. ## In geoDB geoDB judges duplicate pairs on **RPD**, with warnings out to 1.5× the pass threshold: | Duplicate type | geoDB pass threshold | |---|---| | Field / twin | **20%** | | Coarse / prep | **20%** | | Pulp / lab | **10%** | Our **field** threshold is tighter than the industry's 30% — deliberate, and a change we'd measure before making. A project can set a **per-element override** (e.g. Au = 15%). An override tightens any tier, and may loosen only the **field** tier: field tolerance is your deposit's variability, while the coarse and pulp tolerances are the lab's precision, which a per-element preference shouldn't relax. Pairs near the detection limit are judged on absolute difference instead — see *Duplicates near DL*. Each row on the certificate page says which test produced its verdict. The duplicate charts plot RPD; ranked-HARD and Thompson–Howarth plots aren't built into the pages yet — ask Petra when you need one. --- # Duplicate validity > last-split, wrong batch/lab/method void a pair Source: https://geodb.io/guide/topic/qaqc_duplicate_validity/ · Category: QAQC A duplicate only measures what it repeats. Break the repeatability conditions and the pair silently stops measuring precision at all — Simón's list of practices that void a duplicate: - different crews, sampling methods, or intervals; long time gaps; - taking the duplicate from the **last** split instead of the first; - not inserting the duplicate **in the same batch** as the original; - a different **analytical method, aliquot size, or detection limit**; - sending original and duplicate to **different labs** (that's a check assay, a different tool); - **relabelling coarse-reject re-pulps as "pulp duplicates"** — that converts an analytical-precision measure into a sub-sampling measure without telling anyone; - inserting only one duplicate type — pulp-only makes field and sub-sampling error invisible. One genuinely contested point: field duplicates from **quarter core**. Simón describes it as the standard workaround; Bishi calls it "not recommended… biased sampling." Know which side your project's protocol takes. ## In geoDB geoDB records each duplicate's **type** (field/coarse/pulp/lab) and links it to its parent sample — the type decides which tolerance it is judged against, so **log the type truthfully**: a coarse-reject re-pulp is a coarse duplicate, not a pulp duplicate, even though it arrives as a pulp. geoDB does not (and largely cannot) verify the field-side conditions — same batch, same method, first split — those live in your sampling protocol. --- # Expected failure rate > ~4.6% outside 2SD is normal; zero is suspicious Source: https://geodb.io/guide/topic/qaqc_expected_failure_rate/ · Category: QAQC The most counter-intuitive fact in QC: **a healthy program is supposed to show failures.** Under normality, ~4.6% of CRM results fall outside ±2SD **by chance alone**, and ~0.3% outside ±3SD. Snowden Optiro states it directly: *"in excess of 4% of all results should legitimately be outside [2SD]."* So a program showing **near-zero 2SD exceedances is suspicious, not excellent** — it usually means one of two things: - the certified SDs you're checking against are **too wide** (a real, documented problem — an over-wide SD makes the whole program blind), or - the lab has **identified your standards** and is treating them specially. AMIS's practical benchmark: a good laboratory reports within 2SD with a failure rate **under 10%** — under, not at zero. ## The reporting rule that follows **Never report a failure rate without its threshold and the expected rate.** "5% of standards failed" is *normal* at a 2SD threshold and a 16× excess at 3SD — the same number, opposite conclusions. Rainy River's QP used "<5% failure rate acceptable per CRM" — explicitly at 3SD. ## In geoDB The QC pages report pass rates per category (standards, blanks, duplicates) against the thresholds described in the other topics. geoDB does not currently annotate rates with the statistically expected rate — when you read "96% passing", remember 95.4% is the theoretical expectation at 2SD. --- # Failure response > diagnose field→entry→lab before any re-assay Source: https://geodb.io/guide/topic/qaqc_failure_response/ · Category: QAQC A QC failure triggers a **diagnostic first** — the diagnostic determines the re-assay scope, not the other way round. ## The escalation ladder (Bishi) 1. **Check the field first** — was a routine sample transposed with a QC sample? Audit trail before chemistry. 2. **Check data entry** — logs, sample register, lab tickets. 3. **Only then assume the lab.** Re-assay pulps at the original lab with fresh same-type QC inserted in the re-run. 4. Pass → accept. Fail → re-run. **Third failure → send to a secondary accredited lab.** ## Scope: bracket by SAME-TYPE QC The affected range runs from the previous **passing QC sample of the same type** to the next one — CRM failures bracket by CRMs, blank failures by blanks, ideally the same CRM code ("apples with apples"). Simón's dissent against over-scoping is the key nuance: a single random outlier affects *only the outlier's neighbourhood* — repeat **the outliers plus neighbours** to learn whether the error is random or systematic, and re-run the **whole batch only if it proves systematic**. Small batches (≤20 samples) exist precisely so problems can be ring-fenced. ## Two rules that survive every convention - **Failed values are retained, never overwritten.** Keep the failed result, link the replacement, record the reason — the regulatory audit trail (NI 43-101 requires the corrective actions be reportable). - **Timeliness is the #1 documented failure.** "Storing the data… and not processing them on a timely fashion, or not processing them at all" is Simón's most-repeated finding. QC review is a gate before batch acceptance, not a report at resource time — late review has cost operators entire drill campaigns. ## In geoDB geoDB evaluates each certificate as it arrives — pass rates under 85% flag selective re-assay, under 70% flag the certificate for rejection — and the certificate approval flow is your acceptance gate. Re-assayed values are kept alongside originals rather than overwriting them. Same-type bracketing (which sample ranges a failure implicates) is not computed automatically; the certificate page's sequence charts are the manual tool for it. --- # Insertion rates > ~20% total, 4–6%/type; compute the achieved rate Source: https://geodb.io/guide/topic/qaqc_insertion_rates/ · Category: QAQC "5%" and "20%" are **both** correct — 5% is per control type, 20% is the total. Simón's survey of seven QA/QC consultants all lands near 20% (range 15–25%), and *"a 20% control-sample insertion rate has practically become an industry standard."* His recommended breakdown for core drilling: | Type | Rate | |---|---| | Duplicates (twin 2% + coarse 2% + pulp 2%) | 6% | | Standards (CRMs) | 6% | | Blanks (coarse 2% + pulp 2%) | 4% | | Check samples (umpire lab) | 4% | The 1999 TSE-OSC regulatory floor: 1 duplicate + 1 blank + 1 standard per 20 samples = 15%. Practical refinement (Bloom): match blank spacing to the lab's rack size — one per 25–40 samples tracks a fire-assay rack. ## The finding that actually bites **Achieved ≠ planned, routinely.** Rainy River planned 3.3–5% CRMs and achieved **2.2% on average**; blanks landed at 0.7–1.4%; prior operators submitted none at all. The rate that matters is the one **computed from the data** — per period, per hole — never the one in the protocol document. And rigid rates aren't sacred: tailor proportions to the problems your program actually has. ## In geoDB Your planned rates live in the project's **QC insertion protocols**; geoDB computes actual QC presence per certificate and reports low insertion in its batch QC summary (flagging under ~3–5%). The approval page states the achieved rate and any missing QC type right above the approval decision, and stores what it said with the approval — but it is **guidance, not a block**: you may approve any certificate you want to, including one with no QC on it at all. Keep the achieved-vs-planned comparison in your own review habit. --- # No certified SD > own-lab repeats or ±10%±2DL — never batch scatter Source: https://geodb.io/guide/topic/qaqc_missing_certified_sd/ · Category: QAQC Sooner or later a standard has no usable certified SD — the whole certificate reports only expanded uncertainty, one analyte reads `nr`, or a row sits below detection (`<5 IND IND` — not a certified value at all; don't QC-evaluate it). ## The sanctioned fallbacks, in order 1. **Derive the SD from your own lab's repeats.** The unanimous vendor answer — OREAS: *"SD's should be calculated directly from your own laboratory's process."* AMIS wants a minimum of 20 analyses. 2. **OREAS's low-concentration rule:** acceptance at **Certified Value ±10% ±2DL** — OREAS's published formula for near-detection grades (not CDN's; CDN certificates carry no such rule). 3. **The 5% window** — a standing OREAS certificate column, calculated from the certified value. ⛔ **Rules 2 and 3 produce acceptance WINDOWS, not standard deviations.** Never enter a ±10%±2DL (or 5%) result in an SD field: the engine applies its 2SD/3SD ladder *on top of* whatever sits there, so a window entered as a 1SD silently widens your gates 2–3×. A window is the pass/fail test itself; only a real 1SD (rule 1 — your own lab's repeats) belongs in the SD field. Explicitly **not** sanctioned: substituting the confidence interval, expanded uncertainty, or tolerance limits. ## The trap with no support anywhere **Substituting the batch's own scatter** — computing an SD from the very results you are judging — has no support in any source, and it is mechanically self-defeating: the calculated SD **grows with the very error being detected**. A uniformly wrong batch produces tight scatter → small Z → **pass**. This is not hypothetical; it has produced real massively-biased "Pass" verdicts in production databases (including, historically, this one — see below). ## In geoDB For most surfaces geoDB's ladder is: certified 1SD → an SD derived from the certificate's asymmetric 2SD bounds → a ±10%/±15% bias rule. On the certificate-detail page, however, a **batch-scatter SD** currently sits in the ladder for groups with no certified SD — a known, documented gap scheduled for remediation. So **leaving the SD field blank is not a safe "bias-only" fallback**: on the page that judges certificates, a blank SD means your standards get judged against the batch's own scatter — the very thing forbidden above. A hard bias ceiling (50% by default, configurable per project) backstops it: no row can "pass" with a huge bias no matter how the SD came out. If a standard of yours has no certified SD, the durable fix is to add a proper 1SD to the standard's record — from your lab's repeats, per the fallback ladder above. --- # No code mandates numbers > every threshold is convention, not law Source: https://geodb.io/guide/topic/qaqc_no_code_mandates_numbers/ · Category: QAQC Here is the fact that governs everything else in QAQC: **no reporting code specifies a numeric insertion rate, acceptance threshold, or pass/fail rule.** CIM's actual wording is only that control samples be inserted *"frequently enough to provide statistical confidence in the results"*. NI 43-101, JORC and SK-1300 require **disclosure** — of procedures, results, pass/fail criteria and corrective actions — never specific numbers. Every threshold you have ever been told ("±3SD is a fail", "blanks fail at 10× detection", "insert 5% standards") is **convention, not law**. The conventions are good ones, built on decades of practice — but a competent QP can defensibly choose different ones, and different companies do. ## What this means in practice - When you report QC results, say **which** convention you applied. "2% failure rate" means nothing without "at 3SD". - When two geologists disagree about a threshold, neither is "breaking the rules" — there are no numeric rules. Agree on a project convention and write it down. - Your database should let you **configure** the thresholds per project, and record what was in force when each batch was judged. ## In geoDB geoDB ships with the common conventions as defaults — standards judged at 2σ (warn) and 3σ (fail) against certified values, duplicates at 20% RPD (10% for pulp/lab duplicates), blanks against per-element warning limits you configure. Projects can override several of these: **QC insertion protocols** carry your planned insertion rules, per-element duplicate thresholds can be set on the project, and blank warning limits are fully yours to define. Where a default is not yet configurable, treat it as geoDB asserting a convention — a reasonable one, but a convention. --- # The nugget effect > coarse-gold scatter is geology, not QC failure Source: https://geodb.io/guide/topic/qaqc_nugget_effect/ · Category: QAQC In coarse-gold (and other nuggety) mineralisation, wide field-duplicate scatter is often **geology, not a QC failure**. Two different effects hide under one name: - **Geological nugget effect (GNE)** — real in-situ variability; no sampling protocol can remove it. - **Sampling nugget effect (SNE)** — variability *added* by poor protocol (above all, insufficient sample mass). QC that can't separate these will misattribute geology to the lab — Bishi: nuggety deposits *"will almost certainly give challenges in attaining high precision… evaluated on its unique merits."* **There is no universal duplicate tolerance.** ## The landmark case New Found Gold (2022): a suspected bias from 30 half-core duplicates triggered an independent review (Bloom & Srivastava). Result: **no systematic bias** — of 37 visible-gold samples, 17 were higher in one half, 20 in the other. Even with >12,000 screened-metallic assays on ≥3 kg samples, duplicates "may differ by a factor of five or more." The scatter was the deposit, not the lab. ## A usable flag Bishi's implementable rule: flag pairs with **>100% variation AND at least one value above 3 ppm** as likely nugget effect, and send them to **pulp-metallic (screen fire) assay** — flag and investigate, don't fail. ## In geoDB geoDB applies the standard RPD tolerances to all duplicate pairs — it has no nugget-effect flag, so in nuggety mineralisation expect real geology to show up as duplicate "failures." Before treating those as lab problems, look at the grades involved and your deposit style; per-element threshold overrides on the project are the current lever for deliberately widening tolerance on nuggety elements. --- # Consecutive outliers > two same-side 2SD in a row = bias, random 2.3% Source: https://geodb.io/guide/topic/qaqc_westgard_consecutive_rules/ · Category: QAQC A single outlier is noise; a **pattern** of them is bias. Trending rules formalize this, and OREAS endorses them by name on its certificates: *"Westgard Rules extend the basics of single-rule QC monitoring."* The core set: | Rule | Meaning | |---|---| | **1-3s** | one result beyond ±3SD → reject | | **2-2s** | two consecutive beyond ±2SD, same side → systematic error | | **R-4s** | range between two controls exceeds 4SD | | **4-1s** | four consecutive beyond ±1SD, same side | | **10-x** | ten consecutive on the same side of the mean | The mining-specific one is **2-2s** — Bishi (after Barry Smee): results rejected when *"two consecutive batches show two CRM results beyond the two-standard-deviation limit on the same side of the mean."* Under normality that pattern occurs randomly only **2.3%** of the time, which is exactly why it detects bias rather than punishing noise. Whether the long-run trigger is 7, 9 or 10 consecutive same-side results depends on the rule-set you adopt (Westgard vs Nelson) — a genuine convention choice. Full multi-rule stacks are not standard in mining; 2-2s is the one with mining-specific backing. ## In geoDB geoDB does not evaluate trending rules — every verdict is per-result. The **control charts** on the QC pages plot results in sequence against the ±2SD/±3SD bands, which makes same-side runs easy to spot by eye; for a formal check, ask Petra to run one over your data. --- # The interactive map > Layers, base imagery and styling — your project on one live map. Source: https://geodb.io/guide/topic/maps/ · Category: Seeing your data The interactive map is where a project becomes visible: claims, collars, drill traces, samples, structures, water sites and any GIS layers you've brought in, over the base imagery of your choice. ## Layers The panel on the left lists your map's layers — land holdings, drill collars, traces, and everything else you add. Toggle them, reorder them, and add new ones from your project's data. A project can hold more than one saved map (a drilling map, a land-position map, a presentation map), each with its own layer set — switch between them at the top of the panel. ## Base imagery Satellite, streets, terrain — pick per map. You can also drape your own imagery: georeferenced rasters uploaded as project files (a geophysics grid, a historic mine map) become base layers you can fade in and out. ## Styling Point and polygon layers colour by their attributes — holdings by claim status, collars by hole type, geology by lithology. Colours come from your project's lookup definitions, and there are two ways to set them: the **display settings** page (the manual surface), or simply asking Petra — "give my lithologies sensible industry colours" proposes a full scheme you approve in one click. Either way the same colours follow your data onto the strip logs and the 3D scene. Your map layers (geology units, contacts, faults and other lines and areas) draw on the project map, in QGIS and on crew phones; they are not on shared review maps, public embeds or in the 3D viewer yet. *Map layers* under *Sharing your data* covers them. ## Sharing a view Maps can be published as read-only embeds for a website or an investor page — that, plus datarooms, is covered under *Sharing your data*. --- # The Canvas > A workspace of live panes — figures, tables, maps and Petra, side by side. Source: https://geodb.io/guide/topic/canvas/ · Category: Seeing your data The Canvas is a workspace you compose: panes laid out on a grid, each holding something live — a figure, a data table, a map view, a note, a Petra chat. Where the other pages each show one thing well, the canvas is where you put *your* combination together and keep it. ## Workspaces Create as many as you need — "QAQC review", "Targeting meeting", "Weekly ops". Each keeps its layout and panes; the list on the left switches between them. A fresh canvas starts with a sensible three-pane layout you can immediately rearrange. ## What goes in a pane Charts you've made with Petra land here with one click — the expand button on any figure in chat opens it on the canvas, full size and still live. Add tables, notes, and views of your project data alongside; drag, resize, and save. ## Petra in frame The chat rides along on the canvas, so "swap that histogram for copper" or "add a table of the top intercepts" happens in place — the panes update as you talk. Batch imports also report their progress here, so a long import is something you can *watch*. ## Reports and datarooms Two special workspace types build on the same canvas machinery: composed **reports** (sections, figures and text assembled into a document) and **datarooms** (a curated, shareable room of project material — covered in *Sharing your data*). *In development:* geostatistics panes are being built and will show up badged as such — not ready for customer use yet. --- # Claim plotting > From location notices and survey paperwork to plotted claim polygons on your map — starting from a chat upload. Source: https://geodb.io/guide/topic/claim_plotting/ · Category: Seeing your data Claim plotting turns paper — location notices, certificates, survey descriptions — into claim polygons plotted on your interactive map. ## How it works Upload the documents for a claim block into a Petra chat and say you want them plotted. Petra reads the paper (with vision — old scans and handwritten notices included), frames the map on the ground the notice names, and works out the geometry: bearings and distances, tie points to known corners, and the metes-and-bounds arithmetic that turns "N 45° E, 600 feet" into a polygon on the ground. When the notice ties to a landmark no record can resolve — an old shaft, a named boulder, a survey monument — Petra tells you **what** the monument is (in the notice's own words), **roughly where** to look, and **how rough** that estimate is, then asks you to click the spot on the live map. Your click establishes the point; a block that names several monuments collects them one ask at a time, and every claim gets its own. The result lands as plotted claims on your map with an honest per-claim confidence tier, alongside the land holdings you imported directly. Plotted claims keep their link back to the source paperwork, so you can always answer "why is this corner here?" ## Availability Claim plotting is being rolled out gradually. If it's enabled for your account, just ask Petra — "can you plot claims from a location notice?" — and upload the paper in chat. If it isn't enabled yet and you need it, get in touch — we're onboarding projects steadily. This topic will grow a live walkthrough when the rollout completes. --- # The 3D viewer > Terrain, drill traces and downhole data in a live 3D scene — no desktop software needed. Source: https://geodb.io/guide/topic/threed/ · Category: Seeing your data The 3D viewer turns your project into a scene you can orbit: real terrain, drill traces desurveyed from your survey data, and downhole geology and grades painted along the holes. ## Building the scene The scene sets itself up when you open it: drill traces are built from your surveys and the terrain is fetched for the project's area (see the topography topic). The status strip under the scene says what is still building and why. ## What you can show - **Terrain** — from your project's elevation data, with imagery draped. - **Drillholes** — collars and traces; colour and filter them, and paint intervals along the trace: assay grades by ranges you define, lithology and alteration in their lookup colours. - **Point data** — surface samples, structural measurements, water sites. - **Land holdings** — claim polygons draped on the terrain. Grade ranges and their colours are configurable per element — the same ranges drive the map and strip logs, so red means the same thing everywhere. ## Sharing it Save what is on screen as a named view (Views, at the top): your team opens the same view from its link. *In development:* geostatistics — block models and grade estimation are being built and will appear here when ready. What you see today is display, not estimation. --- # API access and vendor grants > Give a vendor a scoped key and let their software pull — you never export for them again. Source: https://geodb.io/guide/topic/api_keys_protocol/ · Category: Sharing your data The endgame of "stop touching your data": when a third party — an AI targeting vendor, a resource consultant, an auditor's data team — needs your project data *in their system*, you don't export and email. You grant access, and their software pulls. ## Vendor grants The **access grants** page issues scoped, revocable credentials: label the grant ("Acme targeting — 2026"), set an expiry and a rate limit, and create it. The token is shown once — hand it to the vendor through your own channel. From then on their software pulls what the grant allows, every pull is logged (you can see who pulled what, when), and when the engagement ends you revoke the grant. No shared passwords, no please-find-attached. ## What they can pull Project data in formats data teams actually want — tabular data, geospatial layers, and rasters — through a documented interface: the full, current reference lives in-app under **API docs**. Your data stays in your database; vendors read through the window you opened, at the rate you allowed, until the date you set. ## Your own keys Your personal API tokens (the same kind the QGIS plugin uses) are listed on your account page. Grants are for organisations and software; personal tokens are for you. ## Why this beats exporting An export is a snapshot with your name on it and no memory of where it went. A grant is scoped, logged, rate-limited, expiring, and revocable — and always serves *current* data. When the vendor asks for "the latest", the answer is: you already have it. --- # Map layers (lines and areas) > Your geology map as live data: sketch it in the field, trace it in QGIS, publish it to the web map and every crew phone. Source: https://geodb.io/guide/topic/data_layers/ · Category: Sharing your data Map layers are how lines and areas live in geoDB as *data*, not as a picture: map units, contacts, faults, alteration zones, targets, infrastructure. Every feature keeps its geometry, its attributes and its original coordinates in the CRS you drew or imported it in. ## From field sketch to project map 1. **Sketch in the field.** On the phone, open a mapping area and sketch contacts, faults and units by hand over the basemap, on separate sheets (lithology, structure, alteration). It works offline; a sync uploads the sketch in place on the map (the field app 2.0 and later also uploads the strokes themselves). 2. **Open it in QGIS.** With the geoDB QGIS plugin, version 2.35.6 or later, **Field sketches** lists each sketch by mapping area, who drew it and when. **Open sketch** loads the image in place with a see-through background, ready to trace. **Open strokes as lines** turns the strokes into draft lines, one layer per sheet, so you clean them up instead of tracing from zero. 3. **Trace it.** **New map layer** makes a layer of lines, areas or points with its kind (map units, contacts, faults…) in your project's CRS. Add the attributes you like (unit, confidence, notes) and note the sketch it was traced from. 4. **Publish to geoDB.** The layer goes live on the web map and on crew phones. Save it as a draft instead if it is not ready. ## Bringing an existing map in Upload a zipped shapefile, GeoPackage, KML/KMZ or GeoJSON from **Import → Import map layers**, from **Display settings → Map layers**, or from the map editor's **Add layer** menu. A package with several layers lists each one so you pick what to bring in. Uploads land as **drafts**: saved, but on no map until someone publishes them. The map editor's **Add layer** and the **Import map layers** page can put them straight on the map when you tick that box. If exactly one live layer of the same type (lines, areas or points) already has that name, a layer from a zipped shapefile package or a GeoPackage replaces it and the old one is archived (kept); a KML, KMZ or GeoJSON layer, which is named after the file, is saved as a draft and asks whether to replace that layer or keep both. A layer that comes with its own style (a QGIS style, GeoPackage or KML styles) keeps it. A layer with none is coloured by geoDB and says so: areas by an obvious unit field (unit, map unit, lithology, formation…), anything else one colour per kind. Restyle it in QGIS and publish, or use **Link to catalog** to take the colours and FGDC patterns of your Lithology, Alteration or Formation catalog, shared with the strip logs and 3D. ## Keeping a layer up to date Pull the layer into QGIS, edit it, and press **Publish to geoDB** (plugin 2.35.6 or later). The new version replaces the old one on every map and phone, and the old one moves to **Archived**: kept, and it can be made live again. Features you did not touch keep their original coordinates exactly. If someone else published a newer version after your pull, the plugin asks before replacing it. ## Managing your layers **Display settings → Map layers** on the web lists every layer of the project, live, draft or archived. There you rename a layer or change its kind (**Rename / kind**), publish a draft (replacing the layer it updates, or alongside it), discard a draft, archive a live layer or make an archived one live again, and link a layer to a catalog. The draft badge in the map's layer panel publishes a draft right there. In QGIS (plugin 2.35.6 or later), the **geoDB map layers** panel does the same and more: it shows each layer's kind, feature count, last edit and the sketch it was traced from, and restores a discarded draft from the Trash. ## On the phone Live map layers download to crew phones with the field syncs and work offline. In the field app 2.0 and later, tap a unit or a fault to see what it is: the layer, its kind, its name and attributes, and the field sketch it was traced from. The phone sketches; lines and areas are made in QGIS (or the web), not drawn on the phone. ## Where map layers show - **Your project's map** in the map editor, toggled in its layer panel, and in map figures you capture from it. - **QGIS**, with their styling, through the geoDB plugin. - **Crew phones**, offline included. - **Partner data access**: live layers are part of the project data that connected tools and vendor exports read. Drafts and archived layers never are. Not yet: the 3D viewer, shared review maps, public map embeds and the company-wide map. --- # Datarooms > A curated, always-current room of project material — share a link instead of maintaining a folder. Source: https://geodb.io/guide/topic/datarooms/ · Category: Sharing your data A dataroom is the answer to "can you send the data room?" without the week of copying files: a curated room of project material — maps, figures, tables, documents, summaries — that you share as a link, and that stays current because it's built on your live database. ## Building one Open your project's **dataroom workspace** and add sections: an overview, drilling, assays, land, reports — whatever the audience needs. Each section holds panes you curate: a live map, key figures, data tables, uploaded documents. You can also just tell Petra what you want — "start a dataroom for the Copper Ridge financing, drilling and land sections first" — and she'll set up the skeleton and add material as you direct; the room is yours to refine. ## Publishing — always your click Nothing is visible to anyone until **you** publish. The Publish & Access panel controls it: publish or unpublish the room and manage how guests get in. Petra can stage everything and will hand you the button — she never publishes a room herself. ## The guest experience Guests open the link and see a clean, read-only room: your sections, your ordering, your framing. They see only what you put in the room — not your project, not your database, no edit surface anywhere. ## Keeping it current Because panes are live views of your data, the room updates as the project does — a new certificate's samples appear in the table pane; the map pane shows this week's collars. Re-curating means editing the room, not re-exporting files. --- # Exporting data > Clean CSV or Excel of anything in the project — big jobs run in the background. Source: https://geodb.io/guide/topic/export_data/ · Category: Sharing your data Sometimes you genuinely need files — for a consultant's model, a regulator, an archive. The **project export** page produces them cleanly, from the same database everything else reads. ## Exporting Tick the data types you want — or everything — pick CSV or Excel, and export. Assay values can ride along with samples, flattened one column per element using your project's merge settings, so the spreadsheet a consultant receives matches what your strip logs show. ## Big projects Large exports (a hundred thousand samples with assays) build in the background: the page shows the job's progress and gives you the download when it's ready — no held-open browser tab, no gateway timeouts. Recent export jobs stay listed on the page so you can re-download. ## Coordinates Exports honour your project's output coordinate setting — the same one the ODBC connection uses — so exported eastings and northings land in the grid your recipient expects. ## Before you export, a thought If the recipient needs it *current* rather than *once*, consider the alternatives on this shelf: a **dataroom** (curated link, always up-to-date), **ODBC** (live desktop connection), or an **API grant** (their software pulls it). Files go stale; those don't. --- # ODBC — live database access > Leapfrog, QGIS and friends read your drilling live — no export files, ever. Source: https://geodb.io/guide/topic/odbc_access/ · Category: Sharing your data ODBC gives desktop software a **live, read-only** connection to your project's drilling data. Leapfrog Geo, QGIS, or anything that can talk to a PostgreSQL-style database sees your collars, surveys, lithology and assays as tables — straight from the database, not from an export that was stale the day after it was made. ## What the connection serves Collar, survey, lithology, alteration and sample tables, with assay values already flattened into one column per element using your project's merge settings — the same "which method wins" preference that drives your exports and logs. Update a hole in geoDB and the next refresh in Leapfrog sees it. ## Coordinates, your way Different desktop tools want different grids. The **output coordinate system** setting (in project settings) controls what the connection serves: WGS84, your project's UTM zone, a local grid, or the original imported values — change it once and every connected tool follows. ## Setting it up The connection details live with your project settings; each user connects with their own credentials, and access follows the same permissions as the web app — a viewer connecting over ODBC still can't write anything. It's read-only by design: the database of record stays the database of record. --- # QGIS and the field app > The QGIS plugin and the mobile field app — the same project, at the desk and at the rig. Source: https://geodb.io/guide/topic/qgis_field_app/ · Category: Sharing your data Two more doors into the same project: the **geoDB QGIS plugin** for GIS work at the desk, and the **geoDB Field** mobile app for data capture away from it. ## The QGIS plugin Install the geoDB plugin in QGIS and sign in with your geoDB account — the plugin talks to the same interface the mobile app uses, with your normal permissions (two-factor included). Your project's spatial data — collars, samples, holdings, vector layers — loads as QGIS layers you can symbolise and analyse alongside anything else in your GIS. For live tabular drilling data in QGIS, the ODBC connection (previous topic) is the companion door. ## The field app geoDB Field (iOS and Android) is for the truck and the outcrop: point samples, field notes, structural measurements, photos — captured on the device, GPS-tagged, and synced to the project when you're back on signal. Offline capture is the point: work all day without coverage and sync once, without hand-copying anything. Forty seconds of it, silent and captioned: Drilling contractors have their own corner of the mobile app for daily shift reports — that's covered in *Running your program*. ## One database, every door The desk, the GIS and the field all read and write the same project — there is no "field copy" to reconcile later. A sample captured on the phone is on your maps and in your exports as soon as it syncs. --- # Drill program monitoring > Rigs, contractors and daily shift reports — then ask for meters by rig and a progress report. Source: https://geodb.io/guide/topic/drill_program_monitoring/ · Category: Running your program Once the drills turn, the questions never stop: how many meters this week? which rig is behind? what did we burn in bits and mud? Drill program monitoring answers them from **daily shift reports** — one small record per drill per shift — instead of from a spreadsheet someone maintains at 9pm. ## Setting up the program A few minutes on the drilling pages before the first shift: - **Drills and contractors** — register each rig and the company running it. Contractor staff can be given **contractor-scoped accounts**: they see their own rigs and their own shift reports, and nothing else of your project. - **Activity types** — what a shift's hours get logged against (drilling, moving, standby, repairs…). Sensible defaults exist; add your program's own. - **Consumables** — bits, rods, mud, additives — with costs if you want burn tracked in dollars as well as units. You'll find all of it under the drilling pages and the drilling group in project settings. ## The daily rhythm: shift reports Each shift files one **daily shift report (DSR)**: date, drill, hole, start and end depths, hours by activity, consumables used. Three ways they arrive: - **Typed at the rig or the office** — the DSR form takes a minute. - **From the field app** — contractors file from the rig on a phone, offline-safe, synced when there's signal. - **From a photo of the paper form** — many contractors still hand over carbon-copy shift dockets. Snap a photo, hand it to Petra, and she reads it into a *draft* report with the activity rows filled in — you review and save. A draft never becomes the record without your eyes on it. ## Asking for the story: summaries and reports With DSRs flowing, the program's story is a question away. Ask Petra things like *"meters by rig this week"*, *"what did shift standby cost us in March"*, or *"summarise drilling progress for the monthly report"* — she reads the shift reports and answers with the numbers, and can compose a period summary — meters by rig and day, activity breakdown, consumable burn — into a progress report document you can keep or share. The drilling pages remain the manual surface: every report and rig list is there to browse whenever you'd rather look than ask. One honest boundary: shift reports are created rig-side, by people or from their paperwork. There's no shortcut that turns a drilling *contract* into shift reports — a contract sets up the contractor and rigs; the shifts still have to happen. --- # What Petra can do > The honest capability map — what she does, what she asks first, and what she hands you a button for. Source: https://geodb.io/guide/topic/what_petra_can_do/ · Category: Petra Petra is the assistant behind the diamond in the bottom corner of every page. The short version: **she's AI for data stewardship** — getting data in, keeping it clean, understanding it, presenting it. Here's the honest map. ## What she does well - **Imports.** Hand her files in chat — clean CSVs, messy spreadsheets, lab certificate PDFs, whole ZIPs — and she reads, proposes, and lands them with your approval. This is her deepest skill. - **Answers questions about your data.** "How many holes are past 300 m?", "top ten copper intercepts", "which certificates came back this month" — she queries the live database and shows her working. - **Charts and figures.** Histograms, scatters, downhole plots — made in chat, editable by asking, and one click from living on your canvas. - **Housekeeping.** Renaming lookup values, fixing units, deduplicating, reassigning samples to the right certificate — the DBA chores, each gated behind an approval card before anything changes. - **Styling.** "Give my lithologies sensible industry colours and patterns" — she proposes a full scheme; one approval styles maps, logs and 3D alike. - **Drilling summaries.** With shift reports flowing, she summarises meters by rig and day, activity hours and consumable burn, and composes them into progress reports. - **Getting you to the right page.** Ask where something lives and she answers with a button. She never redirects you — you click, or you don't. - **Answering from this guide.** Her documentation answers come from the same topics you're reading. If no guide covers a question, she says so rather than inventing steps. ## What she asks you first Every change to your database — an import, an edit, a deletion — shows you an approval card before it happens. Bigger and riskier asks get firmer gates; deletions are never waved through. Autonomy in geoDB means *less clicking*, not *less consent*. ## What she deliberately doesn't do - **Publish for you.** Datarooms go live on your click, not hers. She stages; you publish. - **Find deposits.** Petra does data stewardship — importing, categorizing, QC, analysis, figures, reporting. Targeting and discovery belong to you and whichever specialist tools you choose; her job is making sure the data they get is worth their time. - **Guess.** When she doesn't know — a capability that doesn't exist yet, a question with no guide, a page you can't access — the answer is the honest one, sometimes with a button to the person-shaped alternative. ## In development Geostatistics — block models and grade estimation — is being built and badged as such. She'll tell you it's coming rather than pretend it's here.