Packet Requirements
Review and approve the utility rules GridWonk uses for application packet checks.
Where To Find Packet Requirements
Open the Utility workspace and choose Rules & Sources → Packet Requirements. Applications remains the default destination. Old Program Setup bookmarks redirect here.
Role-Based Review
Requirements are grouped by packet role, including Application Form, Single-Line Diagram, Site Plan, Equipment Specifications, Site Control, and Whole-Packet Checks. The top of the workspace shows one compact summary for the selected set with its status, effect, packet-profile rule, publication context, and review progress. The summary strip shows the total number of sets and reviewed requirements, plus sets needing review, changed sets, and active sets.
Use Previous and Next to move directly through the reviewable roles. Each control names its destination, and the center control shows the current role plus its position in the reviewable set. On smaller screens, Change requirement set stays above the directional controls so switching roles remains visible without pushing the requirement list down the page.
Open Change requirement set to choose from every role. Read-only evidence and blocked sets stay visible with their packet-profile, cardinality, evidence, and blocking details, but Previous and Next skip them because they cannot be opened for requirement review.
A utility with more than one interconnection lane (for example a simplified, fast-track, and study process) has one requirement set per role per lane; the variant label on each set names the lane, and each set is judged against its own lane's readiness policy.
Evidence only means the packet profile expects evidence for that role but no deficiency checks are published for it.
Utility Rules And Common Recommendations
A utility requirement must cite that utility's source documents. A shared consistency check is a Common requirement from GridWonk's catalog instead: the list names it by its catalog id and version and shows its named basis (which utility sources back it). Serving it beside a utility's own requirements does not turn it into a utility rule. A citation to another utility is not evidence that the selected utility requires it.
A common recommendation can also be conditioned on a packet fact defined by its published catalog entry. That condition travels with the common whenever its version is served; it does not convert the common into a utility rule or bypass a utility-authored override.
The advisory baseline for the four shared whole-packet comparisons covers the connection point, inverter identity, system ratings, and equipment spec sheets. Publishing that baseline for a utility and lane supplies Low severity, which does not block packet readiness. Check any saved reviewer severity adjustment before treating a changed rule as advisory. A blocking utility requirement needs its own source-grounded rule and review. Updating the shared baseline in code does not automatically republish any utility's stored requirements.
Approve Or Reject
- Use Previous, Next, or Change requirement set to select a role.
- Review each requirement, finding, severity, and procedure citation.
- Choose Approve or Reject. Rejections require a reason.
- Use Reset review to clear the current decision and presentation edits.
Reviews are intentionally individual; there is no bulk approval in the first release.
A stale decision shows Reconfirm approval or Reconfirm rejection. Read the current requirement before reconfirming; an ordinary edit does not silently refresh the earlier decision. If a saved wording or severity edit no longer fits the current baseline, repair the edit or reset the review before approving or rejecting it again.
Review Progress And What Developers See
Developer requirement surfaces show every published requirement except the ones a utility
reviewer has explicitly rejected. A Reject decision is the only thing that removes a
requirement from those surfaces; it is dropped on the server and never reaches a developer. Every
other requirement is shown, carrying its review status: approved once a current Approve
decision covers it, pending until then.
A change to decision-relevant rule logic, producer severity, or structured provenance makes its
earlier decision stale and returns it to the review worklist. This includes a change to the named
basis of a common recommendation. Preserving the requirement's identifier preserves its history,
not approval of the changed rule. Presentation-only wording changes do not automatically make a
decision stale, but any saved reviewer edit that no longer fits the current wording is still incompatible. Stale
approvals, stale rejections, and incompatible edits all count as unfinished review — the affected
requirement shows as pending re-review; it is never silently dropped or hidden.
Compatible saved reviewer edits are not automatically cleared when a decision becomes stale. Check the displayed effective severity and any saved wording before reconfirming it.
Readers report unfinished review as review progress alongside the list, not as an empty list. API,
MCP, CLI, SDK, and chat responses use the same served requirement groups and preserve a typed
releaseStatus describing that progress, with each row carrying its own reviewStatus. This is
not limited to NES and does not depend on any commercial relationship with the utility. Normal
surface authentication and rate limits still apply. Returned procedure sources are citations
attached to derived packet requirements, not access to raw procedure documents.
Slack Deep Research uses a narrower operator-only procedure corpus. Its default procedure lane can search only current documents that supply provenance for published packet-review requirements, and only for utilities in the packet-review release list. It does not expose the broader procedure catalog or documents from another utility.
Procedure And Requirement Decisions Stay Separate
Procedure-document review and requirement review stay separate. Rejecting a document from the procedure catalog does not silently suppress a requirement that the utility already approved. The requirement keeps its citation, resolved through the shared utility-scoped document lookup, until an authorized requirement reviewer changes the requirement decision or publication.
A citation opens the copy of the document that GridWonk stored and indexed, so it shows the text the requirement was drawn from even if the utility's published file later changes. When no stored copy is available, or the document is not visible to developers, the citation opens the utility's published link instead. A citation to a form or appendix that GridWonk separated from a larger document names its pages, for example "pages 115–131 of" the parent document, and opens only those pages.
Status Meanings
| Status | Meaning |
|---|---|
| Ready | Every stable requirement has a current decision and compatible saved edits. |
| Needs review | At least one requirement has no decision. |
| Changed | A requirement changed after its current decision, or a saved edit no longer fits the current baseline. |
| Blocked | A profile, stable identifier, or source configuration is missing, so the role cannot be reviewed safely. |
| Evidence only | The role participates in readiness but has no deficiency checks. |
Packet readiness itself (which documents a complete packet must contain, and how many of each) comes from the utility's published packet shape and readiness policy — published data, so it is available for every onboarded utility without a software release.
Review Decisions Do Not Activate Screening
Recording decisions controls what developers see on requirement surfaces, but does not activate deficiency screening. GridWonk separately activates an exact utility, phase, packet variant, and document role in shadow or enforce mode. Shadow computes the reviewed result without changing production analysis; enforce applies current decisions to the analyzer — there, a rejected requirement is excluded from automated analysis too. Since November 2026 every role set that reads its common requirements from GridWonk's catalog is in enforce mode, so a utility's decisions take effect in every onboarded lane; a lane onboarded later is switched on with its own reviewed activation. A developer with a valid project can run Packet Review regardless of how far the utility's requirement review has progressed.
Permissions
Utility members, admins, and owners can record decisions for their directly linked utility. Viewers, grant-based collaborators, and synthetic demo utilities are read-only. GridWonk platform reviewers can support cross-utility review only from their native GridWonk organization context. When a platform admin impersonates a utility, the requirement picker and detail reads are limited to that utility, and platform-only editing permissions do not carry into the impersonated session.
A common requirement served from GridWonk's catalog is edited like the utility's own: the utility's reviewers and GridWonk's cross-utility reviewers can reword it, change its presentation, and adjust its severity, and the edit is recorded against that utility's lane only. It never changes the catalog or another utility's copy of the same common. Only platform admins can edit a requirement whose source is unrecognized or that is still a frozen copy of a common.
Requirement-Set Identity and Publication Safety
Every published requirement carries a stable identifier, an affirmative customer-facing title, and complete structured provenance — including the cross-cutting whole-packet rules. The publication step enforces this: a requirement set missing identifiers, carrying unresolved placeholder titles, deficiency-style wording, or incomplete source evidence cannot be published.
Publishing a utility's requirement bundle is all-or-nothing: readers always see the complete previous bundle or the complete new bundle, never a mixture. Each publish records an append-only ledger entry — who published, the whole-bundle content signature (even for single-role publishes), and a link to the previous publish for rollback. The signature covers the producing model era too, so a republish from a different producer generation is always a distinct ledger entry.
Review decisions, publishes, and activation changes all move the requirement-set identity that packet reviews pin, so a review that ran against superseded rules stops counting as current instead of silently standing. This is enforced at runtime: every automatically scheduled packet review runs against the exact rule set captured when it was scheduled, a review still in flight when the rules change is stopped before it can record results, and a completed review whose rules have since moved must be re-run before a packet can be submitted. After a republish, affected packets are re-checked automatically on a rolling schedule (operators can also trigger an immediate re-check — see the packet requirement republish runbook).
The captured set covers every role the evaluator can consult, including whole-packet checks and explicit markers for roles that had no published row. The review loads those stored entries by their content signature and fails closed if the stored snapshot is missing or no longer proves its signature; it never substitutes the latest live rules into an already scheduled review.