Resources / Mining Charter
Mining Charter Submission Pack — what you get (client-facing spec)
This is the standard, template‑driven deliverables specification for a Mining Charter submission pack produced from a controlled baseline (governed inputs + repeatable rules).
Important: this document contains no client figures. The actual pack we deliver is client‑specific (your mine/entity details, your scope, your figures, and your evidence references) and follows this same consistent structure.
Outcome: a pack leadership can stand behind and defend , with traceability from source → metric → scorecard/table , plus an exception closure trail , pack provenance , and approval pages .
What this enables (in plain English):
- a declared scope and reporting period that stays consistent across every table/scorecard,
- a defensible “show me” trail from headline outputs back to source exports (and evidence pointers where required),
- a clear review position: what’s complete, what’s missing, who owns closure, and by when,
- optional, quantified non‑binding scenarios that show potential score movement under explicit assumptions (no recommendations).
What this pack will not include
- “Recommendations”, “strategy”, or bespoke advisory narrative.
- A prescriptive improvement programme. Where uplift scenarios are included, they are non‑binding and framed as quantified “if X were true…” scenarios with explicit evidence/owner dependencies.
- Scope creep: out‑of‑scope contractors/entities are not silently included.
Usage rules (non‑negotiable)
- One pack per Mining Right per reporting period.
- Scope is explicitly stated and consistent across every output: mine + in‑scope contractors + community entities (where applicable).
- Commentary is limited to:
- scope/definitions,
- objective comparisons (targets vs actuals where applicable),
- exceptions and closure status.
- Every scorecard/table includes:
- reporting period label (start → end),
- scope label (consolidated / mine / contractor as applicable),
- Insite export name (or report name), and
- export date/time.
- Preserve traceability: source → metric → scorecard/table (and evidence pointer where required).
Authorisation + release review
- Insite includes a data owner authorisation step when promoting final imports from staging to production for the reporting cut.
- Final release review/approval of the exported pack is completed outside Insite (review meeting and/or signature pages).
Pack inputs (what must be defined up front)
- Mine / operation name
- Mining Right reference number(s)
- Reporting period (start → end)
- Submission date (or deadline)
- Pack version identifier (e.g., v1.0)
- Addressee (DMRE/DMPR regional office)
- Applicable Charter / template interpretation notes (what tables/scorecards are required, and any agreed interpretations)
- Entities in scope (list exactly what’s included):
- Mine entity
- Core contractor(s)
- Community entities / projects (if applicable)
- Source systems and controlled extracts (examples; as agreed), including extract dates/timestamps
Deliverables (artifacts you receive)
- Submission pack (PDF): complete, versioned Mining Charter pack populated with your scope + figures (sections below), with consistent definitions and controlled outputs.
- Workbook (XLSX, where required): a structured workbook version of the scorecard/tables for review/submission workflows (aligned to the pack numbers).
- Pack provenance (scope, period, reports used, extract dates, rules/mappings, data quality position)
- Exception closure list: gaps/anomalies/queries per section with owner, due date, and closure status (including any explicitly accepted assumptions).
- Approval pages: signature blocks per section/metric owner and final authorised signatory page.
- Board summary (optional, 1–2 pages): readiness status, key open exceptions, accepted assumptions, and review/approval position.
- Score leakage & uplift scenarios (optional, non‑binding): quantified table showing where score is unclaimed and potential uplift under explicit scenarios, with assumptions, evidence dependencies, and owners (no recommendations).
Traceability (in Insite)
Traceability is provided in the system (not as a separate exported “index”):
- Drill down from headline scorecards/tables to the list of contributing records used.
- Open record‑level trace to see where an individual record came from.
- Export source ↔ final record mappings where required.
Pack structure (example)
1. Cover + submission letter
- Submission letter addressed to the relevant regional office.
- Cover page: mine name, Mining Right reference(s), reporting period, version/date.
- Pack overview: scope statement (entities in scope), data sources/extracts list, and interpretation notes (what template is being used).
2. Introduction & particulars of operation
Purpose: state the pack scope and operating context factually (no narrative beyond what the template requires).
Outputs typically include:
- Introduction / preamble (controlled wording).
- Particulars of operation (mine context, reporting scope, and entity list).
3. Scorecard (consolidated + breakdowns as required)
Purpose: present the Mining Charter scorecard outputs in a way that is defensible and reviewable.
Outputs typically include:
- Scorecard interpretation notes (DTI/DMRE interpretation as applicable; references to the applied ruleset).
- Consolidated scorecard performance (mine + in‑scope contractors).
- Optional split views (mine only; contractor 1; contractor 2; etc.) where stakeholders require separate review/approval.
- Commentary limited to: completeness/freshness flags and exception closure status (not “advice”).
3A. Score leakage & uplift scenarios (optional, non‑binding)
Purpose: show where score is being left on the table (or is at risk) and make the “way forward” visible as quantified scenarios — without prescribing actions.
This section is framed as sensitivity analysis: “if X were true and evidence Y is available, score impact may be up to Z”.
| Element / table | Requirement (scoring rule) | Current (claimed) | Gap | Potential uplift (score/level) | Evidence / unlock condition | Owner | Due date | Status |
|---|---|---|---|---|---|---|---|---|
| Procurement / Table H | Qualifying spend definition per ruleset | — | — | — | Evidence pack + supplier classification confirmed | — | — | Open |
| HRD / Table Q | Eligible training categories + headcount scope | — | — | — | Training register + proof of spend + scope alignment | — | — | Open |
4. Ownership
Purpose: document ownership position per the relevant template requirements.
Outputs typically include:
- Ownership scorecard.
- Table A (Existing Mining Right Ownership Overview) where applicable.
5. Mine community development
Purpose: show community development commitments/projects as required, with traceable budgets and reporting periods.
Outputs typically include:
- Community development scorecard.
- Project register (name, location, period, budget/actuals where applicable, status, evidence references).
- Table S per project where applicable.
6. Housing and living conditions
Purpose: show housing and living conditions reporting for the defined workforce scope.
Outputs typically include:
- HLC scorecard.
- Table W (Housing and Living Conditions annual reporting), typically:
- consolidated view (mine + in‑scope contractors),
- optional split views (mine only; contractor breakdowns) where required.
7. Human resource development
Purpose: show HRD commitments and performance with a clear boundary between employee vs non‑employee reporting.
Outputs typically include:
- HRD scorecard.
- HRD expenditure summary (controlled categorisation notes if required).
- Table Q totals (employees) — detail typically provided as an annexure.
- Table R totals (non‑employees) — detail typically provided as an annexure.
8. Employment equity
Purpose: present employment equity tables and scorecard outputs at the required scope(s).
Outputs typically include:
- Employment Equity views (consolidated + mine + contractor breakdowns as required).
- Table T (Employment Equity).
- Table U (Income Differentials).
- Table V (Career Progression Plan).
9. Procurement element
Purpose: present procurement element outputs with clear scope, supplier categorisation logic, and traceability to controlled inputs.
Outputs typically include:
- Procurement scorecard views (consolidated + mine + contractor breakdowns as required).
- Table H (Mining Goods Procurement).
- Table I (Mining Services Procurement).
- Table J (Enterprise and Supplier Development).
- Table K (Supplier Development / OEM).
- Table L (Research and Development).
- Table M (Sample analysis / processing location).
- Table N (Mining Goods scorecard).
- Table O (Mining Services scorecard).
- Table P (Weighted scores adjusted by ESD).
10. Statement of undertaking
- Statement of undertaking (standard wording + authorised signatory).
11. Annexures (typical)
Outputs typically include:
- Detailed breakdowns where required (e.g., Q/R detail).
- Extract list and dates (pack provenance) + rules/mappings notes.
- Exception closure summary and closure status (with owner approval blocks).
- Evidence references (where required).
Output checks (before release)
- Reporting period label matches the stated start → end dates on every scorecard/table.
- Mining Right reference number(s) and scope statement match the pack scope (mine + in‑scope contractors + community entities where applicable).
- Every table/scorecard cites its export source (quickview/report name + export date/time).
- Pack provenance is present and matches the stated scope, period, and included exports.
- Exceptions are either closed (with evidence) or explicitly accepted (with owner approval recorded on the approval pages).
- Approval pages are present and signed (outside Insite) or explicitly marked pending approval.
- If score leakage/uplift scenarios are included, they are labelled as non‑binding scenarios and include assumptions + evidence dependencies (not recommendations).