Constraint Shift Factors (Estimated)

This is what answers 'which nodes drive this constraint' and 'which constraints is this node exposed to'. THE DAY-AHEAD MARKET, not real time: this estimate is fitted to day-ahead marginal values against day-ahead nodal congestion and it describes day-ahead congestion. It covers PJM's day-ahead binding constraints with their contingency over roughly 14,450 pricing nodes. PJM names no terminals, so from_station and to_station are always empty. PJM's real-time shadow prices ARE ingested now (pjm_rt_marginal_value, pjm_transmission_limits) and a real-time estimate is fitted separately; it is not this dataset and is not available here, so do not answer a real-time PJM question from this one. shift_factor is in the ISO's orientation — POSITIVE means an incremental MW injected at that node increases loading on the constraint and the node is paid below system lambda while it binds; NEGATIVE means generation there relieves the constraint and earns a premium. These are ESTIMATES recovered from the price identity LMP = energy - sum(shift_factor x shadow_price), not a published PTDF matrix. They are measured RELATIVE TO THE MARKET'S REFERENCE — the identity yields SF(node) - SF(reference), so a single absolute value should be quoted as 'relative to the system reference' rather than as the node's PTDF, while DIFFERENCES between nodes are exact because the reference term cancels. Three further differences from a published matrix: they describe a NODE (a generator at that node inherits its location's value, and two units at one node are indistinguishable), they reflect the topology actually in effect across the window including outages rather than a stated base case, and every one carries a std_error from a 200-draw block bootstrap that resamples whole days. Read std_error before quoting shift_factor: an estimate whose absolute value is not at least twice its standard error is not distinguishable from zero. estimation_status says why a row has no number — 'thin_support' (in the fit, so it is controlled for, but under 12 binding intervals or under 3 distinct binding days), 'no_support' (under 3 binding intervals; not a regressor), or 'collinear' (it bound in lockstep with another constraint, so the two cannot be separated). Where from_station and to_station are populated they identify the monitored element and are NOT the constrained direction — the sign of shift_factor is what says which way. Every read must pin computed_at to one run, and must resolve that run through the companion atg.<iso>_constraint_sensitivity_runs ledger rather than off max(computed_at) here — rows are written in blocks that all carry the new timestamp, so an unfinished or abandoned run would otherwise look like the newest. Mixing runs averages a node across different network topologies.

Query contract

Resolve the latest run through the completed-run ledger, never off the sensitivities table: computed_at = (SELECT max(computed_at) FROM atg.pjm_constraint_sensitivity_runs). A run writes its rows in blocks that all carry the new computed_at, so max(computed_at) on atg.pjm_constraint_sensitivities can name a run still being written, or one that died halfway. Then filter estimation_status = 'estimated' and require BOTH abs(shift_factor) >= 2 * std_error AND std_error <= 0.25 before quoting or ranking a value.

Analysis rules

Never aggregate across computed_at. Two runs are two estimates of a network that may have changed between them, and averaging them describes neither.Rank nodes by abs(shift_factor), not by shift_factor: the sign says which side of the constraint a node is on, and the magnitude is the exposure. Report the sign alongside the rank, and describe such a ranking as exposure RELATIVE TO THE MARKET REFERENCE — see the caution; it is not a reference-free physical ordering.

Interpretation

These are estimated NODE sensitivities recovered from prices, not a published PTDF matrix. A generator inherits its settlement point's value and two units at the same node are indistinguishable here.shift_factor is measured RELATIVE TO THE MARKET'S REFERENCE, because that is what a congestion component is: the identity gives SF(node) - SF(reference), not an absolute shift factor against a named slack bus. Measured across ~1,118 ERCOT settlement points, the cross-sectional mean per constraint is within 0.005 of zero, which is a distributed reference. Say 'relative to the system reference' when quoting one absolute value; do not describe it as the node's PTDF.

Related analysis

which nodes a binding constraint moved and congestion attribution · Join constraint_name to monitored_facility and contingency_name to contingency_facility. Congestion at node i from constraint c in an interval is shift_factor * shadow_price on the published, negative shadow_price. Both sides are the day-ahead market.the congestion component this table was fitted to · location_id is the same settlement-point identifier. congestion_usd_mwh is the left-hand side of the regression these coefficients come from.

Download

Query it in SQL, download it, or read it with an API key. Download data

MCP

Connect an MCP client and load the contract with describe_data before calling query_data.PJM MCPAPI reference

HTTP endpoint

POST /api/v1/datasets/pjm_constraint_sensitivities/query

Full history

Delivered to Snowflake, Databricks or your own storage on a schedule by Data services.

More coverage

Request data coverage

Complete

100.0%

Gap days

0

Days with data

45