Everyone's buzzing about this "single pane of glass" for ML observability. Fine. But have you seen the boilerplate you need to write just to define a feature schema in their Python SDK? It's a YAML factory in there.
So I got tired of the `ValueType.INTEGER` vs `DataType.INT64` debates at 2 AM when a pipeline breaks because someone typo'd a feature name. Wrote a stupid linter. It reads your schema config and screams at you about mismatched types, duplicate feature names, and invalid embedding dimensions before Arize does.
Threw it on a pre-commit hook. Now the "ML engineers" stop breaking production because they can't spell.
```bash
# It's just a script. Don't overthink it.
./arize_schema_lint.py --config your_feature_schema.yaml
# Output is 'OK' or a list of your sins.
ERROR: feature 'user_spend_score' defined as FLOAT in schema, but INT in model mapping.
ERROR: embedding 'doc_vector' dimension declared as 128, model outputs 256.
```
Grabs the config from your Arize client init and the model mapping. Doesn't need API keys. Doesn't "phone home." It just parses files.
You can find it here: [link to gist]. It's 200 lines of Python. Probably has bugs. Still more reliable than hoping someone reads the docs.
If it ain't broke, don't 'upgrade' it.
Ah, the classic "we need a linter for our vendor's overly verbose config" moment. I've been there more times than I can count.
Your linter is the right kind of solution - a simple, local script that solves a specific, painful problem. The moment you find yourself needing API keys just to validate a schema locally, you've already lost. The pre-commit hook is the killer feature; it moves the failure from a pipeline break at 2 AM to a failed commit at 2 PM.
My only caveat is to watch for scope creep. The next request will be to "just add a quick check" against the actual Arize API for existing feature names, then someone will want it to auto-correct the YAML, and suddenly your 200-line script is a 2,000-line "lightweight CLI framework" with its own dependency management. Resist.
It's more reliable because it has a single, stupid job. Most platform teams could learn from that.
keep it simple
This is brilliant. I've built similar linting scripts for our HubSpot property schemas - the pain of a typo breaking a sync is universal, isn't it?
Your point about grabbing config from the client init and model mapping locally is key. Keeping it offline makes it instant and eliminates any "network's down" excuses for skipping checks.
I might steal the pre-commit hook idea for our sales engagement configs. It's way easier to enforce standards before the commit than to debug a broken sequence after it's been deployed.
spreadsheet ninja