Add data center one-shot extraction plugin - #536
Conversation
Add a schema-driven one-shot plugin covering local data center siting ordinances, including the extraction schema and plugin config, and register the extractor so the `data_centers` technology is available in the plugin registry. The 34-feature controlled vocabulary, the feature boundary rules, and the units convention are derived from the COMPASS data center ordinance research workbook, which hand-codes 147 feature rows across 22 jurisdictions in 10 states.
There was a problem hiding this comment.
Pull request overview
Adds a new schema-driven one-shot extraction plugin for data center ordinances under compass.extraction, wiring it into the existing plugin registration/import flow so it can be resolved and executed like the other one-shot technologies.
Changes:
- Added a new
data_centersone-shot plugin configuration (YAML) and extraction schema (JSON). - Registered the new extractor in
compass.extractionand re-exported it from the top-levelcompasspackage. - Added a new
compass.extraction.data_centerspackage initializer that constructs the schema-based plugin viacreate_schema_based_one_shot_extraction_plugin.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| compass/extraction/data_centers/plugin_config.yaml | Defines retrieval/heuristic and extraction-system prompt for the data centers one-shot plugin |
| compass/extraction/data_centers/data_centers_schema.json | Introduces the data centers extraction schema and feature definitions/instructions |
| compass/extraction/data_centers/init.py | Registers the COMPASSDataCentersExtractor via the schema-based plugin factory |
| compass/extraction/init.py | Imports the data centers extractor to ensure plugin registration |
| compass/init.py | Re-exports the data centers extractor from the top-level package |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| "size_tiering": [ | ||
| "Data center ordinances frequently set different standards for different size classes of facility. When they do, emit one row per class and record the jurisdiction's own class name in data_center_type.", | ||
| "Where one standard applies to data centers generally, emit a single row and set data_center_type to the term the ordinance uses for the use, or null when it uses none.", | ||
| "Do not merge tiered standards into a single row, and do not map a local class name onto another jurisdiction's taxonomy." | ||
| ], |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #536 +/- ##
=======================================
Coverage 63.98% 63.98%
=======================================
Files 78 78
Lines 7446 7446
Branches 755 755
=======================================
Hits 4764 4764
Misses 2523 2523
Partials 159 159
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The field description told the model to emit null where an ordinance
sets one standard for data centers generally, while the size_tiering
instructions told it to record the ordinance's own generic term for the
use. Align both on the latter, which matches the reference workbook:
none of its 147 feature rows leave the field blank, and the 17 untiered
jurisdictions record their own generic term ("Data Center", "Large Data
Center"). Null is now reserved for a provision that attaches no term to
the use at all.
| - database | ||
|
|
||
| collection_prompts: true | ||
| text_extraction_prompts: true |
There was a problem hiding this comment.
Did you find that including this improved extraction? If not, I would recommend leaving this out so that the extractor has access to unfiltered text
Adds the
data_centersone-shot plugin (schema + config) and registers the extractor, following the same shape as #522.The feature set is derived from the COMPASS DC Ordinance Research workbook (2026-08-16), which hand-codes 147 feature rows across 22 jurisdictions in 10 states. All 34 controlled terms from its "Feature List (DC)" tab are carried over as the schema's feature enum, so extracted rows can be compared directly against the hand-coded reference set.
Notes on the schema
data_center_typeoutput column. Data center ordinances routinely tier standards by facility size class — Birmingham sets separate residential setbacks for Hyperscale, Medium, and Micro. The schema adds adata_center_typefield so tiered rules emit one row per class, recorded in the jurisdiction's own vocabulary rather than a normalized taxonomy, matching how the workbook codes its Data Center Type column.$definitions. The workbook's feature descriptions carry explicit disambiguation ("Distinct from X, which…") for pairs a model will otherwise conflate: minimum lot size vs. maximum lot coverage vs. minimum vegetative cover; setback-residential vs. setback-property-line; buffer vs. equipment screening vs. fencing; and the three water features. These are encoded as IGNORE clauses.dBA day / night at receiving residential propertyfor a value of55 / 45. The schema requires positional correspondence between compound values and compound units, and instructs the model to keep such provisions in one row.$qualitative_featuresis limited to prohibitions/moratorium, on-site power technology, and decommissioning. District features are deliberately excluded, following the wind schema, since theirvaluecarries the district list.Verification
validate_plugin_configuration()at import;resolve_plugin("data_centers")resolves and yields 14 output columns.NOT_TECH_WORDS, whichKeywordBasedHeuristicstrips before counting matches.pytest tests/python/unit: 575 passed, 63 skipped.