ESG Domain Glossary

Status: Final Version: 1.4 Last Updated: 2026-01-19

---

Purpose

Provide authoritative definitions for all ESG, sustainability, and reporting terms used throughout the platform documentation and implementation. This glossary ensures consistent terminology across technical specifications, user interfaces, and stakeholder communications.

---

Scope

In Scope: - ESG and sustainability core concepts - Reporting framework terminology (GRI, CSRD, ISSB, TCFD, SASB) - Data lifecycle and governance terms - Platform-specific technical terms - Regulatory and compliance terminology

Out of Scope: - Detailed framework-specific disclosure requirements (see Metric Catalog) - Implementation details (see architecture and workflow docs) - Industry-specific terminology beyond ESG reporting

---

Core ESG Concepts

ESG

Environmental, Social, and Governance - A framework for evaluating an organization's collective sustainability and ethical impact. The three pillars are:

• Environmental (E): Climate change, resource depletion, waste, pollution, deforestation, carbon emissions
• Social (S): Employee relations, diversity and inclusion, human rights, labor standards, community relations, product safety
• Governance (G): Board composition, executive compensation, business ethics, corruption, tax transparency, shareholder rights

Platform Context: The system supports data collection, validation, and reporting across all three ESG pillars as defined by GRI Standards and custom client KPIs.

---

Stakeholder

An individual, group, or organization that has an interest in or is affected by an organization's activities, products, or services. Stakeholders can be internal (employees, shareholders) or external (customers, communities, regulators, suppliers).

Platform Context: The system tracks engagement with categorized stakeholder groups for GRI 2-29 reporting. Stakeholder data collection follows PII protection guidelines, using group labels instead of individual names where possible.

---

Sustainability

The capacity to endure and maintain ecological balance while meeting present needs without compromising future generations. Broader than ESG, sustainability includes: - Environmental stewardship - Economic viability - Social equity

ESG vs Sustainability: - ESG: Investor-focused framework for risk assessment and comparative analysis (external reporting) - Sustainability: Organization-wide strategy for long-term value creation (internal + external)

Platform Context: The platform primarily focuses on ESG reporting (disclosure to stakeholders) but supports sustainability management use cases (internal tracking, target setting).

---

Impact

The effect of an organization's activities on the economy, environment, and society. Impacts can be: - Positive (job creation, carbon sequestration) or Negative (pollution, human rights violations) - Actual (already occurred) or Potential (could occur) - Direct (caused by the org) or Indirect (caused by value chain partners)

Platform Context: Metrics capture actual impacts (e.g., tonnes CO₂ emitted, training hours delivered). Potential impacts and impact assessments are out of scope for v1.

---

Materiality & Scope

Materiality

The threshold at which ESG topics become sufficiently important to be reported. Two types:

1. Financial Materiality (Single Materiality)
2. Definition: Topics that could substantially influence investor decisions (impact on enterprise value)
3. Used By: SASB, TCFD, ISSB, US SEC

4. Example: Climate risks that could impair assets or disrupt supply chains

5. Impact Materiality (Double Materiality)

6. Definition: Topics where the organization has significant impact on people or environment, PLUS financial materiality
7. Used By: GRI, CSRD (EU), ESRS
8. Example: Water pollution affecting local communities (impact) AND potential fines/reputation damage (financial)

Platform Context: v1 supports GRI-style impact materiality. Material topics are pre-configured per client based on industry and stakeholder input. Dynamic materiality assessment is vNext.

---

Material Topic

A specific ESG issue deemed material through assessment process (e.g., "Water Consumption," "Occupational Health & Safety," "Anti-Corruption").

Platform Context: Stored in material_topics table, linked to gri_disclosures and metric_definitions. Determines which metrics are mandatory vs optional for a reporting period.

---

Reporting Boundary

The entities, operations, and geographic locations included in an ESG report. See Reporting Concepts for detailed boundary types.

Quick Reference: - Organizational Boundary: Which legal entities are included (parent, subsidiaries, JVs) - Operational Boundary: Which facilities/sites are included - Value Chain Boundary: Upstream (suppliers) and downstream (customers) scope

---

Reporting Frameworks & Standards

Framework

A structured set of principles and guidelines for ESG reporting (e.g., GRI Standards, SASB Standards, TCFD Recommendations).

Platform Context: Stored in frameworks table. v1 supports GRI Standards 2021. vNext: ISSB S1/S2, CSRD/ESRS.

---

Standard

A specific module within a framework covering a topic or sector (e.g., GRI 302: Energy, GRI 401: Employment).

Platform Context: Stored in gri_standards table. Each standard contains multiple disclosures.

---

Disclosure

A specific reporting requirement within a standard (e.g., GRI 302-1: Energy consumption within the organization).

Platform Context: Stored in gri_disclosures table. Each disclosure links to one or more metrics/datapoints.

---

Datapoint / Metric

The atomic unit of ESG data reported (e.g., "Total electricity consumption in MWh").

Platform Context: Stored in metric_definitions table. A disclosure may require multiple metrics (e.g., GRI 302-1 requires electricity, fuel, heating, cooling, steam consumption separately).

Metric vs Indicator: - Metric: Raw quantitative measure (e.g., 5,000 MWh) - Indicator: Derived or normalized measure (e.g., energy intensity = MWh per revenue or per FTE)

---

GRI (Global Reporting Initiative)

The most widely adopted ESG reporting framework globally. GRI Standards 2021 includes: - Universal Standards: GRI 2 (General Disclosures), GRI 3 (Material Topics) - Topic Standards: Environmental (300s), Social (400s), Governance (not numbered)

Platform Context: v1 supports GRI Universal Standards + 11 Topic Standards. See GRI/ESG Scope v1.

---

CSRD (Corporate Sustainability Reporting Directive)

EU regulation mandating sustainability reporting for large companies and listed SMEs. Requires double materiality and ESRS compliance.

Platform Context: Out of scope for v1. vNext consideration.

---

ISSB (International Sustainability Standards Board)

Issues IFRS Sustainability Disclosure Standards (S1 General Requirements, S2 Climate). Focus on investor-oriented financial materiality.

Platform Context: Out of scope for v1. vNext consideration.

---

TCFD (Task Force on Climate-related Financial Disclosures)

Framework for climate risk disclosure across four pillars: Governance, Strategy, Risk Management, Metrics & Targets.

Platform Context: TCFD-recommended metrics (Scope 1/2/3 GHG) supported via GRI 305. Dedicated TCFD reporting format is vNext.

---

SASB (Sustainability Accounting Standards Board)

Industry-specific standards for financially material ESG topics (now part of ISSB).

Platform Context: Out of scope for v1. Custom KPIs can be SASB-aligned via tagging.

---

Data Collection & Evidence

Submission

A package of ESG data submitted by a collector for a specific reporting period, site, and set of metrics.

Platform Context: Stored in metric_submissions table. Immutable after submission (edits create new versions). See Data Lifecycle.

---

Evidence

Supporting documentation that substantiates a metric submission (e.g., utility bill for energy data, training register for social metrics, audit report for governance).

Platform Context: Stored in evidence table, linked to submissions via metric_evidence pivot table. Files are immutably stored with content hashing. See Evidence Management.

Evidence Types: - Environmental: Meter readings, lab reports, waste manifests, utility invoices - Social: HR registers, training records, incident logs, survey results - Governance: Board minutes, policies, audit reports, certifications

---

Template

A pre-configured data collection form defining which metrics to collect, validation rules, and evidence requirements.

Platform Context: Generated from metric_definitions and material_topics for a given reporting period and scope. Delivered via Collector API.

---

Stakeholder Engagement & Grievances

Stakeholder Category

A classification of stakeholder groups with shared characteristics or relationships to the organization (e.g., Community, Employees, Suppliers, Investors, Regulators, Media, NGOs).

Platform Context: Stored in stakeholder_categories master table. Tenant-scoped and configurable by admins. Used to tag engagements and grievances for GRI 2-29 reporting. A single engagement can involve multiple stakeholder categories (many-to-many relationship via engagement_categories junction table). See Stakeholder Engagement API.

---

Stakeholder Group

A specific named stakeholder entity involved in an engagement or grievance (e.g., "Guruve Local Government," "Community Leaders," "Operations Department").

Platform Context: Used in stakeholder_engagements.stakeholder_name and grievances.stakeholder_group fields. PII Protection Rule: Store organization or group names, NOT individual names. In grievances, use general categories (e.g., "Community," "Employees") to protect privacy. See Collection Templates.

---

Engagement Platform

The communication channel or mechanism used for stakeholder interaction (e.g., In-person Meeting, Virtual Meeting, Phone Call, WhatsApp, Email, Letter, Conference).

Platform Context: Stored in engagement_platforms master table. Tenant-scoped and configurable. A single engagement can use multiple platforms (many-to-many relationship via engagement_platforms_used junction table). Tracked for GRI 2-29 disclosure. See Data Model.

---

Stakeholder Engagement

A documented interaction between the organization and one or more stakeholder categories for purposes such as consultation, information sharing, partnership, or impact management.

Platform Context: Stored in stakeholder_engagements table. Quarterly log collection for GRI 2-29 reporting. Each engagement record includes: initial date, stakeholder categories, stakeholder name (group level), purpose, outcome, responsible person, status (Open/WIP/Closed), and status date. Multi-category and multi-platform engagements supported. See Stakeholder Engagement API.

Status Lifecycle: Open → WIP → Closed (one-way transitions).

---

Engagement Outcome

The results, decisions, commitments, or actions arising from a stakeholder engagement. Records what was achieved or agreed during the interaction.

Platform Context: Stored in stakeholder_engagements.outcome field. Required when engagement status transitions to Closed. Captured as free text. Used in GRI 2-29 stakeholder engagement logs. Distinct from grievance interventions (which describe remedial actions for complaints).

---

Engagement Status

The current lifecycle state of a stakeholder engagement. Three states:

• Open: Engagement initiated but work not yet started
• WIP (Work In Progress): Engagement actions underway
• Closed: Engagement completed with documented outcome

Platform Context: Stored in stakeholder_engagements.status enum field. Transitions are one-way (no reverse). Status changes tracked with status_date field. Used for filtering and reporting incomplete engagements.

---

Grievance Mechanism

A formal process through which stakeholders can raise complaints, concerns, or disputes about the organization's operations, and receive a response or remedy. Part of responsible business conduct and access to remedy under UN Guiding Principles on Business and Human Rights.

Platform Context: Implemented as grievances table with tracking for internal/external grievances. Supports GRI 2-29 and grievance mechanism disclosure requirements. Each grievance includes: date reported, internal/external classification, stakeholder group (general label only), nature of grievance, intervention measure, and resolution status. See Collection Templates.

---

Grievance Intervention

The action taken or planned by the organization in response to a grievance. Describes remedial measures, investigations, corrective actions, or compensation provided.

Platform Context: Stored in grievances.intervention_measure field. Captured as free text. Distinct from engagement outcomes (which describe results of consultations, not remedies for complaints). Used in grievance mechanism log exports.

---

Grievance Resolution Status

Indicates whether a grievance has been addressed. Two states:

• OUTSTANDING: Grievance remains unresolved or under investigation
• RESOLVED: Grievance has been addressed with documented intervention

Platform Context: Stored in grievances.resolution_status enum field. Used for tracking open grievances and reporting closure rates. No intermediate states (simpler than engagement status lifecycle).

---

Collective Bargaining

Negotiations between one or more employers (or employers' organizations) and one or more workers' organizations to determine working conditions, terms of employment, or to regulate relations between employers and workers. Recognized as a fundamental labor right under ILO Convention 98.

Platform Context: Tracked via GRI 2-30 metric (GRI_2_30_COLLECTIVE_BARGAINING_COVERAGE). Measured as percentage of full-time permanent employees covered by collective bargaining agreements, including National Employment Council (NEC) membership or Trade Union agreements. Collected quarterly at organization level. See Metric Catalog.

Calculation: (Employees covered by collective bargaining / Total FTE) × 100

---

Human Capital & Employee Data

Employment Level

The hierarchical classification of employees within an organization based on role, responsibility, and decision-making authority. Three levels are tracked for GRI 405-1 diversity reporting:

• Executive: Senior leadership positions (C-suite, board members, managing directors)
• Salaried Staff (Non-NEC): Professional and administrative roles not covered by National Employment Council collective bargaining agreements
• Waged Staff (NEC): Workers covered by National Employment Council collective bargaining agreements (typically production, operations, and manual labor roles)

Platform Context: Stored as enum EmploymentLevel with values EXECUTIVE, SALARIED_STAFF_NON_NEC, WAGED_STAFF_NEC. Used as a dimension in GRI 405-1 employee demographics metrics. Executive metrics collected at organisation level; Salaried/Waged metrics collected at site level. See Metric Catalog.

---

Employment Type

The contractual classification of workers based on duration and nature of employment relationship. Three types tracked for GRI 401 reporting:

• Permanent: Full-time employees with indefinite contract duration (no predetermined end date)
• Fixed-Term: Employees hired for a specific period or project with a predetermined contract end date
• Casual: Day workers or temporary labor not on permanent or fixed-term contracts (e.g., seasonal workers, daily hires)

Platform Context: Stored as enum EmploymentType with values PERMANENT, FIXED_TERM, CASUAL. Used in GRI 401 employment type and turnover metrics collected monthly. Mutually exclusive categories (each employee counted in only one type). See Metric Catalog.

---

Local Community Employee

An employee whose primary residence or origin is in the geographic community where the organization's operations are located. Tracked as a diversity indicator to demonstrate local economic contribution and community integration.

Platform Context: Stored as boolean dimension LocalCommunityStatus (YES/NO) alongside employment level metrics for GRI 405-1. Reported as headcount and percentage of total employees from local community. Aggregated data only (no individual identifiers). Minimum aggregation threshold of 5 employees required for PII protection. See Metric Catalog.

GRI Context: Supports GRI 405-1 diversity disaggregation requirements and demonstrates contribution to GRI 203-2 (Significant indirect economic impacts through local employment).

---

Age Group

The categorization of employees by age range for workforce demographics reporting. Three age groups tracked for GRI 405-1 and employee age distribution metrics:

• Under 30: Employees below 30 years of age (young workforce)
• Aged 30-50: Employees between 30 and 50 years of age (mid-career)
• Over 50: Employees above 50 years of age (senior workforce)

Platform Context: Stored as enum AgeGroup with values UNDER_30, AGED_30_50, OVER_50. Collected monthly for age demographics reporting (E.3 Employee Age Demographics table). Broad age ranges used instead of specific ages to protect employee privacy (PII protection). Aggregated counts only, minimum 5 employees per category required. See Metric Catalog.

Privacy Rationale: Age groups prevent individual identification in small teams. Specific birthdates or ages are never collected or stored in submissions.

---

Organizational Structure

Tenant

The top-level organizational container representing a client organization. Provides hard multi-tenancy boundary.

Platform Context: All data scoped by tenant_id. Isolation enforced at middleware, database, and storage layers. See Tenancy and Roles.

---

Organisation (Org)

The legal entity or corporate group within a tenant. Can have multiple business units and sites.

Platform Context: Stored in organisations table. Defines organizational boundary for reporting.

---

Business Unit

A division, department, or strategic business unit within an organization.

Platform Context: Stored in business_units table. Optional intermediate hierarchy level.

---

Site (Facility)

A physical location where operations occur (e.g., factory, office, warehouse, data center).

Platform Context: Stored in sites table. Primary dimension for data collection (most metrics collected at site level). Can be aggregated to business unit or org level.

---

Reporting Period

A defined time span for ESG data collection and reporting (e.g., FY2025, Q1 2026, Calendar Year 2025).

Platform Context: Stored in reporting_periods table with states (OPEN, IN_REVIEW, APPROVED, LOCKED). See Data Lifecycle.

---

Data Lifecycle States

Draft

Client-side only state (mobile app). Data not yet uploaded to backend. Supports offline editing and auto-save.

Platform Context: Not stored in backend database. Lives in mobile app local storage until queued for upload.

---

Queued

Submission ready for upload but not yet transmitted (offline mode) or in-flight during upload.

Platform Context: Transition state between Draft and Received. UUID generated for idempotency.

---

Received

Submission successfully ingested by backend but not yet validated.

Platform Context: Raw data stored in metric_submissions.raw_data JSONB field. Triggers async validation job.

---

Validated

Submission passed all automated validation checks (schema, domain, business rules, evidence completeness).

Platform Context: Validation results stored in validation_results table. Ready for human review.

---

Rejected

Submission failed validation or reviewer rejected with feedback.

Platform Context: Collector receives structured feedback. Can resubmit (creates new version).

---

Processed

Submission data normalized, unit-converted, and mapped to canonical metrics. Ready for aggregation and reporting.

Platform Context: Processed data stored in metric_submissions.processed_data JSONB field. Triggers review task creation.

---

Approved

Human reviewer (Approver role) formally signed off on submission quality and completeness.

Platform Context: metric_submissions.approved_at and approved_by_user_id set. Eligible for inclusion in reports.

---

Locked

Reporting period closed; submissions immutable and eligible for external reporting.

Platform Context: Cryptographic hash computed over submission + evidence. No further edits allowed without unlocking and triggering restatement process.

---

Access Control & Roles

RBAC (Role-Based Access Control)

Security model where permissions are assigned to roles, and users are assigned roles.

Platform Context: 5 roles defined: Collector, Reviewer, Approver, Admin, Auditor. See RBAC Matrix.

---

Collector

Field user who submits ESG data and evidence. Cannot approve own submissions.

Platform Context: Site-scoped access. Can create Draft/Queued submissions, view own submissions, upload evidence.

---

Reviewer

User who validates submission quality, requests corrections, and transitions to Reviewed state.

Platform Context: Site or project-scoped access. Can view all submissions in scope, add comments, request changes.

---

Approver

Senior user who provides formal sign-off on submissions. Cannot approve own submissions (segregation of duties).

Platform Context: Tenant or business unit-scoped access. Can transition Processed → Approved, lock reporting periods.

---

Admin

System administrator with break-glass override capabilities. Should NOT routinely approve submissions.

Platform Context: Tenant-wide access. Can manage users, configure metrics, override workflows (with mandatory audit justification).

---

Auditor

External or internal auditor with read-only access for assurance purposes.

Platform Context: Tenant-wide read-only access. Can export data, view audit logs, but cannot mutate submissions.

---

Validation & Quality

Validation Rule

A constraint or business logic check applied to submissions during validation pipeline.

Platform Context: Defined in metric_definitions.validation_rules JSONB. Types: - Schema Validation: Data type, required fields, format (regex) - Domain Validation: Allowed value ranges, enum membership - Referential Validation: Foreign key integrity, cross-metric consistency - Evidence Validation: Required evidence present and valid - Business Rule Validation: Custom logic (e.g., "total = sum of components")

See Validation Engine.

---

Anomaly Detection

Automated checks for unusual values (outliers, sudden spikes/drops) that warrant human review.

Platform Context: Statistical checks (Z-score, year-over-year % change) flagged as warnings (not hard failures). vNext: ML-based anomaly detection.

---

Data Quality Dimensions

Standard criteria for assessing ESG data quality: - Accuracy: Data is correct and error-free - Completeness: No missing required fields or evidence - Consistency: Data agrees across related metrics - Timeliness: Data submitted within reporting period - Validity: Data conforms to schema and business rules - Reliability: Evidence supports the claimed values

---

Reporting & Disclosure

Baseline

A reference point (typically a historical year) against which progress is measured.

Platform Context: Stored in reporting_periods with is_baseline = true. Used for trend analysis and target tracking. See Reporting Concepts.

---

Restatement

Retrospective correction of previously reported data due to errors, methodology changes, or acquisitions/divestments.

Platform Context: Requires unlocking a Locked reporting period, creating new submission versions, and re-locking with updated cryptographic hash. See Locking & Restatements.

---

Assurance

Independent verification of ESG data and reports by external auditor (similar to financial audit). Levels: - Limited Assurance: Review-level (ISAE 3000) - Reasonable Assurance: Audit-level (higher confidence)

Platform Context: Auditor role can access all data and audit logs for assurance purposes. Formal assurance workflows out of scope for v1.

---

Consolidation

The process of aggregating data from multiple sites/business units into organizational-level totals.

Platform Context: Aggregation queries sum metrics across sites based on organizational boundary. Different approaches apply depending on metric type (additive vs non-additive). See Reporting Concepts.

---

Technical & Implementation Terms

CDI Bean

A managed component in the Contexts and Dependency Injection (CDI) framework. CDI is the standard dependency injection framework in Quarkus and Jakarta EE.

Platform Context: Services, repositories, and resources are CDI beans with scopes like @ApplicationScoped, @RequestScoped, or @Dependent. Arc is Quarkus's optimized CDI implementation.

---

CDI Container (Arc Container)

The runtime environment that manages CDI bean lifecycle, dependency injection, and contextual scopes. Quarkus uses Arc as its CDI implementation.

Platform Context: Arc provides build-time optimizations, reducing startup time and memory footprint compared to traditional CDI containers. Injectable via BeanManager when needed.

---

Quarkus Extension

A module that integrates a library or technology into the Quarkus framework. Extensions provide build-time optimizations, dependency injection setup, and native image support.

Platform Context: Project uses extensions for database (Panache), security (Quarkus Security, SmallRye JWT), messaging (SmallRye Reactive Messaging), and observability (MicroProfile Health/Metrics). Analogous to Spring Boot Starters but with build-time processing.

Example Extensions: - quarkus-hibernate-orm-panache - Database access with Panache - quarkus-security-jpa - Database-backed authentication - quarkus-smallrye-jwt - JWT authentication - quarkus-smallrye-reactive-messaging-rabbitmq - RabbitMQ integration

---

Quarkus Profile

A configuration mechanism to customize application behavior for different environments (%dev, %test, %prod).

Platform Context: Configuration properties in application.properties can be prefixed with profile (e.g., %dev.quarkus.datasource.url). Profiles replace Spring Boot Profiles.

Standard Profiles: - %dev - Development mode with hot reload and Dev Services - %test - Testing environment with test resources - %prod - Production mode with optimizations enabled

---

Arc

Quarkus's build-time oriented CDI implementation. Performs dependency injection analysis during build, resulting in faster startup and lower memory usage.

Platform Context: Arc powers all dependency injection in the platform. Supports standard CDI features (@Inject, @ApplicationScoped, @Produces) with additional Quarkus-specific optimizations.

---

Panache

Quarkus's simplified Hibernate ORM layer providing active record or repository patterns with less boilerplate than traditional JPA.

Platform Context: All data access uses Panache repositories extending PanacheRepository<Entity>. Methods like .persist(), .findById(), .list() replace JPA repository interfaces.

Example:

@ApplicationScoped
public class OrganisationRepository implements PanacheRepository<Organisation> {
    public List<Organisation> findByTenantId(Long tenantId) {
        return list("tenantId", tenantId);
    }
}

---

Mutiny

Quarkus's reactive programming library providing Uni<T> (single async result) and Multi<T> (stream of results).

Platform Context: Used for async REST endpoints, reactive messaging, and non-blocking I/O operations. Alternative to CompletableFuture or RxJava.

Example:

@GET
@Path("/async")
public Uni<Response> getDataAsync() {
    return repository.findByIdAsync(123L)
        .onItem().transform(entity -> Response.ok(entity).build());
}

---

Dev Services

Quarkus feature that automatically provisions containerized infrastructure (databases, message queues) during development using Testcontainers.

Platform Context: Developers don't need to manually start PostgreSQL or RabbitMQ locally. Dev Services auto-starts containers when running quarkus dev or tests.

Supported Services: - PostgreSQL, MySQL, MariaDB - Kafka, RabbitMQ - Redis, MongoDB - Keycloak (authentication)

---

Dev UI

Quarkus's web-based developer console accessible at /q/dev in development mode. Provides insights into application configuration, beans, endpoints, and extension features.

Platform Context: Use Dev UI to inspect CDI beans, test REST endpoints, view database entities, check health status, and browse configuration properties.

Features: - Configuration browser with resolved values - REST endpoint listing with test UI - CDI bean inspector with dependency graph - Database schema viewer (Hibernate) - Messaging channels monitor - Health check dashboard - Metrics explorer

---

Idempotency

The property that an operation can be applied multiple times without changing the result beyond the initial application. Critical for handling network retries and duplicate submissions.

Platform Context: Submission UUIDs ensure duplicate uploads don't create multiple records. See Ingestion Pipeline.

---

Immutability

The property that data cannot be modified after creation. Ensures audit trail integrity and regulatory compliance.

Platform Context: Submissions are append-only. Edits create new versions. Evidence files are content-hashed and immutably stored. See Data Lifecycle.

---

Audit Log (Audit Trail)

An append-only record of every state transition, approval action, and privileged operation in the system.

Platform Context: audit_logs table stores actor, timestamp, action, before/after state, justification. Cryptographically sealed for compliance. See RBAC Implementation.

---

Content Hash

A cryptographic fingerprint (SHA-256) of file contents or data snapshots. Detects tampering and ensures integrity.

Platform Context: Evidence files and Locked submissions have content hashes stored in database. Verified on access.

---

Soft Delete

A deletion strategy where records are marked as deleted (via deleted_at timestamp) but not physically removed from the database.

Platform Context: JPA @SQLDelete annotation with @Where(clause = "deleted_at IS NULL") used on user-facing entities (users, sites). Audit logs and submissions never soft-deleted (immutable).

---

Multi-Tenancy

An architecture where a single system instance serves multiple isolated client organizations (tenants).

Platform Context: Hard isolation at tenant_id level. Middleware enforces tenant context on every request. Database rows scoped by tenant. See Tenancy and Roles.

---

Regulatory & Compliance Terms

GDPR (General Data Protection Regulation)

EU regulation governing personal data protection and privacy.

Platform Context: ESG submissions may contain PII (employee data in social metrics). System implements right to erasure, data portability, and consent tracking. See Security & Compliance.

---

PII (Personally Identifiable Information)

Data that can identify an individual (names, email, employee IDs, etc.).

Platform Context: Social metrics (diversity, training, incidents) may contain PII. Sensitivity classification enforced. Access restricted by role. Encryption at rest required.

---

SoD (Segregation of Duties)

Control principle where no single person should have permissions to both create and approve the same transaction.

Platform Context: Collectors cannot approve own submissions. Approvers should not be collectors (policy, not technical constraint). Admin approvals flagged in audit log.

---

RTO (Recovery Time Objective)

The maximum acceptable downtime after a disaster.

Platform Context: Defined in Non-Functional Requirements. Target: < 4 hours for critical data collection periods.

---

RPO (Recovery Point Objective)

The maximum acceptable data loss measured in time.

Platform Context: Defined in Non-Functional Requirements. Target: < 1 hour (continuous backups).

---

Version Control & Compatibility

vNext

Features planned for future versions but explicitly excluded from current (v1) scope.

Platform Context: Throughout documentation, "vNext" denotes forward-compatibility considerations (e.g., IoT sensor integration, AI-powered anomaly detection, ISSB support).

---

Breaking Change

A modification to APIs, data models, or workflows that requires client updates and is not backward-compatible.

Platform Context: API versioning (e.g., /api/v1/submissions, /api/v2/submissions) isolates breaking changes.

---

Semantic Versioning

Version numbering scheme: MAJOR.MINOR.PATCH (e.g., 1.3.2) - MAJOR: Breaking changes - MINOR: New features, backward-compatible - PATCH: Bug fixes, backward-compatible

Platform Context: Documentation and API use semantic versioning.

---

Occupational Health and Safety (OHS) Terms

Near Miss Incident

An unplanned event that did not result in injury, illness, or damage, but had the potential to do so. Near misses are leading indicators of safety performance and are tracked to prevent future incidents with actual harm.

Platform Context: Tracked via OHS_INCIDENT_NEAR_MISS metric in F.1 Quarterly Incident Statistics. Evidence tier: OPTIONAL (no validation check for missing evidence). Aggregated counts only, no individual employee identifiers. See OHS Metric Catalog.

Example: Worker nearly trips over loose cable but catches balance; equipment malfunction detected before operation begins; vehicle almost collides with another but driver brakes in time.

---

First Aid Incident

A minor work-related injury requiring only basic first aid treatment (bandages, antiseptic, cold compress). Does not require professional medical treatment beyond first aid.

Platform Context: Tracked via OHS_INCIDENT_FIRST_AID metric in F.1 Quarterly Incident Statistics. Evidence tier: OPTIONAL. Typically recorded in FIRST_AID_REGISTER or CLINIC_REGISTER. See OHS Collection Templates.

Example: Small cut treated with bandage, minor burn treated with cold water, splinter removal, insect bite treatment.

---

Restricted Work Incident

A work-related injury that results in an employee being unable to perform their normal duties but can perform modified or restricted duties. The employee remains at work but with temporary job restrictions (light duties, reduced hours, modified tasks).

Platform Context: Tracked via OHS_INCIDENT_RESTRICTED_WORK metric in F.1 Quarterly Incident Statistics. Evidence tier: RECOMMENDED (soft warning if missing). Supports GRI 403-9 recordable injury disclosure. See OHS Report Outputs.

Example: Sprained wrist allows desk work but not heavy lifting; minor back strain permits sitting tasks but not standing/walking; temporary hearing loss requires reassignment from noisy area.

---

Medical Treatment Incident

A work-related injury or illness requiring professional medical treatment beyond first aid (doctor consultation, prescription medication, sutures, physical therapy). Does not result in lost time or restricted work.

Platform Context: Tracked via OHS_INCIDENT_MEDICAL_TREATMENT metric in F.1 Quarterly Incident Statistics. Evidence tier: RECOMMENDED. Requires MEDICAL_TREATMENT_RECORD or ACCIDENT_REPORT. Supports GRI 403-9 recordable injury classification. See OHS Validation Rules.

Example: Laceration requiring stitches, fracture requiring X-ray and casting, chemical exposure requiring medical evaluation, eye injury requiring ophthalmologist consultation.

---

Lost Time Injury (LTI)

A work-related injury that results in an employee being unable to perform any work duties for at least one full day or shift (not counting the day of injury). LTI is a key safety performance indicator tracked globally.

Platform Context: Tracked via OHS_INCIDENT_LTI metric in F.1 Quarterly Incident Statistics and OHS_LTI_DAYS in F.2 LTI Performance. Evidence tier: MANDATORY (submission blocked if missing). Requires LTI_REGISTER or ACCIDENT_REPORT. Supports GRI 403-9 work-related injury disclosure. Used in LTIFR calculation. See OHS Metric Catalog.

LTI Days Calculation: Total number of calendar days (or shifts) an employee is absent from work due to LTI, not counting the day of injury. Cumulative sum across all LTIs in the reporting period.

Example: Back injury requiring 5 days off work, hand injury requiring 3 weeks absence, concussion requiring 2 days rest.

GRI Context: LTI is a subset of "recordable work-related injuries" under GRI 403-9.

---

Fatality

A work-related death resulting from an occupational injury or illness. Fatalities are the most severe incident type and require mandatory investigation, evidence, and regulatory notification.

Platform Context: Tracked via OHS_INCIDENT_FATALITY metric in F.1 Quarterly Incident Statistics. Evidence tier: MANDATORY (minimum 2 attachments required: FATALITY_REPORT + INVESTIGATION_REPORT). Access restricted to Approver, Admin, Auditor, and HSE Manager roles. Supports GRI 403-9 fatality disclosure. See OHS Evidence Management.

Regulatory Requirements: - Immediate notification to labor inspectorate/mining authority - Full incident investigation with root cause analysis - Corrective actions to prevent recurrence - Evidence retention for 10 years minimum

Privacy Considerations: Fatality reports may contain victim information (name, age, medical details) for regulatory purposes. PHI must be redacted for public disclosure. Aggregated fatality counts reported without individual identifiers.

---

High Potential Incident

An event that did not result in a severe injury or fatality but had the realistic potential to do so under slightly different circumstances. Also known as "high potential near miss" or "serious incident."

Platform Context: Tracked via OHS_INCIDENT_HIGH_POTENTIAL metric in F.1 Quarterly Incident Statistics. Evidence tier: MANDATORY. Requires INCIDENT_REGISTER or INVESTIGATION_REPORT. High potential incidents are leading indicators of catastrophic risk and require formal investigation. See OHS Validation Rules.

Example: Fall from height without serious injury due to safety harness, vehicle rollover with minor injuries, confined space near-asphyxiation, uncontrolled energy release (electrical, mechanical).

Risk Management: High potential incidents are investigated as thoroughly as actual fatalities to identify systemic safety failures and prevent future tragedies.

---

Property Damage Incident

An incident that results in significant damage to equipment, vehicles, infrastructure, or other organizational assets, regardless of whether it causes injury. Property damage incidents indicate control failures and are tracked for trend analysis.

Platform Context: Tracked via OHS_INCIDENT_PROPERTY_DAMAGE metric in F.1 Quarterly Incident Statistics. Evidence tier: RECOMMENDED. Requires PROPERTY_DAMAGE_REPORT or INCIDENT_REGISTER. See OHS Collection Templates.

Example: Vehicle collision damaging truck, equipment failure causing machinery damage, chemical spill damaging infrastructure, fire damaging building.

Threshold: Platform defines "significant" property damage based on client policy (e.g., damage exceeding $1,000 USD or requiring equipment replacement).

---

Silicosis / Pneumoconiosis

Occupational respiratory diseases caused by prolonged inhalation of mineral dust (silica, coal dust, asbestos). These are chronic illnesses that develop over years of exposure and are tracked as work-related ill health under GRI 403-10.

Platform Context: Tracked via OHS_INCIDENT_SILICOSIS metric in F.1 Quarterly Incident Statistics. Evidence tier: MANDATORY. Requires OCCUPATIONAL_DISEASE_REGISTER or MEDICAL_TREATMENT_RECORD. Classified as CONFIDENTIAL + PHI due to medical diagnosis. Access restricted to HSE Manager, Approver, Admin, and Auditor roles. Supports GRI 403-10 work-related ill health disclosure. See OHS Security & Compliance.

Types: - Silicosis: Lung disease from crystalline silica dust exposure (mining, quarrying, sandblasting) - Coal Workers' Pneumoconiosis (Black Lung): Lung disease from coal dust exposure - Asbestosis: Lung disease from asbestos fiber exposure

Reporting: Cases are typically identified through occupational health surveillance programs (chest X-rays, pulmonary function tests). Count includes newly diagnosed cases during reporting period.

Privacy: Employee name and medical diagnosis must be redacted from evidence files. Aggregated case counts reported without individual identifiers.

---

Other Clinic Visits

Health-related visits to the occupational clinic or medical facility that do not fall into other incident categories (not classified as first aid, medical treatment, restricted work, or LTI). Includes routine health checks, follow-up appointments, non-work-related minor ailments treated at site clinic.

Platform Context: Tracked via OHS_INCIDENT_OTHER_CLINIC metric in F.1 Quarterly Incident Statistics. Evidence tier: OPTIONAL. Recorded in CLINIC_REGISTER. This metric provides context for overall clinic utilization but is not a formal incident type. See OHS Metric Catalog.

Example: Routine health screening, flu vaccination, blood pressure check, headache treatment, non-occupational minor illness.

Use Case: Helps differentiate total clinic visits from actual work-related incidents for resource planning and health trend analysis.

---

LTI Days (Lost Time Injury Days)

The total number of calendar days (or shifts) that employees are absent from work due to Lost Time Injuries, not counting the day of injury itself. Cumulative sum of all LTI-related absences across the workforce.

Platform Context: Tracked via OHS_LTI_DAYS metric in F.2 LTI Performance (separate from F.1 incident counts). Measured in days (integer). Dimension: workforce type (Mine, Contractors), quarter (Q1-Q4), YTD. Evidence tier: MANDATORY. Requires LTI_REGISTER or ACCIDENT_REPORT showing days lost. Supports GRI 403-9 severity metric (days away from work). See OHS Collection Templates.

Calculation: - Count starts the day after the injury (day of injury is excluded) - Include all calendar days absent (weekends, holidays count if employee would have worked) - Stop counting when employee returns to full duties (including if they return to restricted work) - Sum across all LTI cases in the reporting period

Example: - Employee A: LTI on March 10, returns March 15 → LTI Days = 4 (March 11-14) - Employee B: LTI on March 20, returns April 3 → LTI Days = 13 (March 21 - April 2) - Total Q1 LTI Days = 17

YTD Calculation: Cumulative sum of quarterly LTI Days (Q1 + Q2 + Q3 + Q4).

Cross-Validation: Total LTI Days must be zero if LTI incident count (from F.1) is zero. If LTI count > 0, then LTI Days must be > 0 (enforced by validation rules).

---

LTIFR (Lost Time Injury Frequency Rate)

A standardized safety performance metric measuring the frequency of Lost Time Injuries per million hours worked. LTIFR is the most widely used lagging indicator for occupational safety globally and is required for GRI 403-9 disclosure.

Platform Context: Tracked via OHS_LTIFR metric in F.2 LTI Performance. Calculated metric (derived from LTI count and hours worked). Dimension: workforce type (Mine, Contractors), quarter (Q1-Q4), YTD. Evidence tier: MANDATORY. Requires LTI_REGISTER, TIME_SHEET, PAYROLL_REPORT, or HR_REGISTER to verify hours worked. Precision: 2 decimal places (e.g., 8.10, not 8.1). See OHS Validation Rules.

Formula:

LTIFR = (Number of LTIs × 1,000,000) / Total hours worked

Multiplier: 1,000,000 (per million hours worked) is the industry standard.

Calculation Example: - Q1 2025: 5 LTIs, 500,000 hours worked - LTIFR = (5 × 1,000,000) / 500,000 = 10.00

YTD LTIFR Calculation (Weighted Method):

YTD LTIFR = (Cumulative LTI count × 1,000,000) / Cumulative hours worked

Important: Do NOT calculate YTD LTIFR as the simple average of quarterly LTIFRs. Use the weighted method (cumulative LTIs over cumulative hours) to account for varying workforce sizes across quarters.

Example (YTD Calculation): - Q1: 5 LTIs, 500,000 hours → LTIFR = 10.00 - Q2: 3 LTIs, 600,000 hours → LTIFR = 5.00 - Incorrect YTD LTIFR = (10.00 + 5.00) / 2 = 7.50 ❌ - Correct YTD LTIFR = ((5 + 3) × 1,000,000) / (500,000 + 600,000) = 7.27 ✅

Validation Rules: - LTIFR ≥ 0.00 (cannot be negative) - LTIFR precision: 2 decimal places (e.g., 8.10, not 8.105) - Cross-validation: LTI count from F.1 must match LTI count used in LTIFR calculation - Zero-consistency: If LTI count = 0, then LTIFR = 0.00

GRI Context: LTIFR is explicitly required by GRI 403-9(a) as one of the "rates of recordable work-related injuries."

Benchmarking: LTIFR allows comparison across organizations of different sizes. World-class mining operations target LTIFR < 1.0; average mining LTIFR globally is 5-10.

---

Hours Worked

The total number of hours worked by all employees (or a specific workforce type) during a reporting period. Used as the denominator in LTIFR calculation and as a proxy for workforce exposure to occupational hazards.

Platform Context: Tracked via OHS_HOURS_WORKED metric in F.2 LTI Performance (not part of F.1 incident counts). Measured in hours (numeric, not integer to allow fractional hours). Dimension: workforce type (Mine, Contractors), quarter (Q1-Q4), YTD. Evidence tier: MANDATORY. Requires TIME_SHEET, PAYROLL_REPORT, or HR_REGISTER to verify hours. Supports GRI 403-9(a) requirement to report "hours worked." See OHS Metric Catalog.

Calculation: - Include all hours worked by all employees (full-time, part-time, contractors) - Include regular hours + overtime - Exclude vacation, sick leave, other paid/unpaid leave (not exposure time) - Sum across all employees in the workforce type (Mine or Contractors)

Example: - Site has 100 Mine employees working 40 hours/week for 13 weeks (Q1) - Hours Worked = 100 × 40 × 13 = 52,000 hours

YTD Calculation: Cumulative sum of quarterly hours worked (Q1 + Q2 + Q3 + Q4).

Cross-Validation: Hours worked is required for LTIFR calculation validation. If hours worked = 0 or missing, LTIFR cannot be calculated.

Anomaly Detection: Platform flags unreasonable hours worked values (e.g., >2,080 hours per employee per year triggers warning for potential data error).

---

PHI (Personal Health Information)

A subset of Personally Identifiable Information (PII) specifically related to an individual's health status, medical history, diagnosis, treatment, or healthcare services. PHI is subject to stricter privacy protections than general PII under regulations like HIPAA (US) and GDPR (EU).

Platform Context (OHS-Specific): OHS evidence files may contain PHI if they include individual employee medical diagnoses, treatment records, or health conditions (e.g., MEDICAL_TREATMENT_RECORD, FATALITY_REPORT, OCCUPATIONAL_DISEASE_REGISTER). All OHS evidence containing PHI is classified as CONFIDENTIAL + PHI and requires additional field-level encryption, access restrictions, and redaction before upload. See OHS Evidence Management - PHI Redaction Guidance.

Examples of PHI in OHS Context: - Employee medical diagnosis (e.g., "silicosis," "fracture," "concussion") - Treatment plan or prescription details - Medical test results (X-ray, blood test, pulmonary function test) - Fatality victim's medical information (cause of death, autopsy findings) - Individual employee health surveillance records

Privacy Protection Rules: 1. Aggregated Counts Only: Platform NEVER stores individual employee health records in metric submissions. Only aggregated incident counts permitted. 2. Redaction Required: Evidence files containing PHI must be redacted to remove employee names, ID numbers, diagnoses, and treatment details before upload. 3. Restricted Access: Evidence with PHI restricted to HSE Manager, Approver, Admin, and Auditor roles only (Collectors and Reviewers cannot view after upload). 4. Encryption: PHI-containing evidence files require field-level encryption using AWS KMS (SSE-KMS with customer-managed keys). 5. GDPR Right to Erasure: Employees can request anonymization of individual medical records; aggregated incident counts remain unchanged.

Non-PHI OHS Data: Aggregated incident counts (e.g., "5 medical treatment incidents in Q1") are NOT considered PHI because they do not identify individuals. Incident summaries without employee names or diagnoses are also not PHI.

---

Workforce Type

The employment classification used to disaggregate OHS incident data based on employment relationship. Two workforce types are tracked for GRI 403-9 and GRI 403-10 reporting: Mine (direct employees) and Contractors (third-party workers).

Platform Context: Dimension used in all OHS metrics (F.1 and F.2). Incident counts, LTI days, hours worked, and LTIFR are reported separately for Mine and Contractors. Allows identification of safety performance differences between direct employees and contractor workforce. See OHS Report Outputs.

Definitions: - Mine (Direct Employees): Full-time, part-time, and fixed-term employees directly employed by the organization (on the organization's payroll) - Contractors (Third-Party Workers): Individuals working at the organization's sites but employed by a third-party contractor company (not on the organization's payroll)

GRI Context: GRI 403-9 and GRI 403-10 require disaggregation of injury and ill health data by workforce type to distinguish between employees and workers who are not employees.

Total Calculation: Platform reports Mine, Contractors, and Total (Mine + Contractors) for all incident types and performance metrics.

---

Environmental Management Terms

TSF (Tailings Storage Facility)

An engineered structure designed to safely store mining waste (tailings) produced during the processing of ore. TSFs are critical environmental and safety infrastructure requiring continuous monitoring and management to prevent failures that could cause catastrophic environmental damage, community harm, and loss of life.

Platform Context: TSF management metrics are tracked monthly via G.8 TSF Management tables, including slurry density, freeboard, surface area, and rate of rise. TSF monitoring data supports GRI 306 (Waste) disclosures and demonstrates compliance with dam safety standards (e.g., Global Industry Standard on Tailings Management - GISTM). See Environmental Metric Catalog.

Components: - Slurry: Mixture of water and finely ground waste rock pumped into the TSF - Embankment/Dam Wall: Structure that contains the tailings - Decant System: Water recovery system for recycling process water - Monitoring Instruments: Piezometers, settlement monuments, flow meters

Risk Management: TSF failures are high-consequence, low-probability events. Monthly monitoring of key stability indicators (freeboard, rate of rise, slurry density) enables early detection of instability.

---

Freeboard

The vertical distance between the current surface level of tailings/water in a Tailings Storage Facility (TSF) and the crest (top) of the TSF dam wall. Freeboard provides a safety margin to prevent overtopping of the dam during heavy rainfall or operational upsets.

Platform Context: Tracked via TSF_FREEBOARD metric in G.8 TSF Management. Measured in metres (m). Collected monthly. Dimension: TSF identifier (if multiple TSFs at site). Evidence tier: RECOMMENDED (TSF_INSPECTION_REPORT). Freeboard is a critical safety indicator for TSF stability. See Environmental Collection Templates.

Formula:

Freeboard (m) = Dam Crest Elevation - Current Tailings/Water Surface Elevation

Regulatory Requirements: - Minimum freeboard thresholds specified by mining regulations and dam safety standards (typically 0.5-1.5 metres minimum) - Reduced freeboard triggers mandatory operational responses (stop tailings deposition, increase water pumping) - Zero or negative freeboard indicates imminent overtopping risk (emergency condition)

Validation Rules: - Freeboard ≥ 0.0 m (negative values indicate critical safety issue, trigger warning) - Freeboard sudden drops (>0.5m month-over-month) trigger anomaly detection - Freeboard below regulatory threshold (e.g., <0.5m) generates compliance alert

Cross-Validation: Freeboard decreases when rate of rise (tailings deposition) exceeds water recovery rate.

---

Slurry Density

The mass concentration of solids in the tailings slurry pumped into a Tailings Storage Facility (TSF), expressed as a percentage of solids by mass or as specific gravity (g/cm³). Slurry density affects TSF stability, water balance, and storage capacity.

Platform Context: Tracked via TSF_SLURRY_DENSITY metric in G.8 TSF Management. Measured in g/cm³ (grams per cubic centimetre) or % solids by mass. Collected monthly. Dimension: TSF identifier. Evidence tier: RECOMMENDED (TSF_INSPECTION_REPORT with lab test results). See Environmental Validation Rules.

Typical Ranges: - Low density slurry: 1.1-1.3 g/cm³ (10-30% solids) - requires more water, lower storage efficiency - Medium density slurry: 1.3-1.5 g/cm³ (30-50% solids) - typical processing plant output - High density slurry: 1.5-1.8 g/cm³ (50-70% solids) - thickened tailings, improved water recovery

Measurement: Laboratory testing of slurry samples (density bottle method, nuclear density gauge, or online density meters).

Operational Significance: - Higher slurry density → less water to TSF → improved water recovery → reduced freeboard consumption - Lower slurry density → more water to TSF → higher pumping rates → faster freeboard reduction - Optimizing slurry density balances processing efficiency, water management, and TSF capacity

Validation Rules: - Slurry density range: 1.0-2.0 g/cm³ (values outside this range likely measurement errors) - Precision: 2 decimal places (e.g., 1.35 g/cm³)

---

Rate of Rise

The vertical increase in tailings surface elevation within a Tailings Storage Facility (TSF) over a specified time period, typically measured in metres per month (m/month) or metres per year (m/year). Rate of rise indicates how quickly the TSF is filling and affects embankment stability and operational lifespan.

Platform Context: Tracked via TSF_RATE_OF_RISE metric in G.8 TSF Management. Measured in m/month (metres per month). Collected monthly. Calculated as change in tailings surface elevation between consecutive months. Dimension: TSF identifier. Evidence tier: RECOMMENDED (TSF_INSPECTION_REPORT). See Environmental Report Outputs.

Formula:

Rate of Rise (m/month) = (Current Month Tailings Elevation - Previous Month Tailings Elevation) / 1 month

Typical Ranges: - Low rate: <0.5 m/month (small operation, seasonal production) - Medium rate: 0.5-2.0 m/month (typical active mining operation) - High rate: >2.0 m/month (large operation, high throughput, may indicate inadequate TSF capacity)

Regulatory Limits: - Many jurisdictions impose maximum rate of rise limits (e.g., 5-10 m/year) to ensure embankment stability - Excessive rate of rise can compromise embankment construction quality and consolidation time - Rate of rise >10 m/year triggers engineering review and potential operational restrictions

Validation Rules: - Rate of rise ≥ 0.0 m/month (negative rate indicates measurement error or incorrect data entry) - Rate of rise >5 m/month triggers anomaly detection (potential data error or operational issue) - Precision: 2 decimal places (e.g., 1.25 m/month)

Cross-Validation: Rate of rise should correlate with tailings generation (G.7 Mineralised Waste) and inverse correlate with freeboard (G.8).

Operational Planning: Rate of rise data informs TSF lifespan projections and raises embankment scheduling.

---

Recycle Stream

Water recovered from various sources within a mining operation and reused in the processing plant or other operations, reducing the demand for fresh water abstraction. Recycle streams are critical for water efficiency and environmental sustainability, particularly in water-scarce regions.

Platform Context: Tracked via water abstraction and recycling metrics in G.4 Water Consumption. Two recycle stream categories: TSF return water (largest recycle stream) and other recycle streams (dewatering, runoff collection, wash water recovery). Measured in m³ (cubic metres) monthly. Dimension: recycle stream source. See Environmental Metric Catalog.

Common Recycle Streams: 1. TSF Return Water: Water decanted from the Tailings Storage Facility and pumped back to the processing plant (typically 60-80% of total recycled water) 2. Dewatering Water: Groundwater pumped from underground workings or open pit sumps, treated if needed, and reused 3. Runoff Collection: Stormwater collected from operational areas and reused after treatment 4. Wash Water Recovery: Water from equipment washing, ore stockpile sprays, and dust suppression systems

Water Balance:

Water Consumed = Water Abstracted (Fresh Sources) + Water Recycled - Water Lost (evaporation, tailings moisture, product moisture)

Platform Reporting: - G.4.2 Water Recycled (monthly volumes by recycle stream source) - G.4.3 Water Consumed (net consumption after accounting for recycling) - Specific Water Consumption (m³ per tonne crushed ore)

Validation Rules: - Recycled water volume ≥ 0 m³ (cannot be negative) - Cross-validation: Total recycled water should generally be less than total water abstracted + previous period carryover - Anomaly detection: Sudden drops in recycle stream volumes may indicate pump failures or pipeline leaks

Environmental Benefit: High recycling rates (>70%) reduce pressure on freshwater resources and demonstrate responsible water stewardship (GRI 303 Water and Effluents).

---

Quality Band

A categorical classification of environmental monitoring data (water quality, air emissions) based on compliance with regulatory limits or internal standards. Quality bands provide a simplified visual indicator of environmental performance using color-coded levels (typically Green, Amber, Red).

Platform Context: Used in G.4.4 Water Quality Monitoring and G.5 Air Emissions Monitoring. Quality bands classify monitoring results by sampling point (water) or area (air) for each quarter. Stored as enum with values: Green, Amber, Red. Supports rapid identification of compliance issues and trends. See Environmental Validation Rules.

Quality Band Definitions:

Water Quality (G.4.4): - Green (Compliant): All monitored parameters within regulatory discharge limits or water quality standards - Amber (Minor Exceedance): 1-2 parameters exceed limits by ≤20%, no major compliance breach - Red (Major Exceedance): ≥3 parameters exceed limits OR any single parameter exceeds limit by >20%

Air Emissions (G.5): - Green (Compliant): All pollutant concentrations (PM10, SO₂, NO₂, CO) within local air quality standards - Amber (Minor Exceedance): 1-2 pollutants slightly exceed standards (typically <20% over limit) - Red (Major Exceedance): Multiple pollutants exceed standards OR significant exceedance requiring corrective action

Non-Compliance Parameters: When a quality band is Amber or Red, the platform captures which specific parameters are non-compliant (e.g., "pH, Cyanide" for water quality or "PM10, SO₂" for air emissions) for transparency and corrective action tracking.

Platform Reporting: - Quality band displayed as color-coded indicator in G.4.4 and G.5 tables - Non-compliance parameters listed explicitly - Trend analysis: consecutive Red quality bands trigger escalation to management

Validation Rules: - Quality band must be one of: Green, Amber, Red (enum validation) - If quality band = Amber or Red, non-compliance parameters field must not be empty - If quality band = Green, non-compliance parameters field must be empty or null

Regulatory Context: Quality band Red indicates potential regulatory non-compliance, requiring incident reporting (G.10 Environmental Incidents if regulatory notification threshold exceeded).

---

Specific Consumption (Per Tonne)

A normalized environmental intensity metric expressing resource consumption (energy, water, materials, waste) per unit of production output, typically per tonne of crushed ore. Specific consumption metrics enable efficiency analysis, benchmarking, and tracking of improvement trends independent of production volume fluctuations.

Platform Context: Calculated metrics derived from total consumption and production data. Used throughout G.2 Materials Consumption, G.3 Energy Usage, G.4 Water Consumption, and G.6 Non-Mineralised Waste. Measured as consumption units per tonne of crushed ore (e.g., kg/tonne, kWh/tonne, m³/tonne). See Environmental Report Outputs.

Formula (General):

Specific Consumption = Total Consumption (units) / Total Crushed Ore (tonnes)

Common Specific Consumption Metrics:

Metric	Units	Formula	Report Section
Materials Intensity	kg/tonne	Total Material Consumed (kg) / Crushed Ore (tonnes)	G.2
Specific Electricity Consumption	kWh/tonne	Total Electricity (kWh) / Crushed Ore (tonnes)	G.3
Specific Diesel Consumption	L/tonne	Total Diesel (L) / Crushed Ore (tonnes)	G.3
Specific Water Consumption	m³/tonne	Total Water Consumed (m³) / Crushed Ore (tonnes)	G.4
Specific Waste Generation	kg/tonne	Total Waste (kg) / Crushed Ore (tonnes)	G.6

Why Crushed Ore as Denominator: - Crushed ore (G.1 Production) is the earliest processing stage and represents total material throughput - Normalizes metrics for operations with varying production levels (seasonal, equipment downtime) - Enables year-over-year efficiency comparisons and benchmarking against industry standards

Validation Rules: - Specific consumption ≥ 0 (cannot be negative) - Precision: 3 decimal places (e.g., 2.456 kWh/tonne) - Cross-validation: Specific consumption = Total Consumption / Total Crushed Ore (formula check) - Zero-consistency: If crushed ore = 0, specific consumption cannot be calculated (set to null or 0)

Performance Tracking: - Decreasing specific consumption trends indicate improving efficiency (better resource utilization per tonne produced) - Increasing specific consumption trends may indicate equipment degradation, ore grade changes, or operational inefficiencies - Specific consumption targets set as part of environmental management plans (e.g., reduce specific electricity consumption by 5% year-over-year)

GRI Context: Specific consumption metrics support GRI intensity disclosures (e.g., GRI 302-3 Energy intensity, GRI 303-3 Water intensity).

---

Cross-References

• Related: Reporting Concepts - Boundaries, baselines, consolidation
• Related: GRI/ESG Scope v1 - Framework coverage
• Related: Data Lifecycle - State machine details
• Related: Tenancy and Roles - RBAC model
• Related: Security & Compliance - Regulatory requirements
• Related: Stakeholder Engagement API - Stakeholder engagement and grievance endpoints
• Related: Collection Templates - Engagement and grievance log templates
• Related: Report Outputs - GRI 2-29, GRI 2-30, and grievance mechanism reports

---

Change Log

Version	Date	Author	Changes
1.4	2026-01-19	Ralph Agent	Added Environmental Management Terms section with 6 definitions: TSF (Tailings Storage Facility), Freeboard, Slurry Density, Rate of Rise, Recycle Stream, Quality Band, Specific Consumption (Per Tonne). Each definition includes platform context, formulas, typical ranges, validation rules, regulatory requirements, operational significance, cross-validation logic, and cross-references to environmental documentation (metric catalog, collection templates, validation rules, report outputs). Definitions support G.1-G.10 environmental reporting sections and GRI 301-307 environmental disclosures.
1.3	2026-01-18	Ralph Agent	Added Occupational Health and Safety (OHS) Terms section with 17 definitions: Near Miss Incident, First Aid Incident, Restricted Work Incident, Medical Treatment Incident, Lost Time Injury (LTI), Fatality, High Potential Incident, Property Damage Incident, Silicosis/Pneumoconiosis, Other Clinic Visits, LTI Days, LTIFR (Lost Time Injury Frequency Rate), Hours Worked, PHI (Personal Health Information - OHS-specific), Workforce Type. Each definition includes platform context, evidence tiers, calculation formulas (LTIFR, LTI Days, Hours Worked), GRI mapping, privacy protection rules, and cross-references to OHS documentation (metric catalog, collection templates, validation rules, evidence management, security & compliance, report outputs).
1.2	2026-01-18	Ralph Agent	Added human capital terminology: Employment Level, Employment Type, Local Community Employee, Age Group. Defined PII protection rationale for age groups and local community status. Cross-referenced to metric catalog, GRI 405-1, and GRI 401.
1.1	2026-01-17	Ralph Agent	Added stakeholder engagement terminology: Stakeholder, Stakeholder Category, Stakeholder Group, Engagement Platform, Stakeholder Engagement, Engagement Outcome, Engagement Status, Grievance Mechanism, Grievance Intervention, Grievance Resolution Status, Collective Bargaining. Cross-referenced to stakeholder engagement API, collection templates, and report outputs.
1.0	2026-01-03	Senior Product Architect	Initial glossary covering all ESG platform terms