For years, data center delivery teams have been told their schedule is healthy. The logic checks pass, the float report is clean, the dashboard is green. The dates slip anyway.
The slips are expensive. Every day energization slips, RFS slips with it, and the owner loses millions in revenue. So the slips get audited, and the audits reach for the same tools: missing logic, excessive constraints, unusual durations, float erosion, critical-path movement. Those checks matter. But they reason over the schedule itself, and a schedule is a declaration of the plan, not proof that the plan is achievable.
On a major data center program, Primavera P6 is the closest thing the project has to a computational model of intended execution. Yet an activity can show on track while the approved submittal is late, the manufacturer has moved the factory test, the electrical room is not ready, or a predecessor has been progressed optimistically. Those signals live in procurement logs, RFIs, submittals, email, field coordination, and commissioning records. Disconnected from P6, they leave a schedule that is mathematically healthy and operationally wrong.
We have come to a different conclusion: the problem is not the schedule, and it is not the scheduler. The problem is that the evidence that decides whether the plan is achievable never touches the plan. What a data center program needs is an intelligence layer on the schedule.
An intelligence layer is not another system of record. It reads the evidence the job already produces and holds it against the schedule graph, activity by activity.
Each of these exists on the project today, trapped in different systems and different inboxes, reconciled only after something has already gone wrong. Connected to the activity network, they answer the only question that matters: does reality still support the plan? P6 supplies the declared plan. The evidence shows whether it is still true.
Consider an activity showing switchgear installation complete on October 12. The schedule may be internally consistent while the latest vendor message carries a revised ship date, the access route is blocked, or permanent cooling for the electrical room is not ready. None of those facts changes the activity until someone finds the conflict. The intelligence layer's job is to find it first, and to trace what it touches through downstream turnover, energization, and commissioning milestones.
On the hyperscale programs we work on, we have learned what works. An intelligence layer has to do four things, or it is not worth adding.
It must treat P6 as the spine. The schedule already defines the work, its sequence, and the milestones that matter. Nobody should be asked to replace it or rebuild project controls somewhere else. Every consequential activity becomes an anchor for evidence. If it competes with the schedule, it is just another silo.
It must run on the documents the job already writes. Schedule updates, vendor emails, RFIs, submittals, meeting minutes, daily reports. Superintendents and project engineers will not maintain another system, and they should not have to. If staying current requires new data entry, it is already dead.
It must give every consequential activity an evidence-backed status. Not a percent complete. A verdict on whether the update can be trusted:
A status without a source document is an opinion.
It must trace every signal to the milestones that matter. A revised ship date buried in a vendor email is trivia until it reaches the activity network. The layer has to show which activities, which turnovers, and which energization milestones a change touches, while there is still time to act.
For each consequential activity, the team should be able to see what P6 claims, which evidence supports or contradicts it, what changed since the previous update, which milestones are affected, and what needs investigation. If the scheduler does not trust that picture, nothing else matters.
Required-on-job readiness. Equipment release, fabrication, delivery, access, and installation must operate as one schedule built backward from the field need date. When a commitment moves, the affected activities and milestones should move into focus immediately.
Phased turnovers. Construction, commissioning, and operations need one view of live boundaries, shutdowns, access, and unfinished work as each phase becomes operational.
Energization and commissioning. Electrical, mechanical, controls, life safety, OEM support, and test evidence must be ready together. One missed prerequisite can postpone a test even when every individual team reports that it is ready.
This is what Terminal Use builds: not a replacement for P6, but the intelligence layer that keeps it aligned with project reality.
The schedule update cycle becomes a continuous process of comparing versions, verifying reported progress, finding unsupported assumptions, explaining downstream impact, and preserving the evidence behind each decision.
That evidence trail earns its keep twice. Day to day, every flag raised in the weekly meeting cites the document behind it. And when a slipped commitment turns into a dispute, the notice trail is already current, so the claim you never wanted to file is supported by evidence you never had to dig up.
The result is a living model of activities, equipment, commitments, systems, and commissioning dependencies. Without that model underneath it, AI on a construction program is fluent and unaccountable. With it, AI can finally do what the brochures promised: help experienced people deliver faster, with answers they can defend. And the first job is simple: determine whether the current schedule can still deliver the next milestone.
