One markdown file documents an application's data model — entities, fields, choice lists, relationships. The diagram and forms stay live while you edit it.
The pull talks to the
instance through the local bridge, which uses the SDK credentials on
your machine. Run npm run serve and open
http://127.0.0.1:4173 — from a file:// page or a hosted
copy there is nothing to connect to.
| Document | Project | Application | Saved | Size |
|---|
A single place to define, see and document a ServiceNow data model — the entities, their fields, and how they relate. The model is designed here, in the document; the instance is only ever read, never written.
Every document opens with a metadata block naming what it models and how it should be drawn. All three keys are required — a document missing any of them is refused rather than opened, so a half-identified model can never be edited under the wrong name.
--- application: ACME Returns description: Customer returns and repairs, modelled for the ACME rollout. diagram: dagre-wm ---
diagram: dagre-wm draws the model for you: the entities, fields and references in the document are laid out as an ER diagram, and it stays live while you edit the tables.
diagram: mermaid draws the diagrams you wrote yourself. Every ```mermaid block is drawn in the preview, in the place you wrote it, and the right-hand pane steps aside so the document has the whole window. A drawn diagram is still part of the document: double-click it to edit its markdown like any paragraph, and it redraws as soon as you close the editor. A block that does not parse says so, with its source, instead of taking the page down.
## Order flow ```mermaid graph TD A[Order placed] --> B[Payment captured] ```
Mermaid is built into this file, so the diagrams draw with no network at all — the same from a hosted copy, from the local bridge, or from a file opened straight off disk. dagre is still accepted as the old spelling of dagre-wm.
The fence is optional and the order does not matter — the keys only have to sit above the first heading. When a file is refused, the studio offers to write this block for you.
This is where you and the architect do the modelling. You decide the entities, the fields, their types and lengths, which field points at which table, what is mandatory, and which choice codes are stored. You also record the things only you know: where each requirement came from, and how confident you are in it.
The document is the specification, and it is exact: field names, types, lengths, reference targets and stored choice codes are to be implemented literally, not improved. Where the model looks wrong, the fix is to have it corrected here rather than to deviate in code.
Writing to an instance safely means judging what is destructive — the platform does not convert data on a type change, and a removed column keeps its rows. Those calls belong with the person making the change, in a reviewed workflow. This tool's job is to make disagreement visible, then get out of the way.
Compares every entity in this document against the live instance — tables, columns, types, mandatory flags — and marks drift on the diagram. Read-only: nothing on the instance is changed.
A prose summary of the application, inferred from the data model the instance actually holds — generated by Claude Code and cached per application. Needs a completed check first.
Runs npm run build on your machine: validates the
documentation paths and compiles the Fluent source. Local only —
it never deploys to the instance.