1. About this specification
This is the specification of a URDAD model: every element a model is made of, its attributes and relationships, and what it means. It is generated from the model’s JSON schema, the form in which the URDAD modelling tool writes a model, so the two cannot disagree.
The schema itself is published at the address its identifier names,
https://urdad.org/schemas/urdad.schema.json (JSON Schema
https://json-schema.org/draft/2020-12/schema). A model exported from the tool is a file holding a
manifest, which says what was exported and from where, and a model, which
is a Model as specified here. How the tool is used to build such a
model is the subject of the user manual.
Generated from commit 3f016715, 68 definitions.
1.1. Reading the element reference
Each element names what it specialises: it has every attribute of that
element as well as its own, which are the ones its table lists. An element
that is one of several others is a choice among them, made by its variant
attribute.
Where an attribute’s type is an element, the attribute holds that element
itself, owned by the element it appears in. An attribute whose meaning says
it is a reference holds the id of another element instead, which is owned
elsewhere. Required says whether a valid model must state the attribute;
an attribute that is not required may be absent.
Conditions, constraints and expressions are formal specifications, held in URDAD-OCL (FormalSpecification).
1.2. Licence
This specification and the schema are published under the Creative Commons Attribution 4.0 International licence (CC BY 4.0). You may share and adapt them for any purpose, provided you credit URDAD (urdad.org), link to the licence and say whether you changed them.
2. The model and its parts
What every element is, the model root, and the responsibility domains that structure it.
2.1. Element
What every element of a model is: an identity, a name, and the annotations attached to it. Every other definition specialises it, directly or through another.
Specialised by Annotation, ResponsibilityDomain, Entity, Model, Requirement, DataType, Variable, ServiceContract, RequirementAllocation, Activity, Compensation, RequestConstraint, ResponseConstraint, ExceptionConstraint, MessageEvent, MessageSendEvent, DurationEvent, DateTimeEvent, MessageConstraint, Decision, DecisionInput, DecisionOutput, DecisionRule, DecisionInputEntry, DecisionOutputEntry.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
yes |
The element’s identifier, unique within the model. Every reference to the element names it. |
|
string |
yes |
The element’s name, as people read it in the tool, in diagrams and in generated documentation. |
|
no |
The annotations attached to this element. |
|
|
list of string |
no |
References to informalRequirement annotation IDs that this element formalizes. Set by AI formalization on acceptance, or manually by users authoring formal elements from informal requirements. Provides informal→formal traceability. |
|
list of string |
no |
Baseline for each formalizationOf ref. Each entry has the form '<annotationId>|<8-char hex hash>|<quote>'. The hash is compared against the current annotation body to detect 'informal changed since formalization' and surface a re-verify badge; the quote is the verbatim substring the formalization cited, preserved for corpus provenance. Legacy 2-segment entries ('<annotationId>|<hash>') are still parsed (quote reads back as absent). |
2.2. Model
The model root. It decomposes into top-level responsibility domains and, unlike a domain, owns no service contracts, data types, processes or exceptions of its own.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
A constant marker that identifies the model root on the wire; always true. |
|
no |
The model’s top-level responsibility domains. |
|
|
string |
no |
The model’s business time zone, an IANA time-zone id such as 'Africa/Johannesburg'; absent means UTC. today() is the date now() falls on in this zone. |
2.3. ResponsibilityDomains
The responsibility domains nested directly inside the model root or inside another responsibility domain.
A list of ResponsibilityDomain, without repeats.
2.4. ResponsibilityDomain
The packaging unit of a model, mirroring an organisational unit or an external party. It owns service contracts, data types, entities, exceptions, processes, decisions and nested responsibility domains, and is what security policies grant access to.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of DataType_polymorphic |
no |
The data types this domain owns. |
|
list of Entity |
no |
The entities this domain owns: the data it is responsible for storing. |
|
no |
The responsibility domains nested inside this one. |
|
|
list of ServiceContract |
no |
The service contracts this domain offers. |
|
list of Process |
no |
The processes realising this domain’s service contracts. |
|
list of Exception |
no |
The exceptions this domain’s service contracts may raise. |
|
list of Decision |
no |
The DMN decisions this domain holds — each a realization of a pure (isQuery) service contract, beside the processes. Absent when there are none. |
2.5. Annotations
The annotations attached to an element, in the order they were added.
A list of Annotation.
2.6. Annotation
Free text attached to a model element and stored with it: an informal requirement, a short or detailed description, a comment, concern, question, response or error, with its language and markup.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
yes |
The annotation’s text, in its markup. |
|
one of |
yes |
What the annotation is: an informal requirement, a short or detailed description, a comment, a concern, a question, a response or an error. |
|
one of |
no |
The language the body is written in, as an ISO 639-1 code. |
|
one of |
no |
How the body is marked up: plain text, Markdown, HTML or LaTeX, as a media type with '/' written as '_'. |
|
string |
no |
The name of the annotation’s author, when it has one. Absent on an annotation the tool itself created. |
|
string |
no |
The email address of the annotation’s author, when it has one. Absent on an annotation the tool itself created. |
|
string (date-time) |
no |
Server-stamped ISO-8601 UTC timestamp at which this annotation was first persisted. Write-once: never overwritten on subsequent edits. |
|
string |
no |
Server-stamped project phase that was current when this annotation was first persisted (e.g. "planning", "development", "sign-off"). Lets queries filter annotations by phase. |
|
string |
no |
Server-stamped git commit hash of the model at the moment this annotation was first persisted. Lets queries trace an annotation back to a specific model revision. |
|
object { |
no |
Origin of this annotation when it was imported from an external system. Used for idempotent two-way sync (e.g. Confluence comments). |
3. Data
The types of the values a model speaks about, and the entities it stores.
3.1. DataType
A type of value in the model: a primitive type, an enumeration, a data structure or a service reference. What every data type has in common is its invariances.
Specialises Element, and has every attribute it has.
Specialised by PrimitiveType, Enumeration, ServiceReference, DataStructure.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
no |
Which kind of data type this is: the discriminator a reader dispatches on to the definition of that name. |
|
list of Invariance |
no |
Constraints every value of this type must satisfy. |
3.2. DataType_polymorphic
Any one of the data types, told apart by its variant.
One of PrimitiveType, Enumeration, DataStructure, ServiceReference, chosen by its variant.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
yes |
Which kind of data type this is: the discriminator a reader dispatches on to the definition of that name. |
3.3. PrimitiveType
A data type with no structure of its own — a number, a string, a date or time, and the like — named after one of the built-in types.
Specialises DataType, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
no |
The built-in type this primitive type is. |
3.4. Enumeration
A data type whose values are a fixed list of named options.
Specialises DataType, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of string |
no |
The enumeration’s values, in order. |
3.5. DataStructure
A structured data type with typed fields. It may specialise another data structure and may carry invariances; a request, a response, an exception and a message are each described by one. One that names an entity is a view of that entity.
Specialises DataType, and has every attribute it has.
Specialised by Exception.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to base DataStructure by ID |
|
string |
no |
Reference to an Entity by ID. When set, this DataStructure is an entity view contributing to the entity’s aggregated field list. |
|
list of Field |
no |
The structure’s own fields, in order. A specialising structure also has every field of its base. |
|
boolean |
no |
Whether this structure serves only as a base for others to specialise, with no value of its own kind. Absent means false. Default: |
3.6. Field
A typed field of a data structure, with its multiplicity and how the structure relates to the value it holds.
Specialises Variable, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
no |
How the owning data structure relates to the field’s value: composition (the value is part of it and does not exist without it), aggregation (it holds the value, which may exist on its own) or association (it refers to a value that exists independently). |
|
string |
no |
Multiplicity of the field, e.g. '0..1', '1', '0..', '1..' Default: |
|
one of |
no |
Meaningful only when the owning DataStructure’s entityRef is set. What this field’s value means toward the entity: 'identifies' names which instance is meant (at most one field per view), 'states' is actual persisted entity data, 'transient' never becomes persisted entity data, 'version' is the version of the instance read, filled by the store and never stored (at most one per entity, an Integer). Optional; absence is a distinct, reported 'unclassified' state, never read as 'transient'. |
|
one of |
no |
Meaningful on any field, anywhere — not scoped to entity views. Whether this field’s value is personal data an execution environment would hold about a real person, and under what erasure regime: 'standard' is erasable on request, 'retentionObligated' is subject to a deployment-defined hold. Optional; absence means 'not personal data' and is never reported. |
|
boolean |
no |
Meaningful only on a 'states' field of an entity view. Whether no two instances of the entity may hold the same value at this field; an execution environment’s entity store refuses a write that would. Optional; absence and false both mean 'not unique'. Set anywhere else, it says nothing and verification warns. |
3.7. Variable
A named, typed value: a field of a data structure, or a value a process names for itself. Its invariances constrain every value it may hold.
Specialises Element, and has every attribute it has.
Specialised by Field, ProcessVariable.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to a DataType by ID |
|
list of Invariance |
no |
Constraints every value of this variable must satisfy. |
3.8. ServiceReference
A data type whose values denote a service.
Specialises DataType, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to a ServiceContract by ID. Optional, and its absence is a statement rather than an omission: the value denotes any service. A named contract means the value denotes that contract or any specialization of it (a contract whose base chain reaches it). |
3.9. Entity
Business object whose full field list is aggregated across every DataStructure with a matching entityRef.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of string |
no |
Ids of the ResponsibilityDomains that may read this entity’s stored instances directly, and the domains inside them: its published read model. Empty is the default and means only the owning domain (the one containing the entity) reads them; every other domain asks the owner’s services. Fields holding personal data are never readable this way. |
3.10. Exception
A data structure raised to tell a service’s client that a pre-condition was violated and the service has been refused.
Specialises DataStructure, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
The message telling the client why the service was refused. |
4. Requirements and service contracts
What a service must achieve, independently of how.
4.1. FormalSpecification
A condition, constraint or expression written in URDAD-OCL, so that the tool can check and evaluate it. URDAD-FEEL is another notation for the same specification; the model stores URDAD-OCL.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
yes |
URDAD-OCL, the only specification language; the wire value is "OCL". A requirement not yet formalisable is an informalRequirement annotation, not a specification. |
|
string |
yes |
The specification’s text, in URDAD-OCL. |
4.2. Requirement
A requirement placed on the model: a functional requirement of a service contract, or an invariance of a data type or variable. Its formal specification states it so that it can be checked.
Specialises Element, and has every attribute it has.
Specialised by Invariance, FunctionalRequirement.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The requirement, stated formally. Absent while it is still stated only informally. |
|
|
list of string |
no |
References to ResponsibilityDomain or Process IDs |
4.3. Invariance
A constraint that must hold of every instance of the data type or variable that owns it, always: a state in which it does not hold must never be observable.
Specialises Requirement, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
A constant marker that identifies an invariance on the wire; always true. |
4.4. FunctionalRequirement
A pre- or post-condition of a ServiceContract. It records nothing about what addresses it — that is the realising Process’s statement, held there as a RequirementAllocation naming the step that discharges it. A requirement may belong to a contract in an element library or another domain, so a particular project’s allocation cannot live on it.
Specialises Requirement, and has every attribute it has.
Specialised by PreCondition, PostCondition.
4.5. PreCondition
A condition that must hold for the service to be provided. When it does not hold the service is refused, and the client is told so by the exception the pre-condition raises.
Specialises FunctionalRequirement, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The exception raised when this pre-condition does not hold. |
|
|
list of ExceptionConstraint |
no |
The values the condition gives its raised exception when it does not hold, each stated as raised.<path> = <expression> from the request and the caller. |
4.6. PostCondition
What must hold once the service has been rendered. condition says when the guarantee applies and is not the requirement’s own formalSpecification, which says what must hold — written as one they cannot be read apart. messageSendEvents declares what realising it may dispatch, which is part of the contract a caller depends on: a caller writes a MessageHandler against each declaration.
Specialises FunctionalRequirement, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
A constant marker that identifies a post-condition on the wire; always true. |
|
no |
When the guarantee applies: the post-condition must hold only when this does. Absent means always. Not the requirement itself, which is its formal specification. |
|
|
list of MessageSendEvent |
no |
The messages realising this post-condition may cause to be sent — part of the contract a client depends on. |
4.7. ServiceContract
The specification of a service: its request and response data structures, its pre-conditions and post-conditions, and the stakeholders requiring them. It names what is to be done, never who does it or how; a process or a decision realises it.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to the base ServiceContract by ID. The contract this one specializes: it imposes every functional requirement of its base. It may add postconditions and functional requirements, and may only waive preconditions (see waivedPreConditions), never add one. |
|
boolean |
no |
Whether this service is a function: pure, so that applying it to a request denotes a value and nothing else happens. Absent means false — purity is a positive claim and is made deliberately. Only a function may be named in a constraint expression, and only a function is generated as an HTTP GET. The claim is verified against the realizing process, which may then request no impure service and contain no send, await or reaction. Purity only ever accumulates down a base chain: a contract specializing a function is a function and must declare it too, while a specialization of an impure contract may freely be one. |
|
boolean |
no |
Whether a requester may cancel a request for this service before it is answered: every requester, another process included. Absent means false. A cancelled request has no net effect: the process realizing it undoes what it committed. A request for a service that may not be cancelled is waited for when its requester is interrupted, and then undone through its contract’s undone-by. Accumulates down a base chain: a specialization of a cancellable contract is cancellable. |
|
no |
The structure of a request for this service: what the client provides. |
|
|
no |
The structure of the service’s response: what the client receives. |
|
|
list of PreCondition |
no |
The conditions that must hold for the service to be provided; the service is refused when one does not. |
|
list of string |
no |
Ids of the base chain’s preConditions this contract no longer requires — the only thing a specializing contract may say about preconditions. Preconditions move the opposite way to postconditions under specialization: a postcondition may be added (promise more), a precondition may only be waived (accept more), which is what keeps a specialization usable wherever its base was. preConditions is therefore meaningful only where base is absent, and each id here must resolve inside the direct base’s effective precondition set. |
|
list of PostCondition |
no |
What must hold once the service has been provided. |
|
list of string |
no |
The parties with an interest in the service, named as text until they are modelled: the source of its requirements. |
|
list of string |
no |
Ids of the ResponsibilityDomains permitted to call this contract directly, as an external entry point. Distinct from provisionalStakeholders: a stakeholder is a requirements-sourcing concept, publishedTo is an access concept — a domain may be either, both, or neither. Empty is the default and means internal-only, reachable only as the target of a RequestService nested inside another contract’s own process realization. |
|
string |
no |
Id of the Entity this contract is a generated query service of; absent for every contract a modeller wrote. Generating again updates only the contracts that carry it. |
|
string |
no |
Why this contract’s change to a stored instance applies to the instance as it is, rather than to a version its requester read — an increment computed from the stored state in the write’s own transaction, or a write meant to win. Present and not blank is the declaration; absent, such a change states a pre-condition reading the entity’s version. |
|
no |
Present exactly when this contract runs on the calendar’s own initiative — triggered by the scheduler rather than by a request. Restricted to a DateTimeEvent specifically, never the general event family a Reaction waits on: only a calendar reading needs no antecedent already in flight. Composable with publishedTo — a contract may carry both, or neither, which is the plain internal-only case. Never inherited down a specialization chain. |
|
|
no |
How a committed request to this contract is undone: its 'undone by', the default for every committing request to it that states none of its own. Its request constraints read this contract’s 'request' and 'response', as its post-conditions do. |
4.8. Compensation
How a committed step is undone: one request to an undoing contract, its request populated by request constraints as a RequestService’s is. A pre-condition exception means the service had no net effect, so whatever a process committed before raising one of its own contract’s pre-condition exceptions must be undone. Owned by a ServiceContract (its 'undone by') or by a RequestService or SendMessage (their own). Each request constraint populates 'providerRequest', the undoing contract’s request.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
The undoing contract, by id. |
|
list of RequestConstraint |
no |
What populates the undoing contract’s request, under 'providerRequest'. |
4.9. RequestConstraint
Populates one field-group of a nested request, before it is sent. Not an Invariance: an Invariance means 'true of every instance of this type, always', where this holds of one request object at one point in one process. Its environment binds 'request' unshadowed plus 'providerRequest': the requested contract’s request structure, the object being built.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
Mandatory: the whole reason to create a RequestConstraint is to state a body. |
4.10. ResponseConstraint
Populates one field-group of the process’s own response — the realised contract’s response structure, under the name 'response'. RequestConstraint’s twin: its environment is the process environment at the owning PopulateResponse step, 'request' unshadowed, plus 'response', which nothing else in a process may name.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
Mandatory: the whole reason to create a ResponseConstraint is to state a body. |
4.11. ExceptionConstraint
States one field-group of the exception a raise raises — the values the handler catching it reads under 'exception'. ResponseConstraint’s twin, owned as a set by a RaiseException step and by a PreCondition. Its environment adds 'raised', the exception being raised; never 'exception', which inside a handler is the one caught, so a re-raise reads raised.reason = exception.reason.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
Mandatory: the whole reason to create an ExceptionConstraint is to state a body. |
5. Processes
How a service contract is realised: the activities a process carries out and the control flow between them.
5.1. Process
The business process realising a service contract: the activities it carries out, the control flow connecting them, and which step addresses each of the contract’s functional requirements.
Specialises ActivitySequence, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to a ServiceContract by ID |
|
list of RequirementAllocation |
no |
Which step of this process addresses each functional requirement of the contract it realises. |
|
no |
Activities allocated to a functional requirement but not yet positioned in the flow. Allocating a requirement to a step says what the process must do and nothing about when, so an activity created in the Responsibility Allocation View waits here until the modeller places it on a transition. Its order carries no meaning — it is the order things were allocated in, not a sequence anything runs, and nothing lays it out. |
5.2. RequirementAllocation
"This step discharges that requirement" — the one statement of responsibility allocation, instance-level. It names an activity rather than a type because a requirement met by notifying a customer is discharged by one particular SendMessage in one particular flow, and one met by a lower-level service by the RequestService that calls it. Any activity qualifies, control-flow constructs included. Each requirement should have at most one. It is held by the Process because the allocation is a statement the process makes about itself — a functional requirement belongs to a ServiceContract that may sit in an element library, so it cannot carry a particular project’s allocation. What a process depends on is not stated separately: it is read off the RequestServices it holds.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to a FunctionalRequirement by ID |
|
string |
no |
Reference by ID to the Activity that discharges the requirement |
5.3. Activity
A step in a process: a service request, a message sent or awaited, a variable defined, the response populated, or a construct grouping further activities, such as alternate or concurrent flows.
Specialises Element, and has every attribute it has.
Specialised by ActivitySequence, RequestService, RawActivity, RaiseException, CheckPreCondition, Undo, AlternateFlows, ConcurrentFlows, EventTriggeredFlows, MonitoredActivities, SendMessage, AwaitMessage, ForEach, While, DefineVariable, PopulateResponse.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
no |
Which kind of activity this is: the discriminator a reader dispatches on to the definition of that name. |
5.4. Activity_polymorphic
Any one of the activities, told apart by its variant.
One of RequestService, RawActivity, DefineVariable, PopulateResponse, SendMessage, AwaitMessage, ActivitySequence, AlternateFlows, ForEach, While, ConcurrentFlows, EventTriggeredFlows, BackgroundFlow, ConditionalFlow, Reaction, MonitoredActivities, Monitor, ExceptionHandler, MessageHandler, Process, RaiseException, CheckPreCondition, Undo, chosen by its variant.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
yes |
Which kind of activity this is: the discriminator a reader dispatches on to the definition of that name. |
5.5. ActivitySequence
Activities carried out one after the other, in order. A process is one, and so is each flow inside a construct.
Specialises Activity, and has every attribute it has.
Specialised by ExceptionHandler, ConditionalFlow, Reaction, Monitor, BackgroundFlow, Process.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of Activity_polymorphic |
no |
The activities, in the order they are carried out. |
5.6. RequestService
The step at which a process requests a service, naming the service contract it requires rather than a particular provider, and saying what is done when the service raises each of its exceptions or sends a message it declared.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to a ServiceContract by ID |
|
string |
no |
where the provider is read from, as a data path over the data this step can reach — 'request.preferredUnderwriter', 'Quote.nextReinsurer'. Not a party and not a reference: a provider known when the model is written is the contract the request names, because a requester requires a contract and never a party. What only the running process knows is which service reference to ask, so the path must arrive at a ServiceReference typed to the contract requested or to something that specialises it. Absent is a statement rather than a gap: the service is requested of whoever provides that contract, and nothing materialises a selector in its place |
|
one of |
no |
whether the service is requested once, or once per provider in a set — BPMN’s multi-instance characteristic. Not a loop over a collection in the data, which is what a ForEach is: this varies who answers one request, not what is asked Default: |
|
one of |
no |
whether the instances of a multi-instance request may run concurrently or must be worked through in order. Meaningless on a single-instance request Default: |
|
string |
no |
how many providers a multi-instance request is addressed to, in the lexical form <lower>[..<upper>], upper may be * — e.g. '3', '1..*', '2..5' |
|
no |
when the request goes on to further providers, stated in continuation polarity — the request carries on while this holds. Meaningful on a multi-instance request: on a sequential one it decides whether the next provider is approached at all, on a parallel one that the outstanding answers are no longer wanted. An early exit and not a bound, which providerMultiplicity is |
|
|
no |
what is done when the service answered without raising — the middle lane of the composite, between the request and the merge. Not the enclosing sequence after the merge, where every arm rejoins: a step there runs whether or not an exception was handled, a step here only where none was raised |
|
|
list of ExceptionHandler |
no |
What the process does when the requested service raises each of its exceptions. |
|
list of MessageHandler |
no |
How the process processes each message the requested service declared it may send. |
|
no |
The name this request binds its response to, for the rest of the enclosing sequence. Its type and multiplicity are derived from the requested contract, never authored: a multi-instance request binds a collection of responses, so the name must then be reached with '→' rather than '.'. Absent means the answer is not named, which is the state almost every request is in. |
|
|
list of RequestConstraint |
no |
Populates this request’s own request object, field-group by field-group, before it is sent. |
|
no |
How this request is undone, overriding the requested contract’s 'undone by'. Its request constraints read the process’s names at the step. |
|
|
string |
no |
That this request needs no undo, and why: what it commits lapses, or repeating it is harmless. Excludes 'compensation'. |
5.7. ExceptionHandler
What a request does when the service it asks raises one exception: recover and rejoin the flow, raise one of the calling process’s own pre-condition exceptions, or — empty and marked ignoresException — ignore it. Every exception the requested contract’s pre-conditions raise must have one; verification refuses a request that leaves one unhandled.
Specialises ActivitySequence, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to an Exception by ID |
|
boolean |
no |
The modeller’s statement that an empty handler is meant: the exception is ignored and the flow carries on after the request. Absent means false — an empty handler is then a decision not yet taken, reported as a warning. Meaningless once the handler has a body. |
5.8. MessageHandler
A lane of a RequestService that processes a message the requested service declared it may send — ExceptionHandler’s counterpart on the other side of the composite widget. A BackgroundFlow, and that is the claim rather than a drawing convenience: the request carries on the moment the service answers, so the lane runs to its own end rather than rejoining the flow. messageEvent names the MessageSendEvent a post-condition owns, not the message’s data structure, because two post-conditions may declare a send of the same structure meaning different things.
Specialises BackgroundFlow, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
Always MessageHandler: the discriminator a reader dispatches on. |
|
string |
no |
Reference to a MessageSendEvent by ID |
5.9. RawActivity
Work that is named but not decomposed: a step whose detail the model does not (yet) state. Its optional formal specification states what it does.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
What the activity does, stated formally. Absent when the model leaves it unstated. |
5.10. CheckPreCondition
Checks a pre-condition of the realised contract at this point in the flow, and raises that pre-condition’s exception when it does not hold. It references the pre-condition and copies nothing: what is checked is the pre-condition’s own formal specification, evaluated as its contract states it, and what is raised is its own exception. The reference is also the step’s allocation — a guard addresses the pre-condition it checks, with no RequirementAllocation beside it. Named after the pre-condition it checks.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to the PreCondition checked, by ID |
5.11. RaiseException
Raises one of the realised contract’s exceptions, refusing the service, with the values the exception carries.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to an Exception by ID |
|
list of ExceptionConstraint |
no |
The values given the exception raised, each stated as raised.<path> = <expression> from whatever is in scope at the step. |
5.12. Undo
Undoes everything the process has committed so far, newest first, and carries on: the undo a refusal runs, without the refusal. Each committed step is undone by its own compensation, else by its contract’s undone-by; what is undone is not undone again by a later refusal or Undo. It names nothing and addresses no requirement, and it may not stand inside concurrent work.
Specialises Activity, and has every attribute it has.
5.13. DefineVariable
Creates and initialises a process variable. Defining and binding in one step is what removes the definite-assignment problem rather than solving it: a variable cannot exist unbound, so nothing has to compute whether it was assigned on every path into a merge, and one introduced inside a branch or a loop body simply leaves scope at the end of that block.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The variable introduced. Owned: there is nothing to set the slot to, so it cannot be deleted on its own. |
|
|
no |
What the variable is bound to, in the environment at this point in the process. Optional only so a half-authored step is a legitimate work-in-progress state. |
5.14. ProcessVariable
A value a process names for itself: what a DefineVariable introduces, what a RequestService binds its response to, and what a loop carries across its iterations. A Variable with a multiplicity, and deliberately not a Field — a field also carries 'relationship', which describes how an owning structure relates to the value, and a local has no owning structure. Process data is lexically scoped and single-assignment: a variable is introduced and bound at one point, and its scope is the remainder of the enclosing ActivitySequence together with everything nested in it.
Specialises Variable, and has every attribute it has.
Specialised by LoopVariable.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Multiplicity of the variable, e.g. '0..1', '1', '0..', '1..'. Not decoration: a name bound to a collection must be reached with '→' and one bound to a single value with '.'. Default: |
5.15. PopulateResponse
Populates part of the process’s own response, from whatever is in scope where it stands — so each branch may build the response its own way. Every path through the process that completes must populate each response field once.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of ResponseConstraint |
no |
The population, field-group by field-group, each stated in assignment normal form: response.<path> = <expression>. |
5.16. AlternateFlows
A branch of which exactly one flow is taken: the first conditional flow whose condition holds, or the default flow when none does. All flows rejoin at a merge.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of ConditionalFlow |
no |
The conditional flows, in the order their conditions are tested. |
|
no |
The flow taken when no condition holds. |
5.17. ConditionalFlow
A flow taken when its condition holds: an activity sequence with the formal specification of that condition.
Specialises ActivitySequence, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The condition under which this flow is taken. |
5.18. ConcurrentFlows
Concurrency of every kind: unconditional flows and conditional flows both terminate on the join, background flows outlive it. At least one flow must be unconditional (an ActivitySequence, possibly empty), so that the join is reached even when no condition holds.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of ConcurrentFlow_polymorphic |
no |
The flows, all started together at the fork. |
|
integer, at least 1 |
no |
How many lanes the join waits for. Absent: every lane that runs. A count n: the join is passed once n lanes have arrived, and the lanes still running are then stopped — waits and unclaimed tasks at once, work that may already have acted waited for — with what they committed left committed until undone. A background lane never arrives and is not counted. With a count, no lane’s names are in scope after the join. |
5.19. ConcurrentFlow_polymorphic
Any one of the kinds of flow a ConcurrentFlows may hold, told apart by its variant. Path is the name older models wrote for an ActivitySequence.
One of ActivitySequence, BackgroundFlow, ConditionalFlow, chosen by its variant.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
yes |
Which kind of flow this is: the discriminator a reader dispatches on. |
5.20. BackgroundFlow
A flow of concurrent flows that runs on independently and ends in a flow end of its own instead of arriving at the join.
Specialises ActivitySequence, and has every attribute it has.
Specialised by MessageHandler.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
A constant marker that identifies a background flow on the wire; always true. |
5.21. ForEach
Carries out its body once for each element of a collection, in order or concurrently, optionally stopping early and collecting each iteration’s result.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
the expression resolving the collection worked through, e.g. request.items |
|
string |
no |
the expression naming where the body’s per-element results are collected, e.g. response.assessments |
|
string |
no |
the variable bound to each element of the source collection during iteration, e.g. item |
|
one of |
no |
whether elements must be worked through in order or may be processed concurrently Default: |
|
no |
condition under which the for-each carries on, in continuation polarity — it stops before every element has been processed once this no longer holds |
|
|
no |
The body, carried out once for each element. |
|
|
list of LoopVariable |
no |
What changes across the loop’s iterations - a fold. Without these a loop reads the same values every time round, which for a While means it can never terminate. |
5.22. While
Repeats its body while a guard holds — the sibling of ForEach, not a merger with it. A ForEach terminates because its collection is finite; a While only because its guard eventually fails, which is why it alone carries maxIterations and why it carries no processingMode: iteration n+1 depends on the state after iteration n, so a parallel while is not a coherent thing to express.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
the guard, in continuation polarity — the loop proceeds while this holds |
|
|
boolean |
no |
whether the guard is tested before the first iteration (an ordinary while-loop) or after it (a do-until, whose body always runs at least once) Default: |
|
integer, at least 0 |
no |
an upper bound on iterations, when the modeller can state one — an integer rather than an expression so that it can be analysed, as BPMN’s loopMaximum is |
|
no |
The body, repeated while the guard holds. |
|
|
list of LoopVariable |
no |
What changes across the loop’s iterations - a fold. Without these a loop reads the same values every time round, which for a While means it can never terminate. |
5.23. LoopVariable
A process variable a loop carries across its iterations - a fold. Single assignment has one consequence that must be answered: if nothing is ever re-bound, a While guard reads the same values every time round and can never terminate. The two expressions are two fields because they are evaluated in two different environments: 'initialiser' at the loop, outside it; 'next' at the end of the body, inside it.
Specialises ProcessVariable, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
What the variable starts as, evaluated in the environment outside the loop. |
|
|
no |
What the variable becomes, evaluated in the environment at the end of the loop body. |
6. Events and messages
What a process waits for, reacts to and sends.
6.1. Event
What starts a Reaction: a message arriving, an interval elapsing, or a clock striking. An event is never a free-standing element — it is owned by the reaction it triggers and reached only through that reaction’s trigger.
One of MessageEvent, DurationEvent, DateTimeEvent, chosen by its variant.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
one of |
yes |
Which kind of event this is: the discriminator a reader dispatches on to the definition of that name. |
|
always |
no |
A constant marker that identifies an event on the wire; always true. |
6.2. MessageEvent
A message has arrived. dataStructure names the message itself, and that data structure is the shared element: a SendMessage naming the same one is what sends this message. That correlates receivers with senders — neither names the other; messageKey and expectedKey say which running instance of a receiver a message is for.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
Always MessageEvent: the discriminator a reader dispatches on. |
|
always |
no |
A constant marker that identifies an event on the wire; always true. |
|
string |
no |
Reference to the DataType that is the message, by ID |
|
string |
no |
Which instance this wait is for: a data path rooted at |
|
no |
The value a message’s messageKey must equal for it to reach this instance, evaluated in the receiver’s own scope when the wait opens ( |
6.3. MessageSendEvent
A message realising a post-condition may cause to be sent. An event, and deliberately not one a Reaction may be triggered by — those three say the model is waiting for something, this says the contract may cause something. dataStructure names the message itself, the same shared element a SendMessage and a MessageEvent name; recipient names the party addressed, as a role and never an address. There is no recipientSelector: a data path picking one instance of a party belongs to a particular send in a particular flow, not to the contract that permits it. A caller writes a MessageHandler naming this declaration, which is what correlates the two sides.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
Always MessageSendEvent: the discriminator a reader dispatches on. |
|
always |
no |
A constant marker that identifies an event on the wire; always true. |
|
string |
no |
Reference to the DataType that is the message, by ID |
|
one of |
no |
whether the message dispatches a unit of work exactly one consumer must discharge, or announces a fact any number of parties may react to Default: |
|
string |
no |
Reference by ID to the ResponsibilityDomain addressed — a role, never an address |
6.4. DurationEvent
An interval has elapsed, measured from the moment the process reached the gateway. There is deliberately no anchor field: the position in the flow is the anchor.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
Always DurationEvent: the discriminator a reader dispatches on. |
|
always |
no |
A constant marker that identifies an event on the wire; always true. |
|
string |
no |
ISO 8601 duration, e.g. 'PT72H' or 'P30D' |
|
boolean |
no |
Whether a deployment may supply a different value than the one written here. Absent or false means fixed, the default. The model keeps its own literal either way; this only ever permits an external fact to supersede it. No declared bound — state any reasonable one as prose in this event’s detailedDescription annotation instead. |
6.5. DateTimeEvent
A clock has struck. The time zone is required alongside the schedule because a cron expression names a wall-clock reading, and the UTC offset of a future local time is not knowable in advance — daylight-saving rules change between now and then.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
always |
no |
Always DateTimeEvent: the discriminator a reader dispatches on. |
|
always |
no |
A constant marker that identifies an event on the wire; always true. |
|
string |
no |
Five-field POSIX cron expression, e.g. '0 2 1 * *' |
|
string |
no |
IANA time-zone id whose wall clock the schedule is read against, e.g. 'Africa/Johannesburg' |
|
boolean |
no |
Whether a deployment may supply a different value than the one written here. Absent or false means fixed, the default. The model keeps its own literal either way; this only ever permits an external fact to supersede it. No declared bound — state any reasonable one as prose in this event’s detailedDescription annotation instead. |
6.6. EventTriggeredFlows
A branch whose flow is chosen by something happening rather than by a condition being tested. The process waits until one of the reactions' events occurs. Unlike AlternateFlows there is no default flow: there is no 'no event occurred' case to fall through to, so a default would be a flow that could never be taken. A timeout is a reaction triggered by a DurationEvent.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of Reaction |
no |
The flows, one per event awaited; the first event to occur selects its flow. |
6.7. Reaction
One flow of an EventTriggeredFlows: the activities carried out when its event occurs. The same shape as a ConditionalFlow — an activity sequence plus the one thing that says when it is taken. The trigger is owned, not referenced, so an event never appears anywhere else in the model.
Specialises ActivitySequence, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The event whose occurrence selects this flow. Owned by the reaction. |
6.8. MonitoredActivities
A stretch of a process watched for something happening while it runs — BPMN’s event sub-process, and its boundary events on a sub-process or a task. The monitors listen from entering the block until its body completes. A monitor’s activities see only what was bound before the block, never the body’s; after the block, what the body bound is in scope only when no monitor can interrupt it. One entry, one exit, as every block.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The body: the activities watched while they run. |
|
|
list of Monitor |
no |
The monitors listening while the body runs. |
6.9. Monitor
One monitor of a MonitoredActivities: what it listens for, whether it interrupts the body, and the activities it runs when it fires. The shape of a Reaction with a flag, and a different meaning: a reaction is chosen, a monitor fires — a non-interrupting one every time it fires, beside the body. The trigger is owned, as a reaction’s is.
Specialises ActivitySequence, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The event the monitor listens for. Owned by the monitor. |
|
|
boolean |
no |
Interrupting: when it fires the body is cancelled — waits and unclaimed tasks at once, work that may have committed waited for — then its activities run and the process continues after the block. Not interrupting: its activities run as a background lane each time it fires, and the body carries on. A BPMN boundary event’s distinction, with its default. Default: |
6.10. SendMessage
Sends a message — the other half of a MessageEvent. dataStructure names the message, and a reaction whose MessageEvent names that same data structure receives it. recipient names the party addressed and recipientSelector picks which instance of it; neither is an address, since how one reaches a party is a design decision. How many parties process the message is separate again, and is said by distribution.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to the DataType that is the message, by ID |
|
one of |
no |
whether the send dispatches a unit of work exactly one consumer must discharge, or announces a fact any number of parties may react to. It is stated on the sender because no other party holds the intent: the correlating data structure is a plain data type, and a single receiver looks the same under both. Default: |
|
string |
no |
Reference by ID to the ResponsibilityDomain that is the party addressed — a role, never an address. An email address or a queue name is a design decision, which is what lets one send be realised as an email to a private client and as a queue message to a corporate one; contact details are fields of the party’s own data structure, not of the message. Optional under both distributions, but a workItem naming none is a point-to-point send with no point, and process verification reports it. |
|
string |
no |
The data path identifying which instance of the recipient party is addressed, such as |
|
list of MessageConstraint |
no |
What the message carries, field-group by field-group, under |
|
no |
How this send is undone (a correction: a message cannot be unsent). Its request constraints read the process’s names at the step. |
|
|
string |
no |
That this send needs no undo, and why: what it commits lapses, or repeating it is harmless. Excludes 'compensation'. |
6.11. MessageConstraint
States one field-group of the message a SendMessage sends, as sent.<field> = … — what the receiver reads under message. ExceptionConstraint’s twin for a send; sent rather than message, since inside a message handler that is the message received. See docs/design/messageCorrelation.md §11.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
Mandatory: the whole reason to create an ExceptionConstraint is to state a body. |
6.12. AwaitMessage
Blocks until a message of a particular type arrives, then the process carries on — the receive task beside SendMessage’s send task. dataStructure names the message, the same element a SendMessage names to send it. Reach for this rather than an EventTriggeredFlows when the process is waiting rather than choosing: a single-reaction gateway says the same thing but draws a diamond, three edges and a merge to say it. There is no timeout — a wait that gives up is a branch, which is what an EventTriggeredFlows with a DurationEvent says.
Specialises Activity, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Reference to the DataType that is the message, by ID |
|
string |
no |
Which instance this wait is for: a data path rooted at |
|
no |
The value a message’s messageKey must equal for it to reach this instance, evaluated in the receiver’s own scope when the wait opens ( |
7. Decisions
Business rules realising a pure service contract, as DMN decisions.
7.1. Decision
A DMN decision: a realization of a service contract declaring isQuery, answering a request by rules (a decision table) or by one expression (a literal expression). Every cell is an element with its own id and formal specification.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Id of the pure service contract this decision realizes. |
|
one of |
no |
A decision table, or one literal expression filling the one output. |
|
one of |
no |
Which matching rules a table’s answer comes from. priority and outputOrder are read but refused: they rank outputs by allowed values URDAD does not record. |
|
one of |
no |
Under collect only: what the matched rules' outputs come to. count counts matched rules (DMN 1.2). |
|
list of DecisionInput |
no |
The input columns, in order. |
|
list of DecisionOutput |
no |
The output columns, in order. |
|
list of DecisionRule |
no |
The rules, in table order — which matters under first and ruleOrder. |
|
no |
For a literal-expression decision: the expression, over request, giving its one output. |
7.2. DecisionInput
An input column. Its name is what the cells test and what output cells and later inputs may name.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
What the input is, over request and earlier inputs, e.g. request.applicant.age. |
7.3. DecisionOutput
An output column, filling one field of the realized contract’s response.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
string |
no |
Id of a field of the realized contract’s response structure. |
7.4. DecisionRule
One rule of a decision table: a cell per input column, all of which must hold, and a cell per output column.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
list of DecisionInputEntry |
no |
One per input column, in order. |
|
list of DecisionOutputEntry |
no |
One per output column, in order. |
7.5. DecisionInputEntry
A rule’s condition on one input, stored as URDAD-OCL over the input’s name (age < 18); read in URDAD-FEEL as unary tests (< 18). Absent or empty matches anything.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The condition, in URDAD-OCL over the input’s name. Absent or empty matches anything. |
7.6. DecisionOutputEntry
A rule’s value for one output column. Absent or empty gives null.
Specialises Element, and has every attribute it has.
| Attribute | Type | Required | Meaning |
|---|---|---|---|
|
no |
The value, in URDAD-OCL. Absent or empty gives null. |
Acronyms and glossary
- A&D
-
Analysis and Design - the process for determining the stakeholder requirements and designing a solution fulfilling those requirements referring to BR.
- access right
-
the level of access a security policy grants on a responsibility domain or a whole model. In increasing order: `deny` (the domain is hidden), `read`, `annotate`, `modify` and `manage` (which additionally permits driving the project life cycle and managing project teams).
- ACL
-
Access Control List - a list attached to a resource, such as a file, naming which users or groups may access it and how, in addition to or in place of the resource’s basic permission bits.
- Activate
-
the last transition of the project life cycle, which merges an approved project’s branch into the main branch once its effective date has arrived, making its work part of the live model.
- activity
-
a step in a process: a service request, a message send or wait, a variable definition, or a construct grouping further activities such as alternate flows or concurrent flows.
- adapter
-
the thin, product-specific part of an integration with an external tool: it realises a bridge's contract for one product — GitLab, Azure DevOps, HashiCorp Vault, Kafka — by mapping the contract’s requests and results to that product’s API, and holds no logic that another product would also need.
- Advance
-
the generic step-forward transition of the project life cycle, moving a project to its next phase; its counterpart is Revert.
- AI
-
Artificial Intelligence - the field of computer science building systems that perform tasks normally requiring human intelligence. In the tool it means the optional assistance an LLM provides, for instance formalising informal requirements.
- AKS
-
Azure Kubernetes Service - Microsoft Azure’s managed Kubernetes platform, on which containers such as an instance’s images can be run.
- alternate flows
-
a branch in a process of which exactly one flow is taken: the first conditional flow, in their modelled order, whose condition holds, or the default flow when none does. All flows rejoin at a merge.
- AMQP
-
Advanced Message Queuing Protocol - an open wire-level protocol for message-oriented middleware, used by message brokers such as RabbitMQ to pass messages between systems.
- ANF
-
Administrative Normal Form - an intermediate form of a program in which every argument of an operation is a variable or a constant, each intermediate result being bound to a name of its own.
- annotation
-
free text attached to a model element and stored with it. Each annotation has a purpose (short or detailed description, informal requirement, comment, concern, question, response or error) and a markup type.
- anonymisation
-
an irreversible processing of personal data that completely prevents the identification of an individual by any means using any of the stored information. Unlike pseudonymised data, anonymised data is no longer subject to data protection regulations like GDPR.
- anonymous instance
-
an instance of the modelling tool with no sign-in, on which every visitor is the same anonymous reader who may open its models and change nothing — the configuration the public playground runs.
- API
-
Application Programming Interface - a set of rules or protocols that enables software applications to communicate with each other to exchange data and functionality.
- applies to the current state
-
what a service contract declares, with its reason, when its change to a stored entity instance applies to the instance as it is rather than to an entity version its requester read: an increment computed from the stored value inside the change’s own transaction, or a change meant to win.
- Approve
-
the transition from In Review to Approved. It records the approver’s signature and the effective date, and is refused unless every team member has signed off, every mandatory checklist item is signed and the separation-of-duties rules hold.
- ASCII
-
American Standard Code for Information Interchange - the 7-bit character encoding of the basic Latin letters, digits and punctuation, of which UTF-8 is a superset.
- AsciiDoc
-
a plain-text markup language for documents, readable as written and rendered by Asciidoctor to HTML, PDF and other formats. The tool writes a model’s generated documentation in it; both manuals are written in it too.
- AST
-
Abstract Syntax Tree - the tree a parser builds from source text, each node standing for one construct of the language, with the punctuation of the concrete syntax dropped.
- audit log
-
the append-only, per-project record of every governance-relevant event — phase transitions, sign-offs, approvals, role changes and the like. Rows are never updated or deleted; the actor is recorded as an opaque identifier.
- await message
-
an activity that stops a process until a message of a named data structure arrives.
- AWS
-
Amazon Web Services - Amazon’s cloud platform, offering hosted compute, storage and LLM endpoints among other services.
- BA
-
Business Analyst - a person who elicits, analyses and documents the requirements of a business and its stakeholders, typically one of the modellers of a URDAD model.
- background flow
-
a flow of concurrent flows that runs on independently and ends in a flow end of its own instead of arriving at the join.
- bounded context
-
in domain-driven design, the boundary within which one model, and the meaning of its terms, applies consistently; another context may model the same things differently, and exchanges with it are translated at the boundary.
- BPMN
-
Business Process Model and Notation - a public standard of the OMG for documenting and diagrammatically representing business processes.
- BR
-
Business Rule - a precise declarative statement that defines or constrains some aspect of an organization’s operations, behaviour or structure. It asserts business knowledge or intent, independent of the systems or manual processes used to implement it.
- bridge
-
the tool-neutral component through which the tool integrates with one responsibility domain it relies on outside itself — CI/CD gating, secrets, an identity directory, messages from a broker. It holds everything that does not depend on a product, and delegates the rest, through a logic-free contract, to one adapter per product.
- BRMS
-
Business Rule Management System - a repository and execution environment for hosting and executing business rules (BRs).
- C4 model
-
a notation for software architecture that describes a system at four levels of zoom: its context, its containers, their components and their code.
- CA
-
Certificate Authority - an entity that issues the digital certificates with which TLS and similar protocols establish the identity of a server or client.
- CAB
-
Change Advisory Board - the body which, in an ITSM change process, assesses, prioritises and approves or rejects a proposed change to a production service.
- cancellable
-
said of a service contract whose requesters may cancel a request before it is answered. A cancelled request has no net effect: the process realizing it undoes what it committed. A request for a service that is not cancellable is waited for when its requester is interrupted, and then undone through its contract’s compensation.
- candidate
-
a model commit, under an environment's current configuration, that the environment has evaluated and that may be promoted to become its pin.
- CDN
-
Content Delivery Network - a geographically distributed network of servers that caches and serves a site’s static content from a location close to each visitor.
- CEF
-
Common Event Format - ArcSight’s Common Event Format: one line per event, a fixed header of vendor, product, event type, name and severity, then `key=value` extensions. Most SIEMs read it from syslog.
- CI
-
Continuous Integration - the practice of building and testing every change automatically as it is integrated; also the pipeline that does so. See CI/CD.
- CI/CD
-
Continuous Integration / Continuous Delivery - the practice of building and testing every change automatically as it is integrated (CI), and of delivering or deploying what passes automatically (CD).
- CJS
-
CommonJS - the module format Node.js used before standard JavaScript modules, loading a module with `require` and exporting through `module.exports`.
- CLI
-
Command-Line Interface - a program operated by typing commands and arguments in a terminal rather than through a graphical UI.
- client
-
the party that requests a service: the one the service is offered to, and the one its response is for. A service contract's _Published to_ list names the responsibility domains that may be its clients from outside its own domain. A client need not be a stakeholder, nor a stakeholder a client. The client of one particular request is its _requester_; once a model runs, the identity a request is made as is its _caller_. Not to be confused with a software client, such as the web client or an OIDC client.
- cohesion
-
the degree to which what a component contains belongs together, because it serves one purpose or one responsibility. Good design seeks high cohesion.
- compensation
-
the request that undoes a change a step of a process committed, stated on the step or, as its _Undone by_, on the requested service contract. It runs when the process refuses after the change was made, so that the refusal has no net effect.
- Compliance Officer
-
the project role representing the compliance function on the project; mandatory for a regulated project.
:def-concurrent_flows:a construct of a process whose flows all start together at a fork. Unconditional flows and conditional flows whose condition holds arrive at a join, which waits for all of them; background flows run on independently.
- concurrent flows
-
{def-concurrent_flows}
- condition
-
a named boolean predicate, optionally with a formal specification.
- console
-
the execution environment's operating tool: the `console` command, which creates environments, applies configurations, promotes and rolls back, and the browser application over the API that `console serve` provides.
- CORS
-
Cross-Origin Resource Sharing - the browser mechanism by which a server permits a web page from another origin to call it; a request a server does not so permit is blocked by the browser.
- coupling
-
the degree to which one component depends on another, and so must change when the other does. Good design seeks low coupling.
- CPU
-
Central Processing Unit - the processor of a computer that executes a program’s instructions.
- CRUD
-
Create, Read, Update, Delete - the four basic operations on stored records.
- CSI
-
Container Storage Interface - the standard interface through which a container orchestrator such as Kubernetes mounts storage — and, through the Secrets Store CSI driver, secrets — into a container.
- CSV
-
Comma-Separated Values - a plain-text tabular format with one record per line and its fields separated by commas.
- CVI
-
Contract Verifying Interceptor - the component of an execution environment that judges each answer to a service request against the service contract it was made under — its pre-conditions, post-conditions and data constraints.
- dangling reference
-
an id held by one model element that does not or no longer resolves to any element in the model.
- data controller
-
the party that decides why and how personal data is processed.
- data dictionary
-
what an entity stores, attribute by attribute: each attribute’s type, role, multiplicity, uniqueness and personal data, the views whose fields of its name are stored in it, and the services that write it and the elements that read it — the entity’s lineage. Generated documentation carries one for every entity.
- data owner
-
whoever is accountable for the data a responsibility domain keeps: in an execution environment, the members of the identity-provider groups named for the domain, who accept each change to the shape of an entity it owns before it is promoted into production.
- data processor
-
a party that processes personal data.
- data structure
-
a structured data type with typed fields. It may specialize another data structure and may carry invariance constraints; a request, a response, an exception and a message are each described by one.
- DB
-
Database - an organised, persistent store of data and the software managing it.
- DDAD
-
Domain-Driven Analysis and Design - an analysis and design method where requirements and design is specified in terms of domain (business) concepts instead of technical concepts.
- decision
-
a model element that works out a response from a request by rules, as a decision table or a single literal expression. A decision changes nothing, so it is a way of realizing a function service.
- decision table
-
a decision made of inputs, outputs and rules, one rule per row; its hit policy says which applicable rules answer.
- dependency inversion principle
-
the design principle that higher-level policy should not depend on lower-level detail, but both on an abstraction; in URDAD, a process and the providers that answer its requests both depend on a service contract.
- descriptive level
-
the lowest verification level, and a new project’s: does each process address its contract’s requirements and state nothing that cannot hold. It does not ask what each request and response carries.
- design by contract
-
specifying what a component requires and what it guarantees as a contract of pre-conditions, post-conditions and invariants, which its client must satisfy and its provider must honour.
- DFS
-
Depth-First Search - a graph traversal that follows each path as far as it leads before backtracking; with three node colours it detects cycles.
- DI
-
Diagram Interchange - the part of the BPMN standard that records the layout of a process’s diagram — each shape’s bounds and each edge’s waypoints — alongside its semantics.
- directory feed
-
how the organisation’s identity provider tells the tool who has left: over SCIM, or by the tool reading the provider’s directory. A person the feed deactivates or deletes loses access and is later erased; the feed also supplies group names to the policy editor. The modelling server and the execution environment each have one.
- DNS
-
Domain Name System - the Internet’s directory, which resolves a host name to the network address of the machine serving it.
- domain schema
-
the PostgreSQL schema in which an execution environment keeps the records of the entities one responsibility domain owns, written only by that domain’s own database role, so that the database itself keeps each domain’s records apart.
- DORA
-
Digital Operational Resilience Act - an EU regulation which stipulates standards for managing ICT risks, third-party provider oversight, sharing of ICT incidents and for testing and auditing ICT processes.
- DSD
-
Data Structure Diagram - the diagram of a URDAD model showing a data structure: its fields and its relationships to other data structures.
- EA
-
Enterprise Architect - a person responsible for the structure of an organisation’s business, information and technology landscape as a whole, and for keeping individual solutions consistent with it.
- EBNF
-
Extended Backus–Naur Form - a notation for writing down the grammar of a language as rules, each naming the sequences, alternatives, options and repetitions of words a construct is made of; the URDAD-OCL and URDAD-FEEL grammars are written in it, as ISO/IEC 14977 standardises it.
- element library
-
a model whose purpose is to hold definitions shared by several models. A model associates with a fixed published revision of a library and may reference its elements, but never change them.
- EMF
-
Eclipse Modeling Framework - an Eclipse framework and code-generation facility for building tools from a model expressed in EMOF (Ecore).
- entity
-
a data object with identity used to store data which is typically persisted in a database.
- entity feed
-
the property of a data structure naming the entity it is a view of. An entity’s fields are not authored directly but are the union of the fields stated by the data structures that feed it.
- entity migration
-
the declared steps that carry an entity's stored instances across a change to its shape, which a promotion applies to every instance, each rewrite recorded in the instance’s history.
- entity version
-
which version of a stored entity instance was read. The store numbers each instance’s versions and fills an entity’s *version* field on every read; a change to the instance names the version it was decided on, and is refused once the instance has moved past it.
- environment
-
in the execution environment, one running deployment of a model — of kind `development`, `test`, `production` or `preview` — with a configuration saying who answers each service contract, a promotion policy and a current pin.
- erasure
-
the deletion of all personal data - a right provided by data protection regulations like GDPR.
- event-triggered flows
-
a branch in a process whose flow is chosen by an event occurring — a message arriving, a duration elapsing or a clock striking — rather than by a condition being tested.
- exception
-
a named data structure raised to tell a service’s client that a pre-condition was violated and the service has been refused.
- exception handler
-
the part of a service request that says what the calling process does when the requested service raises a particular exception. Every exception the requested service may raise must be handled.
- executable level
-
the highest verification level: is each process formal enough to run in the execution environment. What the environment cannot build or follow, or its promotion gate refuses, is an error at this level.
- execution environment
-
the optional deployable that runs a model’s processes for real, on Temporal. It is installed and operated separately from the modelling tool, which does not depend on it.
- expanded service request
-
a service request drawn, in a Process View, as the process that realizes the requested service rather than as a box naming it. Expansion is a viewer’s choice of what to see, not part of the model, and what an expanded request shows is read-only.
- expression
-
a pure expression is a mapping of variables onto some value.
- FEEL
-
Friendly Enough Expression Language - the expression language of DMN, written to read like business prose. URDAD-FEEL, a profile of it, is one of the two notations in which a formal specification may be read and written.
- FFI
-
Foreign Function Interface - the mechanism by which code in one programming language calls functions written in another.
- finding
-
one result of model verification or of evaluating a candidate, carrying a severity.
- formal specification
-
a condition, constraint or expression written in a formal language — URDAD-OCL, or equivalently URDAD-FEEL — so that the tool can check and evaluate it. The model stores every formal specification in URDAD-OCL.
- function service
-
a service whose contract declares it pure: requesting it yields an answer and changes nothing. A process realizing it may only orchestrate other functions.
- functional requirement
-
a requirement a service contract places on the service it specifies — one of its pre-conditions or post-conditions — which a realizing process allocates to the activities that address it.
- FX
-
Foreign Exchange - the exchange of one currency for another, and the market in which it takes place.
- gateway
-
the component of an environment through which external systems request the model’s published services.
- GCC
-
GNU Compiler Collection - the GNU project’s compilers for C, C++ and other languages.
- GDPR
-
General Data Protection Regulation - the European Union regulation governing the processing of personal data.
- governance profile
-
per-project metadata captured during Planning and frozen afterwards: whether the project is regulated, its regulatory regimes, risk and data classification, stakeholders, whether its processes will be executed, and its target activation date.
- GPU
-
Graphics Processing Unit - a massively parallel processor, originally for rendering graphics, on which LLMs are run efficiently.
- GRC
-
Governance, Risk and Compliance - the coordinated management of an organisation’s governance, its risks and its compliance with laws, regulations and internal policies; also the class of tools that record its controls and the evidence that each is met.
- hash chain
-
a sequence of records each of which carries a cryptographic hash of its own content and the hash of the record before it, so that altering, removing or reordering a record already written is detected by recomputing the hashes.
- HEAD
-
in git, the commit a branch currently points to — its latest commit; the HEAD of `main` is the current state of the main branch.
- high-volume entity
-
an entity an execution environment's configuration lists as holding too many instances to read whole: a condition reading its population there must be narrowed, by an equality on a stored field or a date-time window, or the promotion is refused.
- hit policy
-
the rule of a decision table saying which of the rules that apply give its answer — for instance `UNIQUE`, `FIRST` or `ANY`.
- HMAC
-
Hash-based Message Authentication Code - a code computed from a message and a secret key with a cryptographic hash function, with which a receiver holding the key verifies that the message is authentic and unaltered.
- HSTS
-
HTTP Strict Transport Security - a response header by which a site instructs browsers to reach it only over HTTPS from then on.
- HTML
-
Hypertext Markup Language - the markup language of web pages.
- HTTP
-
Hypertext Transfer Protocol - the request/response protocol of the web, used by browsers and by systems calling each other’s APIs.
- human task
-
a request for a service that a person answers. The execution environment offers it to the people of the responsible responsibility domain in the task portal, where one of them claims and completes it.
- IANA
-
Internet Assigned Numbers Authority - the body coordinating the Internet’s global identifiers — among them media types, port numbers and, through the time-zone database, the IANA time zones.
- IANA time zone
-
a time zone named by its identifier in the time zone database maintained by the Internet Assigned Numbers Authority, such as `Africa/Johannesburg`. It, unlike a fixed offset, accounts for daylight-saving rules.
- ICT
-
Information and Communication Technology - encompasses all communication technologies, media, and infrastructure used to capture, process, store, transmit, and display information.
- ID
-
Identifier - a value that names one thing uniquely within some scope, such as a template’s or an event’s ID.
- identity provider
-
the organisation’s sign-in service, which authenticates people and services and states which groups they belong to. The tool holds no passwords of its own and relies on one speaking OIDC.
- informal requirement
-
a requirement as originally stated, in prose, before it has been formalised into model elements. It is held as an annotation.
- information hiding
-
the principle of hiding, behind a component’s interface, the design decisions most likely to change, so that changing them does not affect the component’s users.
- integration run
-
the part of a unit test run in which all of an environment’s processes run together, so that their interactions are tested.
- invariance constraint
-
a constraint which must always hold true, a state where an invariance constraint is not met should not be observable.
- invariant
- inversion of control
-
the arrangement in which a component does not choose the components it relies on, but has them chosen and supplied by whatever runs it; in URDAD, an environment chooses who answers each service contract a process requests.
- IP
-
Internet Protocol - the protocol addressing and routing packets between hosts on the Internet; an IP address identifies one host or network interface.
- IR
-
Intermediate Representation - a data structure a compiler or engine translates its input into before producing its output, so that several front ends can share one back end.
- ISO
-
International Organization for Standardization - the international body that develops and publishes standards such as ISO 8601 and ISO/IEC/IEEE 42010.
- ISO 8601
-
ISO 8601 Date and time — Representations for information interchange - the international standard for writing dates, times and amounts of time, such as `2026-10-15T09:30:00+02:00` or the duration `PT72H`.
- ISO/IEC/IEEE 42010
-
ISO/IEC/IEEE 42010:2022 Software, systems and enterprise — Architecture description - the international standard for describing the architecture of software, systems and enterprises. It requires a rationale to be recorded for architectural decisions.
- IT
-
Information Technology - the computer systems, networks and software through which an organisation stores, processes and communicates information, and the function that runs them.
- ITSM
-
IT Service Management - the discipline by which an organisation designs, delivers, operates and changes the IT services it offers, including the requesting, approval and recording of each change to them; also the class of tools, such as ServiceNow, that support it.
- JMS
-
Jakarta Messaging (formerly Java Message Service) - the Java API for sending and receiving messages through message-oriented middleware.
- JS
-
JavaScript - the programming language of the web browser, also run on servers by Node.js.
- JSON
-
JavaScript Object Notation - a lightweight, text-based format for structured data. Models, exports and configurations are stored and exchanged in it.
- JWKS
-
JSON Web Key Set - a JSON document, published by an identity provider, holding the public keys with which the signatures of the tokens it issues are verified.
- JWT
-
JSON Web Token - a compact, signed JSON token carrying claims about a subject, such as the access and ID tokens an OIDC identity provider issues.
- KV
-
Key-Value - a store or cache addressing each value by a key. An LLM runtime’s KV cache holds the attention keys and values computed for a prompt prefix, so a repeated prefix is not recomputed.
- KYC
-
Know Your Customer - the regulatory obligation on financial institutions to verify the identity of their customers and assess their risk, with records they must retain. Compare AML.
- lane
-
one of the flows into which a construct branches a process: a flow of concurrent flows or alternate flows, one outcome of a service request, or one parallel instance of a multi-instance request.
- layout engine
-
the tool’s component, written in Rust, that lays out and draws every diagram of a model — in the browser as WASM, and on the server for generated documentation and the manuals.
- LLM
-
Large Language Model - a machine-learning model trained on large amounts of text, able to read and produce natural language. The tool calls one, through providers an administrator configures, for its AI assistance.
- MC/DC
-
Modified Condition/Decision Coverage - a test-coverage criterion requiring that every condition in a decision be shown, by a pair of tests differing in that condition alone, to affect the decision’s outcome independently; required by some regulatory regimes.
- merge base
-
the most recent commit that a project's branch and the main branch have in common; the common ancestor of a three-way merge.
- message correlation
-
the statement, on a wait for a message, of which running instance of a process the message is for: a key read from the message and the value that key must match.
- message handler
-
the part of a service request that says what the caller does with a message the requested service declares it may send. It runs as a background flow.
- microservice
-
a small, independently deployable service, owning its own data, that provides the capabilities of one business responsibility.
- MiFID II
-
Markets in Financial Instruments Directive II - an EU directive that, together with Regulation (EU) No 600/2014, provides a legal framework for securities markets, investment intermediaries and trading venues.
- MIME type
-
Multipurpose Internet Mail Extensions - the type label of a file or message body, such as `text/html` or `application/json` (also called a media type), registered with IANA.
- model root
-
the top-level element of a URDAD model, which contains its responsibility domains; an access right granted on it applies to the whole model.
- model tree
-
the modelling tool’s panel showing a model’s elements as a tree of responsibility domains and their contents, from which an element is selected, opened or acted on.
- model verification
-
the tool’s on-demand, deterministic check of whether a model is internally consistent — that its references resolve and its processes discharge what their contracts require. It reports findings at a chosen verification level.
- monitor
-
one watcher of a stretch of monitored activities: a triggering event — a message, a duration or a clock — and the activities run when it fires, either *interrupting* the monitored activities or running beside them.
- multi-instance request
-
a service request asking one service of several providers, either in parallel or in sequence.
- NFS
-
Network File System - a protocol through which a host mounts a file system served by another over the network.
- notification
-
a message announcing that something has happened. Any number of parties may react to it, and none is obliged to. Compare work item.
- OCL
-
Object Constraint Language - a standard of the OMG for writing precise constraints and queries over a model. URDAD-OCL, a profile of it, is the language in which the model stores every formal specification.
- OIDC
-
OpenID Connect - an identity layer on top of OAuth 2.0 through which an application lets an identity provider authenticate its users and learns who they are and which groups they belong to.
- opaque identifier
-
a random identifier, such as `u_9f3c1a…`, that stands for a user in every permanent record. Only the user directory links it to a person, so deleting that one entry de-identifies the person everywhere; see pseudonymisation.
- optimistic concurrency control
-
a way of keeping concurrent changes from overwriting one another without locking: a change names the version of the data it was decided on, and is refused if the data has changed since. URDAD does this with entity versions.
- OS
-
Operating System - the software managing a computer’s hardware and providing common services to the programs running on it.
- OTLP
-
OpenTelemetry Protocol - the vendor-neutral protocol by which OpenTelemetry exports logs, traces and metrics to a collector or observability back end.
- owning domain
-
the responsibility domain that directly contains an entity. In an execution environment only a realization of a service contract of that same domain may write or delete the entity’s instances; another domain asks for a change through one of the owning domain’s contracts.
-
Portable Document Format - a fixed-layout document format that renders the same on any device or printer.
- PEM
-
Privacy-Enhanced Mail - the text encoding of keys and certificates as Base64 between `-----BEGIN …-----` and `-----END …-----` lines.
- personal data
-
any information that can identify a specific person, such as names, addresses, email addresses, and even IP addresses.
- phase
-
one of the six stages a project moves through: Initiation, Planning, Development, In Review, Approved and Active. Each phase constrains what the team may do.
- phase gate
-
the checks the server runs before a transition into In Review or Approved — among them that the branch is not stale, that no semantic conflict exists and that no reference dangles.
- PII
-
Personally Identifiable Information - see personal data.
- pin
-
the model commit and configuration revision on which an environment starts new executions.
- PKCE
-
Proof Key for Code Exchange - an extension of the OAuth 2.0 authorization-code flow that protects the code from interception, allowing a browser application, which cannot keep a secret, to sign in safely.
- PKCS
-
Public-Key Cryptography Standards - a family of standards for public-key cryptography; PKCS #8, for instance, is a format for private keys.
- PNG
-
Portable Network Graphics - a lossless raster image format.
- POPIA
-
Protection of Personal Information Act - South Africa’s data-protection legislation similar to Europe’s GDPR.
- ports and adapters
-
an architectural style, also called hexagonal architecture, in which an application’s core interacts with the outside world only through technology-neutral interfaces, its ports, each connected to a particular person, system or technology by an adapter. The tool’s integration adapters are one instance of it.
- POSIX
-
Portable Operating System Interface - the IEEE family of standards for Unix-like operating systems, which also fixes the syntax of `cron` schedules and of time-zone strings.
- post-condition
-
a condition which must hold true after the service has been provided. A post-condition typically specifies a required result of some of the activities performed in a process realizing the service contract.
- pre-condition
-
a condition which must hold true for the service to be provided. If a pre-condition does not hold true, the service is to be refused.
- predicate
-
an expression which returns true or false.
- preview environment
-
an environment that runs a project's branch rather than the main branch, so the team can try its processes before approval. It may exist only for a project that has consented to it.
- process
-
the business process realizing a service contract: the activities it carries out, and the control flow connecting them.
- project
-
the unit in which a model is changed. A project works on its own branch of the model, cut from the main branch, and moves through a fixed sequence of phases until it is activated or archived.
- Project Manager
-
the project role that drives the project through its life cycle, held automatically by every user on the project’s leads list.
- promotion
-
making a candidate an environment's current pin, automatically or by a person according to the environment’s promotion policy.
- promotion gate
-
the evaluation an environment makes of each candidate before it can be promoted, producing findings.
- provider selector
-
a path over the data a service request can reach, saying which provider of the requested contract is asked. Left empty, whoever provides the contract is asked.
- pseudonymisation
-
the process of replacing direct identifiers in a dataset with artificial codes or references, such that the data can no longer be attributed to a specific individual without access to a separately held “key” or mapping table. This is less rigid than anonymisation and data protection regulations like GDPR still apply to pseudonymised data.
- PSD2
-
Payment Services Directive 2 - an EU directive that aims to enhance the safety and security of payment services and promote innovation and competition in the market. It covers topics such as authorisation, supervision, information, rights and obligations, and access to accounts and payment systems.
- published read model
-
the entities an owning domain lets other named responsibility domains read directly, entity by entity (an entity’s *Readable by*). A domain listed may read the entity’s stored fields that are not personal data; every other domain asks the owner’s query services.
- published to
-
the set of responsibility domains that may request a service contract. An empty set means the service is internal to its own domain.
- purge
-
the deletion of every record a retired environment leaves in the execution environment, its audit log included, so that nothing of it remains and its name may be used again. It cannot be undone.
- query service
-
a service contract declared a function that answers what an owning domain keeps about one instance of its entity: *get<Entity>* by its identifying field, and *find<Entity>By<Field>* by each field marked unique. The modelling tool generates them from the entity’s view, and another domain’s condition applies one rather than reading the owner’s records.
- RACI
-
Responsible, Accountable, Consulted, Informed - a matrix assigning, for each task or decision, who does it, who answers for it, who is consulted and who is kept informed.
- RD
-
Responsibility Domain - short for responsibility domain.
- realization
-
how a service contract is met. In the model, by a process or a decision; in an environment, by whatever its configuration names — a process, a decision, a person, a coded implementation, an external system or a stub.
- rebase
-
bringing a project's branch up to date with the main branch by a three-way merge, written as a single new commit on top of main. The server does this automatically whenever main moves.
- regulated project
-
a project whose governance profile marks it as subject to compliance requirements. It receives the compliance checklists and cannot be approved without a Compliance Officer’s sign-off.
- regulatory regime
-
a body of regulation a project falls under, such as GDPR or DORA. Regimes are maintained by auditors and decide which checklist templates attach to a regulated project.
- reporting view
-
a typed SQL view of one entity's current records, which an execution environment on PostgreSQL makes at each promotion for other systems to read: one column per stored field that is not personal data, read by a reporting role that can read nothing else.
- residue
-
what testing a project could not cover — a partition the generator could not decide, a check that reached no verdict, an unreachable branch, a service the integration run answered with a stand-in; each item must be disposed of on the residue checklist before the project is approved.
- RFC
-
Request for Comments - a document in the series through which the Internet Engineering Task Force publishes Internet standards, such as RFC 7636, which defines PKCE.
- SARIF
-
Static Analysis Results Interchange Format - an OASIS standard JSON format in which static-analysis and security-scanning tools report their findings.
- SASL
-
Simple Authentication and Security Layer - a framework by which connection-oriented protocols such as AMQP and Kafka’s negotiate an authentication mechanism, for instance `PLAIN` or `SCRAM`.
- SAST
-
Static Application Security Testing - the analysis of an application’s source code, without running it, for security vulnerabilities.
- SCSS
-
Sassy CSS - the syntax of the Sass style-sheet language, a superset of CSS adding variables, nesting and mixins, compiled to CSS at build time.
- SDK
-
Software Development Kit - a set of libraries and tools for building software against a particular platform or service, such as Temporal’s SDK for writing workers.
- service request
-
the activity at which a process requests a service, naming the service contract it requires rather than a particular provider.
- responsibility domain
-
the packaging unit of a URDAD model, mirroring an organisational unit or an external party. It owns service contracts, data types, processes and nested responsibility domains, and is what security policies grant access to.
- retired environment
-
an environment whose retirement has been decided: its components are stopped, its executions cancelled and its stored data deleted, while its record and audit log are kept until it is purged.
- Revert
-
the generic step-back transition of the project life cycle, returning a project to an earlier phase.
- scheduled trigger
-
the statement on a service contract that its service runs on the calendar’s initiative: a cron expression and the IANA time zone it is read against.
- SCIM
-
System for Cross-domain Identity Management - an open standard (RFC 7643, 7644) by which an identity provider provisions people and groups to an application — creating, updating, deactivating and deleting them — rather than the application asking. The tool’s directory feed may take this form.
- secret reference
-
the name a configuration gives a credential instead of the credential itself — `ai-gateway-api-key`, `directory-client`. The tool resolves it, when the credential is needed, from an environment variable, an owner-only file or the deployment’s secret store, so no configuration file, response or log line holds the value.
- secret store
-
where a deployment keeps the credentials its secret references name: the organisation’s vault (HashiCorp Vault, Azure Key Vault), or the tool’s own local store of owner-only files when it has none.
- security policy
-
an administrator-defined rule granting users whose identity-provider groups match its selector an access right on a responsibility domain or a whole model.
- semantic conflict
-
the case in which a project and the main branch have both changed the same model element since their merge base. The tool reports it for a person to reconcile rather than choosing a side.
- separation of duties
-
SoD - the principle that no one person both produces a change and approves it. The tool enforces it at the Approve gate.
- service contract
-
the specification of a service’s functional requirements: its request and response data structures, pre-conditions, post-conditions and the stakeholders requiring them. It is offered to its clients. A contract may specialize another.
- severity
-
how a finding is to be read. An error says the model states something that cannot hold; a warning, that the model is silent where it could speak; information, that a default applies.
- SIEM
-
Security Information and Event Management - the system in which an organisation’s security operations centre collects, correlates and searches security events from its applications and infrastructure, and raises alerts on them. The tool streams its own to one (security event export).
- single responsibility principle
-
the design principle that a component should have a single responsibility, and hence a single reason to change.
- SLA
-
Service-Level Agreement - an agreement between a service’s provider and its consumer on the service’s measurable qualities, such as its availability and response time.
- SMB
-
Server Message Block - the network file-sharing protocol of Windows, also served by Samba.
- SMTP
-
Simple Mail Transfer Protocol - the protocol by which e-mail is sent and relayed between mail servers.
- Solvency II
-
an EU directive that codifies and harmonises the EU insurance regulations covering aspects like the capital that an insurance company must hold to prevent insolvency.
- specialization
-
the relation in which one service contract or data structure extends another, its base. A specializing contract inherits its base’s requirements, may add post-conditions and may waive, but never add, pre-conditions.
- specified level
-
the middle verification level: each request and response says what it carries, each contract promises what it must and each field has a type, without saying how a payload is built.
- SQL
-
Structured Query Language - the standard language for defining, querying and changing data in a relational database.
- SSH
-
Secure Shell - a protocol for authenticated, encrypted remote login and command execution, also used to authenticate git over the network.
- SSO
-
Single Sign-On - an arrangement in which a user signs in once with an identity provider and is then signed in to several applications.
- stakeholder
-
a party with an interest in a service, and hence one that may place requirements on it — among them the business itself, a regulator, legislation on behalf of the population as a whole, and even a service provider that needs something in order to provide the service. In a model, a service contract's stakeholders are the parties, usually responsibility domains, that its pre-conditions and post-conditions name as requiring them. A stakeholder need not be a client. A project's governance profile lists the stakeholders of what the project delivers.
- stale
-
the state of a project whose merge base is no longer the head of the main branch because main has moved since; the opposite is fresh.
- SVG
-
Scalable Vector Graphics - the XML-based vector image format of the web, in which the tool renders its diagrams.
- syslog
-
the standard way (RFC 5424) of sending log messages over the network to a collector; the transport most SIEMs accept, usually carrying CEF.
- task portal
-
the web page on which people claim and complete the human tasks of their responsibility domains. Each task service serves it for its environment.
- task service
-
the component of an environment that holds its human tasks and the tasks external systems claim, and serves the task portal.
- TCK
-
Technology Compatibility Kit - a suite of tests published alongside a specification to check that an implementation conforms to it, such as the DMN TCK.
- Temporal
-
an open-source durable-execution platform that keeps the state of long-running workflows so they survive restarts and failures. The execution environment runs a model’s processes on it.
- tenant
-
one instance of the modelling tool, serving one organisation; tenants are separate instances rather than partitions of one.
- three-way merge
-
combining two versions of a model using the version they share, their merge base, element by element and field by field. A change made on one side only is carried through; one made on both sides is a conflict.
- TLS
-
Transport Layer Security - the cryptographic protocol securing network connections, such as HTTP as HTTPS.
- ubiquitous language
-
a shared language with defined concepts which is understood across business and technical role players as well as across responsibility domains. Terms map directly onto responsibility domains, data types and entities, and onto services and operations.
- UI
-
User Interface - the part of a system through which a person operates it, such as the modelling tool’s browser client.
- UML
-
Unified Modeling Language - the OMG's general-purpose graphical language for specifying, visualising and documenting software and business systems.
- UMT
-
URDAD Modeling Tool - a tool enabling cross-functional teams across the organization to collaboratively develop and maintain an URDAD business model.
- Undo step
-
a step that undoes everything its process has committed so far, by the same compensations a refusal runs, and then carries on. It is how a process takes back what it did when the outcome is not a refusal, such as a withdrawal after acceptance.
- unit test run
-
a run of an environment's processes — typically a project’s preview — against cases generated wholly from the model: each process on its own with what it requests stubbed, then all of them together in the integration run.
- URDAD
-
Use-Case/Responsibility Driven Analysis & Design - a systematic Domain-Driven Analysis and Design method used to develop and maintain an organization-wide business model containing service contracts, business process specifications across levels of granularity and domains of responsibility.
- URDAD-Admin
-
the organisation-scoped role, conferred by membership of an identity-provider group, of administering the tool: creating models and libraries, defining security policies and configuring the instance.
- URDAD-Auditor
-
the organisation-scoped role, conferred by membership of an identity-provider group, of auditing: reading every audit log and maintaining the checklist templates and regulatory regimes.
- URDAD-FEEL
-
the profile of FEEL in which a formal specification may be read and written instead of URDAD-OCL.
- URDAD-OCL
-
the profile of OCL in which the model stores every formal specification: pre- and post-conditions, invariances, flow conditions and loop continuation conditions.
- URL
-
Uniform Resource Locator - the address of a resource on the web, such as `https://urdad.example.org`.
- use case
-
a service a stakeholder requires, specified in URDAD by a service contract and realized by a process.
- UTC
-
Coordinated Universal Time - the world’s primary time standard, against which every time-zone offset is stated.
- UUID
-
Universally Unique Identifier - a 128-bit identifier generated so that it is, for practical purposes, unique without any central coordination.
- UX
-
User Experience - the overall experience of a person using a product, including how easy and pleasant it is to use.
- value object
-
a data object used to exchange information.
- verification level
-
what model verification asks of a model, depending on what it is for: one of three ordered levels, the descriptive, specified and executable, each asking everything the one below it does. A project’s level is set on its governance profile and can be raised, never lowered.
- VM
-
Virtual Machine - a computer emulated in software on a physical host, running its own operating system.
- waived pre-condition
-
a pre-condition inherited from a base contract that a specializing service contract does not impose, so that the specialization accepts requests its base would refuse.
- WAL
-
Write-Ahead Log - a database’s log of changes, written before the changes themselves are applied, from which it recovers after a crash and through which a replica or backup is kept up to date.
- WASM
-
WebAssembly - a portable binary instruction format that browsers execute at near-native speed; the tool’s diagram layout engine, written in Rust, runs in the browser as WASM.
- work item
-
a message dispatching a unit of work that exactly one consumer must discharge, however many are listening. Compare notification.
- worker
-
the component of an environment that executes its processes, polling Temporal for work, and offers the coded implementations of `automated` realizations.
- workload identity
-
an identity a cloud platform gives a running workload — an Azure managed identity for a host, a workload identity for a Kubernetes pod — with which it obtains tokens for other services without holding any key or secret of its own.
- XML
-
Extensible Markup Language - a markup language for structured documents and data, nesting named elements carrying attributes.
- YAML
-
YAML Ain’t Markup Language - a human-readable data-serialisation format, a superset of JSON, used chiefly for configuration files.