What gets built on the foundation once the foundation is trusted, and the discipline that keeps a build from becoming an open-ended project.
Automation is the unit of delivery here. Forward-deployed engineering finds and prioritizes the work; this is how each piece of it actually gets built, accepted and put in front of people. Everything is scoped as a single deliverable with a price, so an engagement is a sequence of finished things rather than a monthly burn.
A deployment is not only a chat window. It is a runtime for business applications that serve on their own isolated origins, reach data only through permissions declared in advance, and inherit the governance already in place. Most of what organizations use day to day does not call a model at all, and that is a feature of the approach rather than a gap in it.
Business applications inside the deployment: a secure intake for files with client-side fingerprinting, a forecasting tool over an organization's own records, a scheduling and public-listing tool, a roster tool with field-level encrypted columns and an audited reveal path.
Reaching the systems that already hold the truth, with every external host declared in the manifest before the build is allowed to publish. An undeclared host is a validation failure, not a runtime surprise.
Intake, extraction, checking, routing and filing. Often a deterministic pipeline with a model doing one narrow job inside it, and a person accepting the output before anything irreversible happens.
The small applications a team would build if it had the time and the governance: a form that writes to the right place, a view that finally joins two systems, a generator that writes in your own voice from your own material.
Not a phase, not a workstream, not an allocation of days. One capability with a name, described by what it will let somebody do that they cannot do today. If it cannot be named in a sentence it is not scoped yet, and we keep talking rather than start building.
The conditions under which you will accept it are written before any estimate exists. They are checkable statements, not sentiments. The price for that deliverable is then fixed against those criteria, which is what protects you from scope inflation and protects us from a moving definition of done.
The capability declares what it is, what it may reach, which hosts it may talk to and what it asks of people, and the validator checks the bundle against that declaration before anything is published. Failures name the file, the line and the fix. A capability cannot quietly acquire an ability it did not declare.
It runs on the staging channel of your deployment, on its own origin, with real permissions and real data where that is appropriate. This is where acceptance actually happens: the people who wrote the criteria in step two try it against their own work and say yes or no.
Production promotion is a separate administrator-only route. The approved artifact hash must equal the hash on staging and the same bytes are copied across. Two administrator identities approve; a deployment with a single administrator can self-approve with a written justification, recorded verbatim as exactly that. Our automation has no promote route at all, and that absence is the control.
We run this test before writing anything, and it disqualifies more candidates than it approves. Applying a model where deterministic code belongs is the most common and most expensive mistake in enterprise AI, and it is usually made by someone who was paid to add AI.
| If the work | Build it as | Because |
|---|---|---|
| Involves language, ambiguity or synthesis | ✓Inference, through the governed route | These are the problems a model is genuinely better at, and the content policy, allowlist, metering and logging already apply to every call it makes. |
| Must be exactly right every time | ✕Deterministic software | Inference does not belong in a zero-error critical path. Conventional code that is auditable and repeatable is the correct answer, even when it is the less exciting one. |
| Needs both | △Deterministic core, model at the edges | The rules and the arithmetic stay in code. The model handles the messy input or the drafted output at the boundary, and a person accepts the result before anything irreversible happens. |
This is a judgment made per capability, in writing, with the reason recorded. Where we disagree with you about which row a piece of work belongs in, that disagreement is worth having before the build rather than after it. Further reading: where AI does not belong.
A capability built here inherits the deployment's controls rather than asking to be trusted. The checks below are not review comments, they are the conditions of publication, and the same rules run in the local tool and again on the server against the exact uploaded bytes.
Because a day rate pays us for time and you want a result. Fixing a price against acceptance criteria written first puts the estimating risk on the party who can actually manage it, and it forces the hard conversation about what done means to happen at the start rather than in month three.
We say so, stop, and re-scope it as one or more new deliverables with you deciding whether to proceed. Absorbing it silently would mean cutting corners somewhere you cannot see, and expanding the invoice without a new agreement is the behaviour this model exists to prevent.
Yes. It runs in your account, from source you hold, under a manifest that documents exactly what it may reach. The authoring kit, the validator and the scaffold are the same ones we use. Be aware that client-authored building is a pilot today: the path is proven end to end by us acting as the client, and the first client build is under way.
Client capabilities in use today run on the staging channel, and the production promotion path is built and exercised on our own deployment. Staging here is a full, governed, isolated runtime rather than a sandbox, and the distinction is real.
Publishing to staging can run from your own repository's pipeline, without us cutting a release, where the capability is built that way. Promotion always requires a named administrator of yours. What we will not do is give any automation, ours included, the ability to put something into production.
The assessment produces the first shortlist of candidate capabilities, each one marked for whether it should use a model at all.