builtInProcesses

Helix core runs a set of complete processes — composed behaviours whose members are steps (the system concludes them) and actions (a person does). This page is the maintained baseline: when core gains a process, it gains an entry here. (Every built-in action belongs to one of these — see builtInActions.)

1. Standby callout — the reference implementation

Additional Resourcing. Trigger step: Spiral raises CALL on the head standby roster stop. Steps: CLLD persistence (the call survives a restart), notification sends and retries (callout.notify), the answer-window timeout (concludes the action as a timeout refusal), refusal counting and exclusion, the stand-down at the domain threshold, and the roster rewrite on acceptance. Action: the indoor chase (owning desk, class-less by default; reroutable or disableable). The engineer’s accept/refuse is a state-driven standard function — no action needed on their side. Config: rosterStop.STBY.helix.callout + the contract’s helix.callout.answer — resource-params.

2. Off-duty roster lifecycle

Steps only. The shift-state walk (std → dueOn → late → noShow) with per-period display, the on step fired once at a boundary (stripSkills() the worked example), the boundary alarm events, roster pruning (expired REST/STBY entries shift out) with state convergence, and the eternal REST for rosterless resources (a resource with no roster rests invisibly until one arrives). Config: the rosterStop.REST/STBY.helix period blocks — resource-params, events.

3. Notification delivery

Steps degrading to an action. Queue → adapter send → backoff retries → terminal failure raises notifyFailed (the manual-workaround guarantee: a failing step BECOMES an action). Inbound replies — the token door and vendor webhooks — conclude the originating action or process. Config: channels per process (e.g. callout.notify), client adapters, core adapter env — Notifications & Integration.

4. Two-way messaging

Actions only. messageIn (field → dispatch) and messageOut (dispatch → resource), acknowledge-concluded. Config: the messaging blocks on stop types and the NOW/STBY roster defaults — stop-params.

5. Job offer (voluntary deploy)

State-driven, no action. The engineer app’s DPLY offer screen: accept advances the stop’s state; decline (voluntary work only) releases it back to the pool. The callout response screen follows this pattern. Config: the duty’s deploy/voluntary vocabulary — engineer.

6. Rebooking

Operator-driven with steps; partial. The stop editor’s Rebook: an INIT re-initialisation step returns appointment options; applying one moves the window. The Demand-Smoothing “offer rebooking” action front-end is domain authoring on top (the themes). Config: rebook on stop types.

7. Diagnostic triage

Core machinery, domain-enabled. The Diagnostic Tree walks a triage, records the shared diagnosis on the project, and either concludes the process with no visit (a remote fix) or morphs the stop to a concrete type carrying everything learned. helix.diagnostic on the triage stop type is either one tree or a classed list — specific packs above a general one, each with an optional bespoke attachment gate:

"diagnostic": [
  { "class": "stellantis-remote", "when": "isStellantisRemote()", "prompt": …, "options": … },
  { "class": "general", "prompt": …, "options": … }
]

The attachment when answers is this whole path applicable to this casualty (make/model/year off the project’s vehicle record); the option-level gates inside a tree answer what applies, and what must we ask. Several applicable packs present the operator a class choice; the chosen class rides the diagnosis record. Triage never repeats: once the diagnosis is resolved the runner is gone and the recorded outcome stands — and any action fronting the triage (the demo’s remoteDiagnostics chase) self-suppresses on the same record.

Deliberately not processes

The demo lead capture (marketing plumbing); the action engine, event queue and notify toolkit themselves (the machinery processes ride on); and Spiral-side behaviours — pre-deployment of breaks, hub staging — which are optimisation, not host process.