Building Commissioning Software: Why Nobody Can Say Which Equipment Actually Passed Its Test

Why commissioning status is an argument instead of a number

Six weeks before substantial completion on a 300,000 square foot building. The owner asks a simple question: how much of the mechanical system has actually passed functional testing. The commissioning agent says roughly 70 percent. The mechanical contractor says everything they were asked to demonstrate has passed. The controls contractor says half the tests could not be run because the sequences were not loaded. Nobody is lying. There are four technicians who have been filling in test forms across 900 pieces of equipment for two months, and the only aggregate view is a spreadsheet somebody updates on Fridays.

The tooling is usually CxAlloy or Facility Grid, which are both purpose built and genuinely useful, or for many providers it is PDFs on iPads plus Excel plus email. Commissioning firms tend to have strong intellectual property in their test scripts, built over years, tuned per equipment type and per specification, and that library lives in Word documents. The product tools hold an issue log competently. What they hold poorly is a provider's own script library as versioned, reusable content, and the sampling strategy that decides how many of 84 identical fan coil units you actually test.

The consequence is not just reporting friction. Commissioning is required for many certification programmes and is standard practice on healthcare and laboratory work, and the deliverable at the end is a documented assertion that systems perform as designed. When the record behind that assertion is a folder of scanned forms, the assertion is weak, the owner inherits systems that were accepted on trust, and two years later the energy performance nobody verified shows up in the utility bill.

Problem 1: the equipment register is the project and it arrives late

You cannot commission what you have not listed. The register comes from the mechanical schedules, the controls points list, the submittals and eventually from what was actually installed, which differs. Providers typically build it in Excel from drawings, then spend the project reconciling against reality: equipment substituted through a submittal, three units removed in a value engineering exercise, tag numbers that changed between design and shop drawings.

What a custom build does: treat the register as a living reconciliation between design intent, submitted equipment and installed equipment, with the source of each entry recorded. Every piece of equipment carries its system, its area, its responsible contractor and its required test set. When the register changes, the impact on completion percentages is immediate rather than a manual recount. This sounds like housekeeping and it is the single largest source of disputed percentages on a commissioning project, because two parties counting different denominators will never agree on a completion number.

Problem 2: your test scripts are the firm's asset and they live in Word

A good commissioning firm's value is concentrated in its script library: what to test on a variable air volume box, in what order, with what pass criteria, what to do about the sequence of operations for a chilled water plant with two chillers and a bypass. That library took a decade to build and it is currently a folder of documents that get copied into each project and edited, which means improvements made on project A never reach project B.

What a custom build does: scripts become structured, versioned content: steps with expected values, tolerances, required evidence, and a link to the specification clause or sequence of operations they verify. A project instantiates scripts from the library at a pinned version, so improvements flow to future projects while a project in progress stays stable. When a technician finds a step that is wrong or a criterion that is unclear, that feedback goes back to the library owner as a proposed revision. Within a couple of years this becomes the reason senior people join your firm, because working with a good library is a better job than editing Word documents on a laptop in a mechanical room.

Problem 3: sampling is a judgement nobody records

You are not testing all 84 fan coil units. You test a sample, and if failures exceed a threshold you expand the sample. That approach is standard, defensible and specified in many commissioning plans. What almost never happens is recording the sampling logic in a way the owner can inspect: which units were in the initial sample, how they were chosen, what failure rate triggered expansion, and what the final coverage was.

What a custom build does: make sampling an explicit rule per equipment type, with the initial sample selected by the system, the failure threshold declared up front, and expansion triggered automatically when it is breached. The report then states coverage as a fact rather than an assurance. Owners who have been through a bad handover care about this more than any other feature, because the alternative is a certificate asserting that systems perform, backed by testing whose extent nobody documented.

Problem 4: the issue log is where the contractor relationship goes wrong

An issue raised as a bare line item, with a photograph and a terse description, lands on a contractor who has 200 other things to do and no context. They dispute it, or they fix something adjacent, or they mark it complete without a retest. Then the commissioning agent verifies, finds it unresolved, and reopens it. Four cycles later the relationship is adversarial and the schedule has absorbed six weeks.

What a custom build does: classify issues properly at creation. Is this a deficiency against the contract documents, a design issue that needs the engineer, an incomplete installation that is simply not ready, or an operational adjustment. Those four categories have different owners and different resolution paths, and lumping them into one list is what generates the disputes. Attach the failing test step and its criterion so the contractor sees exactly what was expected. Require a retest for anything closed, with the retest linked to the original. And keep the responsibility assignment aligned to the contract structure, so an issue that belongs to the controls subcontractor does not sit unread in the general contractor's queue.

Problem 5: trend data proves performance and nobody reviews it

A functional test demonstrates that a system responds correctly under observed conditions on one afternoon. Real performance shows up in trend logs from the building automation system over weeks: a chilled water plant short cycling, an economiser that never opens, simultaneous heating and cooling on a floor. Enhanced commissioning scopes usually include trend review, and it is frequently the part that gets compressed when the schedule tightens, because reviewing a month of point data manually is genuinely difficult.

What a custom build does: ingest trends from the building automation system and run analysis rules against them, flagging conditions that indicate a fault rather than presenting graphs for a human to scan. This is well trodden analytical ground and does not require anything exotic. What custom software adds is linking a flagged condition directly to the equipment record and the issue log, so a trend finding becomes a tracked issue with the same lifecycle as a failed test step. Providers who offer this credibly win work, because owners understand the difference between a system that passed a test and a system that is behaving correctly in operation.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the equipment register with reconciliation, prefunctional checklists and functional scripts executed offline on a tablet, issue tracking with classification and contractor response, and completion reporting by system and area runs $55,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding the versioned script library with revision workflow, sampling rules, trend ingestion and analysis, certification documentation packs, an owner portal and handover output into a maintenance system runs $150,000 to $380,000 phased over 6 to 12 months.

What pushes the number up: trend ingestion, because building automation systems expose data through several different protocols and integrations and each site is its own small project. Migration of an existing script library, which is content work and is usually underestimated by everyone including us. Owner portals with per project branding. And handover integration into a computerised maintenance management system, which is valuable and requires agreeing an asset data standard with the owner's facilities team.

What keeps it down: starting with mechanical and controls, which carry most of the scope, and adding electrical, life safety and specialty systems in the second phase. Also, offline first on tablets from day one rather than retrofitted, because mechanical rooms and shafts have no signal and a technician who cannot record a result on the spot will write it on paper.

Build versus buy, and when CxAlloy is the right answer

Buy if you are a small commissioning practice running a handful of projects at a time with one or two agents. CxAlloy and Facility Grid are purpose built, reasonably priced against a build, and will give you a competent issue log and checklist workflow immediately. Buy also if you are an owner commissioning one building, because your provider will bring their own tooling and imposing yours creates friction for no benefit.

Build when two or more of these are true. First, your script library is genuinely differentiated and you want it to be an asset rather than a folder. Second, you run enough concurrent projects that quality depends on which agent is assigned. Third, you commission healthcare, laboratory or data centre facilities where documentation requirements are heavier and sampling has to be defensible. Fourth, you are an owner with a portfolio and want commissioning data to flow into your maintenance system rather than arriving as PDFs. Fifth, you want to offer ongoing or monitoring based commissioning as a service, which requires trend infrastructure that a checklist tool does not provide.

The strategic argument for a provider is straightforward. Your competitors have similar engineers and similar rates. The firm whose scripts improve every project, whose sampling is defensible, and whose owner deliverable is structured data rather than a binder, is selling something different. That difference lives in software.

How to choose a developer for commissioning software

Ask them how a test script differs from a checklist. If they treat both as forms, you will get a form builder, and the script library you wanted to turn into an asset will still be a folder of documents with a nicer front end.

Ask how sampling expansion works. The right answer involves a declared initial sample, a failure threshold set before testing starts, automatic expansion when it is breached, and coverage stated in the report as a fact. Anything vaguer means the defensibility problem you have today follows you into the new system.

Ask what they have done with building automation data. Trend ingestion involves specific protocols and site by site integration work, and the honest answer names the system and how the data was obtained. Anyone who describes it as a simple connection has not done it on a live building.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. If your script library is the firm's core intellectual property, encoding it into a system controlled by someone else is the opposite of what you set out to achieve.