build.exascale/osint

Query the NYISO generator + load interconnection queue — New York ISO's public waiting line of projects that have REQUESTED to connect to the New York grid. Uniquely among ISOs, NYISO publishes a Load Projects tab — load interconnection requests (large-load demand), served as-reported — and since its 2026-07 edition tags each load request with its own `End-Use` class (`end_use`, e.g. DAT / DAT-AI / DAT-CM, served verbatim). Returns cited, project-level records with NYISO's full published structure across every lifecycle tab (nine tabs through 2026-06; seven since NYISO's 2026-07 restructure): summer and winter peak megawatts kept SEPARATE (`sp_mw` = SP, the max summer output; `wp_mw` = WP, the max winter output), the Load Projects tab's `peak_mw_load` with NYISO's own `end_use` class and `sis_bundle` study-batch code (both 2026-07 onward, null before), the as-reported study-phase code (`study_status_code` — NYISO's numeric key, labeled `S` through 2026-06 and `Project Status #` / `NYISO Status` since), the request `record_type` and `project_type`, the `type_fuel` codebook, the energy-storage capability, the NYISO load `zone` (A–K), location (`state`, `county`, derived `county_fips`, `point_of_interconnection`, `utility`), and lifecycle dates (`ir_date`, `last_update`, the milestone dates, and the Year/Qualifier `proposed_cod` kept verbatim). Group or filter by `application_status`, `sheet_name`, `state`, `county_fips`, `study_status_code`, `record_type`, `type_fuel`, `zone`, `utility`, `studies_available`, or `end_use`; filter `ir_date` by the `ir_date_from` / `ir_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"application_status": "ACTIVE", "type_fuel": "S"}` for active solar requests; `{"sheet_name": "Load Projects"}` for the load interconnection requests; `{"end_use": "DAT-AI", "application_status": "ACTIVE"}` for the load requests NYISO itself codes DAT-AI; `{"group_by": ["application_status"]}` for requested…

Query PJM's cluster/cycle service-request grid — the cluster view of PJM's interconnection process: the TC1/TC2 transition cycles (re-processing the pre-Order-2023 serial backlog) and the reopened steady-state cycles (C01+, the new intake). A SEPARATE PJM publication from the full New Services queue (query_power_interconnection_queue_pjm_v1) — richer per-project cluster detail; the two share rows and are never combined. Returns cited, project-level records with PJM's full cluster schema: the cluster `cycle` (TC1 / TC2 / C01 …) and `stage` (phase / decision point), the `developer`, requested megawatts (`requested_max_output_mw` = MFO, `requested_summer_mw`, `requested_winter_mw`), the realized built `in_service_mw`, long-term-firm transmission `ltf_mw`, location (`state`, `county`, derived `county_fips`), `fuel` and `project_type` as PJM reports them, the single `status`, and the phased System-Impact-Study report URLs + statuses. Group or filter by `cycle`, `stage`, `status`, `state`, `county_fips`, `project_type`, `capacity_or_energy`, `fuel`, `developer`, `transmission_owner`, or (group only) `is_hybrid`; filter `submitted_date` by range. Pass each parameter as a top-level key of `params` (flat). Example: `{"cycle": "C01", "status": "Active"}` for the live reopened-cycle pipeline; `{"group_by": ["cycle"]}` for counts by cluster cycle. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. The `requested_*` figures are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed/operating capacity — additive across distinct projects but a REQUESTED total only. PJM also reports `in_service_mw` (the realized built MW). For built/operating capacity use query_power_capacity_v1. PJM cluster grid only. This and PJM's New Service…

Query the PJM New Services (interconnection) queue — the public waiting line of projects that have REQUESTED to connect to the PJM grid (the mid-Atlantic RTO incl. Northern Virginia, PA, NJ, MD, OH, VA, WV and more). Returns cited, project-level records with PJM's full published structure: requested megawatts (`requested_max_output_mw` = MFO, `requested_summer_mw` = MW Capacity / summer net, `requested_winter_mw` = MW Energy / winter net), the realized built `in_service_mw` for completed projects, location (`state`, `county`, derived `county_fips`), `fuel` and `project_type` as PJM reports them, the single as-reported `status`, the study-document URLs and per-stage statuses, and lifecycle dates. Group or filter by `state`, `county_fips`, `status`, `project_type`, `capacity_or_energy`, `fuel`, `project_ac_dc`, `transmission_owner`, the study statuses, or (group only) `is_hybrid`; filter `submitted_date` by the `submitted_date_from` / `submitted_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"state": "VA", "project_type": "Generation Interconnection", "status": "Active"}` for active generation requests in Virginia; `{"group_by": ["status"]}` for requested MW and project counts by status. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. The `requested_*` figures are REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed or operating capacity — it is additive across distinct projects but is a REQUESTED total only. Filter `status` (Active / Withdrawn / In Service / Under Construction / …) to scope the queue; the full export is withdrawn-dominated. PJM also reports `in_service_mw` — the realized BUILT MW for in-service projects (a separate, built figure). For built/o…

Query the SPP generator interconnection queue — Southwest Power Pool's public GI Summary report, the waiting line of generation projects that have REQUESTED to connect to the SPP grid (the ~14-state central-US RTO: OK, KS, TX panhandle, NE, NM, MO, CO, ND, SD, AR, LA and more). Returns cited, project-level records with SPP's full published structure: the requested `capacity_mw` (SPP's headline `Capacity` figure) PLUS five other labeled MW columns SPP publishes — `max_summer_mw`, `max_winter_mw`, `requested_max_injection_mw`, `requested_nrd_mw`, `nameplate_capacity_mw` — served separately and NEVER blended; the `generation_type` (Wind / Solar / Battery/Storage / Thermal / Hybrid / Hydro — SPP encodes hybrids natively as `Hybrid`, so no is-hybrid is invented) and free-text `fuel_type` (slash-delimited combos like `Solar/Storage` kept whole); the study `current_cluster` (e.g. `DISIS-2024-001`, `Surplus`, `RTOE Transitional Cluster`) and regional `cluster_group` (`01 NORTH` … `05 SOUTHWEST`); the transmission owner `to_at_poi`; the `service_type` (`ER/NR`, `ER`, `NR`); the `substation_or_line`; and the lifecycle dates (`request_received`, `in_service_date`, `commercial_operation_date`, `date_withdrawn`). Group or filter by `native_status`, `generation_type`, `fuel_type`, `service_type`, `current_cluster`, `cluster_group`, `to_at_poi`, `county_fips`, or `state`; filter `request_received` / `commercial_operation_date` by their `_from` / `_to` ranges. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"native_status": "DISIS STAGE", "generation_type": "Solar"}` for solar in the DISIS study stage; `{"native_status": "DISIS STAGE", "group_by": ["state"], "order_by": "capacity_mw", "top_n": 5}` for the active study pipeline's biggest states by requested MW. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_e…

Query the MISO generator interconnection queue — the public waiting line of projects that have REQUESTED to connect to the MISO grid (the 15-state Midwest/South footprint). Returns cited, project-level records: requested megawatts (net summer / net winter), location (`state`, `county`, derived `county_fips`), fuel and technology as MISO reports them, three independent status dimensions (`application_status`, `study_phase`, `post_gia_status`), and queue / withdrawn / in-service dates. Group or filter by `state`, `county_fips`, `application_status`, `study_phase`, `post_gia_status`, `fuel_type`, `facility_type`, `service_type`, `study_group`, `study_cycle`, or `is_hybrid`; filter `queue_date` by the `queue_date_from` / `queue_date_to` range. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"state": "IN", "fuel_type": "Solar", "application_status": "Active"}` for active solar requests in Indiana; `{"group_by": ["application_status"]}` for requested MW and project counts by status. Returns JSON aggregates with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of`, and a `source_row` verifiable with get_source_evidence_v1. This is REQUESTED capacity, not built: historically the large majority of queued megawatts withdraw before they are built. NEVER read a requested-MW total as installed or operating capacity — it is additive across distinct projects but is a REQUESTED total only. Filter `application_status` (Active / Withdrawn / Done) to scope the queue; the full export is withdrawn-dominated. For built/operating capacity use query_power_capacity_v1. MISO only — never summed, deduped, or compared across ISOs into a national total (each ISO's methodology, inclusion rules, and withdrawal rates differ). For the PJM interconnection queue (the mid-Atlantic RTO incl. Northern Virginia) use query_power_interconnection_queue_pjm_v1 (or query_power_interconnection_queue_pjm_cycle_v1 fo…

Query accepted native-XBRL FERC Form 1 large-steam plant facts. Returns one separately cited XBRL fact per respondent, report year, raw plant name, and source concept: installed capacity, net generation, plant-cost balance items, fuel expense, and individual operation and maintenance lines. Values and units are as filed; nominal dollars are not adjusted, allocated, divided by generation, or combined into a derived O&M total. Plant names remain raw strings with no EIA ID matching. Every value verifies against its exact archive member, XBRL fact ID, context, concept, and SHA-256. Coverage is the Form 1 filing population, not the full fleet. ERCOT-only merchant entities largely do not file, so ERCOT coverage is partial and plant absence means not present in served filings—not zero. `ercot_relevance=true` is a one-call filter based only on the respondent's raw states-served disclosure mentioning Texas; it is not a plant-location claim. v0 covers accepted native XBRL (report year 2021 onward) and the large-steam schedule including nuclear; hydro, pumped storage, migrated historical XBRL, and Visual FoxPro-era filings are explicitly outside v0.

Query verified ERCOT wholesale electricity prices — ERCOT's Day-Ahead Market Settlement Point Prices ($/MWh, EMIL NP4-190-CD), the price cleared the day before each operating day at every ERCOT (Texas) settlement point, served hourly. Returns cited prices for each (`settlement_point`, `delivery_date`, `hour_ending`): the per-hour `price_usd_per_mwh` in detail records, plus `avg_price_usd_per_mwh`, `min_price_usd_per_mwh`, and `max_price_usd_per_mwh` over the result scope. Each `settlement_point` is one of ERCOT's locations — a trading Hub (e.g. `HB_NORTH`, `HB_HOUSTON` — the regional benchmark prices), a Load Zone (e.g. `LZ_HOUSTON`), a Resource Node (one generator's connection point), or a DC-tie — and `settlement_point_type` carries ERCOT's OWN verbatim classification code (`HU`/`LZ`/`RN`/`LZ_DC` and finer codes) so an agent can tell a regional benchmark from a single-plant node. Filter or group by `settlement_point`, `settlement_point_type`, `hour_ending`, or `delivery_date`; filter a date window with `delivery_date_from` / `delivery_date_to`, or one day with `delivery_date`. Pass each parameter as a top-level key of `params` (flat — not nested). Example: `{"settlement_point": "HB_NORTH", "delivery_date": "2026-06-20", "group_by": ["hour_ending"]}` for the North hub's 24 hourly day-ahead prices; `{"delivery_date": "2026-06-20", "group_by": ["settlement_point_type"]}` for the average price by location type. With no date filter the result defaults to the latest delivery day with prices (it does not scan all history); served delivery coverage begins 2014-05-02 from ERCOT's official Data Access Portal archive. Historical settlement-point names remain exactly as published, and names absent from the current pinned type list have a null type rather than being rewritten. Returns JSON with citations and optional row-level records when `include_records` is true; every value carries `source`, `as_of` (the delivery day), and a `source_row` verifiable with get_source_eviden…

Query ERCOT's actual hourly wind and solar output in MW, system-wide and by published region. Actual is never substituted with forecast/capability and is not accreditation, firm MW, or capacity factor.

Query verified U.S. annual retail electricity sales — billed MWh, revenue, and customer counts — by utility, state, and customer sector from EIA-861. Use this for "who sold how much power to whom" questions at the annual utility×state×sector grain: filter or group by `data_year`, `state`, `sector` (residential / commercial / industrial / transportation), `part`, `service_type`, `ownership`, `ba_code`, `data_type`, `eia_utility_id`, or `utility_name`. Pass filters inside the `params` object. Returns JSON aggregates with citations down to the exact stacked sector/measure cell, and optional row-level records when `include_records` is true. Defaults keep totals faithful: the in-row `total` sector block is excluded unless named explicitly (it duplicates the four sectors); EIA's state-level Adjustment (99999) and Withheld (88888) sentinel rows stay in state totals but are auto-excluded from any utility-keyed query; territories are excluded unless `included_in_default_us_metrics` is false. A result mixing service types carries a `service_type_mix` note quoting the file's own law — revenue sums Parts A,B,C,D but sales/customers sum A,B,D only (Part C delivery re-counts Part B energy). History spans data years 2016–2024, one annual census per year, each its own vintage. Reach an earlier year through `as_of`, not `data_year`: `as_of` resolves to the newest census at or before it (so `as_of` 2018-06-01 — or just 2018 — returns the 2018 census) and the response echoes that resolved `as_of`. `data_year` only filters within the resolved vintage, so `data_year` 2018 under the default `as_of` (latest = 2024) returns an empty scope, not 2018; the default serves 2024, a multi-year trend is one query per year, and an `as_of` before 2016 is refused, naming the floor. Does not determine hourly or peak load (sales are billed MWh over a year — use power.demand), facility-level or data-center-specific load, county-level detail, average retail price (cents/kWh — deferred), the ~1,700 smal…

Query the verified share of US manufacturing plants USING industrial robots — plus workers exposed and robotics capex — from the Census Industrial Robotic Equipment product (the first official federal robotics-adoption statistics). Use this for "are factories actually adopting robots" questions — the INSTALLED-BASE reading the import data cannot see. Serves the percent of plants with robots and the percent of employees at plants with robots (both published as FRACTIONS of 1: 0.121 = 12.1%), Census's demeaned variants, and capital expenditures for robotic equipment ($1000) — by manufacturing industry (`naics_code`, 2/3-digit), by `state`, and by `plant_size` band. Filter by `edition` ("asm_2018_2021" = the ASM annual series; "ec_2022" = the 2022 Economic Census), `table` (the workbook sheet — exactly one of: "Percent of... NAICS", "Percent of... Geo", "Percent of... Geo demean", "Robot adopters vs not", "Robot adoption and plant size", "CapEx... NAICS", "CapEx... Geo", "CapEx and plant size"), `data_year` (2018-2022), `naics_code`, `state`, `plant_size`, or `geo_area_name` ("United States" for the national row). Group by any of `edition`, `table`, `naics_code`, `naics_title`, `state`, `plant_size`, `data_year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"table": "Percent of... Geo", "data_year": 2022, "group_by": ["state"], "order_by": "avg_pct_plants_with_robots", "top_n": 10}` for the most-automated states; `{"table": "Percent of... NAICS", "edition": "asm_2018_2021", "naics_code": "336", "group_by": ["data_year"]}` for transportation-equipment adoption over the ASM years. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites its exact workbook cell-group, re-verifiable via get_source_evidence_v1. THE ENGRAVED BOUNDARY: the two editions are NEVER spliced into one trend — the 2022 Economic Census reaches the small-…

Query verified U.S. monthly IMPORTS of INDUSTRIAL ROBOTS — customs value (USD) AND unit counts (number of robots) — by country of origin, from the U.S. Census Bureau's International Trade data. Use this for "how many robots is the US importing, from whom, and what are they worth" questions — the only high-frequency official U.S. robotics series. Covers the nomenclature's two robot-specific HS-10 codes, served as the `commodity` dimension: "8479500000" (INDUSTRIAL ROBOTS, NESOI — multipurpose: welding/assembly arms, AMRs) and "8428700000" (INDUSTRIAL ROBOTS FOR LIFTING, HANDLING, LOADING OR UNLOADING — created by HS 2022; no data before 2022-01, a structural absence, never zero). Filter by `commodity`, `country` (the verbatim Census name, e.g. "JAPAN", "CHINA", "KOREA, SOUTH"), `cty_code` (the Census country code), `country_level` ("total" = the all-countries TOTAL, "country" = an individual country, "grouping" = a Census bloc/continent like ASIA / APEC / EU), `year`, `data_month` (one month, ISO first-of-month e.g. "2026-04-01") or the `data_month_from`/`data_month_to` range. Group by any of `commodity`, `country`, `cty_code`, `country_level`, `data_month`, or `year`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"commodity": "8479500000", "country_level": "country", "group_by": ["country"], "order_by": "general_quantity_units", "top_n": 5}` for the top robot-supplying countries by unit count; `{"country_level": "total", "group_by": ["data_month", "commodity"]}` for the national trend per code. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every value cites the exact Census response row, re-verifiable via get_source_evidence_v1. Measures: `general_value_usd` / `consumption_value_usd` (customs value) and `general_quantity_units` / `consumption_quantity_units` (Census's "NO" unit of measure = the number of robots). NEVER SUM acro…

Query the verified FCC satellite licensing docket — every space-station (SAT) filing in the FCC's own daily IBFS database dump, back to the 1960s — by applicant, application type, status, and filing date. Use this for "who is authorized to operate what in orbit, what has been filed, and where does each filing stand" questions — the satellite-buildout licensing pipeline. Each filing carries the FCC's public filing key (`file_number`, e.g. "SATLOA2025061800149"), the `callsign` (e.g. "S3069" = SpaceX Gen2), the application type and status in the FCC's OWN vocabulary — verbatim codes plus the FCC's own decode text from the same dump vintage (`app_type_code` "LOA" = Launch and Operating Authority, "STA" = Special Temporary Authority, "MOD" = Modification; `status_code` "A/C" = Action Complete, "ATPN" = Action Taken Public Notice — codebooks in describe) — the full lifecycle date family (filed / granted / expires / …), the FCC's plain-English `description` of the filing, and the applicant identity (`applicant_name`, the FCC's verbatim registrant, e.g. "Space Exploration Holdings, LLC"). Filter by `applicant_name`, `app_type_code`, `status_code`, `callsign`, `file_number`, `state` (the APPLICANT's address state), `applicant_country`, `report_period` (the filing date) via `report_period_from`/`report_period_to`, or `date_grant`/`date_expire` ranges. Group by any of `applicant_name`, `app_type_code`, `status_code`, `state`, `applicant_country`. Pass each parameter as a top-level key of `params` (flat — not nested under a `filter`, `filters`, or `where` key). Example: `{"applicant_name": "Space Exploration Holdings, LLC", "group_by": ["app_type_code"]}` for one operator's filing mix; `{"report_period_from": "2020-01-01", "group_by": ["applicant_name"], "order_by": "source_record_count", "top_n": 10}` for the most active filers of the 2020s. Returns JSON aggregates with citations and optional row-level records when `include_records` is true — every record cites its exact ro…