Engineering Strategy

System architecture, domain model, integration patterns, security framework, and technology stack for the DRC CEIP Platform.

1. System Architecture Overview

The DRC CEIP Platform follows a modular, layered architecture designed for long-term maintainability, multi-tenant scalability, and regulatory compliance. The system is organized around six core domain modules, each encapsulating a distinct bounded context within the CEIP program lifecycle. These modules can be composed, extended, and versioned independently while sharing a common integration backbone.

Core Platform Modules

1 Resource Designer

Defines the organizational fabric of the platform. Manages companies, teams, roles, hierarchies, and people with associated skill sets, schedule capacity, pricing models, and cost structures. Supports custom fields for domain-specific attributes and role-based access control (RBAC) to govern who can view, edit, and approve resources across the program.

Companies Teams Roles & Hierarchies People Skill Sets Schedule Capacity Pricing & Costs Custom Fields RBAC

2 Service Catalog Designer

Assembles reusable project templates by combining resources, materials, and work breakdown structures (WBS) into versioned service offerings. Templates can be parameterized by project scale (e.g., small, medium, or large residential retrofits), property type, and improvement category. Version control ensures that active projects reference a locked template snapshot while allowing iterative improvements for future engagements.

Project Templates Resource + Material Bundles WBS Integration Versioning Scale Parameterization

3 WBS Manager

Provides hierarchical work breakdown structure authoring with support for both vertical (parent-child) and horizontal (predecessor-successor) dependencies. Resources can be allocated at any level of the hierarchy, enabling coarse-grained program-level assignments and fine-grained task-level scheduling. Order-of-operations enforcement ensures that dependency constraints are respected during execution.

Hierarchical WBS Vertical Dependencies Horizontal Dependencies Resource Allocation Order-of-Operations

4 Materials Manager

Manages equipment, licenses, and inventory items with flexible pricing and costing models. Supports both box-level (bulk/kit) and individual-unit pricing for materials procurement. Tracks inventory levels, supplier information, and cost variance across projects to support accurate budgeting and financial reporting.

Equipment Licenses Inventory Box Pricing Individual Pricing Cost Tracking

5 Client Engagement Manager

Orchestrates multi-project program management with support for cross-project dependencies, interactive Gantt chart scheduling, and aggregated pricing/cost views. Roll-up dashboards provide real-time visibility into program health, budget utilization, and milestone progress with RBAC-governed access for each stakeholder tier.

Multi-Project Programs Cross-Project Dependencies Gantt Charts Pricing Aggregation Cost Aggregation Roll-up Dashboards RBAC

6 Analysis Management

Delivers custom dashboards and cross-project performance metrics for program administrators, municipalities, and investors. Includes a what-if scenario engine for modeling program outcomes under varying assumptions (e.g., adoption rates, energy price trajectories, interest rate changes). Supports ad-hoc reporting and scheduled report generation.

Custom Dashboards Cross-Project Metrics What-If Scenarios Ad-hoc Reporting Scheduled Reports

Layered Architecture Diagram

The following diagram illustrates the five-layer architecture of the DRC CEIP Platform. Each layer encapsulates a distinct set of concerns, communicating through well-defined interfaces.

Presentation Layer
Public Portal
Property Owner Portal
Contractor Portal
Admin Portal
Municipality Portal
Investor Portal
▼ ▼ ▼
Application Layer
Application Engine
Agreement Builder
Monitoring Engine
Reporting Engine
Notification Service
▼ ▼ ▼
Domain Layer
Resource Designer
Service Catalog
WBS Manager
Materials Manager
Client Engagement Manager
Analysis Engine
▼ ▼ ▼
Integration Layer
SPIN2 Adapter
ASHRAE Audit Service
Municipal API Gateway
Capital Markets API
APEGA/AAA Verification
Payment Gateway
▼ ▼ ▼
Infrastructure Layer
Database
File Storage
Cache
Message Queue
Search Index
Audit Log

2. Domain Model / Entity Relationship

The DRC CEIP Platform domain model captures the core entities and their relationships across the program lifecycle. The following entity-relationship diagram presents each entity with its key attributes, primary keys (PK), and foreign keys (FK).

Properties
id PK UUID
address TEXT
municipality_id FK UUID
property_type ENUM(residential, commercial, farm, industrial)
assessment_value DECIMAL
tax_status VARCHAR
spin2_reference VARCHAR
footprint_sqm DECIMAL
storeys INTEGER
owner_ids[] UUID[]
PropertyOwners
id PK UUID
name TEXT
type ENUM(individual, corporation, REIT)
contact_info JSONB
legal_rep TEXT
insurance_status VARCHAR
tax_standing VARCHAR
dower_status VARCHAR
QualifiedContractors
id PK UUID
company_name TEXT
license_type ENUM(APEGA, AAA)
license_number VARCHAR
insurance_liability DECIMAL ($5M)
insurance_eo DECIMAL ($2M)
wcb_status VARCHAR
training_complete BOOLEAN
performance_otif DECIMAL
performance_eia DECIMAL
performance_satisfaction DECIMAL
status VARCHAR
EligibleImprovements
id PK UUID
category ENUM(envelope, mechanical, energy_mgmt, renewable, lighting, equipment)
name TEXT
description TEXT
lifespan_years INTEGER
estimated_energy_savings DECIMAL
estimated_co2_reduction DECIMAL
applicable_property_types[] TEXT[]
Applications
id PK UUID
property_id FK UUID
owner_id FK UUID
contractor_id FK UUID
status ENUM(draft, submitted, reviewing, approved, rejected)
application_fee DECIMAL
property_type VARCHAR
audit_id FK UUID
improvements[] JSONB
submitted_at TIMESTAMPTZ
approved_at TIMESTAMPTZ
CEIPAgreements
id PK UUID
application_id FK UUID
municipality_id FK UUID
total_capital_cost DECIMAL
admin_fee DECIMAL
incidental_costs DECIMAL
professional_services DECIMAL
probable_lifetime INTEGER (years)
annual_payment DECIMAL
signatures[] JSONB
spin2_registered BOOLEAN
cure_period_end DATE
status VARCHAR
Projects
id PK UUID
agreement_id FK UUID
contractor_id FK UUID
scope JSONB
milestones[] JSONB
deposit_amount DECIMAL
completion_status VARCHAR
completion_date DATE
monitoring_plan_id FK UUID
EnergyAudits
id PK UUID
property_id FK UUID
type ENUM(level2, level3)
auditor_credentials TEXT
audit_date DATE
ecm_list[] JSONB
kwh_savings DECIMAL
gj_savings DECIMAL
tco2e_reductions DECIMAL
cost_accuracy VARCHAR
report_url TEXT
MonitoringData
id PK UUID
project_id FK UUID
period DATERANGE
kwh_actual DECIMAL
gj_actual DECIMAL
tco2e_actual DECIMAL
water_savings DECIMAL
financial_savings DECIMAL
roi DECIMAL
Escalations
id PK UUID
type VARCHAR
complainant_id FK UUID
respondent_id FK UUID
tier INTEGER (1-4)
status VARCHAR
created_at TIMESTAMPTZ
resolved_at TIMESTAMPTZ
Reports
id PK UUID
type ENUM(annual, municipal, custom)
period DATERANGE
municipality_id FK UUID
published_at TIMESTAMPTZ
data JSONB

Entity Relationships

Properties M:N PropertyOwners — A property may have multiple owners; an owner may hold multiple properties
Properties 1:N Applications — A property may have multiple applications over time
PropertyOwners 1:N Applications — An owner submits applications on behalf of their properties
QualifiedContractors 1:N Applications — A contractor is associated with each application
Applications 1:1 CEIPAgreements — An approved application yields exactly one CEIP agreement
CEIPAgreements 1:N Projects — An agreement may encompass multiple installation projects
Projects 1:N MonitoringData — Each project generates periodic monitoring records
Properties 1:N EnergyAudits — A property may undergo multiple audits (pre-project Level 3, post-project Level 2)
Applications 1:1 EnergyAudits — Each application references a qualifying energy audit
Applications M:N EligibleImprovements — An application selects from the catalog of eligible improvements
Escalations N:1 Applications / Projects — Escalations are filed against applications or projects
Reports N:1 Municipalities — Reports are generated per municipality for annual compliance

3. Integration Architecture

The DRC CEIP Platform integrates with multiple external systems to fulfill its regulatory, financial, and operational mandates. Each integration is designed with resilience, security, and auditability as primary concerns.

1 Alberta SPIN2 Database

The SPIN2 (Spatial Information System) database is the authoritative Alberta land titles registry. The DRC platform registers CEIP agreements, monitoring plans, completion records, and tax documents against property titles. This integration is critical for legal enforceability of the CEIP tax assessment and for property sale disclosure obligations.

Purpose
Register CEIP agreements and completion records against property titles
Protocol
API or secure file transfer (SFTP with PGP encryption)
Data Flow
Bidirectional: title queries inbound, registration records outbound
Security
Mutual TLS, signed payloads, full audit trail on every registration event

2 ASHRAE Audit Systems

Energy audits conforming to ASHRAE standards are the foundation of eligible improvement identification. The platform intakes Level 3 (pre-project, detailed feasibility) and Level 2 (post-project, verification) audit reports. Document uploads are paired with structured data extraction to validate energy conservation measure (ECM) metrics including kWh savings, GJ reductions, tCO2e impact, and cost estimate accuracy.

Purpose
Intake and validate Level 2 and Level 3 energy audit reports
Protocol
Document upload (PDF/XML) with structured data extraction API
Data Flow
Inbound: audit documents and ECM metric data
Security
Document integrity verification (hash), auditor credential validation

3 Municipal Systems

Each participating municipality operates its own property tax assessment and CEIP bylaw infrastructure. The platform maintains per-municipality API adapters to interface with bylaw databases, property tax assessment systems, tax office thresholds, and interest rate configurations. Annual compliance reports are delivered through these integrations.

Purpose
Synchronize bylaw data, property tax assessments, thresholds, and interest rates
Protocol
Per-municipality REST API adapters, SFTP for batch data exchange
Data Flow
Bidirectional: tax data inbound, annual reports and payment schedules outbound
Security
OAuth 2.0 per municipality, IP allowlisting, encrypted data at rest and in transit

4 Capital Markets / Bond Issuance

DRC aggregates approved CEIP projects into bond pools for capital markets financing. This integration supports lender terms negotiation, repayment tracking, and portfolio performance reporting. Secure financial data exchange is paramount, with investment-grade reporting standards for institutional and impact investors.

Purpose
Project aggregation for bond pools, repayment tracking, portfolio reporting
Protocol
Secure financial data exchange (SFTP/API), encrypted reporting pipelines
Data Flow
Outbound: aggregated project data, performance metrics; Inbound: capital terms
Security
End-to-end encryption, SOC 2 compliant data handling, financial audit trails

5 APEGA / AAA Verification

All qualified contractors must hold valid professional licenses issued by APEGA (Association of Professional Engineers and Geoscientists of Alberta) or AAA (Alberta Association of Architects). The platform verifies licensing status both at contractor onboarding and through periodic batch verification to ensure ongoing compliance.

Purpose
Verify contractor professional licensing status
Protocol
Real-time lookup API with periodic batch verification fallback
Data Flow
Outbound: license number queries; Inbound: verification status responses
Security
API key authentication, rate limiting, response signature validation

6 WCB (Workers' Compensation Board)

Workers' Compensation Board coverage is a prerequisite for contractor qualification. The platform verifies that each contractor maintains active WCB coverage, protecting property owners and the program from liability exposure during installation work.

Purpose
Verify contractor WCB coverage status
Protocol
WCB clearance letter API or manual document upload with OCR extraction
Data Flow
Outbound: coverage queries; Inbound: clearance status and expiry dates
Security
Encrypted transport, minimal data retention (status + expiry only)

7 Payment Gateway

The platform processes application fees, deposit payments, and balance payments through a PCI DSS compliant payment gateway. Financial transactions are idempotent, fully audited, and reconciled against the CEIP agreement ledger.

Purpose
Process application fees, deposit payments, and balance payments
Protocol
PCI DSS Level 1 compliant REST API with tokenized card data
Data Flow
Outbound: payment requests; Inbound: confirmation, receipts, refund status
Security
PCI DSS compliance, tokenization (no card data stored), idempotency keys, 3D Secure

4. Technology Stack Recommendations

The following technology selections are optimized for the DRC CEIP Platform's requirements: multi-tenant SaaS delivery, regulatory compliance, Canadian data residency, and a small-to-medium engineering team that values type safety and developer productivity.

Layer Technology Rationale
Frontend Vanilla JavaScript (ES2022+) Zero framework dependency eliminates supply-chain attack surface and reduces build complexity. Web Components for reusable UI elements across six portal variants. Native ES modules for code organization. No transpilation step required — reduces CI/CD surface and ensures long-term maintainability without framework version churn. SSR handled at the server layer if needed.
Backend Node.js / TypeScript or Python / FastAPI Type safety reduces runtime errors in financial calculations; async processing handles concurrent API calls to external integrations; shared TypeScript types between frontend and backend reduce contract drift.
Database PostgreSQL ACID compliance for financial transaction integrity; native JSON/JSONB support for flexible document storage (audit reports, improvement catalogs); PostGIS extension for geospatial queries against SPIN2 property data.
Cache Redis Session management for multi-portal authentication; real-time dashboard data caching; rate limiting counters for API endpoints; pub/sub for live notification delivery.
Search Elasticsearch Full-text search across properties, contractors, and eligible improvements; faceted filtering by property type, municipality, improvement category; fuzzy matching for address normalization.
Queue RabbitMQ / Amazon SQS Asynchronous processing for notification delivery, report generation, SPIN2 registration batches, and audit data extraction; dead-letter queues for failed integration retries.
Storage S3-Compatible Object Storage Document storage for energy audit reports, signed CEIP agreements, completion evidence photos, and generated compliance reports; lifecycle policies for retention management.
Auth OAuth 2.0 + RBAC Multi-tenant authentication supporting six stakeholder types; role-based access control with granular permissions; multi-factor authentication (MFA) for sensitive portals.
Monitoring Prometheus + Grafana System health monitoring with custom CEIP metrics (applications per day, approval rates, integration uptime); alerting for SLA violations and security anomalies.
CI/CD GitHub Actions Automated testing pipelines (unit, integration, E2E); deployment automation with environment promotion (dev, staging, production); infrastructure-as-code validation.
Hosting AWS Canada (ca-central-1) Data residency compliance with Canadian sovereignty requirements; Government of Canada cloud-approved region; low-latency access for Alberta-based stakeholders; disaster recovery to ca-west-1.

5. Security, Compliance & Data Residency

The DRC CEIP Platform handles sensitive personal, financial, and property data subject to Alberta's Freedom of Information and Protection of Privacy (FOIP) Act and ministerial designation conditions. The following security framework ensures end-to-end protection of stakeholder data.

📜

FOIP Act Compliance

Consent management at point of data collection, data minimization principles applied to every entity, right-to-access request workflow with 30-day response SLA, and documented data retention schedules.

🇨

Data Residency

All data stored in Canadian data centers with Alberta preferred. No data replication to non-Canadian regions. Cloud provider contractual guarantees for data sovereignty. Regular residency audits.

🔐

Encryption

AES-256 encryption at rest for all databases and object storage. TLS 1.3 enforced for all data in transit. Key management via AWS KMS with customer-managed keys (CMK). No plaintext secrets in code or configuration.

🔑

Authentication

Multi-factor authentication (MFA) required for admin, municipality, and investor portal access. Phishing-resistant authenticators (FIDO2/WebAuthn) supported. Session timeout policies enforced per role.

👥

Authorization (RBAC)

Role-based access control with principle of least privilege. Permissions scoped to organization, municipality, and property level. Privilege escalation requires multi-party approval.

📑

Audit Logging

Every data access and modification logged with who, what, when, and from where. Immutable audit log storage with tamper detection. Retention aligned with FOIP and ministerial requirements.

🛡

Penetration Testing

Annual third-party penetration assessment by qualified security firm. Quarterly automated vulnerability scanning. Remediation SLA: critical (24h), high (72h), medium (30d).

💾

Backup & Recovery

Daily automated backups with 90-day retention. Cross-region replication within Canada (ca-central-1 to ca-west-1). Recovery time objective (RTO): 4 hours. Recovery point objective (RPO): 1 hour.

🚨

Incident Response

Documented incident response procedure with defined severity levels. 24-hour notification to affected parties for data breaches. Post-incident review and remediation within 7 business days.

📄

Cybersecurity Policy

Comprehensive cybersecurity policy required by ministerial designation conditions. Annual policy review and update cycle. Staff security awareness training mandatory for all personnel with platform access.

6. API Design Principles

The DRC CEIP Platform exposes a comprehensive REST API for all platform operations. The following design principles ensure consistency, security, and developer experience across all endpoints.

📋

RESTful with OpenAPI 3.0

All endpoints follow REST conventions with a machine-readable OpenAPI 3.0 specification. Auto-generated documentation, client SDKs, and contract testing from a single source of truth.

📂

Versioned Endpoints

API versioning via URL path (v1, v2) with backward compatibility guarantees. Deprecation notices issued 90 days before version sunset. Clients specify version explicitly.

🔒

JWT Authentication

JSON Web Token-based authentication with short-lived access tokens and long-lived refresh tokens. Token rotation on each refresh. Revocation via server-side token blacklist.

⚡

Rate Limiting

Per-client and per-role rate limits enforced at the API gateway. Graduated throttling with clear HTTP 429 responses including retry-after headers. Higher limits for municipality and admin roles.

📚

Pagination, Filtering & Sorting

Cursor-based pagination on all list endpoints. Consistent query parameter syntax for filtering (filter[field]=value) and sorting (sort=field,-field). Total count in response metadata.

🔔

Webhook Support

Event-driven notifications for application status changes, project completions, and escalation updates. Configurable webhook URLs per organization with HMAC signature verification.

💰

Idempotency Keys

All financial operations (payments, deposits, refunds) require idempotency keys to prevent duplicate processing. Keys are unique per client and expire after 24 hours.

🔗

HATEOAS Links

Hypermedia as the Engine of Application State: responses include navigable links for valid state transitions. Workflow progression (draft → submitted → approved) encoded in link relations.

Example: Application Lifecycle Endpoints
POST  /api/v1/applications — Create draft application
GET   /api/v1/applications/{id} — Retrieve application with HATEOAS links
PATCH /api/v1/applications/{id} — Update draft application
POST  /api/v1/applications/{id}/submit — Submit for review
POST  /api/v1/applications/{id}/approve — Approve (admin only)
POST  /api/v1/applications/{id}/reject — Reject with reason (admin only)
GET   /api/v1/applications?filter[status]=submitted&sort=-submitted_at&page[cursor]=abc