Skip to main content
DataFramer runs on the models your own Databricks workspace serves, so your data never reaches another provider’s models. Two notebooks also read a sample of your data out of Unity Catalog, generate a larger dataset that keeps its structure and variation, and write the result back.

​
Running DataFramer on your Databricks models

A company admin saves a Databricks service principal in the DataFramer web app under Settings > Keys, provider Databricks: client ID, client secret, and the workspace URL. Databricks credentials need an Enterprise plan. DataFramer calls your models through the workspace’s Unity AI Gateway. Each model’s DataFramer id names its system.ai model service: databricks/system.ai.claude-sonnet-5 is system.ai.claude-sonnet-5. The service principal needs EXECUTE on those model services, which Databricks grants to all account users by default. Every DataFramer feature that calls a model then calls yours — discovery and tracking, root causes and remediation, calibrated judges, evaluations, API guardrails, Review Copilot, anonymization and data generation — and your Databricks account is billed for those calls. A company holds one model-provider credential at a time, so saving this one replaces an Anthropic or OpenAI key for everyone in it. Model pickers then offer only what your workspace serves: a model chosen elsewhere is substituted for the closest one it serves, and one it has no equivalent for is refused.

​
Generating data from Unity Catalog

Both workflows are notebooks you import into your Databricks workspace and run there. The single-file one can also run in Google Colab or a local Jupyter; the multi-file one reads and writes files in a volume, so it cannot. The notebook needs no Databricks credentials of its own. It authenticates as whoever runs it, and reads your DataFramer API key from a Databricks secret scope. Each workflow page lists the permissions that runner needs.