One model of your business. Everything else is generated from it.
URDAD is a method, and a tool suite supporting it, for specifying what an organisation’s services must achieve and how they achieve it — in one technology-neutral model. Diagrams, documentation, tests and running processes are all derived from that model, so they cannot drift apart.
Why URDAD?
In most organisations what the business does is written down three times — requirements in documents, designs in diagrams, behaviour in code — and kept in step by hand until they drift apart. URDAD replaces the three copies with one model.
The business model is the asset
The model is the one artefact you keep; everything else can be generated from it again. It names no technology, so it outlives the applications, platforms and vendors that implement it, and it can grow one business unit at a time.
Read more about the business model is the asset in the manualEverything stays in sync
Nothing is drawn by hand. Every diagram, form and document is regenerated from the model whenever it changes, so no two views can disagree and none can be out of date. Every change is a recorded revision.
Read more about everything stays in sync in the manualWhat is specified is what runs
The optional execution environment runs the approved model’s processes as modelled, rather than code rewritten from them, and checks every answer a service gives against its contract — naming the party at fault when one is broken.
Read more about what is specified is what runs in the manualAI proposes, people decide
The AI assistant works inside the method, in the model’s own vocabulary. Nothing it proposes reaches the model until a person accepts it, and every accepted element records the requirement it was drawn from.
Read more about ai proposes, people decide in the manualEvidence for audit, as a by-product
Requirements are kept apart from design, every activity is traced to the requirement it addresses, and every change passes phase gates, review and sign-off and is recorded in an audit log. The tool certifies nothing itself; it keeps the evidence you need to.
Read more about evidence for audit, as a by-product in the manualChange who provides a service, not the process
A process requests a service contract, never a particular provider. A person, a system, a partner or another process can answer it, so automating or outsourcing a service is a configuration change, held to the same contract.
Read more about change who provides a service, not the process in the manual
How it works
Capture stakeholder requirements
The contractfor a required service is allocated to a responsibility domain, its stake holders identified and their functional requirements in the form of
- (pre-conditions](term:precondition) under which service is refused,
- post-conditions as the service guarantees.
The contract of a motor insurer's Process claim service: what must hold before, and what is guaranteed after. Design the services
Each requirement is allocated to a lower-level service that checks or realises it, and the process orchestrates them. Each lower-level service is designed the same way, in its own domain, down to the level of detail you need.
Entities are defined through and evolve with the business processes which feed them.
In the manual: design the services
The process that realises Process claim, from the services its requirements were allocated to. Verify
The tool checks each process against its contract’s requirements as the model changes: a requirement no step addresses, or a step that cannot run, is reported before anyone relies on the model.
Where a project asks for it, verification goes on to testing: a Testing phase runs the project’s processes against cases generated wholly from the model — each on its own, then all together — with the contracts’ own conditions as the oracle, and its test report goes to sign-off. Nobody writes a test, a stub or a data set.
In the manual: verifyExecute
The optional execution environment runs the approved processes as the model states them, with people answering human tasks and existing systems answering requests — every answer checked against its contract.
In the manual: executeEvolve
Every change is made in a project, signed off and activated. The diagrams, documentation, tests and running processes follow the model; nothing is redrawn or rewritten by hand.
In the manual: evolve
The tool suite
Model once
- Three synchronised views — model tree, diagrams and element details — with every diagram generated by the tool's layout engine.
- Real-time co-editing: every change is committed as a revision and seen by everyone on the branch at once.
- Formal specifications in URDAD-OCL or URDAD-FEEL, and business rules as decision tables, checked as you write them.
- Continuous verification of each process against its contract.
Govern change
- Every change is made in a project, taken through phases and phase gates to activation.
- Roles say who drives each transition and who signs what; regulated projects add the checklists their regimes require.
- Sign-off on signed test reports, and an audit log of what was done and by whom.
Execute
- The optional execution environment runs approved processes as modelled, on Temporal's durable workflows.
- People take part through a task portal whose forms are generated from the contracts.
- External systems are called over HTTP, Kafka or AMQP, and every answer — a person's, a system's or a process's — is checked against its contract.
Share and integrate
- Documentation generated as HTML, PDF or AsciiDoc, and published to Confluence with review comments flowing back.
- Processes and decisions exported to and imported from BPMN and DMN for Camunda 8.
- One vendor-neutral contract per responsibility — CI/CD gating, identity, LLM providers — with each product a thin adapter behind it.
