KCMI Checklist — 12 Things an Auditor Will Ask

A KCMI audit is an experience that gives even a senior Competent Person heart palpitations. I’ve sat on both sides — the auditor’s side and the CP being audited. Both sides are nervous. But if you know the 12 questions that are certainly coming, that anxiety turns into preparation.

This post is a practical checklist: the 12 things an auditor will almost certainly ask when reviewing a KCMI 2017 resource report (and JORC 2012, since the overlap is 90%). For each point I explain why the auditor asks, what answer is expected, and how GeoSuite helps document it.

If you’re preparing for an audit, read this, work through it point by point, and remember: nothing is worse than being caught not knowing the answer to a predicted question.

What is KCMI 2017?

KCMI (Komite Cadangan Mineral Indonesia) 2017 is Indonesia’s national standard for reporting mineral resources and reserves. It descends from the international CRIRSCO template — same family as JORC (Australasia), NI 43-101 (Canada), SAMREC (South Africa). The standard is mandatory for:

• Reporting to ESDM (Ministry of Energy and Mineral Resources)
• Feasibility studies submitted to the government
• Public reserve reporting on the Indonesia Stock Exchange

For dual-listed projects (e.g., ASX + Indonesia), you typically need KCMI + JORC. Good news: 90% of the report content is the same. Bad news: the remaining 10% — Competent Person qualifications, disclosure format, language — can trigger an audit if you don’t prepare.

KCMI requires sign-off by a Competent Person Indonesia (CPI) registered with PERHAPI or IAGI. That detail often delays foreign-owned projects — they have a JORC CP, but no CPI. Plan for it from the start.

The 12 things an auditor will ask

1. How did you validate the drillhole data?

This question is always first. The auditor wants to know whether you have a systematic validation procedure, not “I trusted the database.”

What’s expected: a validation summary covering collar (unique IDs, coordinates, elevation), survey (azimuth, dip, depth monotonicity), assay (overlaps, gaps, BDL convention, unit consistency), and cross-table join completeness. Format: a Pass/Fail table per category, with notes for exceptions.

What often causes trouble: no written validation summary. “The database was cleaned by data entry” is not an answer. JORC Table 1 Section 1 explicitly requires disclosure of validation procedures.

How GeoSuite helps: the Core Web module auto-generates a validation summary — 6 check categories, PDF format, attaches to Table 1. See also the drillhole data validation checklist I wrote previously.

2. What percentage of QA/QC samples (blank, standard, duplicate) did you run?

The auditor wants confirmation that QA/QC samples are ≥5% of the total, and that results were monitored.

What’s expected: a QA/QC summary with:

• Standards: set per batch, recovery within ±2SD (2 standard deviations) of certified value
• Blanks: set per batch, blank value <3x lower detection limit
• Duplicates: field duplicate + pulp duplicate, with precision metrics (HV, RPD, or R²)
• Total percentage: ≥5% of total samples

What often causes trouble: QA/QC claimed as “≥5%” but no control charts. Or failures exist but no corrective action documentation.

How GeoSuite helps: the Assay module auto-tracks QA/QC samples, generates control charts, and flags failures outside ±2SD. PDF report attaches to Table 1.

3. What is your BDL (Below Detection Limit) convention?

A technical question but crucial. BDL handling affects statistics, especially in low-grade domains.

What’s expected: a single documented convention. Common choices:

• Half detection limit (e.g., 0.005 gpt if DL = 0.01 gpt)
• Full detection limit
• -1 as a placeholder, replaced before estimation

What often causes trouble: mixed conventions in one database (some 0, some -1, some string “BDL”). Or convention not documented — the auditor has to guess.

How GeoSuite helps: the Assay module flags inconsistent BDL encoding and consolidates to a single convention of your choice. The audit log records the conversion.

4. How did you define estimation domains?

Domains are the foundation of estimation. The auditor wants to know whether your domains are geology-based (lithology, structure, weathering) or arbitrary (grade shells).

What’s expected: domain justification per boundary. For grade shells: cite the grade threshold + method (indicator kriging, probabilistic, or hard threshold). For lithology domains: cite logging procedure + cross-section validation. For structure-controlled domains: cite structural data (foliation, fault orientation).

What often causes trouble: domains defined in software with no written justification for why a boundary sits where it does. Or domains claimed as “geological” that are actually grade-based, inconsistent with the report text.

How GeoSuite helps: the Resource module tracks domain definitions, and ANOVA per domain is automatic — the F-statistic + p-value quantifies whether domain separation is statistically justified.

5. What variogram parameters did you use?

The classic question. The auditor wants to see the variogram model + parameters, not just the words “ordinary kriging.”

What’s expected: a parameter table per domain:

• Model type (spherical, exponential, nested)
• Nugget
• Sill (or partial sills if nested)
• Range per direction (major, semi-major, minor)
• Anisotropy ratio

Plus the experimental variogram plot with pair count per lag.

What often causes trouble: variogram parameters not disclosed. Or disclosed but the experimental variogram not attached — the auditor can’t validate whether the model fit is reasonable.

How GeoSuite helps: the Resource module renders the experimental variogram + model fit + pair count per lag, and exports the parameter table. See also variogram anatomy for geologists who hate math for theoretical context.

6. Why did you choose that estimation method (OK, IDW, NN)?

The auditor wants justification for the method choice, not “we usually use OK.”

What’s expected: a justification covering:

• Why OK (ordinary kriging): minimization of estimation variance, accounting for spatial autocorrelation via variogram
• Why IDW (inverse distance weighting): simpler, no variogram required, use when data is too sparse for a reliable variogram
• Why NN (nearest neighbor): baseline comparison, or to validate the kriging neighborhood

Plus: a method comparison (swath plot OK vs IDW vs NN) showing OK is consistent or better.

What often causes trouble: only OK with no comparison. Or IDW with no justification for why not OK.

How GeoSuite helps: the Resource module runs OK, IDW, and NN in a single pass and generates a swath plot comparison. The auditor sees all three, with identical parameters.

7. What are your search ellipsoid parameters?

A technical question about the kriging neighborhood.

What’s expected: per domain:

• Search radius (typically 2.5x variogram range)
• Min/max samples (typical 8-20)
• Octant restriction (e.g., min 1 sample per octant, max 3)
• Anisotropy ratio (matching the variogram anisotropy)

Plus: a kriging neighborhood analysis (KNA) justifying the min/max samples choice.

What often causes trouble: search parameters inconsistent with variogram anisotropy. Or min samples = 1, which means some blocks are estimated from a single sample (functionally NN).

How GeoSuite helps: the Resource module suggests a search radius from the variogram range, and KNA automatically tests the min/max sample range. The audit log records the final parameters.

8. How did you justify the top-cut?

A political question. The auditor wants to know whether your top-cut is data-driven or arbitrary.

What’s expected: per domain:

• Pre-cut distribution (histogram, P95-P99.9 percentiles, max value)
• Cut value applied (e.g., P98)
• Number of samples affected + percentage
• Mean change + variance change
• Justification: “P98 chosen because it stabilizes the experimental variogram” or “P97.5 because P98 doesn’t sufficiently cap outliers in domain SED-1”

What often causes trouble: “P98 because the previous consultant used P98.” That’s not a justification. Or top-cut applied but not disclosed in the report.

How GeoSuite helps: the Assay module generates a Before/After summary automatically — mean change, variance change, sample count affected. See the post on Snowden Supervisor-style Before/After validation for the full workflow.

9. What are your classification criteria (Measured, Indicated, Inferred)?

The auditor wants to know whether your classification criteria are data-driven (drill spacing, kriging variance) or subjective judgment.

What’s expected: defined criteria per category:

• Measured: drill spacing ≤ X meters, kriging variance ≤ Y, geological continuity verified
• Indicated: drill spacing X-Y meters, kriging variance Y-Z
• Inferred: drill spacing Y-Z meters, or limited extrapolation

Plus: a classification map + tonnage/grade table per category.

What often causes trouble: classification criteria not documented. Or documented but inconsistent with what was applied in the block model.

How GeoSuite helps: the Resource module applies classification automatically based on criteria you set (drill spacing, kriging variance, or a combination). The classification map renders in section view.

10. How did you validate the block model?

The auditor wants to see estimation validation, not just the estimate.

What’s expected: at minimum three validations:

• Swath plot: estimate vs composite per band (X, Y, Z direction) — estimate should follow composite with smoothing
• Cross-validation (jackknife): leave-one-out, kriging estimate vs actual composite, with slope and correlation
• Visual validation: block model vs composite in section view, per domain

What often causes trouble: no validation at all. Or only visual “looks OK” with no swath plot or quantitative cross-validation.

How GeoSuite helps: the Resource module auto-generates swath plots (X, Y, Z direction), cross-validation with slope + correlation metric, and section view block vs composite. All export as a PDF validation report.

11. What is your Reasonable Prospects for Eventual Economic Extraction (RPEEE)?

A question often skipped in early-stage projects. KCMI (and JORC) explicitly require this — you can’t report a resource with no realistic path to mining.

What’s expected: a discussion covering:

• Mining method that’s plausible (open pit, underground, or combination)
• Pit shell / stope shell demonstrating recoverable proportion
• Economic assumptions (commodity price, recovery, cost) — with a disclaimer that these are preliminary
• Cut-off grade used for resource reporting

What often causes trouble: no RPEEE discussion in the report. Or present, but no pit shell / stope shell to support it.

How GeoSuite helps: the Resource module supports simple pit shell optimization (Lerchs-Grossmann) with economic parameters you input. Output: recoverable resource tonnage per category, with cut-off grade disclosure.

12. Who is your Competent Person, and what are their qualifications?

An administrative question that’s fatal if you’re not ready.

What’s expected: for KCMI:

• CPI registered with PERHAPI or IAGI
• 5+ years of relevant experience with the style of mineralization being reported
• CP consent letter signed, with disclosure of interest

For JORC (if dual-reporting):

• RPO member (AusIMM, AIG, or equivalent)
• 5+ years of relevant experience
• JORC CP consent signed

What often causes trouble: CP not registered as CPI (for KCMI submission). Or CP consent letter not prepared before publication. Or CP relevant experience not documented.

How GeoSuite helps: not directly — this is administrative. But GeoSuite generates all the technical appendices (variogram, validation, ANOVA, top-cut, search parameters) that the CP attaches when signing consent. Your CP signs off on an estimation that’s documented end to end.

How GeoSuite helps overall

Across the board, GeoSuite answers 9 of the 12 questions above with technical appendices generated automatically:

1. Drillhole validation summary → Core Web module
2. QA/QC control chart → Assay module
3. BDL convention audit → Assay module
4. Domain ANOVA → Assay module
5. Variogram parameter table → Resource module
6. Estimation method comparison (OK/IDW/NN) → Resource module
7. Search parameters + KNA → Resource module
8. Top-cut Before/After → Assay module
9. Block model validation (swath, cross-validation) → Resource module

The remaining three (classification, RPEEE, CP qualifications) are still judgment calls that you — the Competent Person — own. But the technical basis for all of them is documented in GeoSuite output.

Product spec: aligned with SNI 4726:2019, KCMI, and JORC reference standards. A single self-contained tool, offline, no install friction, no third-party data uploads. You hold full control over data and workflow.

Bottom line

A KCMI audit is predictable if you prepare. The 12 questions above are what will be asked. The answer key for all of them: written documentation, disclosed parameters, justification per decision. The auditor isn’t looking for perfection — they’re looking for traceability.

If you can’t show documentation for one of the 12 points above, that’s a red flag. If you can’t for three or more, your audit is in trouble.

Start preparation from project day one, not one week before the audit. Reproducible workflows from day one = a relatively painless audit at the end.

---

Preparing for a KCMI or JORC audit? Try GeoSuite Core Web free on your laptop — every technical appendix for 9 of the 12 questions above generates offline, no install friction, no data uploads. Email me at hello@orebit.id if you want to discuss a specific audit scenario.

# From this article:
open geosuite.orebit.id
load(your_drillhole.csv)
apply(workflow_above)

# Done. Ship the report.