Site Control
How GridWonk reads, validates, and explains site control requirements.
Completed site-control checks contribute immediately to the project's current findings and partial report. Processing completion alone does not mean a clean review, and a partial report never proves submission readiness.
Findings and CAD status refresh after document or review changes. Unchanged background polling does not reload those results; a failed refresh shows a warning rather than claiming a clean check.
Background updates
With the permission-aware rollout, findings and CAD readers share background scheduling. Findings retain a 60-second cadence; active processing refreshes faster. A failed refresh retains the prior snapshot and cannot claim recovery or a clean check. Confirmed removal or lost access clears inaccessible data. See live-update status.
Salesforce-sourced site-control evidence
The default-disabled Salesforce connector uses the same utility site-control requirements, but source files must be corrected in Salesforce and captured again. A mapped application field does not replace a required deed, lease, or other supporting document, and inaccessible source evidence must not become a false missing-evidence finding.
That correction rule also applies to files imported by a service identity: the absence of a human uploader does not authorize an ordinary delete or replacement. Retained results require current source access to fields across the complete captured history.
What Site Control Means
Site control is proof that a project has the legal right to use the land or corridor needed for interconnection. GridWonk treats site control as a requirement-backed workflow, not a generic document checklist.
When site-control evidence is uploaded, the upload boundary accepts only a bounded PDF payload and validates its decoded bytes before digitization or requirement matching begins. The stored byte count comes from those decoded bytes even when the upload is linked to an existing project.
The accepted evidence depends on the utility, state, and interconnection track. Common evidence types include:
- Property deed or ownership record
- Lease or lease option
- Purchase option
- Easement or right-of-way
- Development rights or exclusivity agreement
- Shared site agreement when co-location is allowed
How GridWonk Uses Extracted Requirements
When procedure documents have been processed, GridWonk stores structured rows for site control in the requirements database. The assistant and validation workflow should answer site control questions from those extracted rows when they exist.
Each row can include:
- Accepted document or evidence types
- Timing, such as documents required at application
- Minimum term or exclusivity rules
- Deposit-in-lieu policy when the tariff allows one
- Jurisdiction or transmission/distribution track
- Source document references
If no extracted requirement exists for the selected utility, the assistant should say that and point you to the workflow that creates requirement rows.
If you ask about a specific site-control detail, such as an easement, right-of-way, shared site agreement, exclusivity, deposit-in-lieu option, or minimum lease term, GridWonk should keep that focus in the answer. When the extracted rows do not list the requested evidence type or term, the assistant should say that the item is not listed instead of filling the gap with a generic site-control checklist.
Usable Site-Control Requirements
A usable site-control requirement is a requirement GridWonk can safely use for customer-facing validation. It must be validated by a reviewer and linked to a current usable procedure document.
In plain English: GridWonk should not reject, warn, or advise a customer based on an old rulebook, an unapproved rulebook, or a requirement that cannot be traced back to its rulebook.
After current-procedure enforcement is on:
- Customer answers, validation results, deficiency reports, and remediation guidance use only usable site-control requirements.
- Pending, deprecated, rejected, unlinked, or stale-source requirements may disappear from customer outputs.
- Reviewers can still inspect those rows with clear status labels so they can clean them up.
Developer Workflow
Before starting, sign in to the selected organization and complete any requested legal acceptance.
- Select the utility and state in the console.
- Create or select a project before running validation. You only need a project name, capacity, and distribution/transmission track.
- Upload PDF evidence from the project's Documents view with Upload Project Files. Site-control evidence must be a PDF, up to 30 MB per file.
- Confirm or override the detected document type.
- When automatic review is enabled, the site-control document review starts alongside the other typed document reviews as soon as its role and prepared artifact are ready.
- After the last present typed document has current extraction evidence and the required packet documents are ready, GridWonk starts the full packet review automatically.
- Open the project's Review view to see whether the evidence satisfies the selected utility requirements.
Uploaded documents are separate from utility procedure documents. Procedure documents define requirements; uploaded documents are the evidence checked against those requirements.
A native DWG companion is also separate from site-control evidence. It belongs to an exact site-plan PDF version and cannot be attached through the ordinary File Library or counted as a deed, lease, easement, or other proof of land rights. This keeps drawing review aligned to the utility's CAD procedure profile without changing the site-control evidence rules.
When one PDF contains multiple packet roles, GridWonk may mark it as a possible combined document. For an enabled applicant organization, a developer must open the split review, account for every page, and confirm each document role. GridWonk never lets an automated suggestion silently decide which pages become site-control evidence. After completion, the derived children are reviewed and the combined source remains only as immutable lineage.
An optional packet ZIP is only an upload container. It does not count as site-control evidence and never enters review. After the whole ZIP passes safety checks, each accepted PDF, PNG, or JPEG enters ordinary Packet Intake and must independently carry the right evidence and accepted role.
A retry remains tied to the exact stored document generation that was checked as eligible. If the source generation changes before the reset or while classification runs, the older retry stops rather than attaching stale digitization or classification results to the newer file.
Compliance validation follows the same rule. Its findings and document verdict are written only while the reviewed document generation is still current. If you replace the file during review, the older run stops without reporting a customer-facing failure; the replacement generation owns the next result.
Utility Workflow
Utility teams manage source procedure material from the Procedures tab.
- Review discovered procedure documents.
- Extract requirements from the relevant procedure documents.
- Validate or dispute extracted requirement rows.
- Use Screening to check submitted application documents against those requirements.
- Use Notices to draft and approve applicant deficiency notices when evidence is missing or insufficient.
Pending requirement rows can still be useful because they came from candidate procedure documents, but they must be shown with their review status. Deprecated and unlinked rows are cleanup records, not customer-facing rules.
Reviewers can temporarily use /console filters to inspect this work:
- Documents:
Current usable,Pending review,Deprecated, andAll reviewable - Requirements:
Current usable,Pending source document,Deprecated source document,Missing source document, andAll reviewable
These filters are saved in the URL, so reviewers can share links to the exact cleanup view for a utility, state, interconnection level, and status.
Deposit in Lieu
Do not assume a deposit can replace site control. Some tracks allow a deposit-in-lieu policy, while others require actual site rights. GridWonk should answer this from the extracted requirement row for the selected utility, state, and track.
Nashville Electric Service Pilot Cleanup
Nashville Electric Service (NES) is the first pilot for this cleanup model. The goal is not to delete useful history. The goal is to decide which NES procedure documents are current, approve and read those documents, re-extract site-control requirements from them, validate those requirements, and retire or migrate older unlinked rows.
Until that cleanup is complete, NES may show fewer customer-facing site-control requirements after enforcement because GridWonk is waiting for approved source-backed requirements. Reviewers can still use the temporary filters to see the pending, deprecated, and missing-source records that need cleanup.