A scoped outcome handed back running

An in-house project is the engagement form for work that can be described before it is built. The customer says what should be true when the work is done. The practice writes a scope, builds to it on the customer's appliance, and hands back a version that is running.

The phrase that matters is handed back running. Not designed, not prototyped, not demonstrated. Running, on the customer's Czar, as a published version their people can point to and change.

It starts with a description

The customer describes an outcome. A desk that drafts and waits for a named person to approve. A corpus of the site's manuals and procedures that anyone with the right role can question. A product their own customers will run under the customer's name.

The description does not have to be technical. It has to be something the owner of the outcome can read aloud and recognize. The practice calls this naming what done means, and in a project it is the first and most important artifact.

From the description, an E31-certified engineer draws out the packet: what arrives, what a good result looks like, which step a person still takes, and which system the result has to land in. If the customer can answer those four questions in a sitting, a project has what it needs.

The scope names four things

The scope is where the description becomes buildable. It names the material the use case may read: which documents, which records, which feeds. It names the calls it may make: which on-premise systems it reaches, through which declared routes, for what purpose. It names the role that approves: the person whose approval the version waits for before an action lands. It names the systems of record: where the result goes so the work counts as done.

Those four are the boundaries of the use case. They are also the properties that will be visible inside the published version when it comes back. The materials, approvals, and systems in scope goes through each of them.

In a project, the scope is held fixed. It is what the returned version is checked against, and changing it mid-build would make the check meaningless.

The build is on the stack, for the appliance

The same kind of engineer who does forward-deployed work builds the project. The stack is the same: Czar as the appliance, Substrate as the platform providing inference, retrieval, memory, adaptation, evaluation, integrity verification, and declared routes, and Agency as the layer where agents are composed, bounded, approved, published, and recorded.

The build may happen in a scoped environment the customer provides, or on the appliance itself. Either way, the result is a version published on the customer's Czar in the customer's posture. An air-gapped customer gets a version built for an air-gapped appliance. A connected customer gets a version that reaches only the systems they already secure.

Nothing the project produces depends on anything outside the customer's building.

What comes back

A published version, running. It does what the statement of done said.

The operating picture, inside the version. Who may publish, which model it uses, where a person has to approve, which systems it may call. These are declared in the version, not described in a document, so they stay visible when the engineers are gone.

A record of how it behaved. The run record from the build and from the check at handoff, so the operators can see what the version did and the site can show an auditor the same thing.

The notes the operators need to change it. Written for the people who will run it, covering the changes the desk will actually need: adding material, adjusting bounds, updating a route, reassigning the approver, rolling back.

What a project delivers walks through each of these in more detail.

The check at the end

The project ends with the customer running the version and the owner confirming the statement of done is true. The operators walk through the notes and confirm they can make a change. The version is checked against the scope: it reads what the scope named, calls what the scope named, waits for the role the scope named, lands where the scope named.

Then the version is the customer's, along with the corpus, any adapters, the record, and the documentation. The practice keeps nothing. If the customer later wants the use case to do more, that is a second version with its own scope. The engagements page at /engagements describes the project form alongside forward-deployed work.