A product that ships under your name
When the outcome is a product your own customers run, Czar Chassis is the path. E31 engineers build it as a scoped project, and it ships carrying your name, your terms, and your version.
· 4 min read
IN SHORT
When the outcome is a product the customer's own customers will run, E31 Consulting builds it as an in-house project on Czar Chassis. The customer specifies the behavior, the engineers build it on the appliance as a published version, and it ships under the customer's name. The customer holds the version, the material, the routes, and the notes to produce the next one.
Most engagements build something the customer's own people will run. Some build something the customer's customers will run. The second kind is a product, and when it should carry the customer's name rather than Element 31's, Czar Chassis is the path.
This article describes what that engagement looks like: why it is a project, what gets specified, what ships, and what the customer holds afterward.
Czar Chassis is a path, not a different machine
Czar is the appliance. Czar Chassis is one way to use it: the customer's product runs on the appliance and is presented, supported, and sold under the customer's own name. Underneath is the same Czar, with Substrate providing inference, retrieval, memory, adaptation, evaluation, integrity verification, and declared routes, and Agency providing the agent layer with versions, bounds, approvals, and the run record.
What changes is whose name is on it and whose terms govern it. The customer's customers see the customer's product. They do not see Element 31, and they do not need to.
Why a product is a project
A product has to behave the same way every time, for people who were not in the room when it was built. That means its behavior has to be specified before it ships, and a specification is a scope.
So the engagement takes the project form. The customer describes what should be true when the product is done: what the user sees, what the product does with what the user gives it, where a person on the customer's side still has to act, and what the product never does. The engineers draw out the packet and write the scope: the material the product may read, the calls it may make, the role that approves, and the systems of record it writes to.
The scope is held fixed. The product is built to it and checked against it. If the customer learns during the build that the product should do something else, that is the next version.
Customers who are still discovering what the product should be sometimes start forward-deployed, with engineers building alongside the product team while the behavior settles. Once it has settled, the work becomes a project, because nothing ships to a customer's customers without a fixed scope.
What gets built
The engineers build the product on the customer's Czar. Agents composed in Agency Studio, governed by bounds that encode what the product never does. A corpus, if the product answers from material, indexed on the appliance. Adapters, if the product has been tuned on the customer's own data, trained and kept on the appliance. Declared routes to the systems the product has to read from and write to. An approving role, if any action the product takes should wait for a person on the customer's side.
Then a version is published. That version is the product. It has an identity the customer can point to, support against, and supersede when the next version is ready.
What ships
What ships is the published version, under the customer's name. The customer's customers run it on the customer's appliance, in the customer's posture. If the customer runs an air-gapped estate, the product is built air-gapped. If connected, it reaches only what the customer already secures.
With the version come the things that make it supportable. The run record shows what the product did, for which user, under which version, with which approvals. The operator notes tell the customer's team how to change the product: add material, adjust a bound, update a route, publish a new version, roll back.
What the customer holds
Everything. The version, the adapters, the corpora, the record, the documentation. The product is the customer's product, built on the customer's appliance, and nothing about it is held by the practice or depends on anything outside the building.
The customer supports it under their own terms. When they want the next version, they scope it, and either their own team builds it with the notes they have or they bring the practice back for a new project. When a project needs a second version covers that step.
A customer thinking about a product on Czar Chassis should arrive with a description of what the product does for its users, who those users are, and what the product must never do. The use cases page at /use-cases shows the kinds of outcomes the practice builds, and one stack: Czar, Substrate, Agency describes what the product is built on. For the appliance itself, see e31.io/czar.
Questions this raises
- Does Czar Chassis mean a different appliance?
- No. Czar is the appliance. Czar Chassis is a way to use it: the customer's product runs on it and ships under the customer's name. The engineers build on the same Czar with the same Substrate and Agency underneath.
- Who supports the product once it ships?
- The customer does, under their own name and terms, which is the point of the path. The engagement leaves them with the version, the record of how it behaves, and the notes to change it. Any help with a later version is a new engagement the customer initiates.
- Can the product be built forward-deployed instead of as a project?
- It can start that way if the customer is still learning what the product should do. But once the behavior is specified, which it must be before anything ships to the customer's customers, the work takes the shape of a project with a fixed scope.
KEEP READING