What a project delivers

The deliverables of an in-house project are concrete enough to list, and listing them is useful because it shows what the customer should expect to be able to point to on their own appliance when the engineers are done.

There are six. One is the version. Four are the properties that make the version safe to run and possible to change. One is the written material for the people who run it.

The published version, running

The use case itself. An agent, an application, or a workflow composed on the customer's Czar, published as a version in Agency, and running. It does what the statement of done said it would: drafts and waits, answers questions from the corpus, or serves customers under the customer's name.

A version is a thing the site team can point to. It has an identity. It can be compared to the version before it and rolled back to if the version after it misbehaves. That is why the practice delivers a version and not a deployment.

The material it may read

The corpus and any other material the use case is allowed to read, indexed on the appliance by Substrate. For a corpus people can question, this is the documents themselves, organized so the version can retrieve from them and cite them. For a desk that drafts and waits, it is whatever the version needs to produce a good result: the procedures, the prior records, the reference material.

Any adapters trained on the site's own material during the build are delivered with it. They were trained on the appliance and stay there.

The scope named this material at the start. The version reads it and nothing else. That boundary is visible in the version afterward.

The calls it may make and the role that approves

The declared routes from the version to the on-premise systems it reaches. The ticketing system where the draft lands. The records system where the answer is filed. The planning system the version reads a schedule from. Each is a declared route with a declared purpose, set in the version, and the version makes no call the scope did not name.

On a connected site these routes reach only systems the customer already secures. On an air-gapped site they reach only systems inside the building. In both cases the site team can read the list of routes in the version and change it when a system on the other end changes.

Alongside the routes comes the named role whose approval the version waits for before an action lands. In a desk that drafts and waits, this is the person who reviews the draft. In other use cases it is whoever the scope said still has to act.

The role is a property of the version. When the person in the role changes, the site team reassigns it in Agency Studio and publishes. The practice delivers the role set correctly and the notes for changing it.

The run record

The record of how the version behaved during the build and during the check at handoff. Every run, every approval, every action that landed, with the version that did it. It is the evidence that the version does what the statement of done said, with the approvals the scope named.

The run record is also the first thing the operators will reach for the first time a result looks wrong, and it is something an auditor can read without the engineers in the room.

The notes the operators need

Written for the people who will run the use case, not for engineers. The notes cover the changes the desk will actually need: how to add material to the corpus, how to adjust a bound that is too tight or too loose, how to update a route when a system changes, how to reassign the approving role, how to send a change through approval and publish it, how to roll back.

The notes live with the version on the appliance. They are the written half of the handoff; the other half is the check at the end, where the operators walk through a change and confirm the notes work.

All six of these live on the customer's appliance, where they were built. Nothing is held by the practice. Nothing leaves the building. The customer keeps the version, the material, the routes, the role, the record, and the notes, and can point to every one of them on their own Czar.

A scoped outcome handed back running describes how a project reaches this point, and when a project needs a second version covers what happens when the customer wants more. The engagements page at /engagements sets out the project form alongside forward-deployed work.