Requirements
Understanding interconnection requirements extracted from utility tariffs.
What are Interconnection Requirements?
Requirements are the technical, procedural, and financial rules utilities impose on energy projects. They define:
- What documentation is needed
- Equipment specifications required
- Processes to follow for grid connection approval
Requirement Categories
Requirements are organized into four main categories:
Site Control
Land documentation proving you have rights to the interconnection location:
- Deeds
- Leases
- Easements
- Letters of intent
See Site Control for the workflow that connects extracted utility requirements to uploaded applicant evidence.
Technical Requirements
Equipment and engineering specifications:
- Inverter certifications (UL 1741 SA)
- Protection settings
- Voltage ride-through capabilities
- Anti-islanding requirements
Application Requirements
Forms and documents needed for submission:
- Completed application forms
- One-line diagrams
- Site plans
- Insurance certificates
Fees
Financial requirements:
- Application deposits
- Study deposits
- Processing fees
- Per-kW charges
Published Packet Requirements
The developer Requirements view shows the published requirements for exactly one packet variant at a time: every published requirement except the ones a utility reviewer has explicitly rejected. Rejected requirements are removed on the server and never reach the page.
Each requirement carries its own review status. Approved means the utility's reviewers signed off on it. Pending means it is still awaiting a current utility decision — including a requirement whose logic changed after a decision, which returns to pending re-review rather than being dropped or hidden. A saved reviewer edit that no longer fits the new wording likewise puts the requirement back into pending re-review.
This mirrors what a packet deficiency report can raise: reports cite requirements from the same all-except-rejected set, so the list shows what a report may cite, with pending rows labelled honestly instead of hidden.
Utility review progress is reported separately from the list. Where a role's review is still in progress, the page says so and reports how many of the shown requirements are awaiting a decision — but the requirements themselves are still listed. Automated checks published for a role are shown whatever its review progress.
API, SDK, CLI, and MCP clients receive the same information: a typed review-progress state plus a per-row review status. A zero-row result means no technical publication exists, or every in-scope row was rejected — never that review is merely unfinished.
Page Layout
The page title names the selected program, for example "Requirements for the Expedited Process". The page has three titled sections.
Interconnection Application Documents lists the documents the selected program's application packet includes, built from the utility's published packet shape and readiness policy. Each row gives the document's name and one line saying what it is. Documents needed only in specific situations are marked If applicable, with a short line explaining that they do not block submission by default. If the packet shape or readiness policy is not published, or the published shape and policy disagree, the section shows a short notice instead — published rules still render when they are available.
Specific Document Requirements groups the published rules by document:
- Application Form
- Single-Line Diagram
- Site Plan
- Equipment Specifications
- Site Control
Document Cross-Checks holds the Whole-Packet Checks: facts that must match across documents, checked over the whole packet.
These groups use the exact published interconnection-level and tier discriminator. The program (packet variant) is chosen in the console header’s Program segment (Utility › Program), which Procedure Docs shares, so both tabs show the same program; when the URL names none, the view picks the first published program and the header reflects it. GridWonk never merges rules from different application variants or exposes raw discovery candidates.
Each rule shows its reviewed requirement statement, when it applies, what happens if it is unmet (some findings are always blocking or advisory, while others depend on the specific result), and every citation, linked to the source utility document where a public copy is available. A rule whose reviewed wording is still pending shows the document-role label with a "Wording pending review" badge instead of unreviewed text.
Requirement chat answers omit pending wording, report that review state when every match is pending, and exclude those hidden rows from the available-result count. They also preserve the difference between reviewed-but-empty and not-published results, and report how much of what they return is still awaiting a utility decision.
If no packet shape or technically published rule set exists for the selected utility, the page shows a clear "Published requirements unavailable" notice rather than rules from a different application path. Published rules can still appear without a checklist when the utility has rules but no packet shape.
The Requirements total counts individual served rules. Group headings organize those rules but do not count as requirements themselves.
Packet requirement groups start collapsed so the page opens with an overview of the available document roles. Select a group heading to expand its rules, citations, and source detail.
Live Updates Indicator
The Live badge means the reference requirement list refreshes automatically when its stored data changes, without needing to refresh the page. Published packet groups load with the page and change only when a reviewed set is published. They are not continuously re-extracted or automatically re-verified against utility source documents.
Developer views refresh from the served requirement set when source data changes. Reviewer-only rows do not create new requirement badges or update notices for developers.
Reviewing Requirements
Requirement reviewers work from the published Packet Intake catalog. They can:
- Approve — Confirm a published requirement is correct.
- Reject — Keep an incorrect requirement out of effective packet checks.
- Refine — Correct allowed customer-facing text or severity without changing executable rule logic.
- Reset — Remove the decision and return the requirement to review.
Platform reviewers use Admin → Requirements Review. Utility reviewers use the Packet Requirements workspace for their own utility.
Source Traceability
Published requirements carry reviewed provenance. When a utility procedure document is the source, the review surface shows its public link and cited excerpt. Common-practice and reviewed-form requirements are labeled separately.
Source linkage means GridWonk can show which procedure document produced the requirement. A requirement is safer when it points back to a current usable source document and, when available, to the same text version GridWonk used during extraction.
The review surface fails closed if a published set cannot be projected safely. Raw executable rule fields and content fingerprints are not sent to the browser.
Review Status
Individual published requirements are approved, rejected, or unreviewed. A published set is summarized as ready, needs review, changed, blocked, or evidence-only.
When the assistant answers requirement questions, it uses the published Packet Intake reader and cites the utility procedure source when available.
For focused questions, the assistant should preserve the user's requested term in the answer. Examples include site-control variants such as site-control, land control, shared site, right-of-way, easement, exclusivity, deposit-in-lieu, timing, milestone, and minimum lease term. If the published set does not contain that detail, the answer should say so.
Customer-Usable Requirements
Customer-facing requirement views use only the published Packet Intake catalog. A rejected row is omitted. An approved or still-pending row is labeled honestly, and no legacy requirement is mixed into the result.
If the requested utility or packet variant has no published set, GridWonk shows an unavailable state. It does not substitute a similar utility or fall back to the frozen legacy table.
Site Control Details
Site-control requirements should preserve the details users need for validation:
- Accepted document or evidence types
- Timing, such as documents required at application or before agreement execution
- Minimum term or exclusivity rules
- Deposit-in-lieu policy when the tariff allows one
- Jurisdiction or transmission/distribution track
- Source document references
Transmission vs Distribution
Interconnection requirements differ based on whether a project follows a transmission or distribution track. Do not classify a project from one universal megawatt or voltage threshold. The selected utility, governing procedure, queue, and saved project track determine which rules apply.
Names such as LGIP (Large Generator Interconnection Procedure) and SGIP (Small Generator Interconnection Procedure) appear in some tariffs and queues, but they are not universal labels for every transmission or distribution project. Study steps, deposits, fees, and jurisdiction must come from the current source for the selected utility and track.
Using the Filters
The published packet view uses its exact packet-variant selector and never merges transmission and distribution variants. Changing the selector loads the complete published set for that exact variant.
Key Terminology
| Term | Meaning |
|---|---|
| Deposit in Lieu | Tariff-specific cash alternative to site-control evidence, only when the governing source allows it |
| Exclusivity | Sole land control requirement |
| Timing Requirements | When documents must be submitted at different project phases |
| Project Term + Decommissioning | A lease-term formula only when the governing source explicitly requires it |
Asking the Assistant About Requirements
Useful requirement questions include:
- "What site control documents does Duke Energy require in North Carolina?"
- "What application fees should I expect for Duke Energy NC?"
- "Show me PJM site control requirements."