For Utilities

Establish utility accessCopy Anchor Link

When self-service setup is available, verify your account, accept the current terms and privacy policy, then submit a utility affiliation claim. Staff review evidence independently. Approval creates a utility workspace with the claimant as Owner or grants Member access to the existing workspace selected by staff. It does not activate formal intake: the exact state/program acceptance and an active qualified reviewer are still required. Existing invitations remain a separate way to join an approved utility team.

Trial or prepaid screening uses the utility workspace's processing allowance and the exact submitted package. A developer's private review credit does not pay for utility screening.

Applicant partial reports show current document self-checks, not utility approval. Utility screening remains a separate authority over submitted packages. The developer capacity selector does not change the MW units in utility batch CSVs.

Salesforce pilot preparationCopy Anchor Link

Utility account settings link to Manage Salesforce. Its four authenticated integration operations and automatic service package creation are implemented but disabled by default. Setup requires an exact utility sandbox, approved mapping and review profile, individual reviewer links, and separately granted automation authority. Follow the pilot preparation guide; source implementation does not establish a live integration.

Who Is This For?Copy Anchor Link

Utility interconnection engineers and queue managers responsible for reviewing grid connection applications. GridWonk automates the most time-consuming parts of your review process — document screening, deficiency detection, and applicant communications — so your team can focus on engineering judgment.

What You GetCopy Anchor Link

When an applicant completes a confirmed PDF split, current reviews cover the resulting documents. The original and its earlier findings remain historical; they do not inflate current findings or packet counts. This does not change utility review authority or an already frozen package.

• Automated application screening — AI agents analyze selected submissions for completeness, compliance, and site control issues
• Deficiency notice generation — AI drafts structured notices with requirement citations, ready for your review and approval
• Email delivery — Send branded deficiency notices directly to applicants with one click
• Cross-org visibility — Developers on the platform can view notices for their own applications
• Project-first resubmission flow — Review the current application state while preserving prior submitted package history
• Discovery feedback — Rate and correct the AI's understanding of your interconnection procedures

The Utility WorkspaceCopy Anchor Link

Every utility organization uses the utility workspace on the same shell as the developer console: a left rail of global destinations, a header that hosts the selected application's views, a jobs tray, and a Cmd+K destination palette.

A selected application shows Overview, Documents, Review, Communications, and History in the header. An application the utility originated itself starts as a draft in intake; Freeze package in the header turns its current documents into the immutable package that review, adjudication, and notices work from. Every destination has a shareable address (/utility?view=applications&app=…), and older ?tab= links open the matching destination.

On Review, each finding of the submitted package's review also shows the applicant's own response when they gave one: Applicant confirmed or Applicant declined, with the date and any reason. It is read-only context that helps you focus on findings the applicant agrees with; it does not change your adjudication, and you never see responses on the applicant's unsubmitted self-checks.

The previous six-tab shell and base64 batch uploader are retired. The Applications V2 control still governs package reads and packet creation; disabling it hides both upload entry points and refuses package reads without restoring the old screen.

Getting StartedCopy Anchor Link

1. Verify your utility affiliation — Create your account and submit a claim. Staff verifies your authority before granting native utility access. Claim approval does not activate formal intake; state/program acceptance and reviewer eligibility remain separate.
2. Navigate to the Utility Workspace — Your org type determines which workspace you see after login
3. Intake applications — Applications is the default destination for daily work
4. Review packet requirements — In Rules & Sources, approve or reject each published role-based requirement and check its procedure citations
5. Review procedures — Confirm the source documents supporting those requirements are current and usable. In Rules & Sources → Procedures, pick a document from the list to preview the stored copy GridWonk indexed, the text extracted from it, and the utility's published link side by side, then confirm it or report a problem. The address includes procDoc=<id>, so you can share a link to one document. A confirmation applies to the copy you viewed; if the stored copy is re-captured later, the document asks to be confirmed again.
6. Screen and review — Trigger screening, review findings, and generate deficiency notices
7. Track notice and resubmission rounds — Review the next resubmission against the same shared submission record without losing earlier submission history

Current Procedure ReviewCopy Anchor Link

Procedure documents are the rulebooks GridWonk reads before it extracts requirements. The review status tells GridWonk whether a document can safely support customer-facing outputs.

Requirements also need source linkage. A validated requirement without a linked current usable procedure document is still a cleanup item, not a customer-facing rule.

Reviewer Filters and LinksCopy Anchor Link

The /console reviewer workflow includes temporary filters while current-procedure cleanup is underway.

Documents filters: Current usable, Pending review, Deprecated, and All reviewable.

Requirements filters: Current usable, Pending source document, Deprecated source document, Missing source document, and All reviewable.

These filters are saved in the URL. Share the browser URL when you want another reviewer to open the same utility, state, view, interconnection level, and cleanup filter — inside Utility Research the URL also carries the research subview, as in ?view=utility-research&research=documents. Older ?tab= links still redirect to the matching current destination.

Customer-facing users do not get the full cleanup view after enforcement. They see only the current usable source-backed set.

Application IntakeCopy Anchor Link

Developers may privately review packets by default for your utility's released full packet setups, both before and after your organization has accepted submissions. Those drafts and correction reviews are not in your queue. Formal GridWonk intake for each state and program requires GridWonk approval, acceptance by an active utility owner or admin, and an active qualified reviewer. Once accepted, reviewers receive an in-app receipt for each frozen package; revocation stops new submissions without removing earlier packages. Revocation does not stop developers already answering one of your deficiency notices from resubmitting their corrections. Manage acceptance under Settings → Integrations → Application packet submissions; see Private Reviews and Utility Submissions.

GridWonk supports three intake methods:

Applications the utility originates itself are owned by the utility organization (ADR-093): they can enter the same Storage-native intake and start utility screening through the same code developers use, and while their documents are still arriving they show the workflow state Intake in progress. That intake surface for utilities lands with the utility workspace; the batch upload below is the current utility path.

Organization owners and admins reach the key page from the account settings sheet (Integrations tab, Manage API keys) or directly at /utility/api-keys. Keys can carry an optional expiry of 1 to 365 days. A platform admin can suspend one organization's API and MCP access, and every organization has request and screening budgets that refuse a call or run once they are reached.

For batch uploads, prepare a CSV with columns for application number, project name, applicant name, email, capacity (MW), and generation type. Then select the corresponding PDF documents in the upload dialog. The utility batch-upload dialog does not accept ZIP bundles. A separate applicant-project ZIP control is implemented behind the storage-native intake and ZIP_INGESTION organization cohorts; it is not a utility batch-import format.

Combined PDF statusCopy Anchor Link

GridWonk can preserve a combined PDF as an immutable source container and record proposed page ranges and derived-document lineage. The human-confirmation workflow is enabled by default per applicant organization (the COMBINED_SPLIT env dial or a per-organization feature toggle can narrow or disable it). An applicant developer must confirm every page range and document role before separate packet documents are created; GridWonk never auto-applies the split.

Utility and consultant org contexts are read-only for this action (a consultant acts only through a granted developer context with write access). After completion, queue counts, readiness, review, and submitted-package projections use the derived children and exclude the retained combined source. Existing uploads are unchanged unless a permitted applicant confirms a split.

Native drawing statusCopy Anchor Link

Native-CAD intake accepts one private DWG as an immutable companion to the current site-plan PDF for applicant organizations, regardless of utility. The PDF remains the packet's site-plan; the native drawing does not create a second document role. Replacing the DWG creates a new logical site-plan version, so a utility reviewer never sees an old drawing presented as evidence for a newer submission.

When an exact package-pinned Autodesk derivative is ready, an authorized reviewer can open the site plan from Documents, switch between the sanitized PDF and native drawing, inspect layouts and layers, select entities, view properties, and measure geometry. A CAD finding includes an Open native drawing action that opens the same package-bound viewer at the implicated entity only when the source hash and every derivative identity still match. Package review never silently substitutes the developer's newer draft. Approximate and unresolved findings stay labeled and are not converted into PDF page boxes.

Automated checks remain utility-specific through reviewed procedure profiles. NES is the first profile; adding another utility supplies its accepted procedure evidence and rules without changing the shared upload, derivative, evidence, or viewer pipelines.

Interpreting the automated reportCopy Anchor Link

Review incomplete means declared checks remain unresolved or coverage was not recorded. Valid deficiencies remain visible with their severity and evidence. An absent required document can be a deficiency while its content checks are not evaluated. Unknown evidence is not N/A; N/A requires evidence that the rule does not apply. No deficiency identified applies only to completed checks, never utility approval. See Application Packet Review for the outcome meanings and coverage reasons.

Automated Screening PipelineCopy Anchor Link

When you trigger screening for selected applications, each application starts one whole-packet review run in the utility lane, the same engine that reviews a developer's packet before submission:

1. Digitize — Converts each current document version to extractable text
2. Review — Checks the whole packet against your utility's published packet requirements
3. Findings — Records each deficiency with severity, citation, and page reference
4. Package — For a packet your utility originated, the immutable package is frozen pinned to the completed run (automatically when the utility-packet-screening feature is on for your organization, otherwise with Freeze package)

Automated review is switched on per utility. If your utility has not yet been onboarded for automated review, Screen Selected reports Automated review is not yet available for this utility for each row; the rows stay unchanged and notices stay manual.

For formal applications in Pending, Queued, or Resubmitted, starting a review moves the application to Screening before work starts, then Screened when it completes. A failed start or run restores its prior status once no other utility review is active. Console, REST, SDK, CLI, and MCP starts follow the same workflow. Re-screening preserves existing human decisions and notice states; utility-owned drafts still use the package-freeze step above. Screened does not mean approval to interconnect.

After current-procedure enforcement is on, site-control compliance uses only usable site-control requirements. If a utility has pending, deprecated, or unlinked site-control rows but no usable rows yet, screening may wait for cleanup instead of judging the application against unapproved rules.

Packet review records findings and their severities. It does not produce a single score or grade.

Deficiency Notice LifecycleCopy Anchor Link

Notices follow a controlled workflow with human review and approval:

1. Draft — Begin a notice from the current package's accepted and edited findings, preserving their citations
2. Review — Edit the subject, body and existing findings in the split-pane composer; excluded findings require justification
3. Approve — An authorized member, admin or owner approves that exact saved content revision
4. Send — Save a delivery request and follow its queued, retrying, held or provider-accepted progress; Sent does not prove inbox delivery
5. Acknowledge — The developer views the notice and can acknowledge receipt

Follow-up notices track the round number so you can see the full history of communications per application.

Unresolved delivery blocks conflicting application decisions. Revoke Approval is available only before any delivery attempt; afterward resolve the delivery instead of resending. See Notices for recovery and current-access rules.

The dependent utility-event release records actual package, study, decision, and notice changes for your organization's webhook subscriptions. It does not make a decision on your behalf or turn automated review completion into human approval. Verified provider receipts are separate delivery evidence, not applicant acknowledgment. Schema activation, provider setup, and production release require separate approval; see Webhooks.

After a sent notice, a developer organization can select Start response from its project Overview or Review view. Utility and GridWonk reviewer organizations do not receive that developer-only control. Starting the response moves the project into resubmission_under_development and records the stage change in application history, so the next working-document round is traceable without changing the earlier submitted package. When the developer resubmits, the corrected immutable package returns to Pending. Select Screen Selected to run the whole-packet utility review; completed screening enables the decision on that current package.

Cross-Org VisibilityCopy Anchor Link

When an applicant's organization is on the GridWonk platform, they can view notices sent to them through their own developer console. This creates a shared record of communications without email-only tracking.

The important ownership rule is:

• the utility organization still owns the queue and review workflow
• the developer organization is linked as the applicant on the same submission
• consultants join only through grants when that access is explicitly configured

Nashville Electric Service Pilot CleanupCopy Anchor Link

Nashville Electric Service (NES) is the first pilot cleanup for this model. Cleanup means reviewers decide which NES procedure documents are authoritative, approve and digitize those documents, re-extract and validate site-control requirements from them, and retire or migrate older unlinked or deprecated-derived rows.

During that cleanup, NES may show fewer customer-facing site-control results than reviewers can see in the cleanup filters. That is expected until the approved source-backed NES requirement set is ready.

Energy Source SupportCopy Anchor Link

Programmatic utility workCopy Anchor Link

Owners and administrators can create an organization key at /utility/api-keys after ordinary onboarding, then exchange it for a token with partner.read, partner.write, or both. The token selects the utility organization; an application ID never grants access to another utility. Use the utility lane guide for application reads, screening starts, and the REST, SDK, and CLI decision workflow.

Screening automation uses the shared review budget and may be started through MCP. Manual freeze, adjudication, screening completion, and study requirements remain human decisions and are excluded from MCP. These interfaces use the same cores as the console; they do not add notice sending or make completed screening an approval to interconnect.

Next StepsCopy Anchor Link

• Utility Applications API — Screen applications and record package-bound human decisions through REST, SDK, or CLI; MCP can start screening but cannot make these decisions
• Application Queue — Managing the application queue
• Screening Pipeline — How packet review works and how to interpret historical scores
• Deficiency Notices — The full notice workflow
• Help Center — All feature documentation