Model once
One model of what your services must do and how, from which every diagram and document is drawn, shared by everyone at once.
The model is the one thing the tool keeps. Everything you see, i.e. every diagram and every generated document, is drawn from it, so nothing has to be kept in step by hand.
Nobody keeps diagrams in step
You work in three linked views: the model as a tree, its diagrams, and the details of whatever is selected. Change something on a diagram and the change lands in the model; every diagram is then redrawn from it.
The whole team, in the same model
There is no save button. Every change is recorded as a revision the moment you make it, and everyone working on the same project sees it straight away.
In the manual: modelling together
Read a journey level by level, or end to end
Each process stays small, as it holds one level of detail. When you want the whole customer journey, open any service the process uses in place and read on downwards.
In the manual: expanding requested services
Rules that say exactly what they mean
Requirements can start as plain prose and be made precise later, in a language readable by the business. Business rules are decision tables in the same model, and each rule can be tried on an example before anyone relies on it.
Mistakes found while you model
The tool checks every process against the requirements of the service it provides, continuously as the model changes, and tells you what is missing.
In the manual: model verification
Data that serves a process
An entity is not designed apart from the processes. It is assembled from the data the processes record, and grows as they do. For each entity, a view shows which services use each part of it and how, and the tool reports any stored data which no service uses.
In the manual: the Entity Usage View
AI that proposes, people who decide
The AI assistant can turn informal requirements into proposed model elements or check the model against them. Each proposal is reviewed one by one, and each accepted element records the requirement it came from. Once accepted, it is verified like any element made by hand.
In the manual: AI element actions
For architects
- Diagrams are laid out by the tool’s own layout engine, never by hand (model tree, element details).
- Formal specifications in URDAD-OCL, read and written as URDAD-FEEL; tried on an example.
- Verification at a descriptive, specified or executable level.
- Annotations, element libraries and dependencies between models.
- AI provenance is recorded per element; the language model, hosted or your own, is configured by an administrator and reached only by the server.