A new semantic model can be designed for you in a chat with the Warehouse Builder Mind: you answer one batch of questions, approve one design card, and an empty model is created with the choices you approved. This page covers that design stage, the checks that must pass before the model is created, and the handover to Model AI; the build that fills the model follows, and is on Model Builder.
Ask for a design
Open a chat with the Warehouse Builder Mind. Admins reach it, and so do members of its permission groups who hold View Warehouse Objects and Create/Edit Warehouse Objects; see Warehouse Builder and Lake Builder. Asking for a model needs the Create DataPrism Semantic Models and Use DataPrism AI permissions, and approving the design needs the admin role. See Who can do what in DataPrism.
Describe the model you want: which questions it should answer and which charts it should serve. You can also type /star-schema, whose description reads "Use the Star schema skill: design and build a semantic model"; it joins your message as a Star schema pill.
The chat loads the Star schema skill, the playbook the builder follows, and the transcript shows a chip reading Using: Star schema v1. When the builder loads a deeper part, the chip adds it, for example Using: Star schema v1 · Warehouse Builder steps; a chip for a skill already in the chat reads Star schema v1 already loaded. The tooltip reads "A DataMind playbook shipped with this platform version".
The builder explores the Lake and Warehouse tables it needs, then asks its questions in one batch. Answer them in the chat.
It proposes one design card, headed Semantic model design. Review it, set your choices and decide it, as below.
Note
The design card is the single consent for the build. It carries the owner role, the data mode, the history depth, the plan policy, the change policy and the control totals, and nothing is built from the design until you approve it. The card asks in every acceptance mode: a chat set to apply changes automatically still stops for it. It arrives on its own, and the chat resumes when you decide.
What the builder asks you first
The builder asks once, and only what it cannot work out itself. Each question offers concrete choices, and you can always type your own answer. The batch covers:
the questions and the charts it proposes;
the owner role, with admin offered last;
the data mode, only when a chosen column carries a personal data domain: Tokenized (recommended) or Clear values;
the history depth, each option with its numbers for daily history, the monthly aggregate, partitions, disk, backfill time and a chart speed chip;
for a plan or budget, its source, grain, versions and which version is current;
two or three control totals from a report you trust, for example a sales total from a monthly report.
When one model cannot serve everything
A DataPrism model has exactly one fact table, and a dashboard reads one model, so some questions cannot share one model. Before building, the builder says so in the card's What this model cannot serve section, which starts "These questions cannot be answered correctly by one semantic model:", lists the questions and recommends the models and dashboards to build instead. Each leftover entry is grouped as Needs a warehouse change, Needs a separate model or Not possible in DataPrism today, with the reason and a Recommendation:.
What a design may hand over
One fact source: the fact table itself, or one handover view of it, never both. The rest of the design hands over the dimensions the fact joins to and the helper views it lists.
A handed-over view reads at most 20 objects of the design, and the model reads only what the design hands over.
Each object is marked as new, existing or changed. New objects are built by the builder; an object marked as new that already exists in the Warehouse is refused, because the platform does not adopt a table that this conversation did not create.
Two objects cannot share a name, and two handed-over objects cannot both use one business column name: Two group-bys of one name fail: prefix them.
The limits on one design
Objects: 1 to 60, each with 1 to 200 columns.
Relationships: up to 60, each going from the fact source to a handed-over dimension.
Charts: up to 20, with up to 3 history options to choose from and up to 10 items under What this model cannot serve.
A design that outgrows its size budget is refused with the limit named; the builder shortens it or splits the model.
Read the design card
The header names the model and its description, shows who asked with Requested by, and carries a session id you can copy with Copy session id. While the card waits for you, its status pill reads Needs your approval; after you decide, it reads Approved or Rejected. The sections below it, in order, each expand and collapse:
Goal and grain: what the model is for, the grain sentence ("One row = ..."), a chip for the fact type (Transaction fact, Periodic snapshot, Accumulating snapshot, Event fact, Factless fact or Aggregate fact), the Business date and example questions.
Diagram: the design as a diagram, with Copy diagram source, and the relationships listed below it.
Objects: every object, grouped as Fact, Dimensions, Views the model reads and Other, with chips for its kind, its status and Model reads it on a handed-over view. A row dimmed as "only with option" or "not built for this choice" is outside the build as chosen.
Your choices: the owner role, the personal data mode and the history depth, plus the row-level security warning when there is one.
Type, plan and versions: when the design has a Type column or a plan, the Type values, the plan's policy sentence, the Current version: rule and any plan limits.
Charts and cost: the charts the model will serve, with Rows read, Partitions, Joins, Statements and a speed chip: Fast, Moderate or Slow.
What this model cannot serve: as described above.
Backfill and proofs: figures for Sample load, Sample rows, Full history, Full rows and Full load time, the sentence "The sample is the last 3 closed months plus this month. Full history loads only after the model is finished.", and the Control totals the tests must match table.
Change policy: two lists, I may do without asking and I will ask first, with entries such as Add a column and Change the grain.
Set the choices. The Owner role options are the roles the requester holds; admin is offered only when nothing else fits, and an admin-owned model ignores warehouse row-level security unless row-level security is added on the model. The data mode appears only when the design needs it, and each option states how many personal data columns it covers. History depth shows each option with its numbers.
If the red Row-level security will not apply callout appears, tick I understand. Changing the owner role clears the tick, so tick it again after you settle on a role.
Click the approve button. Its label carries your choices: Approve · owner role · data mode · history option. To send the design back instead, click Reject with a note, write why and confirm; the note stays on the card as Rejection note:, and the builder can propose a corrected design.
A few things to know:
An admin other than the requester can decide the card, but the model is created only when the requester continues: "Approving or rejecting continues this conversation as you. The model is created only when name continues it."
Once you decide, the card locks. It reads Approved by name · date or Rejected by name · date, keeps your choices as chips (Owner role, the data mode, the history option, nobjects to build and Row-level security acknowledged when the warning was ticked), and keeps the session id.
A design is proposed only in a person's own turn: scheduled tasks and swarm agents cannot propose one, because a design needs the person who asked to approve it.
The owner role and the data mode you approve are fixed once the model is created: they cannot be changed later.
When you approve, the platform re-checks the design and your choices before it records the session. If a check fails, the card says the design no longer passes its checks and asks you to reject it with a note so the Warehouse Builder proposes it again.
Before the model is created
On approval, the builder builds the objects the design lists and proves them, checking the load against your control totals. The model is then created only when all four checks pass. In order:
Every approved object is built and deployed. A missing object is refused with "X" is not built yet. Build every approved object first.; an object that exists but is not deployed is refused with is not deployed. Deploy it, and the builder tries again once it is deployed. Deploy the table from its Settings tab (Deploy, run, truncate and monitor tables).
The owner role reaches every object. When the owner is a business role, a card titled Grant role access arrives: add the role under Permission Groups on each object (Warehouse permissions and row-level security) and click I've granted them, check again. The admin role reaches every object without a grant, so its check finishes straight away, but an admin-owned design hands over views only: Owner role admin needs views over every handed-over table. See Access checks and Model AI handoff.
Row-level security is acknowledged. If a handed-over object reads a table whose row-level security the model does not apply, tick I understand on the card. A warning that the card could not show sends the design back for a new proposal.
Personal data is marked. A handed-over view that projects personal data must carry its mark before the model can be created: the builder reports that the column carries no PII mark, so every report on this model would show it in clear, marks it after you ask in the same chat, and the check re-runs.
Create the model
Only the person who asked for the design can create it: if someone else tries, the answer is only name, who asked for this model, can create it. Ask them to continue this conversation.
The model is created empty, in the requester's personal workspace, with the approved owner role and data mode. It opens from the created card; the model itself is Semantic models and BI tables.
Creating is idempotent: one design creates one model. If a first attempt was interrupted, asking again finds this model by its session key and records it, it never creates a second one; while a creation is in flight the answer is the model of this session is being created, and a reply that DataPrism did not answer just needs another try in a minute.
If the model is deleted after creation, the session stops: the model of this session was deleted; propose the design again to start over. If the design was approved again later, the older session was replaced by a newer approved design, and only the newest one creates the model.
Hand over to Model AI
The builder adds no tables itself: the model is created empty, and the brief says which tables to add.
From the created card, Send the brief to Model AI hands the build brief to the model's Model AI, which builds the model's tables and relationships, and the model opens in DataPrism. When the Model Builder sends the brief itself, it does so in its first round. See Model Builder and Model AI.
From then on, changes to the model are decided in the model's own chat, by the person who asked or another editor of that model: while a change waits, the chat says This change has NOT been made., and a rejection reads An editor of this model rejected this change, so it was NOT made.
When a decision is refused
A decision that fails leaves the card pending, shows the reason under the buttons and adds an Approval failed toast (a failed rejection reads Rejection failed). The sentences come from the platform, for example:
"Owner role "role" is not one of name's roles."
"Owner role "role" cannot own a semantic model for name."
"name's account is inactive, so this design cannot be approved."
"Owner role admin needs views over every handed-over table; name is handed over itself. Pick another role, or reject with a note so the design uses a view."
'This design reads tables with row-level security that the model will not apply (tables). Tick "I understand" on the card to approve it.'
"This design's card could not show its row-level-security warning; reject it with a note so the Warehouse Builder proposes it again."
Questions, answered
What do I need before I can ask for a model?
A chat with the Warehouse Builder Mind and the Create DataPrism Semantic Models and Use DataPrism AI permissions. Admins reach the Mind, and so do members of its permission groups who hold View Warehouse Objects and Create/Edit Warehouse Objects. The design itself is approved by an admin. See Who can do what in DataPrism.
What does the builder ask me before it proposes a design?
One batch of questions: the questions and charts it proposes, the owner role, the data mode when personal data is involved, the history depth with its numbers, plan and version details, and two or three control totals from a report you trust. Each question offers concrete choices, and you can type your own answer.
Why do my questions need more than one model?
Because a DataPrism model has exactly one fact table and a dashboard reads one model, so questions with different grains or facts cannot share one model. The builder says so on the card, recommends the models and dashboards to build instead, and names the alternative, such as a warehouse change that costs time, storage or a rule the business must approve.
Can someone else approve the design for me?
An admin other than the requester can decide the card, but the model is created only when the requester continues the conversation: "The model is created only when name continues it."
How do I get a corrected design?
Click Reject with a note, write what should change and confirm. The note stays on the card as Rejection note:, and the builder can propose a corrected design. The choices on a card lock once you decide, so a rejection is the way to change them.
Can the builder design a model while I am away?
No. A design is proposed only in a person's own turn and needs the person who asked to approve it, so scheduled tasks and swarm agents cannot propose one.
What are the control totals on the card for?
They are numbers from a report you trust, listed under Control totals the tests must match. The build checks its load against them before the model is created, so a mismatch surfaces before reports do.
What does "Model reads it" mean on an object?
The object is a view handed over for the model to read, rather than the base table itself. An admin-owned model reads views for every object, and a handed-over view carries only the columns the model needs. See Relationships and the core table for how the model joins its tables.
Why must the fact be handed over only once?
A semantic model has exactly one fact table, so the design hands over either the fact table itself or one handover view of it. Handing over both is refused: "X" and its handover view "Y" are both handed over: hand over only the view. A design that does not hold exactly one fact object is refused before it reaches you.
What happens if an approved object is not deployed yet?
The model is created only after every approved object is built and deployed. If an object is missing, the builder refuses with "X" is not built yet. Build every approved object first.; if it exists but is not deployed, it refuses with is not deployed. Deploy it, then runs the check again once you deploy it. Deploy the table from its Settings tab (Deploy, run, truncate and monitor tables).
Can one design create more than one model?
No. One design creates one model, and a retry adopts the model it already made: it finds this model by its session key and records it, it never creates a second one. If the model was deleted, propose the design again to start over.
Why does the design no longer pass its checks?
The platform re-checks a design when you approve it, so something that was fine earlier can fail later. One common case: an object marked as new whose table already exists in the Warehouse but was not created in this conversation; the refusal asks you to reject the card with a note so the Warehouse Builder marks it as existing or changed. Reject with a note whenever the card says the design no longer passes its checks, and the builder proposes a corrected design.