Every data architecture eventually needs the same business in several shapes — an integration model, an analytics model, a semantic model for consumption — and today teams build each by hand. Because business meaning and implementation are coupled, every business change has to be re-translated into each model manually, and that translation is where most modeling errors happen.
Business Concepts in biGENIUS-X reduce that coupling: you describe the business once, in an architecture-neutral way, and derive the technical models from it — a model-driven alternative to source-driven modeling, where your source structures would otherwise shape the model. The workflow has five steps: describe the business meaning, derive the target model, review the derivation's decisions, map your sources (still manual, and among the hardest), and generate the code. This article covers the first three on a small example; Part 2 tests them on a harder one.
What a Business Concept is
A Business Concept captures an entity the way the business describes it: a client with an ID, a name, and an address; a product with a number, a name, and a category. Between them is a single connection: clients buy products. That is the entire input. There are no hubs, no satellites, and no surrogate keys, so the people who understand the domain can build or review this layer directly. Attributes can optionally be classified (as a business key, attribute, measure, or date) and assigned a general datatype. For this walkthrough, we deliberately left everything unclassified.
biGENIUS-X’s Convert to Model Objects turns this input into a model: pick a target architecture, optionally steer the derivation with a free-text prompt, review the proposal, and apply it. The key idea is the division of labor. The concepts define what the business is; the target defines how it is implemented. That separation is what makes the same description reusable for the next architecture.
Two Business Concepts and one connection on the modeling canvas: the entire input.
Deriving a Raw Vault model from Business Concepts
For the Raw Vault run, the prompt was a single sentence: “the connection between client and product needs to capture dates, as well as quantity and price.” It expresses what the graph alone cannot: that this connection is a business transaction with facts attached.
We could have modeled this differently. A third Business Concept — Sale, with date, quantity, and price as attributes — would carry the same information in the graph rather than in the prompt. Both approaches are valid, and that is part of the point. The graph and the prompt are two channels for the same business description, and the derivation works with whichever mix your modelers find natural. We used the prompt here to demonstrate it.
The result is a complete Data Vault model: Hub_Client and Hub_Product on the business keys, Link_Client_Product from the connection, Satellite_Client and Satellite_Product for the descriptive attributes, and Satellite_Client_Product as a link satellite holding the dates, quantity, and price from the prompt. We never told the tool which attributes were the business keys; it identified the client’s ID and the product’s number on its own. And because a link is always m:n-capable, the model can absorb a later change in business cardinality without remodeling.
Review & Confirm in biGENIUS-X for the Raw Vault target: reasoning per object on the left, the model preview on the right.
Deriving a star schema from the same concepts
Switch the target to Data Mart, adjust the prompt in the same way (the connection should become a fact table with measures and a date dimension), and the same two concepts produce a dimensional model: MartDimension_Client and MartDimension_Product, MartFact_Sales with sales amount and quantity as measures, and MartDimension_Date as a conformed date dimension. The stated grain is one row per sale of a product to a client on a date. The target changed; the business description did not.
The same Business Concepts with Data Mart as the target: dimensions, a fact table with measures, and a conformed date dimension.
Reviewing each derivation decision before it's applied
Before anything is added to your model, Review & Confirm shows a justification for every proposed object alongside a preview diagram. MartFact_Sales, for example, is described as the fact table for sales of products to clients, referencing the three dimensions and carrying the measures. You check the stated reasoning against the drawn structure. The workflow is deliberately simple today: apply the proposal as a whole, or go back, refine the prompt, and derive again.
On a textbook example, the justifications read like documentation. Their value becomes clearer when the derivation faces something genuinely difficult and gets part of it wrong before you apply. That is the subject of Part 2.
What AI-assisted data modeling still leaves to you
The automation takes over the repetitive modeling work, not the thinking. The quality of the output depends directly on the quality of the concepts, their connections, and the prompt. Together, these three form the definition of the business that everything else is derived from.
Two boundaries, stated plainly. Mapping your actual source systems onto the generated objects is still manual modeling work in biGENIUS-X today; the derivation designs the target, it does not infer your sources. And each derivation run creates new model objects — regenerating into an existing, already-mapped model is not yet supported, though an approach for it is in early development. Once the mappings are in place, biGENIUS-X generates the executable code for the target platform, for example a complete dbt project.
What remains is the claim this article set out to demonstrate: one business description, two technical architectures, with every derivation decision justified and reviewable before it is applied. The harder question is whether this holds when the business model becomes genuinely complex — role-playing relationships, difficult grain decisions, and history requirements. That is what Part 2 examines.
