How we verify requirements

The entire product is encoded requirements, so the encoding rules are the product's integrity. Here they are, in full.

• Primary documents only. Utility tariffs, interconnection manuals, application guides, and the state rules behind them. Blog posts and secondhand summaries are never a source of record.
• Every page shows its sources, each with the date we accessed it. If a fact can't be traced to a cited document, it doesn't go on the page.
• Uncertainty is labeled, not hidden. Anything revision-sensitive — form numbers, fee amounts, current schedules — carries a visible verify flag telling you to confirm the current version before filing. A flagged fact is a claim about structure, not a guarantee about today's revision.
• No invented specifics. Where a utility doesn't publish a number, we say so rather than estimate one.

Requirements drift — that's the core problem this whole project exists for. Every wiki page keeps a dated change log, and every page shows when it was last reviewed.

Current cadence, stated plainly: pages are reviewed manually. There is no automated monitoring yet. Planned: staffed change-log monitoring as a budgeted job — a scheduled sweep of source documents with every change logged and, for subscribers, emailed. When that's running, this page will say so; until then, treat "last reviewed" dates as the truth about freshness.

SunDocket is not affiliated with, or endorsed by, any utility. Nothing here is legal or engineering advice. The utility's current published requirements are always the final word — our job is making them legible, current, and checkable, never replacing them.

Tell us: support@sundocket.com. Corrections get logged in the page's change log with the date. People who file with these utilities every week know things documents don't say — that's exactly why design partners shape what gets encoded.