330 Settings, Not Vibes
Generation Is Governed By A Real Settings Catalog, Not Guesswork
July 13, 2026
Ask a code generator to target Snowflake instead of SQL Server and you find out fast whether its output is governed or improvised. Improvised output looks fine in a demo and falls apart in production: the hash column comes out as the wrong type, the warehouse never auto-suspends, the schema names follow a convention nobody agreed to. You end up hand-patching the generated code, which defeats the point of generating it.
BimlFlex takes the opposite approach. What the generator emits is governed by a settings catalog: a defined surface of named, typed options that decide how your model becomes platform-specific code. Change the target, the relevant settings change with it, and the output is correct for the platform by configuration rather than by hope. This is the quiet machinery behind "one model, many targets." It is worth looking at directly.
A surface, not a guess
The catalog is large and deliberate. In the shipped 2026 build there are 330 settings spanning 24 categories. The biggest categories are the ones you would expect from a tool that automates a data warehouse:
Data Vault: 45
Databricks: 37
Azure Storage: 24
Snowflake: 22
Fabric: 16
Staging: 16
Naming: 14
Hashing: 12
A note on that Data Vault figure, because counts depend on how you slice them. The product folds Data Vault naming options into the Data Vault category, so the catalog reports 45 Data Vault settings and 14 general Naming settings. The documentation sometimes splits naming out separately and arrives at different numbers. Same settings, different taxonomy. When you see a count, ask which taxonomy produced it. The figures here are the product's own.
The point of naming a number at all is not the number. It is that the behavior is enumerated. There is a known, finite set of decisions the generator can make, each one a setting you can read, set, and audit. That is what makes the output reviewable instead of mysterious.
Two axes that filter the catalog
Not every setting applies to every model. The catalog is filtered along two axes, and that filtering is what keeps the surface manageable instead of overwhelming.
The first axis is the integration template: the orchestration runtime you are generating for. The choices are SQL Server Integration Services, Azure Data Factory, Azure Databricks, Fabric Data Factory, and Fabric Lakehouse. The second axis is the target system type: where the data actually lands. That list is longer and includes SQL Server, Azure SQL Database, Synapse, Snowflake, Databricks, Fabric SQL Database, Fabric Data Warehouse, Fabric Lakehouse, Delta Lake, Oracle, Teradata, PostgreSQL, and MySQL.
Every setting carries its own applicability on both axes. A setting can apply to all templates and all targets, or it can be pinned to one. SnowflakeWarehouse, SnowflakeAutoSuspend, and SnowflakeFileFormat only surface when the target system is Snowflake. DatabricksUseUnityCatalog, DatabricksUseLiquidClustering, and DatabricksOptimizeTable belong to the Databricks template. They are not relevant when you are emitting T-SQL for SQL Server, so they do not clutter the picture there.
This is why switching targets is a configuration change rather than a rewrite. The model, your entities and their relationships, does not move. The settings that are in scope shift to match the platform you picked, and the generator reads that filtered set when it produces output.
The same decision, expressed per platform
Some settings are cross-cutting on purpose. Hashing is the clearest example, because hashing is the same idea everywhere but the implementation differs by engine. The catalog keeps the decision in one place and lets the generator express it correctly per platform.
Take two settings from the Hashing category that apply across templates and targets:
HashAlgorithm string e.g. MD5 / SHA1 / SHA2_256 / SHA2_512
UseSqlCompatibleHash boolean match SQL Server hashing semantics on other engines
HashAlgorithm is one choice you make once. UseSqlCompatibleHash governs whether the hash an engine produces is byte-compatible with the way SQL Server would have produced it. If you are migrating a warehouse from SQL Server to a lakehouse and you need keys to reconcile across both during the cutover, that single boolean is the difference between matching keys and a silent mismatch. You are not editing generated SQL on each platform to force agreement. You set the intent, and the platform-specific emitter honors it.
That separation, intent as configuration versus implementation as generated output, is the whole design. It is also why custom logic has a home that does not fight the catalog. When you need behavior the settings do not cover, you reach for column-level customization rather than hand-editing output, as covered in creating custom column-level transformations in BimlFlex. The catalog handles the platform-correct defaults; customization handles the exceptions.
Why this is a governance feature
It is tempting to read a settings catalog as a convenience, a way to avoid typing. It is more than that. A defined, named, typed configuration surface is a governance artifact, in the same family as the metadata-driven patterns we have written about in scalable data architectures.
Three things follow from settings being explicit. They are reviewable: a setting has a name and a value, so a code review or an audit can ask "why is UseSqlCompatibleHash off here" and get a real answer instead of archaeology through generated files. They are consistent: the same setting at the project scope governs every object that inherits it, so naming conventions and hashing rules do not drift object to object the way hand-written pipelines do. And they are portable: because the configuration lives in metadata, it travels through source control and CI/CD with the rest of the model, which is the discipline we walk through in metadata-driven automation.
Compare that to the alternative. In a hand-built estate, the rules that govern how code is generated live in people's heads and in the code itself. Onboarding means reading thousands of lines to infer the conventions. Here the conventions are the catalog. A new engineer reads the settings, not the output, and knows how the warehouse will be built. That is how a team takes on more without taking on more people, which is the argument in do more with the same team.
What to take from it
The settings catalog is the layer most people skip past on the way to looking at generated code, and it is the layer that makes the generated code trustworthy. The output is correct for your platform because a named, typed, filtered set of decisions made it correct, and you can see every one of them.
So the next time you point a generator at a new target, ask the question that separates governed automation from a glorified template: when I switch from SQL Server to Snowflake, what exactly changes, and can I read it? With BimlFlex the answer is a filtered slice of a 330-setting catalog, each entry visible, typed, and owned by you.
