Application Packet Review

Self-service processing availabilityCopy Anchor Link

Self-service processing remains unlaunched. Its guarded packet path requires an eligible workspace, processing credit, and a supported processing route before paid work can begin. A stopped or unconfirmed paid attempt does not count as a successful review or automatically restore credit. It cannot continue through a different provider or a general assistant job to bypass that stop. The review and source-checking guidance below remains applicable to completed, authorized reviews.

If your workspace is limited to PDF review, its packet sources must be standalone PDFs. The server refuses images, ZIP archives, and native CAD files for that scope, including saved File Library attachments and existing packet sources. A supported upload control or an earlier upload does not override the current workspace restriction. A PDF-only review does not waive the utility's required evidence or establish that a packet is ready for submission.

When following a review through an assistant or integration, keep its returned job and review-run identifiers. Check the same run after an interruption before starting another attempt. Preserve source document and page citations when sharing its findings; an upload receipt, a queued job, or an individual-document result does not establish completed packet-review evidence.

Trial and prepaid reviewsCopy Anchor Link

New packet work needs a current processing allowance. One logical review covers its preprocessing, document checks, eligible platform retries, and automatic follow-up checks for the same input snapshot. Saving a usable packet report consumes one credit, including when cached evidence avoids another provider call. Reading an existing report is free.

Trial upload allowances count the ZIP container and each expanded source entry. Resuming the same entry does not count it again. Native DWG processing is unavailable for trial and prepaid workspaces, including archive entries; purchasing capacity does not change that restriction. A utility's required-evidence policy still applies and cannot be bypassed by uploading only a PDF.

Point of interconnectionCopy Anchor Link

Turning this optional feature off for the packet's applicant organization stops new geographic processing and hides the geography panel and coordinate checks, including on saved reports. Historical evidence remains in the saved report and authorized API, CLI and MCP report reads. Required utility findings, including service-point requirements, remain visible and unchanged.

When this feature is enabled for your organization, Projects → Review → Report includes a Point of interconnection section to help you check locations before submission. Every observed coordinate retains its source document, page, role and interpretation. Select a row to see distances to other explicit POI observations; distance is advisory because two documents may describe different physical points. The feature does not create deficiencies.

Choose View source to open the safe PDF rendition of the reviewed document version and page. Show POI map plots all explicit POI observations with usable coordinates. Select coincident pins separately through their source rows. Site, equipment and point-of-common-coupling coordinates remain separately labelled in the table. External Open in Google Maps links work without the embedded map. Loading a map shares geographic context with Google.

When the review read the drawings for POI labels, a Marked on drawing table under the observations lists each label as written, what it states and how many reads agree, with View source focused on the label. A marker is not a coordinate and is not placed on the map.

Approximate NAD83 conversions show their accuracy qualification. Coordinates with an unknown geographic datum may have a provisional map position; incomplete projected coordinates remain unresolved. Document coverage shows which attachments were inspected, need more review, failed or were not geographically inspected.

Geographic review coverageCopy Anchor Link

Standard geographic review covers application forms, site plans, single-line diagrams, equipment specifications and site-control documents. Supporting documents and native DWGs are not geographically inspected. An accepted PDF companion can contribute evidence when it has one of those document roles.

No coordinates found is reported only after every page has been explicitly inspected by at least two complete interpretations. Missing text recognition does not block the ordinary document review; available interpretations can use the PDF without text assistance.

Coordinate interpretations and text evidenceCopy Anchor Link

The report shows the actual interpretation count for each coordinate. One interpretation requires source review and does not establish a map location. The report also states how many interpretations used existing text and how many text transcriptions they shared. Reusing one optical character recognition (OCR) transcription is not independent confirmation of its digits.

Conflicting evidence stays unresolved and is not mapped, even when several interpretations repeat the same text transcription. Check the source page and highlighted region before acting on it.

Recording a location decisionCopy Anchor Link

Choose I checked this observed location on the map or add a note and Record issue. Decisions are independent per observation and source version; they do not approve the packet, certify a survey, or remove differences elsewhere. Historical decisions remain readable after sources change, but cannot be applied to a new review. Utility reviewers see the same evidence in submitted packages with separate, package-bound decisions.

Mandatory CAD follows the published utility/process policy and its cited requirement. NSP's current published policies make CAD optional; supported NES behavior retains its 50 kW rule. Completed document checks remain applicant self-checks, and only a genuine packet run provides completed packet-review evidence.

Background updatesCopy Anchor Link

The gated permission-aware rollout coordinates packet details, document findings, readiness, and history refreshes. Failed reads preserve the last snapshot; only confirmed removal or access loss clears it. A successful job refresh cannot conceal a failed document or findings refresh. Recovery waits for required snapshots, not merely a reconnected channel. See live-update status.

Captured application fieldsCopy Anchor Link

The default-disabled credentialed Salesforce connector can supply typed application answers without inventing an application-form PDF. Field citations identify the source object and field, record, application answer path, capture time, and exact snapshot fingerprint. Selecting an older run or package retains that captured identity, not the current Salesforce value. Signature-dependent checks still need real signature evidence. Read access is rechecked against current linked-reviewer and source permissions; connector activation and full revision acceptance remain pending.

The separate outbound-only installed application remains disabled. Its Layer 1 foundation records the Salesforce reviewer without creating an individual GridWonk account, and ordinary packet/report readers deny that content. It does not yet submit packets or display Salesforce results. The normal project review workflow below is unchanged.

What a Packet Review DoesCopy Anchor Link

Application packet review checks the documents linked to one project before formal submission. It can run document-specific checks and cross-document consistency checks, then save a durable report with findings, coverage, and review history.

Split controls and automatic-review readiness are resolved on the server for the applicant organization that owns the packet. Another organization's feature settings cannot enable those controls for this packet.

This is decision support, not a final utility, engineering, or legal determination. Confirm each finding against its cited requirement and the applicant evidence before acting on it.

Where to Find ItCopy Anchor Link

Create Project lists only utilities enabled for full application packet review, including authorized synthetic choices backed by those utilities. Utility Research still searches the full catalog. Review support covers the utility's supported state and interconnection program; it does not imply support for every program or state the utility serves.

Open Projects, select the project, use Documents to manage the packet, then open Review. That destination is addressed by view=projects&project=<id>&subview=review in the URL, so a copied link reopens it; older ?tab=packets&submissionId=<id> links still redirect there.

Packet review workflowCopy Anchor Link

1. 1

   Select the project

   Open the project whose current working documents you want to review.

2. 2

   Prepare and digitize documents

   Upload the packet PDFs and wait for each document to finish digitization.

3. 3

   Confirm document roles

   Assign the accurate role to each file. Use the compact assigned-role summary, and expand it when you need the full checklist.

4. 4

   Run packet review

   Confirm the review action and let the durable background job evaluate the reviewable documents and cross-document checks.

5. 5

   Verify, correct, and rerun

   Read findings with their evidence and coverage, correct the working set, and run a new review when needed.

Source anchors: components/console/views/projects/project-documents.tsx, components/console/views/projects/project-review.tsx, components/console/views/projects/storage-native-intake/intake-file-row.tsx, components/console/views/packets/packet-detail.tsx, components/console/views/packets/packet-documents-manager.tsx, components/console/views/packets/packet-report-view.tsx, app/actions/packet-review.ts

Prepare the PacketCopy Anchor Link

Reserved uploads can recover after a refresh in the same tab and account. Return to Documents and reselect the unchanged original files when prompted. Recovery keeps the same upload identities and exact CAD target; accepted files are not uploaded again. Dismissing the browser recovery record does not cancel server work or release the review/freeze gate.

A rejected new file selection is not an interrupted upload: correct the selection and try again. Use Retry Recovery when the account or saved upload cannot be verified.

1. Select the correct project and utility context.
2. Add the current working files to the project. Documents accepts PDFs, images, DWGs, or one ZIP through the same control. It can also attach a file already in your File Library; attach it to the project when it belongs in the packet, or link it to the utility only when it is reusable reference evidence.
3. Preview the safe, sanitized rendition when needed, then wait until the current document has a valid review artifact — the sanitized file used as review evidence. The Documents progress card labels Upload, Text recognition, and Document review separately. A completed review reads Document review: Complete, even if independent text recognition failed. A file without a valid current artifact that is genuinely pending, processing, or failed is not ready for the same review work as a completed document.
4. Assign the role that matches each document's actual purpose.
5. Use the compact N of M required roles assigned summary to check role assignments, then open Review readiness for all blocking requirements, human confirmations, and documents needing attention. A complete role count alone does not prove the packet is ready. Do not force an unrelated document into a role just to complete the checklist.

Submitted package documents are immutable history. When correcting a working document, use the project's replace or delete controls only for the current working set while the packet is a draft or resubmission under development, then follow the upload safety states and use a distinct working copy when the interface requires one.

Human confirmationsCopy Anchor Link

Open Overview → Human confirmations when readiness asks for a fact that automated document checks cannot establish. On an applicant-owned packet, these are still applicant confirmations. On a utility-owned packet, a direct, active utility member with write access can confirm the utility's own evidence while the packet is a draft or resubmission under development. Viewers, grantees, and impersonated sessions cannot author these confirmations; utility reviewer access to an applicant's packet does not allow changing the applicant's confirmations.

GridWonk never pre-checks these statements from an AI result. Each confirmation records its authenticated author, organization, time, and exact document versions. A utility-authored record is labeled Confirmed by utility staff in the confirmation view and, when it satisfies the requirement, readiness. This is not a customer signature or a substitute for a customer declaration. Replacing a linked document makes the previous confirmation out of date; check the replacement before confirming again. Human confirmation writes remain in the console, not REST, CLI, SDK, or MCP tools.

Utility-owned confirmations require the reviewed repair migration and matching application deployment to be active. See Utility-owned packets and developer details for ownership and privacy boundaries.

Split a combined PDFCopy Anchor Link

Choose More actions → Split PDF on an eligible accepted 2–250-page PDF. Assignment, an earlier review, and a missing classifier warning do not prevent splitting. The possible-combined hint opens the same dialog.

1. Review the sanitized page thumbnails; raw original bytes are never shown.
2. Correct the proposed page ranges so every page is covered exactly once.
3. Confirm a canonical packet role for every document range. Mark only true separator or blank ranges as discarded.
4. Select Confirm and create documents and wait for completion. Invalid ranges are rejected immediately, before any background work starts. If the split outlives the short status poll, the dialog stays open in a still-processing state instead of assuming success. The split keeps running in the background, and Check status refreshes that exact split attempt.

Opening, analyzing, and canceling change nothing. Analysis failures offer Try again, with manual page-range editing when page previews are available. Confirmation pauses new reviews and submission. Reopen Split PDF for progress; a failed split offers Retry split and Keep original. Keeping the original abandons that attempt without changing its type or review history.

After successful completion, the original PDF and earlier reviews remain available as history, but the source leaves the readiness checklist, editable packet list, review input, and submitted package. Its derived children take those ordinary roles. Only the applicant developer organization (or a platform administrator) can confirm a split, and only while the project stage is editable. Utility and consultant org contexts are read-only; a consultant can confirm only after switching into a granted developer-client context that still has write-capable, in-scope access. Children require fresh review; an earlier clean parent review never counts as a review of the children. The existing per-organization feature controls govern enablement; no new developer setting, API operation, or re-upload is required.

Upload a packet ZIPCopy Anchor Link

Choose one ZIP in the project's shared Upload Project Files control to use it as a temporary container for 1–12 PDF, PNG, JPEG, or DWG files. GridWonk validates the complete archive before handing any file to ordinary Packet Intake; one unsafe or unsupported entry rejects the whole ZIP. The ZIP itself never becomes part of the packet or enters review. Each accepted file follows the same preparation, role-confirmation, and review path as an individual upload.

Retrying an interrupted ZIP keeps files already handed off. If the interruption happened after a child file was copied but before processing began, recovery rechecks your current permission and resumes the same valid upload attempt; it does not create another child or charge another upload reservation. Expired or retired attempts are not silently revived. If the file was already accepted and initial processing stopped without recording an error, recovery resumes that unfinished work on the same document. It does not repeat completed processing or use one of your failed-processing retry cycles.

When the archive or its coordinating upload batch becomes terminal, GridWonk checks packet readiness once and reserves a review only when the remaining evidence is eligible. Abandoning the container does not remove an already handed-off document or attached CAD companion; immutable child work remains in the packet and the readiness profile decides whether it is sufficient.

Attach a native DWGCopy Anchor Link

Each site-plan card offers Attach DWG, including before a companion exists. That action targets the exact displayed site-plan version through the ordinary validated upload workflow. Replace DWG accepts a new companion; replacing the PDF requires reconfirming or replacing its companion. The card distinguishes required, optional, processing, failed, attached, and outdated evidence. Required CAD comes from the selected published utility/process policy with a cited requirement, not a global project-size rule. NSP's current published policies make CAD optional; NES retains its supported 50 kW rule.

Open the project’s Documents view and use Upload Project Files. You may select a site-plan PDF and matching DWG together; each file may be up to 30 MB. GridWonk pairs only when one current site plan is proven. An ambiguous drawing asks you to choose the matching site plan.

For a simultaneous replacement, pairing waits until the sibling PDF is the authoritative current Site plan. The DWG is never attached to the version that happened to be current before that PDF finished processing. If processing is interrupted, the same accepted source can be retried or found by bounded recovery; it is not silently treated as packet evidence while unattached.

The server validates the file extension, AutoCAD header, exact byte count, and SHA-256 source hash. Upload, retry, cancel, and status checks use the same authorized byte-transfer rules as ordinary documents while preserving the CAD-specific validation and attachment result. The original DWG stays private. The interactive viewer loads Autodesk's derivative rather than the raw source, and its short-lived credential is restricted to the exact companion the session is already authorized to read. A replacement creates a new logical site-plan version and preserves the prior version; it does not edit either file in place. Utility readers can see safe attachment metadata but cannot replace the applicant's drawing.

When a reviewed Autodesk derivative is ready, select Review PDF and DWG. The rendered PDF stays on its existing viewer; the native tab streams an authorized derivative with layout selection and the Autodesk toolbar for layers, selection, properties, measurements, and view reset. The evidence summary states the detected version, units, coordinate metadata, layers, layouts, Xrefs, and proxy objects. A replacement also shows structural changes and which preflight items are new, still present, or resolved. Preflight items are mechanical prompts to verify; they do not replace engineering review.

When a utility has a reviewed CAD procedure profile, GridWonk can use the exact stored evidence to flag Xrefs, coordinate metadata, units, layers, layouts, proxy objects, and missing required drawing content. It can also compare extracted address, inverter, system-size, and point-of-interconnection evidence with the application. These first-rollout findings are advisory and require reviewer confirmation. An exact finding selects a CAD entity only while the source hash and derivative identities match; otherwise GridWonk shows approximate or unresolved guidance without a highlight.

Upload, visualization, and evidence summaries are available to authorized accounts. Utility-specific findings still require a configured CAD procedure profile. Nashville Electric Service is the first profile: its DWG is optional below 50 kW and required for readiness at 50 kW or more. Attached proves immutable delivery; processing remains protected by operational kill switches.

CAD pairing and recovery do not create another review lane. The existing packet-review scheduler waits for active mixed-upload coordination to settle, then uses the current immutable PDF and DWG identities in the ordinary packet input fingerprint. Autodesk evidence that becomes ready later can start a new deduplicated review against that updated evidence set.

Document previews in ReviewCopy Anchor Link

For a utility-created project with no applicant organization, the utility owns the packet. Authorized utility reviewers can preview the current sanitized document version in Review without first creating a submitted package.

For an applicant-owned project, utility reviewers still preview the version saved in a submitted package. The Review findings view requires that saved version to match the current document; without a matching submitted version, the preview remains unavailable. Access checks and document privacy still apply to both paths.

Run the ReviewCopy Anchor Link

Read Upload, Text recognition, and Document review independently. Failed text recognition does not relabel an already-completed review as failed. If an individual review failed, use its retry control only after any known platform issue is resolved; retrying review does not retry OCR or upload a new PDF. See Document troubleshooting.

Eligible projects start typed document checks automatically and in parallel, including site control. Each finished check saves current extraction evidence and rechecks packet readiness; the full packet review starts automatically after all present typed documents and required packet evidence are ready. The Documents view states whether that full review has not run, is active, last completed, or failed. The Review toolbar shows Findings, Report, and History as full-size tabs, with the active one underlined, beside a labeled readiness status and Review Actions. Open readiness only when you need its explanation, missing requirements, documents needing attention, package details, or report links. Use Review Actions for a deliberate manual run or rerun. This is the developer's applicant self-check; historical utility-authority results remain in a separate review lane.

Review Actions uses that same readiness result. If document roles are missing, it offers Assign Document Roles and opens Documents. If another required document or human confirmation is missing, Run Review stays disabled and tells you to complete the requirements shown in the readiness row. Returning to Review after changing roles or confirmations refreshes that result. If your active role cannot edit applicant documents, missing roles remain a blocker instead of opening a read-only Documents view. This prevents a click from looking successful when the server cannot start a review.

The developer console defaults to the applicant lane and does not show a large authority card. Utility teams run utility screening from their utility organization context. GridWonk can enable a compact Review as selector for an authorized operator when exceptional cross-organization testing is needed; that presentation control never grants either authority by itself.

1. Open Review Actions and select Run Review or Run Review Again when a deliberate manual run is needed.
2. Review the confirmation. GridWonk reuses saved document extractions when their identities still match and reads changed or unmatched documents again, so a routine rerun can finish much faster than a first or fully fresh review.
3. Confirm the run.
4. Follow its queued or running state while the background workflow processes the packet. Completion is pushed to the page in real time — even though the review executes in the connecting utility's workspace — with a periodic check as backup, so the finished state appears without reloading.
5. Open Report. It shows the current completed applicant packet review, or an immediate partial report from current document checks while that full review is outstanding. Utility confirmation is not needed to see applicant self-check results. Use History for earlier or out-of-date runs; a clearly labeled utility fallback is used only when no current applicant results exist.

Starting the same active review again reuses the in-progress work instead of creating a conflicting second run.

Cancel an active packet reviewCopy Anchor Link

Open Review Actions → Cancel Packet Review, then confirm the exact active run. This action is available only to users authorized to run reviews in that same applicant or utility review lane. Access to another lane's results does not grant permission to cancel it.

Cancellation ends that run's status and prevents it from saving further packet results. It does not delete completed document findings, cancel their separate reviews, or repair failed text recognition. A request already being processed by an external provider may finish in the background. If GridWonk cannot confirm that the background workflow stopped, it shows a warning; contact support before starting another packet review. A review that completed before cancellation keeps its completed result.

Review an individual documentCopy Anchor Link

In Documents, open a row's More actions menu for Review or Retry review when available. That per-document review saves the document's extracted content. Automatic checks can run together; the final completed extraction triggers the full-packet readiness check. When a utility publishes multiple programs for the chosen connection level, Create Project requires you to select a program. The application form is checked against that program rather than used to guess your choice. A refused form shows whether it appears to be the wrong instrument, a different revision, or could not be verified, together with the recorded reason and observed differences. This explanation appears in both normal and compact Documents rows and disappears after a successful retry or replacement. Upload the correct form before retrying. When a required-documents roster cannot be determined at all, both Documents presentations (the packet view and the compact projects view) say so explicitly and Run Review stays closed until it can. Retry review on a failed document review re-opens that same review attempt; it does not count as a revalidation unless an earlier review of that document had completed.

On eligible editable demo packets, a platform administrator also sees Force fresh document perception for synthetic quality assurance. It deliberately re-reads every reviewable PDF with the current models, takes longer, and uses additional compute. Ordinary customer runs do not expose this control.

Findings opens on the document with the most severe findings already selected, so evidence is on screen as soon as you arrive. The chosen document is marked as selected in the document row, and picking a different one replaces it — your choice is then kept, including across the automatic background refresh. A document whose file changed after its last review is only opened when nothing current has findings, and it keeps its Review out of date warning.

When no document has findings, the workspace says which situation you are in rather than leaving the area blank: No findings once every document in the packet was reviewed and came back clean, No findings yet when the reviewed documents are clean but others have not been reviewed (it names how many), or Nothing reviewed yet before any review has run.

The Review toolbar carries a compact document switcher — a combobox listing every reviewable document with its status — and [ and ] step to the previous and next document without opening the list. Your selection is written to the URL, so a copied link reopens the same document. Whole-packet findings appear as a compact count beside the switcher. Open that count to see each finding's severity, description, and source. A retained-snapshot warning uses the same compact pattern if a background refresh fails, leaving the findings and PDF workspace available.

Completed current document findings remain available while a packet review is queued, running, failed or cancelled. The workspace labels them Individual-document review results, not whole-project results or utility approval. A current completed packet result takes priority over overlapping document results. An older file version or an earlier successful document check is not restored as current evidence when that document's newer review failed.

History keeps this project's resolved and superseded findings beside every packet review run. Opening it re-checks for work finished since you last looked, so a review that completed while you were on another tab appears there without reloading the page.

Respond to a Sent NoticeCopy Anchor Link

When a project has a sent deficiency notice, a developer organization can select Start Response from the project toolbar above Overview, Documents, Review, or Activity. The action moves the live project into resubmission_under_development, records the transition in application history, and unlocks the working documents for correction. The toolbar then changes to Resubmit Project until the revised package is submitted. Utility and GridWonk reviewer organizations do not see this developer-client action. A consultant may see it after switching into a granted developer-client context, but the server succeeds only when that context still has write-capable, in-scope access. If a teammate already started the response, refresh the project; the action is idempotent and does not write a duplicate history row.

ChecksCopy Anchor Link

This optional workspace has its own organization feature flag. Turning it off hides all six supplementary categories and the Checks queue: map coordinates, AI follow-ups, engineer stamp, site-control terms, equipment listing and fees. It does not stop the core utility requirement review, resolve findings, or hide incomplete required checks. Saved decisions remain preserved.

When packet review checks are enabled for your organization, the Review toolbar adds a Checks tab beside Findings, Report and History. Checks is the human pass after the AI packet review. It reads the current completed review and lists what a reviewer still confirms by hand:

• Coordinates on the map: one element at a time, the point of interconnection first, then site, point-of-common-coupling and equipment locations. The panel is a console: the title row, one verdict line, the pictures, and the decision bar. The (i) beside the title says what the check asks. The verdict line reads Same place, One read only, 2 places within 14 m, 2 places, 1.2 km apart, Not on the map or Not stated, with the counts of reads and documents and a gauge of the farthest read. Chips on that line carry the hedges; hover or focus one for its sentence. The drawing crop around the coordinate label and the satellite map fill the rest, side by side, so you compare the drawing and the imagery. The document and page, the previous/next pager, the text as written and Open page sit on the drawing; the pin legend, the shown position and the Google Maps link sit on the map. Coverage at the top right lists every document and how much of it was inspected. One decision per place.

  The rules behind the words: reads of one element are grouped across documents and pages, and reads within 2 m are one place. Places more than 50 m apart are a discrepancy to look at before you decide. N reads uncertain means the model's own interpretations of a read disagree, or fewer than two agree; open the source before you decide. N reads not on the map means the document states the element but its text gives no confirmable position; the chip's tooltip says why (the source evidence conflicts, not enough reads agree, or the coordinates have no supported map position). A location drawn on a site plan without written coordinates is not a place. When the documents put the element in more than one place, a digit strip above the pictures marks the digits of each document's coordinates that differ from the first and the distance that difference amounts to; the strip also appears when a read is uncertain, with that document's row marked, so you know which page to open. When every document agrees and no read is uncertain, there is no strip. Comparison only marks a place or marker that another organization decides; it is shown so you can compare, not record.

• Marked on drawing: when the review read the drawings for POI labels, the applicant's own "point of interconnection" label on a drawing is an item beside the point of interconnection: the label as written, what it states (feeder, substation, voltage, structure) as chips, and how many reads agree, with the drawing crop showing the label and its leader outlined. A marker is not a coordinate and has no pin; the map keeps showing the stated coordinates. Confirm by eye that the marked place sits where the site coordinates and the imagery put the site, then record one decision per marker. 1 of 3 reads saw it or Reads disagree on the marker line means the reads of that drawing did not agree on the label; open the page before you decide. Reviews made before drawing-marker reading is activated have no such item; an empty list never means a drawing has no POI label.

• AI follow-ups: every item the AI review could not verify or did not perform. Marking one "Reviewed myself" records that you looked at it; it is not a pass.

• Documents: manual items such as the engineer stamp and license, the site-control term and signer, the equipment listing, and fees received.

Pick a check in the left rail (icons with a status dot; the arrow at the top expands it to titles, and the choice is remembered in your browser), then record Mark checked, Record issue or Not applicable. An issue or a not-applicable decision needs a short note. Decisions are append-only and bound to the exact review run and evidence. When a new review runs, the checks start again. The utility sees applicant decisions read-only on a submitted package; applicant users never see utility decisions. A role that can only view the checks sees the decision buttons disabled and a View only chip; hover or focus the chip for the reason. A check records your review. It never approves the packet, creates or resolves a deficiency, or changes the AI verdict.

Keyboard: j and k move between checks, c marks the selected item checked, i and n open the note for an issue or not applicable, and ? lists every shortcut. Shortcuts are off while you type in the note.

The left rail also gains a Checks destination under Projects. From inside a project it opens that project's checks. Otherwise it opens the project you last chose there, or the queue when there is none: a table of every project with checks (newest review first) with its utility, review date, progress and what needs attention. Filter it to open checks, recorded issues or all projects. A row opens that project's checks in a side panel, so you can clear several projects without leaving the table; ↑ and ↓ move through rows, Enter opens one, and [ and ] move the panel to the previous or next project. A project view adds a switcher strip: Previous and Next, a dropdown of every project with checks and its progress, Open project to jump into that project's own Review tab, and the queue icon at the left to return to the table. [ and ] move between projects there too. The Report tab shows one line, "Checks: 3 of 7 reviewed", with a link into the Checks tab.

Read the ReportCopy Anchor Link

The Report tab follows current results without pinning the first run it sees. Explicit run links from History stay pinned; selecting Report returns to current results. A current completed packet review replaces overlapping document results, so findings are never counted twice.

Before that review completes, Partial report — document checks shows real completed document checks and their critical, high, medium, and low counts. It lists missing requirements, unfinished or failed processing, stale results, and cross-document checks not yet completed. It is not a fabricated packet run, utility approval, or proof of submission eligibility. Uploads, replacements, deletions, role changes, and CAD attachments refresh the current view as their packet updates arrive. Background refresh failures retain the last snapshot with an explicit out-of-date warning.

Unchanged polling responses do not trigger extra findings or CAD reads. Hidden findings panels refresh when visible again. If a new packet retry fails, current document checks remain the partial result; older completed packet findings are not relabeled as document checks. Cards and Overview show Findings unavailable when the current counts cannot be loaded.

If no current applicant results exist, a completed utility review can appear with a Latest completed utility review notice. It remains pinned utility evidence, not the current applicant report. Failed reads show an unavailable state rather than claiming no report exists. This also applies when the last saved snapshot was empty: a failed refresh cannot silently switch to a utility report.

Start with the result, then inspect its limits:

• Review Finished means processing has ended for that review. The report shows findings and their severity. Open Coverage to see which checks ran, which did not apply, and which still need evidence. Expand a check for its recorded reason and any next action.
• Deficiency identified — Required information is missing or the evidence demonstrates a problem. Read the finding to distinguish a completeness gap from a technical issue.
• Unable to verify — The check was attempted but could not reach a supported conclusion.
• Not applicable — Evidence establishes that the requirement does not apply to this project. Unknown or unreadable evidence is not a reason for N/A.
• Not evaluated — The check was not performed; Coverage gives the reason, such as an absent document, missing context or a separate review step.
• No deficiency identified — Only the completed checks found no deficiency. This is not utility approval or proof that every possible requirement was checked.
• Missing documents — Shows required roles without an assigned document. An uploaded file may still need its role confirmed. A missing required site plan can be a deficiency while its downstream content checks remain not evaluated.
• Classification — Shows the project classification and thresholds used for the review.
• Coverage — Lists completed, unfinished and partially evaluated checks with their reasons. A readable spec sheet or breaker does not hide another unreadable one. Expand a group for check names and any applicability evidence.
• Finding groups — Organize document-specific and cross-document findings with source-backed evidence.

A check not performed is not a pass. If coverage was not recorded for an older run, its completeness is unknown. Findings already identified still apply. A known out-of-scope requirement is resolved as N/A; absence of a document alone cannot establish that the requirement is optional.

Correct and RerunCopy Anchor Link

1. Review the cited utility requirement and the applicant evidence for each finding. Each card names the requirement, the source document and page, and the verbatim cited text.
2. Correct the current project working set without changing an earlier submitted package.
3. Wait for changed documents to finish digitization and confirm their roles.
4. Run packet review again.
5. Compare the new report with earlier history. Revalidation reports can identify findings that were resolved or superseded.

Keep earlier runs as review history. A newer result does not rewrite the evidence or conclusions stored with an older run.

Explain a finding before actingCopy Anchor Link

Select Explain this finding on a finding to inspect quotations from its original source edition. The server rechecks project access and verifies each quotation before showing it. Nearby passages are kept separate, and governing scope and project applicability remain explicitly unconfirmed. The assistant does not invent interpretations or section references, inspect your drawing again, decide pass or fail, or treat publication as utility approval.

The selected finding stays visible for follow-up questions and retries. Select Clear finding to change topics. If an older review, a form-model finding, or a missing or ambiguous source lacks enough saved evidence, the assistant explains that limit instead of substituting today's rule. See Explain a Review Finding.

Review BoundariesCopy Anchor Link

• Only documents available to the active organization and project can be reviewed.
• A developer's pre-submission review stays private. A utility can see the review frozen with a formally submitted package and its own later screening, not a developer's draft corrections.
• Unassigned, unreadable, or unsupported documents may not receive document-specific checks.
• Supporting documents can contribute to readiness without having their own automated analyzer.
• Customer-facing conclusions should rely on approved, current utility procedure sources.
• Human review remains required for ambiguous evidence, checks that could not be verified, and final submission decisions.

RelatedCopy Anchor Link

• Upload — Add and safely revise project documents
• Requirements — Understand the utility rules behind findings
• Results — Work with document-level deficiencies and source locations
• Applications — Understand submission and review lifecycle states
• Developer Notices — Respond after utility review

Confirm or Decline a Finding as an ApplicantCopy Anchor Link

On a completed packet review, an owner, admin or member of the applicant organization can choose Confirm or Decline on each finding. Declining requires a reason. A consultant working under a write grant from the applicant organization for that project can also record decisions; a read-only grant can see them. Viewer seats can read the organization's decisions but cannot record them. Utility membership and platform admin status never grant permission to decide on the applicant's behalf. Anyone who can see the decisions but not record them, such as a viewer seat or a platform admin, sees the same Confirm and Decline buttons greyed out: the applicant's answer is shown pressed, or the card says No applicant response yet.

A changed decision adds a new version; the latest version counts and earlier decisions remain in history. A new review has its own findings to decide. Before you submit, your decisions on your own self-checks stay private to your organization, its consultants and platform admins. Once a review is part of a submitted application, the receiving utility can see your responses on that review's findings, which helps it focus on the findings you agree with. Decisions do not change the utility's adjudication, fix the underlying finding, or replace review, correction and submission requirements.