Results

Project-Scoped ResultsCopy Anchor Link

The default-disabled Salesforce connector can produce application-field citations without a PDF. These show the object and field, source record, answer path, capture time, and exact snapshot fingerprint. An older selected run retains its own captured identity. Current linked-reviewer and Salesforce permissions are still required to read its findings, files, or report links; working-copy edits cannot change the Salesforce source. See Salesforce preparation.

Historical reports now require current permission for all committed captured fields, including fields removed from the current mapping. A revoked older field can also deny the current view. Malformed history and more than 200 revisions are refused; live sandbox acceptance remains open.

Results are saved inside a project. Review opens inside a project workspace, so when no project is selected the console shows the Projects list and you select or create a project before any validation history appears.

A developer's pre-submission findings stay private to the developer organization. The receiving utility can read the review frozen in a formal package and its own screening, not later private correction reviews or replacement files.

This keeps deficiencies, scorecards, remediation work, and status tied to a durable project record instead of a loose utility-wide file list. You can still browse procedures and requirements without a project, but validation outputs require one.

Split-View LayoutCopy Anchor Link

With permission-aware live updates enabled, findings keep their 60-second refresh cadence and History refreshes periodically while visible and online. Temporary connection or permission-service failures retain saved results with a warning; they do not prove a project was deleted. Confirmed removal or access loss clears the affected results. Return to the tab or use Retry updates to request fresh authorized data. An unrecoverable session offers Sign in.

After a confirmed PDF split succeeds, the retained original and its earlier findings remain in History. Current findings use the resulting documents and a packet review of that exact set. Each new document requires its own review; the parent's clean result does not carry over. Pending or failed confirmed splits pause new reviews and submission. Use More actions → Split PDF to inspect progress, retry a failed split, or keep the original.

On desktop, Results display in a two-panel split view:

• Left panel — Deficiency list with severity, status, and quick actions
• Right panel — Source PDF evidence with page navigation and source-location status

On a phone, use the Findings and Document tabs to switch between those same panels.

The Deficiencies and Document Viewer titles are announced to screen readers instead of taking a header row, so the review evidence receives more of the available height: the severity counts and list tools share one compact row, and the viewer's own pager shows the page position once the document loads. On desktop the document pane also carries a Hide findings toggle (Cmd+\ / Ctrl+\) plus a Full screen mode that Esc exits, where the browser supports it. The toggle shortcut keeps working while a toolbar disclosure such as readiness or the document switcher is open; it stands down only for a full dialog.

On the project Review page, Findings, Report, and History share one compact toolbar with a labeled readiness status and Review Actions. Open readiness for missing requirements, documents needing attention, package details, and report links. Manual packet runs and reruns live under Review Actions. When the packet is incomplete, that menu links to missing document roles or names the requirements that must be completed before a manual run can start. Whole-packet findings and retained-snapshot warnings open from compact disclosures in the document selector row instead of full-width messages, leaving most of the page height for the evidence workspace.

Click any deficiency to sync the PDF evidence to that finding. Project Findings is read-only; working-copy editing and retry controls are not offered in this view.

The PDF panel shows the current page and total page count after the document loads. When a selected deficiency only has page-level evidence, the panel warns that exact source bounds are unavailable. When no reliable source location exists yet, the panel tells you to review the document manually instead of pretending the map is exact.

The deficiency list supports keyboard navigation while that panel has focus: press j/ArrowDown and k/ArrowUp to move between deficiencies, Enter or Space to expand the focused deficiency, and Escape to collapse the open deficiency. These are bare-key bindings: modifier chords such as Cmd+K never move the focused deficiency.

Document Preview VersionsCopy Anchor Link

Upload, text recognition and review are separateCopy Anchor Link

An accepted upload, searchable text and a completed document review are three different outcomes. Text recognition (OCR) can fail while the safe PDF preview and a completed review remain available. That OCR failure must not be read as a failed review. Results belong to the version that was reviewed; replacing a PDF preserves earlier results as history and starts a separate current-version lifecycle.

Completed individual-document results can appear in a partial report while the whole-project review is still outstanding. They also stay visible in Findings while a packet review is queued, running, failed or cancelled, labeled Individual-document review results. A current completed packet result takes priority and is labeled Whole-project review results; the two sources are not added together. Neither is utility approval. Results from replaced files, or from before a newer failed document review, are not restored as current results. For recovery choices, see Document troubleshooting.

To stop an active packet review, use Review Actions → Cancel Packet Review when your review permissions allow it. Cancellation preserves completed document findings. A provider request already in progress may finish in the background; read any cancellation warning before retrying. See Cancel an active packet review.

Which PDF version opensCopy Anchor Link

In Review, utility-owned projects preview the current sanitized document version without a submitted package. A utility-created project with no applicant organization is utility-owned. For applicant-owned projects, utility reviewers still need a submitted package version that matches the current document; otherwise the Review findings preview remains unavailable. Document privacy and access checks continue to apply.

How Location Works (Plain English)Copy Anchor Link

Each deficiency now has two pointers:

1. Working pointer: where the issue sits in the editable digitized copy.
2. Source pointer: where supporting evidence was found in the original PDF.

A stored working pointer does not make the Project Findings view editable. Use the source PDF to inspect evidence, and prepare corrections in your document editor. A reviewer must confirm approximate or unresolved locations before treating them as exact citations.

Severity LevelsCopy Anchor Link

The underlying severity values and visible groups are critical, high, medium, and low. High findings are not counted under Critical. Address Critical and High findings first, but a severity badge is not itself a final utility or regulatory decision. Current document checks appear immediately in project counts and the partial report; no utility confirmation is required.

Cards and Overview show Findings unavailable when current counts cannot be loaded. A failed background refresh retains an explicit warning, including when the prior results were empty. It never silently substitutes an older utility report for unavailable applicant results.

Deficiency Card AnatomyCopy Anchor Link

Every finding card, on the developer console and the utility adjudication view alike, shows the same body:

1. Severity — the coloured dot before the finding (see the table above); the open card spells it out on a Severity line. The card carries no other badges: the document is already named by the list you are in or the section heading above the card.
2. Finding — what GridWonk detected, as the card title. In the developer console a collapsed card shows only the dot and the finding; expand it for the lines below.
3. Type — only when the category changes what you should do: Project eligibility (no document fix resolves it) or Documents disagree.
4. Requirement — the utility's published requirement statement, when the review's published set carries one.
5. Source — the utility, the source document (linked when it is published), the page, and the verbatim cited text with its surrounding context. This is the same provenance the utility sees under Rules & Sources.
6. Location — one line: a validated page highlight, an approximate page, or why nothing can be highlighted (for example, an absence finding cites no document text).

Below the body, the developer card offers View in PDF and Explain this finding, which opens the assistant for a quotation-first explanation of that exact saved finding. The server rechecks project access and verifies quotations against the source edition used by the review. Nearby text is not treated as governing scope; applicability remains unconfirmed. It does not invent section references or re-read the applicant's drawing. The utility card carries adjudication controls instead. Whole-packet findings (the toolbar's packet-findings disclosure) render on the same card, with the same Requirement and Source lines.

The assistant shows the selected finding and keeps it for follow-up questions and retries. Use Clear finding to leave it, or choose another finding. Changing user, organization, or project clears the selection. If the historical requirement or cited quotation cannot be verified, the assistant explains the limitation instead of using a different edition or guessing. A published requirement is not necessarily human-approved, and a common-practice recommendation is not utility text. See AI Assistant for source limits.

Location StatusesCopy Anchor Link

• Exact — Verified source bounding box and quote.
• Approximate — Reliable page-level evidence, but no trustworthy box.
• Unresolved — No safe source mapping (contextual/inferential findings).

Selecting a finding with an exact location, or choosing View in PDF, zooms the viewer so the highlight fills the pane and centres it; a finding without a highlight opens its page at fit width. You can zoom further with the viewer's zoom buttons and menu, Cmd/Ctrl with +, -, or 0, or Cmd/Ctrl + scroll. Approximate and unresolved locations are still useful for review, but they should not be treated as exact legal citations until a reviewer confirms the source evidence.

Remediation WorkflowCopy Anchor Link

1. Select a deficiency and inspect its cited evidence in the PDF panel.
2. Prepare corrections in your document editor; Project Findings does not edit the source.
3. Upload the corrected file through the project's supported replacement or intake action.
4. Run an eligible review and compare the current results with retained History.

Trial and prepaid customer workspaces use supported packet-processing actions. Generic chat, legacy digitization and other unsupported processing paths remain unavailable; credits do not unlock them. See Document troubleshooting.

ReportsCopy Anchor Link

Use the project's Report tab for the current packet report or available individual-document partial report. History retains earlier runs. Project Findings does not show the legacy Scorecard download button. Report access is checked against the project and selected run.

Re-ValidationCopy Anchor Link

After fixing deficiencies:

1. Export or prepare the corrected PDF.
2. Upload changed content under a new filename when the existing document identity cannot be replaced. Documents frozen into a submitted package remain immutable history.
3. Eligible, classified site-control documents in a selected project can start validation automatically. Otherwise, start validation from the available upload or results action.
4. Review the newest run for current findings. Prior validation and submission history remains available; do not assume an older finding was deleted merely because it does not appear in the newest run.

Asking the Assistant About ResultsCopy Anchor Link

Useful results questions include:

• "What critical deficiencies remain for this document?"
• "Where did GridWonk find the site-control issue?"
• "How do I fix this lease-term deficiency?"