-
Notifications
You must be signed in to change notification settings - Fork 0
Add telco_network_recovery template (multi-reasoner, private) #56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
6fc0967
Add telco_network_recovery template (multi-reasoner, private)
cafzal 33eb532
Regenerate v1/README.md index
cafzal d1b0c72
Add references/: full ontology + multi-reasoner runbook
cafzal 4e2abbe
Reframe runbook as recipe for (re)building the chain with agent skills
cafzal ef07cea
Drop runbook from PR 56 (PR 57 owns runbooks for all 4 multi-reasoner…
cafzal daa7207
Add reproducibility runbooks for five multi-reasoner templates (#57)
cafzal 0168098
Address PR review: switch per-step format to fenced-code blocks
cafzal 11ea21b
Remove three accidentally-committed _sf.py files
cafzal File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,151 @@ | ||
| # Runbook: Energy Grid Planning — Multi-Reasoner Walkthrough | ||
|
|
||
| ERCOT processes 10 hyperscaler interconnection requests (2,930 MW) against a 12-substation Texas grid. The chain forecasts substation load, finds structural bottlenecks, screens compliance, and produces a Pareto frontier across 5 budget levels — no single reasoner can answer this end-to-end. | ||
|
|
||
| ## The chain | ||
|
|
||
| ``` | ||
| ERCOT has 10 hyperscaler interconnection requests totalling 2,930 MW | ||
| on a 12-substation grid where DFW is the binding capacity bottleneck. | ||
| The chain produces a Pareto frontier across 5 budget levels — the knee at | ||
| $300M unlocks 5 DCs (1,500 MW, $264M net value) including xAI Colossus. | ||
|
|
||
| ───────────────────────────────────────────────────────────────── | ||
| STAGE 1 Predictive ──► Substation.predicted_load (12) | ||
| DFW: 1,100 → 1,700 MW (+54.6%) ── breaches | ||
| 1,600 MW capacity at 24mo. The only | ||
| substation predicted to breach. | ||
| ───────────────────────────────────────────────────────────────── | ||
| STAGE 2 Graph ──► Substation.betweenness (12) | ||
| (WCC/ Substation.grid_community (3 regions) | ||
| Louvain/ Substation.is_structurally_critical (3) | ||
| centrality) DFW, Houston, San Antonio dominate. 7 of 10 | ||
| DC requests target critical substations. | ||
| ───────────────────────────────────────────────────────────────── | ||
| STAGE 3 Rules ──► DataCenterRequest.is_compliant (2) | ||
| fails_capacity / fails_structural / | ||
| fails_low_carbon flags written back. | ||
| Only Crusoe (Midland) and Oracle | ||
| (Corpus Christi) pass all three. | ||
| ───────────────────────────────────────────────────────────────── | ||
| STAGE 4 Prescriptive ──► DataCenterRequest.x_approve (per InvestmentLevel) | ||
| SubstationUpgrade.x_upgrade (per InvestmentLevel) | ||
| OPTIMAL across 5 budget levels in one solve. | ||
| Knee $300M · 5 DCs · 1,500 MW · $264M net. | ||
| Google + Lambda never approved — DFW full. | ||
| ───────────────────────────────────────────────────────────────── | ||
| ``` | ||
|
|
||
| ## Workflow | ||
|
|
||
| ### 1. Build ontology | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-build-starter-ontology Build an ontology for grid infrastructure planning from the CSVs in data/ covering substations, generators, transmission lines, demand forecasts, data center requests, and substation upgrades. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| Concepts: `Substation`, `Generator`, `TransmissionLine`, `LoadZone`, `DemandPeriod`, `RenewableProfile`, `MaintenanceWindow`, `Customer`, `DataCenterRequest`, `SubstationUpgrade`, `DemandForecast`, `LoadHistory`, `DCAnnouncement` — bound to the bundled CSVs (12 substations, 10 DC requests, 18 transmission lines). | ||
|
|
||
| ### 2. Examine ontology | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-querying Show the ontology as a concept-relationship diagram and report row counts per concept. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| 13 concepts: 12 `Substation`, 15 `Generator`, 18 `TransmissionLine`, 8 `LoadZone`, 24 `DemandPeriod`, 12 `RenewableProfile`, 8 `MaintenanceWindow`, 100 `Customer`, 10 `DataCenterRequest` (2,930 MW total), 10 `SubstationUpgrade` ($630M total), historical `LoadHistory` and forward `DemandForecast` rows backing the predictive stage. | ||
|
|
||
| ### 3. Discover reasoner questions | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-discovery We have 10 hyperscaler interconnection requests against a 12-substation grid. Which to approve, which substation upgrades to fund, at what budget level? | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| Plan routing sub-questions to predictive, graph, rules, and prescriptive reasoners. | ||
|
|
||
| ### 4. Forecast substation load | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-predictive-modeling + /rai-predictive-training Forecast substation load growth over the next 24 months from historical demand, planned generator additions, and the DC request pipeline. Use the pre-trained model from the bundled DemandForecast table if available, or train fresh. Bind each substation's predicted peak load back to the ontology so the rules engine and optimizer can read it. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| `Substation.predicted_load` for all 12; DFW breaches at 1,700 MW vs 1,600 MW cap at 24 months (+54.6%). | ||
|
|
||
| ### 5. Find structural bottlenecks | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-graph-analysis Which substations are most critical to power flow based on grid topology? Flag the top 3 most structurally critical, surface any regional clustering, and persist the structural-criticality scores back to the ontology. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| 1 connected component, 3 Louvain communities (North Texas, West Texas, Gulf Coast); DFW, Houston, San Antonio flagged `is_structurally_critical`; 7 of 10 DC requests target critical nodes. | ||
|
|
||
| ### 6. Screen DC requests | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-rules-authoring Screen each data center request against three criteria: (1) substation must have enough capacity after predicted load, (2) substation's low-carbon (renewable + nuclear) generation share must meet the DC's low-carbon requirement, (3) substation shouldn't be one of the top-3 structurally critical. Which requests pass all three? | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| `fails_capacity` / `fails_structural` / `fails_low_carbon` + `is_compliant`; 2 pass (Crusoe, Oracle), 8 flagged. | ||
|
|
||
| ### 7. Approve DCs and fund upgrades | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-prescriptive-problem-formulation Decide which data center requests to approve and which substation upgrades to fund at $200M, $300M, $400M, $500M, and $600M investment levels. Maximize annual revenue across all five levels in a single solve. A request can only be approved if its substation has enough capacity after upgrades, and total upgrade spend at each level must stay within that level's budget. Consider all 10 requests — the Stage 3 compliance flags are informational, not hard filters. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| OPTIMAL MIP across 5 `InvestmentLevel` values in one solve; `x_approve` and `x_upgrade` written back per level. | ||
|
|
||
| ### 8. Read the frontier | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-prescriptive-results-interpretation Which data centers get approved, which upgrades are selected, and where's the biggest return on investment at each budget level? | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| Pareto frontier with knee at $300M (5 DCs, 1,500 MW, $264M net); marginal $995K/$M at knee, declining to $400K/$M by $600M; Google + Lambda never approved (DFW full). | ||
|
|
||
| ### 9. Persist solution concepts into the ontology | ||
|
|
||
| **Prompt** | ||
|
|
||
| ``` | ||
| /rai-ontology-design Add an InvestmentPortfolio concept indexed by InvestmentLevel that materializes the per-budget aggregates (approved-DC count, total MW, annual revenue, upgrade cost, net value, marginal value per added $M) and flags the knee point. | ||
| ``` | ||
|
|
||
| **Response** | ||
|
|
||
| Ontology gains an `InvestmentPortfolio(InvestmentLevel)` Concept (5 rows, one per budget) with `dc_count`, `total_mw`, `annual_revenue`, `upgrade_cost`, `net_value`, `marginal_per_m_to_next_level`, `is_knee_point`. All five frontier rows — $200M ($165M net) → $300M ($264M net, knee) → $600M ($395M net) — are queryable as ontology rather than stdout. | ||
|
|
||
| ## Data | ||
|
|
||
| Bundled CSVs in `data/`: 12 substations, 15 generators, 18 transmission lines, 10 DC requests (2,930 MW), 10 substation upgrades ($630M total), plus historical load and forecast tables. Full chain implemented in `energy_grid_planning.py`. | ||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker, but it seemed a little odd that these sections are fully wrapped in code blocks. I guess because it's sort of a "diagram"? It might look nicer as a markdown table instead.