GDD’s Fundamental Data Philosophies

With many years of experience in many environments and countries, GDD has developed and evolved our own data management philosophy. This consists of a combination of some basic high-level philosophies, underpinned by our very specific technical data management standards and procedures.

The GDD Difference Over a period of 40+ years, our staff and associates have been involved n a broad range of exploration, open pit and underground mining and other industry projects. Over the same timeframe, we have been involved in the development and commissioning of many large-scale technical databasese application systems across that spectrum. Our qualifications, skills and experience set us apart in the data collection, management and analysis workspace. GDD’s vision is to help companies – Understand the true value of their data, and the risks in not managing it properly Effectively collect, manage and analyse all of their data And ultimately save time and money leading to increased profits and reduced project risk. We encourage innovation, application and cooperation. We share our knowledge with clients to help them better create, manage and make full use of their data asset. We focus efforts also on research and development to deliver the best data environments using the most current but rigorously tested technologies, including AI and the new scanning technologies. Our database and application systems are built to assist in every stage of the mining life cycle. Very simply – We believe in doing things once and doing them right! To that end, GDD have evolved a series of fundamental data management philosophies around defining what master technical data consists of, understanding its true importance and value to resource projects, and treating it accordingly.

Our Data Philosophies

These core data management philosophies guide strongly the design and implementation of the data environments we build, and the database applications and utilities that GDD have developed.

They seek to address the following questions relevant to the technical data universe! In summary these include –

The TWO Master Technical Data Sets

‘Begin with the end in mind…’

There are several key requirements for your master technical data if it is to provide the best return on investment made in collecting it. Every project, process or discipline that relies on the analysis of specific technical data should be maintaining two master data sets.

• • The Master Working Technical Data Set – The ‘single point of truth’; the assembled, standardised, integrated, validated data sets you build for your project analysis and decision-making requirements
  • The Master Source/Original Data Set – The original as-collected, inherited, received, scrounged or pilfered data in its complete original untouched form. These components will often exist in two places; as original as-received system files, and within the database, with links to the working data set and the original system files

The Master WORKING Technical Data Set

The master working technical data sets, the assembled, integrated and standardised data ultimately used for analysis and decision making, should be –

• • ‘The data, the whole data and nothing but the data’
  • Instantiated – The master data must actually exist / be visible or ‘observable’; it should not rely on arcane queries or processes to extract it or make it visible
  • Common Data Type Instantiation – All standard or commonly expected observation or measurement data types should have a single, fixed and unambiguous location.
  • Logical, Clear and Consistent Data Structure – Clear, transparent and unambiguous data structure (schema) – with understandable, logical and consistent object naming conventions
  • Contained Data – must be complete, integrated and standardised
  • • Contain only the ‘accepted’ (highest priority, ‘golden’) data value for any item
  • Data Integrity – Must be accurate and regularly validated
  • Accessible – No matter who assembles or manages your data, you should maintain an accessible current local copy at all times
  • Secure and Quarantined – The data set should be segregated from any intermediate, working, QAQC or additional measurement (lower priority) data that should not be included be included in the master working data set
  • • Should also be protected from inadvertent MCU’s or malicious damage. E.g. set to read-only once validated
  • Auditable – The data should be linked to its source / original data records

The Master SOURCE Technical Data Set

The master source / original technical data collection should likewise be –

• • Complete and Unaltered – The source data should be retained exactly as collected or received (following validation)
  • Accessible
  • Secure and Quarantined
  • Auditable – With provenance data / links to identify its origin

Data Analysis is DATA Analysis!

• • Understand that all data analysis processes and applications, including the newly emerging technologies, rely on a complete, sound underlying master technical data set. …Which is why it’s called ‘data analysis’!

Understand Your Technical Data’s Value And Importance

• • Understand the full and fundamental importance and significant value of your technical data

Maintain That ‘Single Point Of Truth’

• • Ensure that the master or ‘gospel’ copy of each dataset type exists in one place only

The Technical Data Life Cycle

There are three distinct activity phases in the data life cycle –

• • Collect – Getting the data in the first place, identifying and storing it
  • Manage – Validation and integrity checking, accessibility and security, standardisation and assembly of the master working data sets
  • Analyse – Using the assembled data; analysis, evaluation, extraction and reporting; decision making

Link and Use Of ALL Your Data Understand what master technical data consists of; these days; it’s much more than the letters and numbers! What aspects need to be considered to assemble all of the relevant data types and attributes useful to the project? GDD recognise and use four data-use classes – Primary Data – The conventional alpha-numeric data Secondary Data – generally multi-media data and information types related to specific primary data records (e.g. core tray and other photos, videos satellite and aerial images, field drawings and maps etc.) Linked to and retrievable from the related primary data record Tertiary Data – files / data of any type that may not add information, but serves to verify the data in the primary and secondary data sets. (E.g. survey or lab assay certificates, historical report PDF’s) Again with links to their relevant primary and secondary data records for instant auditability Metadata – Data about the data records as stored; date created / modified, source data and original file details, data and validation status, data change-control stuff etc.

Link and Use Of ALL Your Data

Understand what master technical data consists of; these days; it’s much more than the letters and numbers!

What aspects need to be considered to assemble all of the relevant data types and attributes useful to the project?

GDD recognise and use four data-use classes –

• • Primary Data – The conventional alpha-numeric data
  • Secondary Data – generally multi-media data and information types related to specific primary data records (e.g. core tray and other photos, videos satellite and aerial images, field drawings and maps etc.)
  • • Linked to and retrievable from the related primary data record
  • Tertiary Data – files / data of any type that may not add information, but serves to verify the data in the primary and secondary data sets. (E.g. survey or lab assay certificates, historical report PDF’s)
  • • Again with links to their relevant primary and secondary data records for instant auditability
  • Metadata – Data about the data records as stored; date created / modified, source data and original file details, data and validation status, data change-control stuff etc.

Structure Your Master Data Environment

• • Know how to structure and implement your master technical data / database
  • Understand and provide the data management characteristics and attributes, as dictated by the type of data being assembled
  • Understand the data collection, management and analysis processes that are required

Segregate Your Master Technical Data

• • Keep your master technical data and database separate from and independent of all application and work folders and files

Make Data Access Simple And Intuitive Make data access simple and intuitive to all those needing to make use of the data through queries or linked 3D modelling applications Think JORC ‘Transparency’

Data Validation And Integrity Checking Ensure that complete and sound data validation processes are in place and active during data entry, Provide data integrity checking tools that further monitor and check the data once inside the database Tools should also exist to allow the revalidation of all or part of the data at any time. This may be to detect subsequent changes to the data, or to check for changes to say code libraries or to other related data records in other tables etc.

Standards And Procedures To help ensure everything gets done the same way, in the same order, with the correct equipment, by the appropriate people, at the appropriate time, in a safe environment, every time. Design, implement, document and enforce data management standards and procedures and related tools and guidelines to maximise your project value, and reduce project risk inherent in, your technical data collection Standardisation of Terms – ‘Calling the same data attribute the same name’ Data Collection and Logging Guides – ‘Calling the same stuff the same name’ Standardisation of Reference (Lookup) Codes – ‘…and giving it a standard code’ External Standards and Procedures – Government legislated and industry guidelines; for reference, cogitation or mandated use… Determine how these should best be implemented to ensure they are used, and ‘encouraged’ To that end, establish some technical data governance guidelines; these are in effect standards and procedures… for your standards and procedures! Think JORC ‘Competence’

Capture And Retain Data Provenance Carefully retain the data provenance (where it came from) and ensure it is auditable Again, JORC ‘Transparency’

New Technologies

• • AI, Master Technical Data, and The Need For Some RI – AI’s have significant and valuable potential, but also associated risks. They (nearly) all require an underlying platform of sound ‘foundational’ data. There is a real need to apply some serious RI as we start to make use of them