Development Plans

Products

Spiral — a dynamic scheduling optimisation engine.
Travel Calculator — an optional Spiral extension integrating the OSRM routing engine, with support for other routing solutions through Spiral’s open interface.
Helix — Spiral Workforce Management: a web-hosted field workforce management solution for SMEs and enterprises, cloud or on-premises, with modules for field workers, deployment control and order management.

Versions

Application	Version	Name	State	Release date	Supported
Spiral	1.0	Basic Scheduling	Released	01/08/2022	No
Travel Calculator	1.1	Embedded OSRM	Released	05/03/2025	Yes
Spiral	1.8	Constraints	Released	27/03/2025	No
Spiral	2.0	Input Interpretation	Released	02/09/2025	No
Spiral	2.1	Offer	Released	01/12/2025	No
Spiral	2.2	Predicted Income	Released	01/03/2026	No
Spiral	2.3	Declarative	Released	01/06/2026	Yes
Helix	0.0.1 – 0.0.2	Dispatch and Applications	Released	28/07/2026	No
Spiral	2.4	Surge 2	Released	01/08/2026	Yes
Helix	0.0.3 – 0.0.4	Supported Core	Released	20/08/2026	No
Helix	0.0.5 – 0.0.6	Logistics Hubs and Roster States	Released	26/08/2026	No
Helix	0.0.7 – 0.0.8	Standby Callout and Notifications	Released	28/08/2026	No
Helix	0.0.9	Actions Taxonomy	Released	01/09/2026	Yes
Helix	0.0.10	Audit and Archiving	Released	03/09/2026	Yes
Helix	0.0.11	SME Demo	Released	03/09/2026	Yes
Helix	0.0.12	Mobile Application	Released	04/09/2026	Yes
Spiral	2.5	Logistics Hubs	Released	07/09/2026	Yes
Helix	0.0.13	Spiral Laboratory	Released	07/09/2026	Yes
Helix	0.0.14	Release Management	Released	28/09/2026	Yes
Helix	0.0.15	Mission Control	Released	30/09/2026	Yes
Helix	0.0.16	Containerisation	Released	05/10/2026	Yes
Helix	0.0.17	OSRM routing	Released	06/10/2026	Yes
Helix	0.0.18	Break windows	Released	09/10/2026	Yes
Helix	0.1	Prototype	Test	01/11/2026	—
Spiral	2.6	Break management	Released	09/10/2026	Yes
Spiral	3.0	Assets	Design	01/01/2027	—
Helix	0.2	Assets	Design	01/01/2027	—

Helix milestones

Helix reaches its 0.1 Prototype milestone through the 0.0.x core series. Each milestone below names the releases that built it.

0.0.1 – 0.0.2 · Dispatch and Applications. The surface itself: the dispatch screen, and the applications beside it — the Contact Centre, the Engineer app, Administration and Mission Control. Also the actions engine, surge zones, and multi-node clustering.
0.0.3 – 0.0.4 · Supported Core. The first officially released core. Its headline was delivery: the plan now arrives as a single bulk snapshot rather than thousands of per-event deltas, taking a 10,000-job stress test from around two and three-quarter minutes to sixteen seconds. Version pinning and bundle-core provenance arrived with it, so a node can always say which core it runs.
0.0.5 – 0.0.6 · Logistics Hubs and Roster States. The hub entity, matching Spiral’s staging-point work. Rosters gained off-duty shift states, so a resource’s status through its shift is derived rather than asserted, and scenario and live timing moved onto one shared event queue.
0.0.7 – 0.0.8 · Standby Callout and Notifications. The standby callout end to end — called, offered, accepted or refused, stood down on timeout — and the notification toolkit underneath it: an outbound queue with retry, pluggable channels, and inbound replies that close the loop.
0.0.9 · Actions Taxonomy. A systematic pass over what the operator is asked to do and when — processes composed of steps and actions — alongside eternal rosters and a reconciled location model.
0.0.10 · Audit and Archiving. What is recorded and for how long, where it is kept once it leaves the live system, and how a node that has been running for years is kept to the work that still matters — the audit trail, the client identity doors and header/extension split, and the archive framework.
0.0.11 · SME Demo. The “build your own Helix” journey: register with an email, set your business up from a sector template — mobile trades, delivery and collection, mobile vehicle services — and keep a working Helix you can start, stop and tune. A business is a domain file and nothing else: the image’s own stock client serves it, the example day is derived from it, and every tune is kept with the account. The first step of a progression that leads to a hosted service; the self-config wizard now works on any client, and the core gained the trade vans.
0.0.12 · Mobile Application. The engineer in the field on their own device: one generic hybrid shell for iOS and Android, a lean entry that opens straight into the day’s work, shift-bound location tracking, an offline outbox that survives a tunnel, observed times stamped as they happen, and device-local events that let a domain open a map or a call without the core knowing what either is.
0.0.13 · Spiral Laboratory. How a situation becomes a test, and how a test proves a release. Data logging records what a live system sends the optimiser; a vault beside the node keeps enough to rebuild any moment; a tuning machine, reading that vault read-only over a shared disc, extracts the world as it was just before a chosen command. In the laboratory the test opens parked, plays, steps and records; the requirement is written down as a check on a stop; a minimiser reduces the case to the smallest that still demonstrates it; and a lifecycle of seven directories, with proposals rather than automatic moves, carries it to the regression suite that every new Spiral release and every domain change must pass. A test holds Spiral data only, which is what makes the library shareable.
0.0.14 · Release Management. How a version reaches a machine, and how a machine says what it is running. A node’s life is five verbs — check, install, start, stop, uninstall — where install acquires a version and start selects one, split along where the downtime falls. A version is a pair, a core and a client bundle, named by one artefact; and a release is pulled by the account that wants it, never pushed at it. There are five forms of release, most self-contained to least: studio, which carries the client repo’s own source so a demo or a tuning lab needs no credential at all; set and core-set for an airgap; bundle for a node already on the core; and image from a registry. The artefact declares its own form and the node inherits it, so a node’s record cannot disagree with what it was handed. Alongside that: one storage/ directory per node with its parts separately mountable, licences an operator can collect and grant from the console, and a first administrator who is minted rather than assumed.

Also in this release, cluster locality — where a client reads from. A deployment that spans sites should not drag every operator’s view across the link between them. A node knows which site it is in and reads from its nearest neighbour; and the cluster will now tell a client where it ought to be — a recommendation and the list of nodes it is allowed to use. An operator’s browser takes that, measures the nodes itself, uses the best and reports back what it found, so the cluster learns the locality of each network that calls it. That last part is what carries the clients which cannot measure anything: a script or a host integration gets a good answer because the browsers around it found one. Writes still go to whichever node is writing, wherever that is — and a load balancer in front of the cluster stops being necessary at all.
0.0.15 · Mission Control. The operations console, returned to. 0.0.14 gave it the node lifecycle — five verbs, a machine’s stages, the licences an estate needs — and running a real estate through it showed what it still does not do. This release is that second pass: what an operator actually needs to see, and what they need to be able to do about it, from one screen.
0.0.16 · Containerisation. What a node is allowed to leave behind on the machine that ran it, and what the launcher says when it cannot do what was asked. Only a cluster keeps anything. The three simulators and the two fed modes write no environment file and mount no log directory unless one is asked for, so several of them run from one checkout without sharing — or quietly rotating away — each other’s files. Facts about a container are observed rather than declared: whether a run’s logs outlive it is read from that container’s own mounts, not inferred from the word it was started with, and the detail it logs follows the same answer. And a launcher that cannot build an image reference now names the file that is wrong, instead of passing four words from the container runtime back to whoever typed the command.
0.0.17 · OSRM routing. Road-network journey times from OSRM, kept current and set up the same way everywhere. Each country’s preprocessed road data is published as its own image alongside the core and rebuilt when a new core is released and newer map data exists. A machine keeps one copy of it, shared by every Helix account and container there, refreshed when a core is pulled or installed. Spiral now always runs in a working directory that holds the travel engine and the road data, so one travel-calculator setting works in a container, on a server without containers, and in the test harness. The client’s domain file decides whether the travel calculator is used.
0.0.18 · Break windows. Calculating the break timing from the contractual rules, including mini and full breaks. A contract’s breaks become one break object — the standard break, an optional mini, the window of worked time in which the break must start, and how the resource is taken to it — which Spiral 2.5.6 reads in place of maxWorkPeriod and breakLength. The host still supplies the break stop; Spiral places it in the window.
0.2 · Assets (design) — the Helix side of asset optimisation, pairing with Spiral 3.0.

How the two products line up

There is no declared minimum Spiral version. Each Helix release carries its own Spiral engine, baked into the image, so a Helix version is the pin — and a running node reports the engine it actually found rather than one it was promised. Spiral 2.4.0a shipped in the 0.0.3 line, 2.5.0a in 0.0.5, 2.5.0c in 0.0.8, the official 2.5.0 in 0.0.13 — which is also the release that made “does this engine still pass the client’s own requirements?” a question the product can answer — 2.5.1 in 0.0.13.10, 2.5.2 in 0.0.13.11, 2.5.4 in 0.0.16, 2.5.5 in 0.0.17, and 2.6.0 in 0.0.18.

Versioning

Versions follow an x.y.z scheme:

Major (x) — new releases that require host-interface updates.
Minor (y) — development streams that may extend the API while remaining backward compatible.
Increment (z) — official releases; only these receive support.