Deployment Concern

Readiness Blockers

A practical checklist for deciding whether an HVAC optimization deployment is ready to proceed, needs intake cleanup, or requires a scope decision before field work.

A blocker is not a rejection. It is a condition that makes model training, BMS integration, acceptance, or savings evidence unreliable until the project team resolves it or narrows the scope.

Triage

Separate blockers from intake gaps

The review should produce one of three decisions for each issue so the project does not stall on ambiguous risk language.

Hard blocker

Deployment should not move forward until this is resolved because the missing item affects safety, access, control authority, or contractual evidence.

Fix during intake

The issue is real, but it can be repaired with data cleanup, point mapping, additional exports, or a short site clarification before activation.

Scope decision required

The project can continue only if the customer, ClimaMind, and SI agree to exclude a system, limit the control mode, or adjust the acceptance method.

Common blockers

What usually delays deployment

These categories cover the issues most likely to affect baseline modeling, integration work, supervised control, and M&V review.

Fix during intake

Trend history and data quality

Model readiness depends on usable history for the systems inside scope, not simply a long list of exported points.

  • Missing or sparse trend history for key plant sensors, setpoints, commands, equipment status, or energy meters.
  • Timestamps that cannot be aligned across BMS trends, meter data, weather, schedules, and operating events.
  • Values that are stuck, clipped, unit-inconsistent, renamed without mapping, or affected by undocumented manual operation.

Scope decision required

Meter and measurement boundary

Savings evidence needs a defensible boundary before acceptance, especially when payment, financing, or third-party review depends on the result.

  • The meter does not isolate the optimized equipment or mixes unrelated loads that cannot be explained.
  • The baseline period includes major occupancy, weather, retrofit, schedule, or equipment changes without an agreed adjustment method.
  • The project has not decided whether savings will use customer-led review, ClimaMind-led reporting, or a third-party M&V partner.

Hard blocker

BMS point access and permissions

Read and write paths must match the approved operating mode before field activation.

  • Required live points, trend points, alarms, schedules, or equipment states are not accessible through the approved BMS interface.
  • Writable points, priority behavior, override semantics, or supervisory limits are not confirmed with the SI or BMS contractor.
  • Point names and equipment mapping are not trustworthy enough for commissioning or operator review.

Hard blocker

Network and security approval

Connectivity must be approved before an edge device, remote support path, or data transfer process becomes part of site operation.

  • Network path, firewall rules, edge placement, remote support policy, or account ownership is unresolved.
  • The customer has not approved what data leaves the site, where it is stored, and who can access it.
  • Security review is still depending on informal file exchange instead of the approved Trust & Security process.

Scope decision required

Fallback and operator authority

The site needs an agreed manual authority path before supervised writes or advisory recommendations are treated as operational.

  • The team has not defined what happens during connection loss, stale telemetry, BMS rejection, local alarms, or operator override.
  • Operators do not know where to see current operating mode, how to pause optimization, or who receives escalation notices.
  • Native BMS fallback behavior conflicts with the intended ClimaMind control boundary.

Hard blocker

M&V method and acceptance evidence

When savings claims are part of acceptance, the evidence path must be agreed before go-live.

  • There is no approved baseline method, adjustment method, exclusion rule, or review cadence.
  • Acceptance criteria are limited to savings targets without comfort, uptime, override, and issue-log evidence.
  • The commercial agreement depends on contractual savings but the measurement boundary and reviewer role are still undecided.

Unblocking packet

What we need to unblock deployment

The smallest useful packet is enough to move forward; it should answer the blocker directly instead of restarting discovery.

  • A point list and trend export that identify required sensors, setpoints, commands, equipment status, alarms, and meters.
  • A BMS access note from the SI or BMS contractor covering read access, write path, priority behavior, and override handling.
  • A network and security approval path for the edge device, data transfer, remote support, and user/account ownership.
  • An M&V and acceptance note covering measurement boundary, baseline method, adjustment method, exclusions, reviewer role, and sign-off criteria.

Decision record

Keep a readiness decision log

A short log prevents the same issue from being rediscovered in model training, commissioning, and acceptance.

  • Record each issue as hard blocker, fix during intake, or scope decision required.
  • Name the owner, evidence path, due date, and deployment stage affected by the issue.
  • When the issue is accepted as a scope limit, record what is excluded from control, savings evidence, or acceptance.
Back to deployment overview