Does Model One connect to our databases?
No. It never connects to a source system or a warehouse and stores no database credentials. It produces DDL, migration scripts and a dbt project, and your team runs them with its own tools.
Is the concept model a separate model?
No, and that is deliberate. A concept is a business-level view over the logical model: it stands for a subject area, is drawn on the Full Model view, and its dashed lines are computed from the relationships beneath it, so they cannot drift from the entities. Concepts carry a name, a definition and named connections, not attributes or cardinality. If your concept model is finer-grained, with business concepts joined by relationships and their cardinalities, draw those concepts as entities in a subject-area submodel and show that submodel in Name + Definition mode. The diagram then shows names, definitions and relationships without attributes or datatypes, and the same entities get their attributes and keys during technical design.
What about the reporting layer and Power BI?
Model One designs and generates the warehouse and the marts your reports read, including SCD2 dimensions and Aggregate steps. It does not build Power BI semantic models, measures or reports: those stay in your BI tool. You can still document a report or BI tool in a Flow as an external system.
We already run a warehouse and model it in ER/Studio. Where do we start?
Import your ER/Studio DM1 files, which bring entities, keys, submodels, physical names and types, data sources and Data Lineage diagrams, or paste the warehouse's DDL to build a logical and a physical model with native types. Save that as a version and record it as what production runs, and the next change can ship as a migration.
Does it handle SCD2 and Data Vault?
With building blocks, not a generator. Historize loads type-2 dimensions, or insert-only satellites, from a business key and a history mode per column, and Hash builds hub and link keys and change hashes. You model the hubs, links and satellites yourself; these steps load them.
How does the dbt project fit our CI pipeline?
It is a plain dbt project for dbt-fabric or dbt-sqlserver, downloaded as a .zip with a README listing what to review. Commit it to your repository and run it from your CI like any dbt project. When the model changes, export again: the export always regenerates the whole project from the current model, so the change arrives as an ordinary diff in your repository, and Merge loads add new columns to their existing target tables on their own. Tables whose keys the database assigns, and every Historize target, must be created from the generated DDL before the first dbt build.
Can business owners take part without editing?
Yes. Give them the Viewer role: they can read every module, the concept map included, and export an HTML report, but cannot change anything. The HTML report opens in any modern browser, so people without an account can read it too; it carries the logical model, Flows, dictionary and DDL, but not the concept map, which is reviewed in the app.
Where does our data live, and is it sent anywhere?
Model One is installed in your own Azure subscription, in the region you choose, and stores what you model, never the rows in your databases. OneAssist is optional: once it is set up, prompts and model context are processed by Azure AI Foundry in your subscription. Its web search, which queries the public web, is on by default and can be switched off only when the agent is created.
