What the customer keeps

Everything built during an engagement with E31 Consulting belongs to the customer and stays on the customer's appliance. That sentence is short, and it is worth spelling out what it covers, because the list is longer than most customers expect.

The published version and its history

The use case itself is a version published in Agency on the customer's Czar. The customer keeps that version and every version before it, back to the first draft the engineers published on site. Each version carries its own operating picture: who could publish it, which model it ran on, where it waited for approval, which systems it could call.

The customer can republish an earlier version, compare two versions, or build the next one from the current one. None of that requires the practice.

The corpus

If the use case retrieves over the site's documents, the corpus that was assembled for it is the customer's. It was their material before the engagement and it is their material after. The organisation the engineers gave it, the way it is split and indexed for retrieval, stays on the appliance as part of what was built.

Adapters and anything learned on site

Where the engagement adapted a model on the site's own material, the resulting adapters are the customer's. They were produced from the customer's data on the customer's appliance, and they do not leave. The practice does not carry an adapter from one customer to another and does not keep one for itself.

The run record

The record of every run, from the first test case to the last run before handoff and onward, is the customer's. It is on the appliance. It is what an operator reads to understand a result and what the site shows to anyone who needs to see how the agent behaved. It is described in a record of how it behaves.

The notes and documentation

The notes written for the operators, describing how to make each ordinary change on this site in the site's vocabulary, are the customer's. So is any design documentation the engineers produced during the work. These are handed over at the end and are not retained by the practice.

The posture, unchanged

The customer chose a posture before the engagement, and keeps it. Air-gapped work was built air-gapped and stays that way. Connected work uses the systems the customer already secures and introduces nothing new to secure. A mixed estate stays mixed. The engineers leave no path out behind them, so there is nothing to close down after they go.

A team that can change it

The least tangible thing on the list and the most important. The engagement does not end until the site team can publish a version on their own. What the customer keeps is a group of named people who have made each ordinary change with their own hands and have the notes to do it again.

What the customer does not get

For completeness: the customer does not get the engineers' access, which ends with the engagement; the practice's internal methods, which are how the engineers work rather than something that is delivered; or E31 certification for their own staff, which is Element 31's assessment of its own practitioners. These are covered in what the handoff does not include.

In the case of Czar Chassis

When the result ships under the customer's own name, the same list applies and the ownership matters more. The product the customer's customers run is the customer's product. The versions, the adapters, the corpus, the record, and the documentation are theirs to ship, support, and change. The practice built it; the customer owns it, under their name.

Ownership here is not something negotiated at the end. It follows from where the work was done. Nothing was ever anywhere but the customer's appliance, and so there is nothing the practice could keep.