When BCA invited Grand Dunman to join the Whole-of-Government Virtual Inspection pilot, my first reaction was not excitement.
It was caution.
That may sound strange from someone who writes often about construction innovation. But supporting innovation in principle differs from introducing a new process just as a project approaches Temporary Occupation Permit, or TOP.
TOP is not the stage at which developers go looking for extra excitement. By then, years of planning, design and construction have converged into a few unforgiving weeks. Contractors are completing final works. Consultants are inspecting. Defects are being rectified. Clearances pursued. The handover team is preparing to receive the development.
Years of decisions. Thousands of interfaces. One fixed date.
Ask me then whether I'd volunteer for a new inspection process at TOP, and my honest answer would have been: try it on the next one.
But Grand Dunman became one of the pilot projects—and what I took away from it was not what I expected.
The camera was useful. But the camera was not the innovation. The real innovation was different government agencies and the project team working from a shared representation of the same development—and thinking about readiness together.
That distinction matters beyond virtual inspection. It goes to why construction projects struggle, why productivity problems keep surfacing on site, and what developers and government can do differently upstream.
What Whole-of-Government Virtual Inspection Actually Is
The term is still unfamiliar even inside the industry, so it's worth explaining plainly.
Whole-of-Government Virtual Inspection is BCA's pilot letting a project submit one set of 360-degree captures of completed works for several regulatory agencies to review at once, instead of a separate physical inspection for each agency's TOP or CSC requirements. Rather than BCA inspecting first, then SCDF, then PUB—each working off its own site visit and its own read of what's ready—the agencies review one shared digital record of the same physical condition.
That principle echoes CORENET X: BCA and URA's one-stop digital shopfront, meant to move consultants from dealing separately with agencies and different versions of plans toward coordinated design around a single common BIM model, with a collaboration platform spanning BCA, URA, SCDF, PUB and other public agencies.
Whole-of-Government Virtual Inspection can be read as a completion-stage analogue of the same principle. Design-stage coordination establishes what should be built. Reality capture establishes a governed representation of what was actually built—a connection that runs through the rest of this piece.
We Notice the Technology Because It Is Visible
When people hear "virtual inspection," they focus on the technology—360-degree cameras, photogrammetry, digital twins, AI-powered image processing—tangible enough to display the model, walk through captured spaces, and show an inspector reviewing a development remotely.
Technology photographs well. Integration does not.
Yet the most important words in the initiative were not "Virtual Inspection." They were "Whole-of-Government."
Had we merely digitised one BCA inspection, it would still have been useful—less movement, better documentation—but still one inspection, within one regulatory lane.
The real shift was different agencies referring to a common representation of the project, while the project team treated readiness as one integrated condition—not prepared sequentially, agency by agency, but brought to readiness together.
The camera made the project visible. Whole-of-Government made the project integrated.
This Was Not an Isolated Experiment
The broader rollout of virtual inspection in Singapore suggests the mechanism at Grand Dunman was not a one-off.
As of June 2026, BCA reported that more than 70 projects had completed virtual inspections, with productivity savings of up to 60%. The framework supports 360-degree capture for full or hybrid TOP and CSC inspections, subject to suitability and acceptance. Crucially, projects can submit completed phases for review while work continues elsewhere—comments on one phase get addressed, and the same feedback applied elsewhere, before the problem repeats.
That is the real mechanism. Not simply remote inspection, but earlier information leading to earlier action.
One Project Does Not Mean One Objective
Whole-of-Government does not mean every agency suddenly has the same job. Nor should it.
BCA safeguards structural requirements. SCDF protects fire safety. PUB protects drainage and water infrastructure. NEA protects environmental outcomes. Each has its own mandate, expertise and public responsibility, and none of that disappeared under virtual inspection.
The challenge was never to make every agency think alike. It was to bring their different, legitimate requirements together around the same project reality without weakening any of them. Integration is sometimes misread as compromise—it isn't. Good integration doesn't ask specialists or regulators to abandon their responsibilities; it creates the conditions in which their individually correct decisions work together.
The aim isn't one regulator. It's one trusted project reality supporting several independent regulatory judgements—considerably harder than organising another coordination meeting.
Projects Are Rarely Difficult Because Nobody Knows What They're Doing
Major developments contain considerable expertise: the architect protects design intent, the structural engineer protects safety, the contractor protects sequence and programme, the quantity surveyor protects commercial viability, the regulators protect the public interest.
Everyone is protecting something legitimate. Nobody in the room is necessarily wrong.
The difficulty begins when their individually reasonable positions no longer fit together. A design may be aesthetically correct but hard to construct or maintain. A technically safe solution may block access for another system. An efficient sequence for one trade may obstruct another. A valid requirement introduced late may become highly disruptive once finishes are complete.
The project doesn't struggle because one party lacks competence. It struggles because the interfaces between competent parties weren't resolved early enough—someone has to see the combined consequence for the whole development.
That's the developer's role. We don't design every detail, execute every trade, or carry the regulator's authority. But we shape the conditions everyone else performs under—when specialists are appointed, when information becomes available, when hard decisions get escalated, and whether everyone works from the same understanding.
This is usually called coordination. I think the more accurate word is integration: the developer's job isn't merely passing information between parties, it's making separate decisions work as one project—and making them work in time.
Construction Has an Information-Flow Problem
We often say construction has a productivity problem. That's true, but many productivity losses that eventually surface on site begin much earlier, as information-flow failures.
The pattern is consistent. First, information arrives late, in different formats and channels—one consultant working off the approved drawing, another off photographs, someone else recalling a site condition that's since changed. Everyone ends up discussing the same issue from a different version of reality.
Second, interfaces remain unresolved. A decision is required, but ownership is unclear; several parties must contribute, but nobody owns the combined outcome. The matter stays technically "in progress" while the window for an economical solution quietly closes.
Third, the site absorbs the consequence: work is resequenced, completed finishes reopened, teams working longer hours to recover time lost to earlier indecision. By the time it looks like poor site productivity, the root cause is often months old.
A downstream construction problem is frequently an upstream information problem arriving late. This is also why productivity can't be fixed by asking site teams to move faster: if the information is late, the interface unresolved, or the decision still in motion, faster execution may just produce rework more efficiently.
The Pilot Made the Work Harder Before It Made It Easier
Innovation is often presented as though its benefit appears the moment the technology arrives. Real projects are less polite—someone has to absorb the learning, preparation and coordination first, and at TOP, with the team stretched, that effort is felt directly.
Areas had to be genuinely ready before capture—not "almost ready," not "ready except for a few items," and certainly not ready only from one favourable angle. The camera is not diplomatic. It records what is actually there.
Comments then had to move through a real workflow: capture, comment, owner, required-by date, rectify, verify, close. A digital comment doesn't rectify itself simply because it was recorded efficiently—someone still has to own the issue, do the work, and verify the final condition.
The technology did not remove the work. It moved the work forward.
Earlier doesn't always mean easier, but it usually means more options stay open. A problem found before finishes close can be corrected at modest cost; the same problem found at final inspection may mean hacking, replacement, reinspection, delay and an argument about responsibility. The physical defect is identical—the timing of its discovery changes everything.
The Project Started Inspecting Itself
The most interesting benefit was one we hadn't anticipated: preparing for virtual inspection improved our own quality assurance.
Once everyone knew completed spaces would be captured clearly and kept in a shared digital record, behaviour changed. Consultants reviewed works more carefully. The contractor organised rectification earlier. Nobody wanted an unfinished item permanently visible in high resolution.
Before the authorities inspected the development, the project team had already inspected itself more critically. This didn't replace regulatory inspection—independent professional judgement remains essential—but it improved readiness before formal inspection occurred. Visibility changed preparation; earlier preparation changed the outcome.
There's a fair challenge here: was the improvement the technology, or everyone knowing Grand Dunman was a closely watched pilot? Probably both—a high-profile pilot draws more management attention, and we shouldn't confuse an attention effect with a technology effect. But the mechanism still matters. If persistent, location-linked evidence makes incomplete work harder to ignore and closure easier to trace, the operating system has improved, even if the camera can't claim all the credit.
The Most Valuable Outcomes May Be Invisible
The completed photographs of Grand Dunman don't show the meetings, rehearsals, comments and rectification that preceded TOP, or the problems caught early enough to avoid becoming final-stage crises. That is the nature of good integration—when it works, its value is often invisible.
An issue closed earlier. One fewer return inspection. One less completed surface reopened. One less last-minute argument about responsibility. There's no ribbon-cutting for a coordination problem that never happened. But when enough problems don't arrive in the final inspection window, the whole project feels the difference.
Construction productivity shouldn't be measured only by visible site activity. Avoided rework is productivity. Earlier closure is productivity. A defect prevented before installation, an interface resolved before finishes close, a decision made while alternatives remain—these are outcomes too. The absence of disruption is still an outcome.
The Evidence Must Not Become Another Silo
There's a real danger worth naming: the wrong implementation adds virtual inspection on top of consultant inspections, contractor QA systems, email, photographs, agency platforms and existing TOP documentation. Do the same work and upload another set of evidence into another platform, and virtual inspection becomes administration disguised as productivity. The right model progressively replaces duplicate evidence production; it doesn't add a channel.
This is the CORENET X problem again, pointed the other way: durable value depends on staying interoperable, not on trading many agency silos for one large vendor silo. Standards should define the evidence and portability required, not force every project into a proprietary solution.
The stakes rise once the record itself becomes an asset. Persistent 360-degree capture can pick up workers, private interiors, security arrangements and spatial geometry, and may stay accessible long after the inspection ends. Access control, retention, provenance and audit trail aren't IT footnotes at that point—they're part of regulatory trust. Every evidence object should carry, at minimum, where and when it was captured, who submitted it, which drawing revision it relates to, and who verified closure—without that discipline, a shared project reality becomes another uncertain version of one. If these records are later used for AI, the governance bar needs to be higher still.
AI Should Come Last, Not First
The long-term opportunity is real. Across enough well-structured project records, recurring defects become visible, repeated interface failures get identified, and a comment on one floor can be propagated to similar floors before the same defect repeats. That is where AI becomes useful.
But the order matters. First, build reliable project records. Then standardise inspection items, comments, causes and closure outcomes. Then set access, security, retention and audit rules. Only after that should cross-project AI be applied—otherwise it simply learns the different ways projects document confusion.
The ambition shouldn't be artificial intelligence sitting on top of unstructured archives. It should be shared industry memory, governed well enough that the next project doesn't relearn every lesson from the beginning.
The Next Pilot Should Start Before TOP
The developer integrates designers, specialists and contractors around one project; government integrates agencies and regulatory objectives across many. Different scale, same principle: better upstream conditions produce better downstream outcomes.
The practical lesson isn't to adopt more cameras. It's to introduce the information discipline earlier—reality capture supporting progress monitoring, consultant reviews and interface closure during construction, not surfacing for the first time once TOP has already become an emergency. Learning the platform while time exists spreads the capture and training cost across several applications, and catches regulatory risks before finishes and access constraints make them expensive to fix.
The trade-off is real: earlier capture demands manpower, platform cost, disciplined information management and more consultant attention upfront. Some benefit accrues to regulators; some cost falls on contractors and consultants. Developers likely capture the largest share of value, through reduced schedule risk. A proper business case weighs total system cost, not a saving for one participant that shifts work onto another.
The test should be simple: did the system reduce overall inspection effort, rework, return visits and TOP compression—or only produce better-looking evidence of the same unresolved process?
The Camera Was the Witness
The pilot did not eliminate standards, professional responsibility or physical work. It did something more fundamental: it made information more common, exposed interfaces earlier, let issues close while options still remained, and let different parties work from a more consistent representation of the project.
That is why the camera was not the breakthrough. The camera was the witness. Integration was the innovation. A trusted project record was the foundation—and the longer-term opportunity is turning many such records into shared industry intelligence, so the next development doesn't relearn the same lessons from the beginning.
Upstream information shapes upstream decisions. Upstream decisions shape downstream execution. If we want better productivity, fewer surprises and more confident completion, we have to stop treating every downstream problem as though it began on site. Very often it began earlier—in information that didn't flow, an interface left unresolved, or a decision that arrived after the economical options had disappeared.
The future of construction is not simply faster work. It is earlier readiness, a shared project reality, better-timed professional judgement—and integration designed before the project is forced to pay for its absence.
Originally published on Medium on 20 August 2026.