Private Reviews and Utility Submissions

Reviewing a packet and submitting it to a utility are two separate steps. A developer can check a packet privately while its processing allowance and supported workflow remain available. A formal submission is possible only after the receiving utility has agreed to accept submissions for that state and program.

Private packet review (developers)Copy Anchor Link

A developer can create a project and run Packet Review for any utility that has a released, complete packet setup for the project's state, connection type (distribution or transmission) and, where the utility publishes more than one, program.

• The project state is required. A utility's packet requirements are specific to a state. For example, Delmarva Power's Maryland requirements never make a Delaware project reviewable.
• Unavailable combinations are refused at creation. If the utility has no released setup for the chosen state, connection type or program, project creation explains that packet review is not available yet.
• Drafts and private review results stay private. Utility users cannot see a developer's draft project, its working documents or its private review results. They see only what is in a formal submission package, plus reviews the utility itself runs on that package.

A private review is a self-check. Running one never sends anything to the utility. Private review is the default for supported packets without needing a receiving utility organization. Trial and prepaid workspaces also require an enabled, qualified processing path and current processing allowance. It remains available by choice even when the utility accepts formal submissions.

Formal submissionCopy Anchor Link

Submit Project sends a frozen package of the project's documents to the receiving utility. It is available only when all three of these are true for the project's state, connection type and program:

1. GridWonk has approved the utility for that state and program.
2. An authorized utility representative has accepted submissions. This must be an active owner or admin of the utility's own organization, not GridWonk staff.
3. The utility has an active qualified reviewer, meaning an owner, admin or member of the utility organization who is not platform staff or a test account.

Submissions to real utilities are off by default. The separate, verified reciprocal synthetic QA pairs used for internal testing accept by default and can be revoked by a platform admin; they do not turn on intake for their real-utility counterparts. Until all three real-utility conditions are met, the Submit button is disabled and shows: "This utility is available for private packet review, but is not accepting submissions for this state and program yet." Private review keeps working in the meantime.

The Submit page rechecks automatically every 30 seconds while submission is blocked, and again when you return to the browser tab, so you do not need to reload after a utility starts accepting. If the check itself fails, for example during a brief outage, the page says it could not check and to try again. That message does not mean the utility has declined.

The server repeats every check when you press Submit, so a stale page can never send a packet to a utility that is not accepting.

What the first accepted submission doesCopy Anchor Link

• Binds the receiving utility. The project is permanently linked to that utility organization.
• Freezes the package. The exact document versions sent are stored as an unchangeable package.
• Shares the pinned report. The receiving utility can read the packet report included in that package. Other private review history and private document reviews remain applicant-only.
• Notifies the utility. Each qualified reviewer at the utility receives an in-app notice, "New application packet", with a Review application link. Notices appear in the same notification inbox as other alerts and can be marked read or dismissed.

Synthetic QA submissions do not create real-utility receipts or notices.

Resubmission after a deficiency noticeCopy Anchor Link

A resubmission is the developer's corrected packet after the utility sends a deficiency notice. It goes to the same utility that already accepted and reviewed the original submission.

Resubmission does not require the utility to be currently accepting new submissions. The Resubmit Project button is never blocked by the acceptance status. This means:

• If the utility later stops accepting new submissions, or GridWonk withdraws approval, developers who are already answering a notice can still send their corrections.
• If the utility has no qualified reviewer at that moment, the resubmission is still delivered and stored on the project, but no reviewer receives an in-app notice. The utility sees it in its applications list when a reviewer is next available.

All the other resubmission checks still apply, including linked documents, upload completion, project stage and the signed-in user's authority.

For utilities: managing which submissions you acceptCopy Anchor Link

Utility owners and admins control acceptance in Settings → Integrations → Application packet submissions → Manage packet submissions (/utility/submission-acceptance).

The page lists each state and program your utility has a released packet setup for. Each row shows three statuses:

When all three are in place, the row reads "Developers can submit packets."

• Accept submissions turns on your side of the agreement for that row.
• Stop accepting revokes it. Revoking by either party clears both approvals, so reopening requires GridWonk to approve and your utility to accept again.
• Revoking blocks new submissions immediately. It does not remove packages already received, their notices, or developers' ability to send corrections for applications already under review.
• An acceptance counts only while the person who accepted is still an active owner or admin. If that person leaves or loses the role, another owner or admin must accept again.

GridWonk operators manage GridWonk's side in Admin → Organizations → Packet submissions.

Related pagesCopy Anchor Link

• Applications — submission stages, package history and resubmission flow
• Developer Notices — responding to a deficiency notice
• Application Packet Review — building a packet and running Packet Review
• Email Notifications — notification preferences