Skip to content

ESG Domain Glossary

Status: Final Version: 1.0 Last Updated: 2026-01-03

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.

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.

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.

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

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: Laravel SoftDeletes trait 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.

Cross-References

Change Log

Version Date Author Changes
1.0 2026-01-03 Senior Product Architect Initial glossary covering all ESG platform terms