検証事例：推奨結果をその根拠まで追跡する
提出された申請書から増強検討の推奨結果の背後にある根拠まで、合成Tessera Compute申請を追跡します。対比事例は、なぜ準備度、熱容量影響、検討優先順位を分けて説明する必要があるのかを示しています。すべての申請および系統は合成データです。スクリーンショットに表示される申請者企業名はフィクスチャラベルであり、実際の顧客、導入実績、支持を意味するものではありません。
スクリーンショットを選択すると、オリジナルを原寸大で開くことができます。これらは実際の製品画面です。表示されている操作パネルは記録されたローカルワークスペースのものです。
推奨結果を信頼する前に申請内容を検証する
Tesseraは連系点（POI）であるbus 3において750 MWを要求しています。提出された文書には用地確保（サイトコントロール）と現行の保証金納付が記載されています。原典ビューにより、審査担当者はプロジェクト名や要求容量から網羅性を推測するのではなく、これらの記載と抽出されたフィールドを直接突き合わせることができます。
受付ビューには確認済みの用地確保と納付済みの検討保証金が記録されます。これらの入力により準備度0.92（100点中92点として表示）が算出されます。これは設定された優先順位付けヒューリスティックであり、連系成功の確率、信用評価、または技術的実現可能性の証明ではありません。
オプションのモデル支援受付は、原典と比較するための追加の抽出結果を提供します。動画ウォークスルーでは保存された実際のモデル応答を再利用しています。その助言的な結果が保存されたキュー推奨結果や検討順位を変更することはできず、キュー全体の実行でもモデルは使用されません。審査担当者は依然として、抽出されたフィールドを提出された申請書と照合する必要があります。
スクリーニングが実際にカバーする系統を定義する
この合成テストケースは、2,000母線（バス）と3,633ブランチで構成されています。スクリーニングでは、両端が138 kV以上の976本の非放射状送電設備を監視します。潮流配分係数（PTDF）が電力注入による送電線潮流の変化を推定し、送電線事故配分係数（LODF）が監視対象送電線の脱落後の残存送電線潮流を推定します。
申請MWは大口需要家と表記された申請も含め、スラック母線で平衡化された注入電力として扱われます。これは説明用のモデリング上の慣例であり、検証済みの需要引き出し検討ではありません。既存のベースライン過負荷はプロジェクトへの帰属から除外されるため、新規プロジェクト制約が存在しないからといって系統全体が安全であると証明されるわけではありません。
検討ルートを一変させる事故を特定する
Tesseraの帰属可能な最大ベースケース潮流負荷率は92.3%であり、100%の熱容量制限を下回っています。しかし、監視対象送電線の単一事故が発生すると、帰属可能な最大潮流負荷率は112.4%に達します。したがって、申請の準備が整っておりベースケースが制限以下であっても、推奨結果は増強検討となります。
有意義なレビューの問いは、どの設備が、どの事故条件下で制約を受け、その過負荷が申請に起因して新たに発生したものか否かです。単線結線図は連系の文脈を示し、特定されたブランチ、想定事故、負荷率が決定的な熱容量の根拠を提供します。増強検討ルートは特定の工事設計を承認するのではなく、さらなる技術的検討を求めるものです。
問題なしスクリーニングと境界域レビューを比較する
合成Apex DCも同様に750 MWを要求し、準備度は0.92です。帰属可能な最大ベース負荷率は79.7%、単一事故時負荷率は96.4%であり、新規の過負荷は発生しません。この案件は「問題なしスクリーニング（Clean screen）：詳細連系検討へ移行」を受けます。このラベルは連系を許可するものではありません。
合成Cortex Computeも新たな過負荷はありませんが、単一事故時負荷率96.7%は95%の警告帯域を新たに超過したことを示しています。設定されたポリシーは、この境界域の事例を技術レビューへと送ります。したがって、過負荷制限を下回る値であっても判断が求められる場合があり、レビューへ進むことは技術的判断の完了を意味しません。
系統補強と受付不備を区別する
合成Stargate Computeは500 MWを要求し、帰属可能な最大ベース負荷率は163.6%に達します。この案件は大規模系統増強検討（Major network build）へとルーティングされます。この構成では、135%を超える負荷率または4件を超える新規制約レコードがこのルートをトリガーします。このラベルは検討の必要性を特定するものであり、法的な違反や完成した補強設計を確定するものではありません。
合成Helios Computeは異なる問題を抱えています。その申請書には締結済みの用地確保と納付済み保証金が欠落しており、過去の取り下げ履歴やペーパーカンパニー・特定目的会社（SPC）による申請者調整によって、設定された準備度スコアも0.00に引き下げられます。受付順1位から準備完了順213位へと後退し、追加の受付審査のためにキューに残ります。
未解決の連系点、0.60未満の抽出信頼度、および物理計算不可の案件も、技術レビューへとルーティングされます。これにより、根拠の欠落と審査合格の差異が維持されます。各推奨結果にはその理由が必要です。単一の複合スコアでは、次のアクションが受付審査、熱容量解析、技術的判断のいずれに関するものかが覆い隠されてしまいます。
順位を時間と混同せずに検討順序の比較を読み解く
| 検討推奨結果 | 合成申請件数 | 解釈 |
|---|---|---|
| Clean screen（問題なし） | 84 | 新規の帰属可能な過負荷がなく、設定されたレビュー条件にも該当しない。 |
| Upgrade study（増強検討） | 22 | 増強検討を必要とする新規の帰属可能な過負荷あり。 |
| Engineering review（技術レビュー） | 30 | 未解決の根拠、物理計算不可、または境界域の潮流負荷率。 |
| Major network build（大規模系統増強） | 24 | 設定された大規模系統増強検討ルート。 |
| Low readiness（低準備度） | 90 | 優先検討の前にさらなる受付審査が必要。 |
問題なし（Clean screen）および増強検討（Upgrade study）のルートには、合計106件の申請と約62.2 GWの申請容量が含まれます。インターフェースはこの容量を「検討準備完了容量（study-ready capacity）」と呼びます。増強が必要な申請も含まれているため、これは即時連系可能または受入可能な容量ではありません。電気的近接性クラスタリングはこれら2つのルートのみをグループ化しますが、規制上の適格性を確定したり統合技術検討を完了したりするものではありません。
準備完了優先順（First-ready order）は、推奨結果の優先度、準備度の降順、そして申請MWの降順でソートします。問題なしおよび増強検討の106件の申請全体において、正確な中央値順位は138.5から53.5へと変化し、インターフェースはこれらの中央値を切り捨てて表示します。Tesseraは増強検討ルートを維持したまま順位が9位から92位へと移動し、準備度単体では優先順位が決まらないことを示しています。
表示されている再検討リスク（restudy-exposure）指標は、後続の問題なしまたは増強検討の申請ごとに、上位にある低準備度または大規模増強の申請を1回カウントします。設定された順序付けによってそれらの上位ルートが後方に配置されるため、この数値は6,596件からゼロ件へと変化します。これは実際の再検討、取り下げ、経過時間、増強工事の完了、または技術的工数をシミュレートするものではなく、この比較は最適化や公平性を保証するものではありません。
検証項目を精査し正確な検討記録を保持する
ランタイムベンチマークは、6項目の物理同一性チェックと6項目の明示的なポリシーケースを分離しています。物理チェックは数値的関係性をテストし、ポリシーケースは設定されたルーティング境界をテストします。記録された実行では12項目すべてが合格と報告されています。これは固定された合成スイートにおける実装の根拠であり、実地精度、送電網全体の実現可能性、または独立した検証結果ではありません。
実行固有の検討計画JSONエクスポートはキューの根拠を保持し、印刷可能なプロジェクトHTMLは1件の申請に対する検討ID、受付情報、推奨結果、および決定要因となった制約を保持します。ベンチマークJSONは観測された検証項目を個別に保持します。これらの記録により、審査担当者は単独のスクリーンショットに頼るのではなく、どの実行が記述を裏付けているかを特定できます。
ダウンロードされたファイルは、サーバーの実行期限が切れた後も保持されます。ローカルワークスペースはメモリ内に最大16回の最近の実行のみを保持します。完了した実行は作成後1時間で期限切れとなり、サーバーの再起動によってクリアされます。本番環境での利用には、検証済み系統データ、永続的記録、アクセス制御、技術的権限、および本スクリーニングを超えて必要とされる検討事項に関する個別の決定が必要となります。
