Skip to content

Architecture and Responsibilities

Jump to bottom
mindsongreen edited this page Jan 27, 2026 · 1 revision

Databases

The system relies on four logically independent PostgreSQL databases, separated by data sensitivity and function:

  1. Activity Data – customer-hosted, contains internal activity data and calculation results (measures).
  2. Emission Factors – reference database, may be customer-hosted or centrally maintained.
  3. Conversion Factors – reference database for unit conversions.
  4. Parameters & Measures Definitions – shared database for parameters (e.g. inflation factors, allocation keys) and measure metadata.
    Customers may choose to host only the Activity Data database on their own infrastructure, while connecting to externally hosted reference databases for the other domains.
    Database administration (schema creation, SQL execution, inspection) is performed using pgAdmin / phpPgAdmin only. These tools are never used by the application at runtime.

Backend

The backend is implemented in PHP (Composer-enabled) using the PDO pgsql driver.
All database access is performed through prepared statements and repository abstractions, ensuring isolation between business logic and physical data storage.

Frontend

The frontend is a lightweight HTML / JavaScript application (React or Vue optional) that allows users to:

• Create and edit Calculation Tabs
• Enter and manage Activity Data, Emission Factors, and Parameters
• View line-level results, sub-totals, and calculation-tab totals
The frontend interacts exclusively with backend APIs and has no direct database access.\

Calculation Engine

The carbon calculator is a federated calculation system.

Sensitive data (Activity Data and calculation results) always remain customer-hosted.
Reference data (Emission Factors, Conversion Factors, Parameters) may be shared, centrally maintained, cached, or overridden locally.
The calculation engine operates solely on repository interfaces and must never depend on the physical location of the underlying databases.

• Unit & Formula Logic: all unit and pair-of-units algebra is handled centrally by the UnitEvaluator. Persistence, versioning, and data lifecycle management are handled by domain-specific repositories, not by the evaluator.
• Releases & Governance: the project is maintained as an open-source GitHub repository with:
• Tagged releases: automatically generated changelogs. Scheduled functional updates twice per year (e.g. June / December)

Clone this wiki locally