A model is a Mermaid document, and Mermaid draws only half of it. The business rules, the workflows, the enumerated values and the access control live in %% directives it treats as comments — which is the half worth checking while the model is still being written. This page draws all of it.
.eml.mmd file anywhere on this page.Or open one of the six worked examples:
An .eml.mmd describes a whole application, and the ERD is the smallest part of it. Everything below lives in %% directives, which every Mermaid renderer treats as a comment.
Every column with the type the generator resolved it to, its key modifiers, the enumerated values it is bound to and the help text that becomes its label in the generated application. Relationships in crow's foot notation, because the glyph pair is what decides which table carries the foreign key. Double-click a box to open it in full.
Each state machine as a canvas: green where a record starts, grey where the process ends, and one arrow per move the generated API will allow — a move with no arrow is refused with a 403, for every caller including the administrator. A move restricted by role is drawn differently and names its roles. Multi-step sagas are an ordered ladder, one rung per step, with what each step publishes for the next.
Each decision flow in the five colours the design tool uses — start, decision, action, compute, end — with the branch conditions on the arrows. Beside it, what the rule emits: the refusals, the transforms and the workflow triggers that Mermaid renders identically whether they are there or not. A decision table is drawn as a table.
The roles the model declares, the account each one is seeded as, and how many of the entities each can read. A role that reads 0 of 14 entities signs in to an empty application, and that is worth knowing before the application exists rather than after.
The same verdict chapter 11 prints, from the same engine, on every change — with the codes the fixer can repair marked as such. The page carries one copy of one checker; it does not have an opinion of its own.
Nothing on this page parses a model. viewers/eml-model.js is the parser, the rule compiler, the workflow compiler, the access-control derivation and the checker from the generator repository, bundled for a browser tab — the same code appwithai generate runs. The modules beside it decide how a column, a state or a step looks, never what it is.
That distinction is the whole point. A viewer with a parser of its own would eventually disagree with the generator about which columns are foreign keys, which enum binding took, or which transition is legal — and the author would find out only after generating. CI in that repository rebuilds this bundle and compares it byte for byte, so it cannot fall behind the code it claims to be.
The page makes no request to any other host. Your model is read in your tab, and nothing about its contents is recorded — the analytics on this site count that a model was viewed and how big it was, never a line of it. The privacy page lists every event by name.
Then this page is the other half of the loop. The enterprise prompt points a model at llmdetailed.txt, whose §10 walks a business end to end and builds the .eml.mmd on disk one phase at a time. Press Watch a file, pick that file, and the diagram fills in as the walkthrough runs — so what you are approving at each step is something you have seen, not something you have been told about. Watching needs the File System Access API, which today means a Chromium-family browser; Open a file and pasting work everywhere.