A developer submits an interconnection application for a 200 MW solar-plus-storage project. Twelve days later, after two rounds of back-and-forth with the transmission operator's intake team, it is returned for a third time: the one-line diagram labels the collector voltage as 34.5 kV but the application form lists 34 kV, a one-line mismatch that a sharp reviewer caught buried in exhibit seven. Meanwhile, 40 other applications are waiting for their first look, the intake engineer is already three weeks behind, and the queue clock has not started for any of them. This is not a story about careless developers. It is a story about a manual process scaled far beyond what manual processes can handle.

The Intake Crisis in Numbers: Why Completeness Matters Before Everything Else

The interconnection queue holds over 2,060 gigawatts of projects waiting for studies at the end of 2025. The median time from application to commercial operation date has more than doubled, now exceeding four years. Most of those projects will withdraw before reaching the grid. The engineering staff who run the studies are not the bottleneck in the crude sense: they are working hard on a caseload that has grown by an order of magnitude. The bottleneck is throughput at every step of the pipeline, starting with the very first step: determining whether an application is complete enough to enter the queue at all.

In most tariff frameworks, an interconnection application must meet a defined set of completeness requirements before it is assigned a queue position and before the study clock starts. The requirements are not trivial: evidence of site control, identification of the point of interconnection, technology specifications and capacity data, electrical one-line diagrams meeting format requirements, signed agreements, and payment of the study deposit. An application missing any required element must be rejected and refiled. The developer loses time. The intake reviewer loses time reviewing an application that could not proceed. And the queue position may be jeopardized depending on the tariff's treatment of refiled applications.

At a large ISO processing several hundred applications per filing window, the completeness review alone can consume thousands of staff-hours per cycle. Much of that work is repetitive: checking the same fields against the same tariff checklist, cross-referencing data across exhibits, verifying that signatures and notarizations are present, confirming that deposit amounts match the current rate schedule. This is exactly the kind of structured, rule-based document processing that AI tools are well-suited to support.

What Completeness Checking Actually Requires: The Tariff as the Ground Truth

Before any AI tool can assist with completeness checking, the completeness requirements themselves must be precisely specified. This is the ground truth problem: the AI can only check against what it knows the rules are, and those rules come from the applicable tariff or pro forma interconnection procedures, not from the AI's general knowledge of interconnection practice.

A typical large-generator interconnection application (the kind processed under FERC Order 2003 and its successors) requires the developer to provide: a completed application form with all fields filled in, a one-line electrical diagram meeting the interconnection provider's specifications, documentation of site control (deed, lease, or option agreement), a deposit in the amount specified in the rate schedule, identification of the proposed point of interconnection by substation name and bus number, generator technology specifications including nameplate capacity, voltage and power factor specifications, a proposed commercial operation date, and contact information for the developer and their authorized representatives. The exact requirements vary by ISO and tariff, but the structure is consistent.

Each of these requirements has a corresponding check the reviewing engineer performs. Does the one-line diagram show the correct generator bus voltage? Does the application form's stated capacity match the one-line? Is the site control documentation current (not expired)? Is the proposed POI substation a real substation on the network (not an invented name)? Is the deposit amount correctly calculated for the project's capacity and the current rate schedule? Does the contact information include a valid email address and phone number?

When an AI tool is configured for completeness checking, it works from a structured representation of these requirements. The most effective approach is to represent the completeness checklist as a set of explicit rules against which each application can be evaluated: rule R-1 requires that field F-1 on the application form is populated; rule R-2 requires that the value in field F-1 matches the voltage label on the one-line diagram to within a specified tolerance; rule R-3 requires that the site control document's expiration date is at least six months after the proposed study commencement date. Each rule has a defined pass/fail criterion, a source citation in the tariff, and an associated output: pass (no action needed), fail (specific deficiency noted), or flag (human review required because the rule requires judgment).

The AI completeness checker is not a replacement for the engineer who understands the tariff. It is a first-pass filter that catches the 60 to 70 percent of deficiencies that are mechanical and obvious, so the engineer can focus on the 30 to 40 percent that require judgment.

AI Document Parsing and Field Extraction: What Works and What Fails

The core technical capability that makes AI completeness checking possible is document parsing and field extraction: the ability to read a PDF application form, identify the relevant fields, and extract the values in those fields for comparison against requirements. Modern AI tools, particularly those using large language models with document understanding capabilities, are quite good at this for standard form fields and tabular data. They are less reliable for data embedded in engineering drawings, complex multi-column layouts, or handwritten annotations.

For a well-structured application form with clearly labeled fields, AI field extraction achieves accuracy rates high enough to be useful as a first-pass review tool. The AI can read 100 application forms in the time it would take a human reviewer to read four, and it can cross-reference fields across documents (comparing the application form's capacity value to the one-line diagram's rating, for example) without losing track of which application it is reviewing.

For one-line electrical diagrams, the situation is more complex. A one-line diagram is a engineering drawing, not a form, and extracting structured data from it requires understanding conventions and symbols that are specific to electrical engineering. Some AI tools have been trained on collections of one-line diagrams and can reliably identify generator buses, transformer ratings, and voltage labels. Others will misidentify a protection relay symbol as a voltage label, or confuse a collector feeder with the main interconnect. Before deploying AI for one-line review, the responsible engineer needs to understand what types of diagrams the tool was trained on and how well it handles the specific format conventions used by developers filing in that queue.

The practical approach most teams adopt is a tiered review: AI handles the straightforward field checks (form completeness, numeric field presence, date validity, deposit calculation), flags discrepancies for human review, and passes the clearly complete applications through to technical review without delay. One-line review may remain a manual step, or may be AI-assisted but always human-confirmed, depending on the reliability demonstrated for that specific tool and diagram format.

Handling Common Failure Modes in AI Completeness Checking

When AI completeness checking tools fail, they fail in predictable ways that a well-designed workflow can catch. The most common failure modes are worth understanding concretely because they inform how you design the human oversight step.

The first failure mode is field confusion in non-standard form layouts. If a developer uses a custom form layout instead of the ISO's standard form (which happens more often than it should), the AI may extract the wrong field. It may read the "rated capacity" field but actually capture the "summer net capacity" value, or it may fail to find the POI substation name because it appears in an unusual location. The mitigation is to require developers to use the ISO's standard form and to have the AI flag any application where the form structure does not match the expected template.

The second failure mode is numeric extraction in different units. A developer may specify generator capacity in MW while the application form expects MVA, or specify voltage in kV when the diagram labels it in V. The AI may extract the number without converting units, producing a mismatch flag where there is actually no problem (or, worse, failing to flag a genuine mismatch because the numbers happen to match numerically after the unit error). The mitigation is to include unit checks as explicit rules in the completeness checker and to have the AI output the extracted value with its unit for human verification when any numeric comparison is performed.

The third failure mode is OCR errors in scanned documents. Some developers submit paper applications or scan their supporting documents at low resolution. OCR extraction from low-resolution scans introduces transcription errors that can cause false completeness failures. The mitigation is to require native PDF (not scanned) submissions where possible and to flag applications where document quality is below a defined threshold for human review of the raw document.

Workflow Integration: Triage, Routing, and the Human Touchpoint

An AI completeness checker that produces a list of pass/fail results has limited value unless it is integrated into a workflow that routes applications appropriately based on those results. The workflow integration question is as important as the AI technology question, and it is where many implementations fall short.

The most effective workflow designs use the AI completeness check as a routing gate with three outputs: applications that pass all checks cleanly are routed to technical review with a completeness clearance notation in the study management system; applications that fail hard checks (missing required exhibits, deposit not received, POI not identified) are returned to the developer with a deficiency letter generated from the AI's output; and applications that trigger flag conditions (human review required) are routed to an experienced reviewer with the AI's analysis pre-populated so the reviewer can evaluate the specific flag rather than re-reading the entire application from scratch.

The deficiency letter generation from AI output is a significant efficiency gain in itself. Instead of a reviewer writing a deficiency letter from scratch, the AI's completeness check output can feed directly into a letter template: "Your application for [Project Name] filed on [Date] is missing the following required elements: [List from AI output]. Please address the following deficiencies and refile within [X days] as specified in Section [Y] of the applicable tariff." The reviewer's job is to confirm that the deficiency list is accurate and complete before the letter is sent, not to generate the list from scratch.

The study management system integration is worth particular attention. The AI completeness check should write its results to the project record in whatever system the ISO or transmission owner uses to track interconnection applications (this is often a combination of a ticketing system, a spreadsheet, and a custom study management database, rather than a single polished platform). When the check passes, the queue position assignment can proceed without a human completeness sign-off step. When the check flags items, the flag and the AI's reasoning are documented in the project record so that the human reviewer's decision is also documented. This creates an audit trail for the completeness determination that can be referenced if a developer later disputes their queue position.

Worked Example: The Solar-Storage Application That Almost Took Twelve Days

Return to the 200 MW solar-plus-storage project from the opening. The developer submits a 47-page application package as a PDF. With an AI completeness checker in place, here is what happens instead of the twelve-day back-and-forth.

Within four hours of submission, the AI tool processes the application and produces its completeness report. It identifies the following: the one-line diagram on page 23 labels the collector bus voltage as 34.5 kV, while the application form's technical specifications table on page 8 lists the interconnection voltage as 34 kV. This triggers flag rule CR-14 (voltage specification consistency check), which is routed to a human reviewer. Separately, the AI confirms: deposit receipt number is present and the deposit amount matches the rate schedule for a 200 MW project; site control documentation expires in 18 months, which exceeds the six-month minimum from the proposed study start; POI substation "Millbrook 230/34.5 kV" is confirmed present in the network model directory; all required form fields are populated; the proposed COD of Q3 2029 is within the tariff's allowable range.

A human reviewer looks at the completeness report in the study management system. The flag for rule CR-14 notes the 34.5 kV vs 34 kV discrepancy. The reviewer, who knows that the local distribution standard in this area is 34.5 kV and that "34 kV" on application forms is a common shorthand for the same voltage class, makes a professional judgment: this is not a substantive deficiency, the application is clear about the intended voltage, and requiring a refile for this notation difference would be poor stewardship of both parties' time. The reviewer overrides the flag, documents the reasoning ("34 kV and 34.5 kV refer to the same nominal voltage class per ANSI C84.1; no substantive inconsistency"), and approves the application for technical review.

Total time from submission to completeness clearance: six hours, including the human reviewer's override and documentation. Under the previous manual process, this same application with its 34/34.5 kV notation issue would likely have been flagged during a multi-day review cycle and returned to the developer for clarification, who would refile, triggering another review cycle. The AI-assisted process captures the genuine issue, but the human reviewer's judgment about whether it actually matters eliminates the unnecessary iteration.

Now multiply this by 340 applications in a filing window. The AI processes all 340 in the same six-hour window. Eighty-seven applications have flags or failures: 34 are clear failures returned with deficiency letters, 28 need human judgment on borderline issues, and 25 have format or notation questions like the solar application above. The 253 cleanly passing applications move immediately to technical review. Two human reviewers handle the 53 flagged applications over the next two business days. The entire completeness cycle for 340 applications takes less than a week instead of six weeks of staff time.

Developer-Side Pre-Submission Tools: Catching Deficiencies Before Filing

One underutilized dimension of AI completeness checking is deploying the same logic on the developer's side, before submission. A pre-submission completeness checker that a developer can run on their own application package before filing it with the ISO serves everyone's interest: the developer avoids queue position jeopardy from a rejected application, the ISO avoids processing a deficient application, and the overall throughput of the intake pipeline improves.

Several ISOs have experimented with self-service pre-submission tools, though as of 2026 these remain more the exception than the rule. The same completeness rule set that the ISO uses internally can, in principle, be made available as a developer-facing tool. The developer uploads their draft application package, the tool runs the completeness check, and the developer receives a detailed report of any deficiencies before they file. This is not a competitive advantage issue: the completeness requirements are published in the tariff and available to everyone. Making it easier to file a complete application the first time benefits the ISO by reducing intake burden and benefits developers by reducing the risk of lost queue position.

The most likely near-term form of this kind of tool is an AI-assisted application portal where developers build their application through a structured workflow that validates data as it is entered. Instead of submitting a completed PDF that is then reviewed for completeness, the developer enters their project data through a form that performs real-time validation: the voltage field requires a numeric value in kV and cross-checks it against the collector voltage label on the uploaded one-line. The deposit amount is calculated automatically from the capacity input and the current rate schedule. Required documents are checked for presence and format as they are uploaded. By the time the developer submits, most mechanical completeness issues have been resolved in the application workflow itself.

Key Takeaways

• Completeness checking is the first and often the most delay-prone step in the interconnection study pipeline. With 2,060+ GW in the queue and a median study time exceeding four years, reducing intake cycle time is a direct contribution to queue throughput.
• AI completeness checking works by executing a structured rule set derived from the tariff's completeness requirements. The AI checks fields, cross-references data across documents, validates numeric values and units, and routes applications based on check results. The ground truth is always the applicable tariff, not the AI's general knowledge of interconnection practice.
• The most common AI failure modes in completeness checking are: field confusion in non-standard layouts, numeric extraction without unit conversion, and OCR errors in low-quality scanned documents. Well-designed workflows include mitigation steps for each of these.
• Human oversight is essential and has a defined role: reviewing flagged applications where the AI's rule-based judgment is insufficient, making professional determinations about whether a detected discrepancy is substantive, documenting override decisions in the project record, and signing off on the completeness determination. The AI catches the mechanical issues; the engineer decides what matters.
• Workflow integration matters as much as AI capability. Routing completed applications to technical review, routing deficient applications to deficiency letters, and routing flagged applications to human reviewers with pre-populated analysis must be connected to the study management system so that the AI output creates an audit trail, not just a report that someone reads and then manually acts on.
• Developer-side pre-submission tools that use the same completeness logic as the ISO intake review represent a high-value, underutilized extension of AI completeness checking. Making it easier for developers to file complete applications the first time benefits throughput on both sides of the process.
• Every completeness determination, including AI-assisted ones, must be documented. The queue position assigned to a project is a commercial right. The basis for accepting or rejecting an application must be defensible if challenged, which means AI flags and human override decisions both need to live in the project record with clear reasoning.