Notices
Deficiency notice workflow — draft, review, approve, and send.
The dependent notice-interface release adds REST, SDK and CLI workflows for direct utility members and read-only MCP access. Schema activation and deployment remain separate approvals. Programmatic send recipients must be current addresses on file; existing authorized console recipient entry is unchanged. Source-managed applications cannot acquire notice-write permission through either interface.
Deficiency Notice Overview
The public plugin can read notices within its confirmed workspace and current permissions. Drafting, editing, approving, sending, and acknowledging notices remain website workflows for that connection. Switching the website's active workspace does not retarget the plugin connection.
Deficiency notices are formal communications sent to applicants when their interconnection application has issues that need to be resolved. GridWonk automates the drafting process while keeping humans in control of review and approval.
Notice Lifecycle
A notice can move through five stages:
| Status | Description | Available Actions |
|---|---|---|
| Draft | A structured notice is composed from accepted and edited package findings | Save Draft, Submit for Review |
| Review | Engineer reviews and edits the notice content | Save changes, Send Back to Draft, Approve |
| Approved | An authorized reviewer approved the current content revision | Request sending; revoke only before any delivery attempt |
| Sent | The email provider accepted the notice for sending; this is not proof of inbox delivery | Read-only (shows recipient and timestamp) |
| Acknowledged | Applicant has viewed and acknowledged the notice | Read-only |
The workflow moves forward: Draft → Review → Approved → Sent → Acknowledged. Reviewers can send a notice back to Draft from Review. Approval can be revoked before any delivery attempt; once sending has started or its outcome is uncertain, resolve delivery first. Once sent, the notice waits for applicant acknowledgment.
In the broader lifecycle, a sent notice usually leads to a developer revision cycle and then a resubmission on the same shared submission record.
Starting a Draft
Open the application from Applications, choose Review in the header, and click Begin deficiency notice. GridWonk composes a structured draft from the selected package's findings:
- Accepted and edited findings are included; dismissed findings are excluded
- Findings are ordered by severity and carry their requirement citations
- The draft carries a subject line, an introduction explaining the deficiency review, the categorized list of findings, and a response deadline (30 days by default)
The control is only available when the screening decision allows it: the package must be the latest one, the application must be awaiting a screening decision (no draft already open for this round), every blocking finding must have a recorded decision (deferred findings still count as unresolved), and at least one accepted finding must remain to include. Drafting requires current review results for every document in the packet. If a document was replaced and its current version has not been re-reviewed yet, GridWonk hides the findings tied to the older bytes and keeps the control unavailable until the review has been re-run. A notice is a formal communication, so it is never generated from a packet where any document is still waiting for re-review — re-run the review first, then draft.
Notices created before package-bound review kept their original generated draft. For those notices, if you modify the body and want to revert, the Restore AI Draft button next to the body field (marked with a rotate icon) replaces your edits with that original; it only appears when the current body differs from it. Package-bound drafts have no separate original to restore.
Editing Notices
The notice composer provides a split-pane editor:
- Left panel — Edit the notice subject, recipient email, response due date, deficiency checklist, and body text (Markdown supported)
- Right panel — Live preview showing the notice as the applicant will see it, with GridWonk branding
Deficiency Checklist
Each deficiency item in the notice can be:
- Included or excluded — Toggle items on/off to control what appears in the final notice
- Modified — Edit the description, severity, or recommendation
The notice retains its original finding IDs and adjudication links. Editing cannot add or remove findings from that set; use the checklist to include or dismiss existing items.
When you dismiss (uncheck) an item, an amber-highlighted textarea appears below it labeled "Dismissal justification (required)". You must provide a written explanation for each dismissed finding. The Save Draft and Submit for Review buttons are disabled until every dismissed item has a justification. This is a compliance requirement — you cannot skip it.
Review and Approval
The workflow enforces a review chain:
- Save Draft — Save your work at any time during the Draft stage
- Submit for Review — Mark the notice as ready for review by another team member
- Send Back to Draft — During Review, return the notice to Draft status for further edits
- Approve — Approve the notice for sending after review
- Revoke Approval — Move an approved notice back to Review only before any delivery attempt
Notice mutations require a utility organization member, admin, or owner. A consultant using delegated access also needs a write or admin grant; read-only viewers cannot approve or send notices.
Approval applies to the exact saved content revision. If another edit lands after you opened the notice, refresh and review that version before approving. Editing after revocation clears approval, so approve the new revision before requesting delivery. Older approved notices without revision-bound approval must be reviewed and approved again. Current membership and the exact delegated grant are rechecked when changing a notice and before dispatch.
Sending Notices
After approval, click Send Notice to save a delivery request. The sender defaults to
notices@gridwonk.com, with replies routed to support; it is not a per-utility identity.
The request freezes the recipient, sender, reply address, subject, and rendered notice.
The composer shows delivery progress separately from notice status:
- Queued / Sending — The saved request is waiting or being attempted. Do not resend.
- Retry scheduled — The same saved request will retry automatically; its next attempt is shown.
- Provider accepted; finalizing — The provider accepted the message, but the application update is still pending. Do not resend.
- Held — Sending needs review. Read the reason and contact an authorized operator; a new send request does not clear the hold.
- Status unavailable — Use Refresh status before taking another action.
Sent is recorded only after provider acceptance and the application's notice-sent update commit together. It does not prove inbox delivery. A failed or unconfigured transport does not mark the notice sent. Automatic retries retain the same request for at most eight attempts within 23 hours of the first attempt; uncertainty beyond those bounds is held.
The dependent receipt layer can retain verified provider delivery, bounce, or other email events as separate evidence. A receipt does not mark the notice Sent, resend it, or acknowledge it for the applicant. It is not proof that a person read the message, and this layer adds no receipt viewer to the composer. Receipt configuration, schema activation, and production release require separate approval.
Before the first attempt, Revoke Approval can cancel the pending request. Reapproving unchanged content can resume the same frozen request for its original authorized sender; it cannot silently replace the recipient or create a fresh delivery key. Pending, attempted, held, or accepted-but-unfinalized delivery blocks conflicting application decisions.
Each draft creation, edit, send, and reviewer status change is appended to the notice's edit history with who did it, when, and a provenance record naming the credential and surface it came through (a console session today) and the request id.
When the utility-event layer is released, actual lifecycle changes also create one durable integration event for the receiving utility's subscriptions. Editing content, requesting a send, receiving a provider receipt, or repeating an acknowledgment does not create another status event.
Developer Acknowledgment
When the applicant's organization is on the GridWonk platform:
- They can view the notice in their developer console
- They can acknowledge receipt of the notice
- Acknowledgment is recorded with a timestamp
- They can work toward the next resubmission round from the developer side without losing the notice history
Acknowledgment requires a developer or utility organization member, admin, or owner. A read-only viewer cannot acknowledge a notice. Acknowledging an already acknowledged notice is a successful no-op; it does not add another history entry.
After a notice is sent, the 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 shared project into Resubmission Under Development and records the stage change in application history, so you can see when the applicant began working on corrections without losing the earlier submitted package.
Follow-Up Notices (Rounds)
If an applicant resubmits after addressing deficiencies, you can:
- Re-screen the resubmitted application
- Generate a new notice (Round 2, 3, etc.)
- Each round links to the previous notice for a complete audit trail
The round number is displayed on each notice so you can track the full communication history.
Notices List View
The Notices tab shows all notices with:
- Filtering — Filter by status (draft, review, approved, sent, acknowledged) or notice round
- Search — Search the notice subject and body
- Sorting — Sort by date, status, or notice round
- Pagination — Navigate through large notice volumes
- Status badges — Color-coded indicators for each lifecycle stage
Edit History
Notice edits are tracked for audit in the underlying record. The current notice UI does not expose a full edit-history viewer.
Related
- Screening Pipeline — How screening produces the findings that feed into notices
- Application Queue — Managing the application queue
- For Utilities — Utility workspace overview
Corrected package handoff
After the applicant addresses a notice and resubmits, the corrected immutable package returns to Pending in the receiving utility's queue. Select the application and choose Screen Selected to review that package. The earlier package and notice remain history. Once the new review finishes, complete screening or begin another notice from its current findings; resubmitting alone does not send a new notice.