Why the Project Is Called FlowChassis

A car’s chassis is the frame everything else bolts onto. The engine, the wheels, the body and the seats all hang from it. You don’t see it when you look at a car, and you don’t choose a car by it. But it decides whether the car holds together on a bad road.

That is the job FlowChassis does for a workflow. The flow is the work you care about: an order, a sign-up, a device update. The chassis is what carries it, and the part that keeps it in one piece when something hits.

Workflow tools are usually sold by their bodywork. Visual designers, dashboards, run histories with charts, hosted consoles. That is the part people see, and it is useful. But under every one of them sits the same small machine, and it’s the machine that decides whether a run survives a crash.

The name says what the project builds and what it leaves out. FlowChassis builds the frame: state transitions, checkpoints, retries, compensation, resume. It leaves the bodywork to other products, or to you. A team can build a designer on top of it, or a dashboard, or nothing at all and just call it from their code.

There’s a second reason the word fits. A chassis is meant to be small, stiff and hard to bend. The project holds itself to that: one Go library, no dependencies outside the standard library, one file for its state, a contract that fits on two pages. Small enough to read, strong where it counts.

The name is spelled as one word, FlowChassis, with two capitals. The code lives at flowchassis/flowchassis, and the about page has the rest of the story.