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 build that fills the model follows, and is on Model Builder.
Ask for a design
Open a chat with the Warehouse Builder Mind. Builder Minds are visible to the admin role only, and asking for a model needs the Add DataPrism Semantic Model and Use DataPrism AI permissions. 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.
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:.
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.
After the design is approved
The builder builds the objects the design lists and proves them, checking the load against your control totals.
It then checks that the owner role can read every object. When the owner is a business role, a card titled Grant role access arrives: grant the role on each object and click I've granted them, check again. An admin-owned model reaches every object, so its check finishes straight away. See Access checks and Model AI handoff.
The model is created empty, in the requester's personal workspace, with the approved owner role and data mode. From the created card, Send the brief to Model AI hands the build brief to the model's Model AI; when the Model Builder sends the brief itself, it does so in its first round. See Model Builder.
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, which is visible to the admin role only, and the Add DataPrism Semantic Model and Use DataPrism AI permissions. 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.
Can I read an approved design later?
Yes. The card stays in the chat, read-only: its status, the decision line such as Approved by name · date, the choices it stored as chips and the session id. To read the model itself, open it in DataPrism; see Semantic models and BI tables.