Documentation

This is the reference and guide material for Spiral (the real-time scheduling engine) and Helix (the workforce-management system built on it). It is written to be read two ways: front to back when you are learning, and by lookup when you are building. This page explains how it is laid out so you can do either.

The two kinds of page

Guides explain how something works and why — running prose, worked examples, the shape of a feature. Reach for a guide when you are forming a mental model.

• Helix guides — Introduction, Actions, Events, Scenarios, the Contact Centre, the Engineer App, Notifications & Integration and the Audit Trail. Start here to understand what Helix does.
• Spiral guides — Getting started, the Input stream and Output stream, and Concepts. Start here to understand how the engine consumes and produces its JSON streams.
• How-tos — task-focused walk-throughs: Develop a client extension, Tune Spiral with Helix, Versions and upgrades and more under How-To.
• Training — hands-on, step-by-step lessons under How-To & Training.

Formal reference is the exhaustive, structured description of every object and configuration block — one page per type, each field named, typed and explained. Reach for the reference when you know what you are building and need the exact field. It lives under Reference, and the pages are generated from the same definitions the software uses, so they stay true to the running system.

A recommended reading order

If you are new to the platform:

1. Helix — what it is, then the Introduction guide.
2. Spiral Getting started and Concepts — the engine underneath.
3. The guide for whatever you are here to do — Actions, the Audit Trail, Notifications.

If you are building a client:

1. Develop a client extension — the repo layout, the dev loop, and the extension points.
2. The Input and Output stream guides — what Helix sends Spiral and receives back.
3. The Reference pages for the objects you author — resource, project, stop, and their Params configuration blocks — kept open as you work.

How a reference page is structured

Every reference page follows the same shape, so once you can read one you can read them all:

• A title and one-line description of the object or block.
• A field table — each field’s name, type, whether it is optional, and what it means. Nested objects link to their own reference page; a field that takes an expression is marked as such.
• Sections below the table expand anything that needs more than a row — a worked JSON example, the rules a set of fields obey together, defaults and edge cases.
• A Related list at the foot, linking the objects that appear alongside this one.

Configuration blocks that Helix adds on top of Spiral (the helix.* blocks) are called out as Helix additions and are ignored by Spiral itself — a useful signal for which side owns a field.

If you get stuck

The Support page has the contact routes. If a page describes something that no longer matches the software, that is a bug in the documentation — tell us, because a doc that lies is worse than no doc.