The published version and the notes to change it

At the end of an engagement two things are handed across the table. One is the published version, running on the customer's Czar. The other is a set of notes written for the operators who will change it. Neither is complete without the other, and E31 Consulting does not count the work finished until both are in the site's hands.

The version is the deliverable

A version is what Agency publishes: the agent or workflow as it runs, with its publishing role, its model, its declared routes, and its approval points fixed inside it. It is a thing the site can point to. When someone asks what the engineers built, the answer is a version on the appliance, not a repository somewhere else.

The practice builds on the customer's stack from the start, so the version that is handed back is the same one that has been running during the work. There is no migration at the end, no rebuild for production. What the desk tested is what the desk keeps.

Earlier versions stay on the appliance too. If the site wants to see how the agent behaved before the last change, the previous version is there to read and, if needed, to publish again.

What the notes are for

The notes are not a manual for the platform. Substrate and Agency have their own documentation, and the notes do not repeat it. The notes answer a narrower question: how the people on this site change this use case without calling anyone.

They cover the kinds of change the site is likely to want. Adding a document set to the corpus the agent reads. Moving an approval from one role to another when the desk reorganises. Adding a declared route when a new system of record arrives. Tightening a bound after a run record shows a case the agent should have refused. For each one, the notes say what to open, what to change, who has to publish, and what to check afterward.

The notes are written in the site's own vocabulary. If the desk calls a packet a ticket, the notes call it a ticket. If the approving role is called the shift lead on the floor, the notes do not call it something else.

Written during the work, not after it

In a forward-deployed engagement the notes are written while the engineers sit with the desk. Each time an operator asks how something is done, the answer goes into the notes, and the operator reads it back. By the time the engineers leave, the notes have been tried by the people they are for.

In an in-house project the notes are part of the scope from the first conversation. The customer says what should be true when the work is done, and one of those things is that the operators can make the ordinary changes themselves. The notes are reviewed with the operators at handoff and corrected on the spot where the words do not match the floor.

Keeping them true

Notes drift if nothing holds them to the version. The practice ties each note to the version it describes, so when a new version is published the operators know which notes need a second look. The notes for an approval change are checked against the approval points in the version; if they disagree, the version is right and the notes are corrected.

This is a small discipline, and the site keeps it after the engineers go. It is covered in training the site team to change it, and it is one reason the handoff described in the operating picture you keep stays readable long after the engagement.

What the site holds

When the engagement closes, the site holds the version, every earlier version, the corpus the agent reads, the adapters applied to the model, the run record, and the notes. All of it is on the appliance in the customer's rack. None of it is held by the practice, and nothing has left the building to get there. The notes make that collection usable; the version makes it real.