GridWonk Documentation

Current-result contracts distinguish document self-checks from completed packet reviews and utility approval. Partial findings never prove submission eligibility; mandatory CAD follows the published utility/process policy.

Welcome to the GridWonk documentation. This site covers everything you need to use the platform, integrate via API, or connect your own AI agents.

For public-plugin access, start with account and workspace setup, then connect with MCP. Registration, prepaid purchases, and client availability depend on their rollout settings. The public plugin uses a fixed customer tool catalog and the workspace confirmed in Connected apps. Purchases and human approval workflows remain on the website.

The console's Create Project utility picker requires a released full state/program packet setup, not a receiving utility organization. Private review is the default; authorized synthetic choices retain pairing checks. Utility Research keeps the full catalog. Availability does not guarantee exhaustive coverage or utility approval. Review coverage is specific to the utility's supported state and program. See Utility Selector.

Projects show current document findings and partial reports before whole-packet review completes. The completed packet shows Review Finished. Its Coverage section explains which inputs were missing and what the reviewer can do next. Individual document results remain visible during a failed, cancelled or running packet review and are labeled as individual-document results. Authorized reviewers can cancel an active packet run from Review Actions without deleting completed document findings. Those partial results are neither utility approval nor proof of submission eligibility. See Application Packet Review for current-result selection, outstanding checks, and exact-version DWG attachment.

GridWonk supports utility teams, project developers, and engineering consultants in one shared platform. Utilities own the review queue, developers can follow their own submission lifecycle, and consultants participate through scoped cross-org access when granted by a client organization.

Salesforce connector statusCopy Anchor Link

A separate outbound-only installed application now has its Layer 1 certificate-authentication foundation and Layer 2 packet-submission workflow in source. It can preview the selected packet, save a durable Salesforce receipt, pin exact field and file versions, authorize scoped uploads, finalize an immutable packet and read submission progress. It remains hard-disabled: no customer installation, review processing, result retrieval, MCP tool or CLI command is active.

The Salesforce utility connector is implemented but disabled, not an activated customer integration. Its guide covers the four scoped REST/MCP/SDK operations, current access across captured history, automatic immutable packages, and the real utility sandbox acceptance still required before activation.

Direct Owners and Admins of developer and utility organizations can preview and save workspace appearance from Team and logo, using colors found in the organization's source palette.

For DevelopersCopy Anchor Link

When enabled for the packet owner, Projects → Review → Report includes source-linked point of interconnection coordinates and an optional map. This capability starts disabled. Its geographic evidence and human confirmations do not create deficiencies, certify surveyed locations, or approve a packet. See Point of interconnection.

Project developers preparing interconnection applications can start with the For Developers guide to create a project, upload and validate working files, submit to the utility, receive notices, and revise/resubmit. The console's Utility Research view also provides read-only access to active procedure documents and published requirements for the selected utility — everything except requirements a utility reviewer has explicitly rejected. Requirements still awaiting a utility decision are shown and labelled as pending rather than hidden or replaced by legacy or neighbouring-utility rows; integrations expose the same per-row review status.

For enabled projects, GridWonk automatically accepts positive packet-role classifications and starts the applicable document analysis. It also rechecks whether the complete packet is ready for automatic review. A person can correct a wrong role at any time before the package is frozen; that correction becomes authoritative, keeps the automatic assignment in audit history, and starts analysis again for the corrected role. Unknown and possible-combined results remain manual. The internal admin measurement separately reports later human changes, explicit retention, and assignments not yet revisited, without exposing tenant or document identifiers.

Packet reruns normally reuse exact current document extractions and re-read only changed or unmatched documents. Platform administrators can force every reviewable PDF through the current models only on demo packets for synthetic quality assurance; this internal control is not exposed through partner APIs, MCP, or the CLI.

For every applicant organization, projects can attach an immutable private DWG companion to the exact current site-plan PDF version regardless of utility, even when that utility does not require CAD. Native intake accepts DWG files, not DXF. Upload and attachment prove delivery and package identity. Native CAD visualization and evidence extraction run when the operational APS switches are healthy; utility-specific checks require a reviewed procedure profile. NES is the first profile, not a hardcoded platform limit. The original DWG remains private; the browser receives an exact-model authorization, not native bytes.

An optional Combined-PDF workflow — on by default for every account, and set per organization by GridWonk — lets an applicant developer review sanitized page thumbnails and human-confirm complete page ranges and document roles. It never auto-applies the split; derived children replace the retained source only in current packet projections.

An optional packet ZIP lane — on by default for every account, set the same per-organization way, and subject to the same platform rollout controls — lets an applicant use one bounded archive as a temporary shipping container for PDF, PNG, JPEG, or batch-linked DWG files. GridWonk validates the whole archive before any file enters its ordinary document or CAD processor; the ZIP itself never becomes a packet document or enters review.

The capability contract also records an active mixed-upload batch coordinator. One Documents selection reports combined progress and safe CAD pairing while each PDF, image, DWG, or ZIP continues through its own authoritative processing lane.

After a refresh in the same browser tab and account, reserved console uploads can recover their original identities. Reselect unchanged original files when prompted; accepted files are not uploaded again. See Upload for recovery and local-record dismissal. This adds no API, SDK, CLI or MCP operation.

Whole-packet review, including a manual start, waits for any active, unexpired upload batch to settle. Cancellation, abandonment, or expiry preserves accepted documents and releases only that upload gate; the packet must still meet its other readiness requirements.

The capability contract records native-CAD intake, visualization, and deterministic preflight as separate operations. The shared partner REST intake and console attachment lanes can be enabled for an applicant-organization cohort without enabling Autodesk processing. SDK, CLI, and MCP expose batch coordination and applicant-owned CAD pairing, but not standalone native-CAD creation. The batch routes do not enable native-CAD intake for utility-owned packets.

The capability contract also records active organization feature controls for an audited, signed-in human UI. These controls are intentionally absent from MCP and public REST mutation surfaces, so an integration cannot silently enable an organization's feature.

For UtilitiesCopy Anchor Link

Utilities looking to integrate AI-powered deficiency detection into their review workflows can use For Utilities for queue ownership, screening, notices, resubmission review, and source-review workflows. When a submitted package includes native CAD, authorized reviewers can switch between its sanitized site-plan PDF and package-pinned drawing derivative and open exact CAD findings in that same viewer. Utility organizations also have API and MCP access on by default: owners and admins mint keys at /utility/api-keys, then use the documented scopes and utility-specific routes.

The Utility Applications API now describes screening and the REST/SDK/CLI bindings for manual freeze, adjudication, screening completion, and study requirements. MCP can start screening but cannot record those human decisions. Package-bound notice workflows also have implemented REST/SDK/CLI bindings, with current utility writer authority and on-file send recipients. MCP exposes notice list/detail reads only. Pending or provider-accepted delivery is not canonical sent status or proof of inbox delivery; schema activation, package publication, and production release remain separate gates.

The dependent utility-event contract adds five ordered event families to existing receiving-utility webhook subscriptions. Events describe saved changes, not new decision authority; verified email-provider receipts remain separate from notice status and human acknowledgment. Schema activation, provider configuration, and production release are still separate approval gates.

Utility-created packets remain utility-owned and private to authorized utility staff by default. Recording a developer name or contact neither creates an account nor shares the packet. The utility-owned packet guide explains direct-staff confirmations and the separately required repair deployment and database activation. Human confirmations remain console-only; no new CLI, MCP, SDK, or REST write is added.

For ConsultantsCopy Anchor Link

Engineering consultants and IX advisors managing workflows across multiple clients — see For Consultants for multi-client setup, team coordination, and reporting.

API & IntegrationsCopy Anchor Link

The API Reference covers the External API v1 surface under /api/v1, including developer project management under organization-key authority, async jobs, webhooks, usage analytics, and MCP access. See Integrations for discovery and integration workflows, including the complete Slack setup and usage guide, the Slack and Microsoft Teams channel comparison, and how GridWonk works alongside systems such as PowerClerk while preserving its own lifecycle model.

For an accepted document with failed processing, follow Document troubleshooting. Support may investigate a scoped recovery without another upload; protected operator tooling does not add customer API, CLI, SDK or chatbot repair authority, or change these integration entry points. Files that were never accepted may still require their originals.

For AI AgentsCopy Anchor Link

• Product llms.txt — Public product and marketing discovery.
• Docs llms.txt — Anonymous plain-text bundle of explicitly public guides.
• Public plugin and MCP guide — Customer research, intake, review, and result workflows.
• Connected apps — Confirm one workspace for an exact sign-in session and revoke access.
• Help Center — Account setup, utility claims, processing allowances, and packet guidance.

Public documentation, search, navigation, metadata, and Markdown exports are readable without sign-in. Internal content and the complete docs-host discovery documents require native GridWonk platform-administrator authority. An administrator using a customer or support context sees the public audience. Search at /docs-site/api/search follows the same visibility policy.

The public plugin catalog is stable before and after connection setup; ordinary calls require an active workspace connection and current permissions. Existing partner API keys and scoped tokens retain their separate credential-specific catalogs. Use the MCP integration guide and API authentication for those connections. Public help does not provide access to another organization's files, an operator tool, or a human decision.

The current requirements endpoint serves published Packet Intake requirements. The old requirements REST address returns 410 Gone and names its replacement. See Requirements API.