Execute and test
Optionally, run and test the approved model itself, so that what was specified is what runs and the tests come from the model.
The optional execution environment runs the model’s processes as the model states them. What was specified is thus what runs, as there is no hand-written program to drift from the model.
Only what was approved runs
Each environment runs one model’s approved version, i.e. only what a project team signed off. A new version needs no build and no redeployment, and work already running finishes on the version it started on.
In the manual: running a model
Nothing half-done
A new version is first a candidate. Anything which cannot run is refused before anything starts, and never half-way through. Each environment promotes new versions automatically, by hand, or not at all, and a promotion can be rolled back.
People and the systems you already have
Where a process needs a person, that person answers a task in the task portal, on a form generated from the model. Where it needs one of your existing systems, it calls it. For each service, configuration says who answers it, and changing who answers changes no process.
In the manual: who answers each contract
Every answer checked
Every answer, whether a person’s, a system’s or a process’s, is checked against the service’s contract, and a broken one names the party at fault. A refusal undoes what was already done, and work which takes too long is chased, escalated or withdrawn.
In the manual: contract violations
Every request checked
What a request must be in itself, e.g. an amount which is positive or a period which ends after it starts, is stated once on the request, and not in every process which handles it. Every service refuses a request which breaks it before anything starts, and says what is wrong field by field. The task portal furthermore shows the same problem at the field before the form is sent.
In the manual: invalid requests
Tests nobody writes
A test run exercises every process against cases generated wholly from the model. For each service it finds a case where every pre-condition holds, a case where each one fails, a case breaking each rule of what a request must be, and a case down every branch of the process and every way a service it uses can refuse. Each process is tested first on its own, with the services it uses answering as their contracts say they would, and then all of them together. The contracts themselves decide what counts as correct. Hence, nobody writes a test, a stub or a data set, and nobody states the expected result by hand.
The report measures coverage per service, i.e. every refusal and every branch, and condition by condition where a regulation demands it. It also says what was not covered and why. Signed by the environment that produced it, it is what a project’s testing phase is signed off on.
For architects
- Processes run on Temporal’s durable workflows; environments and candidates.
- External systems over HTTP, Kafka and AMQP; people through the task portal and human tasks.
- Compensations and monitored activities.
- Test runs on Temporal’s time-skipping test server, so a month’s deadline passes in a moment; MC/DC coverage where a regime requires it; the report is submitted to the modelling server.
- Operators use the console; executions are recorded for auditors and streamed as events to monitoring and SIEM tools.