# 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.