Application Overview

Data Centre Infrastructure Assurance (DCCIA) is a reference/demo prototype for operational assurance of mission-critical data-centre infrastructure. It answers three questions a critical-facilities team lives with:

  1. Are our critical controls actually effective right now?
  2. Where are the open exceptions, and how bad are they?
  3. Will this planned change break redundancy or collide with an open exception?

The core operating chains

The 16 models form five modules that connect into a single assurance record.

1. Estate & dependencies

Site ─▶ Location ─▶ Asset ─▶ AssetDependency
  • Site — a campus (e.g. Northgate Data Campus).
  • Location — the spatial hierarchy inside a site: campus → building → data hall / electrical room / mechanical room / network room. Locations self-nest via parent_location.
  • Asset — every piece of infrastructure: utility feed, transformer, switchgear, UPS, battery string, generator, chiller, pump, CRAH, fire detection/suppression, access control, network distribution. Assets carry an operational_status and an assurance_status, a redundancy_group_code (e.g. POWER-A / POWER-B) and a redundancy_role, and self-nest via parent_asset.
  • AssetDependency — the directed graph between assets: FEEDS, SUPPLIED_BY, BACKED_BY, STANDBY_FOR, COOLED_BY, REDUNDANT_WITH, etc. This is what makes "removing GEN-02 compromises Data Hall 02" knowable.

2. Critical controls

CriticalEvent ─▶ CriticalControl ─▶ ControlAsset ─▶ Asset
  • CriticalEvent — an unwanted event we protect against (loss of power, loss of cooling, fire in a hall) with severity and likelihood.
  • CriticalControl — a preventive, mitigating or recovery control with an objective, a performance standard and a current_status (effective / degraded / failed / unverified / suspended).
  • ControlAsset — which assets deliver a control, and in what role (primary, secondary, backup, monitoring, supporting).

3. Verification

CriticalControl ─▶ VerificationRequirement ─▶ VerificationActivity
  • VerificationRequirement — how a control is proven: type (test / measurement / inspection / functional test / audit), frequency and acceptance criteria.
  • VerificationActivity — a performed verification with its result (pass / pass-with-observation / degraded / fail / unable-to-verify), measured value and whether it raised an exception.

4. Assurance & exceptions

VerificationActivity / CriticalControl / Asset ─▶ AssuranceException ─▶ CorrectiveAction
                                                              └─▶ Evidence / Approval
  • AssuranceException — a control that is degraded, failed, unverified, deferred or defective, with severity, status, an interim control and whether risk acceptance is required.
  • CorrectiveAction — the action that closes an exception (or a verification, incident, audit or change) with owner, priority and verification-required flag.
  • Evidence — measurements, test results, photos, certificates and documents supporting any record (polymorphic source_type + source_id).
  • Approval — decisions on changes and risk acceptances (polymorphic source).

5. Change & conflicts

ChangeRequest ─▶ ChangeAsset ─▶ Asset
      └─▶ OperationalConflict ◀─ AssuranceException (by code) / CriticalControl / Asset
  • ChangeRequest — planned/corrective/emergency work with a status lifecycle, risk level and a redundancy_impact.
  • ChangeAsset — the assets a change affects, and the effect (unavailable, degraded, isolated, bypassed, configuration change, monitoring only).
  • OperationalConflict — a recorded clash: a change that would compromise redundancy, run concurrently with another outage, or intersect an open control exception. Carries severity, a blocking flag and a status.

Design boundary (what this prototype is and is not)

This is a records-and-assurance system, not the source of truth for the systems it references. BMS/EPMS, DCIM, the CMMS/EAM and permit-to-work systems stay authoritative; DCCIA holds the assurance record and references them.

Crucially, Phase 1 does not compute the conflicts — the orchestration rules that would automatically detect a redundancy compromise, block a change approval, or require an engineering risk acceptance are Phase 2 rule-engine work. In this build the flagship scenario (DC-SCENARIO-001) is seeded as finished state so the assurance dashboard tells the story; the app runs in demo read-only mode.