A change you can read.

Save a StateTick project and you get a directory. Inside it, every authored thing is its own plain text file, in a folder named for what it is, under a filename that is the entity’s own name.

States sit in states. Conditions sit in conditions. Equipment, interfaces, logic blocks, alarms, composites and machines each have their own. Fieldbus work lives apart from the logic, because it is a different concern.

Nothing about this is a special export or a sidecar copy that has to be kept in step. It is simply how a project is saved and opened. There is no “now generate the version-controllable form” step to forget.

Splitting a project into files is only half of it. If the contents shuffle between saves, every save still looks like a rewrite and the diff is noise.

So everything is written in a fixed order — entities sorted by name, the same layout, the same formatting on every save. Save a project twice without touching anything and nothing changes on disk. Change one guard expression and the record of that change is this:

That is the entire change set. Not a rewritten project, not a binary that reports only “differs” — one line, with the old value next to the new one, attached to a name that says what it belongs to.

Which means the ordinary habits of software finally apply to a machine. You can review a change before it reaches the plant. You can see who made it and read why. You can go back to exactly the version that was running in March, not the archive somebody remembered to take in March.

Commissioning weeks are the test. One engineer is fixing the capper on site. Another is building out the outfeed from the office. Traditionally this ends one of two ways: they take turns, or they merge by hand at midnight and hope.

Because each entity is its own file, most of that conflict simply never arises. Two people working on different parts of the machine are writing to different files, and the merge is arithmetic rather than judgement.

This is the quiet consequence of the naming scheme described elsewhere on this blog: because a state, a condition and a piece of equipment are separate named objects rather than regions of one program, they are separable on disk too. The structure that makes the machine readable is the same structure that makes it mergeable.

Two things could spoil that, and both are handled when the project is written.

The first is leftovers. Delete a condition and its file is removed, not orphaned. Empty the test suite and the suite file goes with it. A folder that keeps stale files around is a folder that lies to you a year later, when someone finds a state nothing references and cannot tell whether it matters.

The second is provenance. Alongside the project sits a small record of what it is: the name, when it was created, when it was last saved, which version of the software wrote it, a format version so older projects keep opening, and a fingerprint of the authored content. When a project arrives from a colleague or comes back off a branch, that record travels with it.

Where exactly that line falls is your team’s call, not something the software decides quietly on your behalf. Everything is written out, and you choose what to leave untracked — because sharing a little too much costs you some noise in a diff, while sharing too little costs a colleague a project that opens with something missing.