The workflow from intent to authorized integration, how outcomes become lessons, how a release is independently verified, where the keys live, and how a client connects.
F-200ProductIssued
From intent to authorized integration
This is how Fleet's workstation runtime carries out work on Oracis engineering today. The hosted service offers invited organizations the jobs, independent validation, evidence and lessons parts of it; the capabilities page says which is which.
Intent. Someone says what they want done, in the client they already use.
Scoped work. Before anything runs, the work is written down as a brief: what to do and why, what must be true when it is done, the exact files it may change, and a spending ceiling. Two pieces of work never share a file.
Specialist execution. Bounded workers carry out the scoped pieces in parallel, each in its own isolated copy of the repository, running the tests in a sandbox. A worker that stalls is stopped cheaply rather than left to spend.
Review and verification. An independent seat, not the author, reviews the change. A real finding goes back for repair with a failing test that proves it first. A worker's own "done" is not a review.
Evidence. What ran, what it cost and what the tests said is recorded when the job ends.
Authorized integration. A person reads the change and decides whether it lands. Nothing merges on a model's say-so.
Fig. 5Work is scoped before it starts, carried out by specialists in parallel, reviewed and verified, recorded as evidence, and integrated only when a person authorizes it.
How outcomes become lessons
When a person corrects Fleet's work, the correction is recorded with its reason and what it was about. After it is verified, it becomes one of three things: a lesson retrieved for similar work later, a guard that stops the same mistake mechanically, or an evaluation that measures whether the mistake recurs. Recording a correction does not by itself change a model, and nothing on this site claims it does.
Fig. 6An outcome becomes a verified correction, then a lesson, a guard or an evaluation. Recording a correction does not by itself change a model.
Independent verification of a release
One capability inside Fleet is independent verification: connect a repository, approve its verification policy, and receive independently executed checks, durable evidence and controlled releases. The repository's own verification policy runs against one exact commit on an independent runner: each lane in a fresh VM that receives an archive of that commit, runs in a jail with no network, and is destroyed afterwards. The result is a signed receipt that binds the source, the policy, each command and its exit code, and hashes of the output. When a person asks, a separate publisher turns the receipt into a GitHub check. This is implemented in the hosted service; the docs say what has been demonstrated end to end.
Fig. 1A release is checked by an independent runner in its own VM; the signed receipt is what the publisher turns into a GitHub check, after a person approves.
Where the keys live
The hosted service that faces the internet holds neither the key that signs receipts nor the key that posts GitHub checks. Two private services with no public address hold them, and each refuses to start with the wrong key in its environment.
Fig. 2The internet-facing API holds neither key. Receipts are signed and check-runs are posted by private services it can only ask.
How a client connects
Fleet's hosted service is a remote MCP server. Your client opens the browser; the consent page shows the client, where it will return you, your identity, your organization and the exact scopes; you approve or deny. Step-by-step guides: Claude, ChatGPT and Codex.
Fig. 3Your MCP client opens the browser; the consent page shows who you are, which organization, and the exact scopes; you approve or deny.
What stays in your control on the hosted service
What it costs: every job carries a spending ceiling you set, reserved before it starts.
Who sees it: every call is tied to your organization, and another organization's work answers not found.
What reaches GitHub: a receipt becomes a check only when someone asks the publisher to post it.
What you granted: the consent page lists the exact scopes before you approve.