How an engagement ends
An engagement ends when the statement of done is true, the version is published on the customer's appliance, and the people who run it can change it without the engineers in the room.
· 4 min read
IN SHORT
An E31 Consulting engagement ends when three things hold: the statement of done is true, the use case is running as a published version on the customer's Czar, and the site team can publish the next version themselves. The engineers leave behind the version, the operating picture inside it, a record of how it behaves, and the notes operators need to change it.
The end of an engagement is easy to describe and hard to fake. The use case is running on the customer's appliance. The statement of done is true. And the people who will run it from now on can change it without anyone from the practice in the room.
That last condition is the one that matters most, and it is the one most consulting work never tests. This article describes what the end looks like in both engagement forms, what stays behind, and what does not.
Three conditions
The practice treats an engagement as finished when three things hold at once.
The statement of done is true. The desk drafts and waits for its approver. The corpus answers questions with sources. The product is in the hands of the customers it was built for. Whatever the statement named at the start, the owner of the outcome can confirm it now.
The use case is a published version on the customer's Czar. Not a branch, not a prototype on an engineer's machine. A version the site team can point to, with its bounds, its approving role, its model, and its routes all declared inside it.
The site team can publish the next version. For forward-deployed work this is the literal test: the team opens Agency Studio, makes a change, routes it through the approval the version names, and publishes it, with the engineers watching but not touching. For a project, it is the team receiving the version with the notes that make such a change possible and confirming they can follow them.
What stays behind
Four things remain when the engineers leave.
The published version, running. It is the use case itself: the agent, the application, or the workflow on the appliance the customer already has.
The operating picture, inside the version. Who may publish. Which model the version uses. Where a person has to approve. Which systems it may call, through which declared routes. These are not in a slide deck; they are properties of the version, visible to anyone with the role to read them, long after the engineers are gone.
The record. The run record shows how the version behaved during the build and at the end. It is something an auditor can read and something the operators will use the first time a result looks wrong.
The documentation, written for operators. Not a system design document. The notes a person on the site team needs to change the version: where the bounds live, how to add material to the corpus, how to adjust a route, how to send a change through approval, how to roll a version back.
What does not stay behind
The engineers leave no path out. Any access they held inside the customer's segment is withdrawn. There is no remote session left open, no account that outlives the engagement, no route from the appliance to anywhere the customer did not already secure.
Nothing built during the engagement leaves the building. Versions, adapters, corpora, records, and documentation all belong to the customer and stay on the customer's appliance. The practice does not keep a copy.
This is not an inconvenience the practice tolerates. It is the posture the customer chose, and the engineers work inside it from the first day to the last. Engineers who leave no path out describes what that discipline looks like in practice.
The end of a forward-deployed engagement
For forward-deployed work, the end is a capability, and it is tested rather than declared. Over the last stretch of the engagement, the engineers step back. The site team makes the changes. The engineers answer questions but keep their hands off the keyboard.
When the team has published a version of their own, through their own approval, and it runs, the engineers leave. If the team is not there yet, the engagement is not over, because the engagement was scoped to that capability. Finished when your people can publish alone covers this test in more detail.
The end of a project
For a project, the end is a check of the returned version against the scope and the statement of done. The customer runs it. The owner confirms the outcome holds. The operators walk through the notes and confirm they can make a change.
Then the version is theirs, along with everything that went into it. If a second version is needed later, that is a new scope, described in when a project needs a second version.
In either form, any support after the engagement is customer-initiated. The practice does not reach into the appliance from outside. If the site wants help with the next version, the arrangement starts the way the first one did: with a description of what should be true when the work is done. The engagements page at /engagements describes both forms from start to finish.
Questions this raises
- What happens if the site team cannot yet publish on their own at the planned end?
- Then a forward-deployed engagement is not finished, by its own definition. The engineers keep working with the team until they can. The engagement is scoped to that capability, not to a calendar.
- Do the engineers keep any access after they leave?
- No. Access is granted inside the customer's segment for the duration of the work and withdrawn at the end. Any later support is a new, customer-initiated arrangement, not a standing connection.
- Is there a formal acceptance step?
- There is a check against the statement of done and the scope, done with the owner of the outcome. For a project the customer runs the returned version and confirms it. For forward-deployed work the test is the team publishing a version without the engineers' hands on it.
KEEP READING