A conventional commercial construction project has a defined scope, a sequential schedule, and a relatively small set of systems that need to be coordinated at any one time. A gigafactory does not operate this way. At peak execution, a gigafactory program runs Engineering, Procurement, and Construction concurrently across multiple building systems - process, electrical, mechanical, fire protection, automation - each with its own vendor ecosystem, submittal queue, and inspection regime.
The numbers compound quickly. A single gigafactory program might have 4,000-8,000 pieces of major equipment, each with its own utility requirements that need to propagate through the electrical single-line, the mechanical drawings, and the fire protection design. A mid-sized BESS facility might have 200+ battery rack units, each with a separate interconnection drawing set, a site-specific AHJ approval path, and an ITP that must be executed before energization.
The coordination requirement is not just large, it is structurally interdependent. A change to one equipment utility connection cascades through multiple systems and multiple vendors. A delay to one equipment delivery shifts the commissioning sequence for every downstream system that depends on it.
This is the operating condition that makes conventional program management inadequate. Not because the program managers are under-skilled, but because the volume of concurrent interdependencies exceeds what any team can track manually at the level of fidelity that good coordination requires.
On a gigafactory program I worked on, the electrical single-line was updated 14 times over eight months. Each revision incorporated new or revised utility data from equipment vendors. On three occasions, the as-posted single-line in Aconex did not reflect the latest vendor data because the power lead had been working from a local copy. Field work was sequenced against the as-posted version. Two NCRs resulted directly from the disconnect.
This failure is not a discipline problem, it is a structural problem. When the authoritative design state for a critical document lives partially in Aconex and partially in a field engineer's laptop, the system does not have a mechanism to surface that gap. A well-designed operating layer would flag the discrepancy at the moment the local version diverged from the posted version, not two weeks later when the NCR is written.
On both BESS and gigafactory programs, the submittal queue peaks when it is least manageable - during the period when Engineering is finalizing 60% and 90% design sets, Procurement is processing the bulk of vendor documents, and Construction is mobilizing subcontractors who need approved submittals to begin work. This is a predictable collision that every fast-track program encounters and almost none have a systematic way to address.
The standard response is to triage manually: a design manager reviews the queue every morning and escalates the submittals that are blocking active work packages. This works until the queue grows large enough that manual triage itself becomes the bottleneck. At that point, the design manager is spending 30-40% of her day on submittal routing - time that is not available for resolving the design questions that are generating the submittals in the first place.
Machine-assisted prioritization of the submittal queue - based on schedule float, active work package dependencies, and overdue response times - does not require a general intelligence. It requires a system with access to the submittal log in Procore, the schedule in Primavera P6, and the work package sequencing logic. That system can produce a ranked list that the design manager validates, rather than one she assembles from scratch each morning.
BESS facilities have specific fire protection requirements that interact with electrical design in ways that are not always obvious at the drawing stage. A change in battery rack configuration can affect sprinkler head placement, which affects the structural steel penetration schedule, which affects the concrete sequence. On a program where those disciplines are running concurrently, the first person to notice the conflict is often the field foreman - after work has already been performed.
EOR review cycles are the designed mechanism for catching these conflicts, but EOR review operates on a schedule that was set before the program started. The structural condition that creates the conflict may have arisen between scheduled reviews. An automated conflict detection pass - comparing the current fire protection drawing set against the current electrical layout, flagging dimensional incompatibilities - does not replace EOR judgment. It produces the list of potential conflicts that EOR judgment should be applied to, before any concrete is poured.
Pre-commissioning on a gigafactory or BESS facility requires executing a sequence of inspections, test procedures, and energization steps that has thousands of interdependencies. The sequence is typically documented in an ITP, but the ITP is a static document - it does not know which steps have been completed, which are blocked, and which can proceed in parallel on a given day.
The commissioning superintendent manages this from memory and daily walkdowns. When the program is running 50+ active commission sequences simultaneously across multiple systems, the cognitive load is such that suboptimal sequencing is inevitable - work that could proceed sits idle while a different crew waits for a step that could have been done yesterday.
A live commissioning tracker - a system that maps the current state of each step against the dependency graph and surfaces the executable steps each morning - does not require machine learning. It requires a properly structured dependency model and a mechanism for recording step completion in real time. The value is not in the intelligence of the computation; it is in the accuracy and currency of the information available to the superintendent.
Vendor submittals on gigafactory programs arrive from 50-100 vendors, each operating on their own documentation schedule, with drawing packages that need to be reviewed by multiple engineering disciplines before approval. The typical review process routes each submittal to the relevant discipline lead, who has 5-10 business days to respond. When those leads are also managing active design work, review responses are late 40-60% of the time.
Late submittal responses create procurement delays, which create schedule delays, which create cost impacts. The chain is predictable. The point at which it can be interrupted most cheaply is early - before the 5-day review window expires, not after. A system that monitors response times against the review deadline and surfaces impending overruns to the design manager three days before expiry gives the program a chance to intervene. One that reports overruns the day they occur does not.
There is a category error in how AI is often described in the context of construction projects. The claim that "AI will manage your project" is not credible and not useful. The more tractable claim - that machine reasoning over structured project data can perform specific tasks better or faster than a human performing those tasks manually - is well-supported and immediately applicable.
For BESS and gigafactory programs, the specific tasks where this applies:
The professionals who will define how the next generation of gigafactories and BESS facilities gets built are those who understand both what the drawings say and what the data means - who can read a P&ID and also recognize when the submittal queue pattern is signaling a design coordination breakdown three weeks before it manifests as field rework.
The list of tasks where machine reasoning adds value is long. The list of tasks where human judgment is irreplaceable is also long, and on construction programs it tends to involve higher stakes per decision.
Interpreting a vendor's technical exception to a specification requires understanding whether the exception matters for this application - which requires knowing the application well enough to assess functional equivalence. No current system does this reliably for novel situations.
Resolving a coordination conflict between two subcontractors requires reading the motivations and constraints on both sides and reaching an agreement that both parties will actually execute - which requires interpersonal judgment that is not in any model.
Deciding whether to accelerate a late equipment delivery or re-sequence the construction schedule requires weighing schedule risk, cost impact, subcontractor capacity, and weather - a multi-factor judgment call that involves probability estimates that the data alone cannot provide.
The useful framing is not "machines versus humans" but "which tasks should humans be doing." On a program where the design manager spends 35% of her time on submittal routing and data reconciliation, the answer is probably not "those tasks." Automating the mechanical work creates capacity for the judgment work - and the judgment work, on a $500M BESS program, is where the real schedule and cost leverage lives.
The implementation bottleneck on BESS and gigafactory programs is rarely the technology, it is the data quality and the integration work. A submittal prioritization system is only as good as the schedule data it is reading. An RFI pattern analysis is only as good as the RFI categorization in Procore. A utility reconciliation check is only as good as the equipment data in the procurement log.
This means the first investment is not in the machine reasoning layer. It is in the data discipline that makes machine reasoning possible: consistent equipment tagging across Aconex, SAP, and the electrical design model; structured RFI categories rather than free-text descriptions; a schedule that reflects actual construction logic rather than a contractor's bid baseline.
Organizations that have already invested in data discipline find that the machine reasoning layer delivers quickly. Organizations that have not find that the machine reasoning layer surfaces how bad their data quality is - which is also valuable, if uncomfortable.
The programs that run best are those where the program director treats data quality as an operational requirement rather than an IT project. On those programs, the design manager who understands both the engineering content and the data structure is not a rare specialist - she is the standard operating model.