How it works

Sheet
F-200
Set
Product
Status
Issued

How Fleet works

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.

How work moves through Fleet An intent becomes scoped work. Specialists execute it in parallel. It is reviewed and verified, and a failed review sends it back for repair. The result is recorded as evidence. A person authorizes it, and only then is it integrated. intent scoped work specialist execution review and verification evidence you authorize authorized integration How work moves through Fleet An intent becomes scoped work. Specialists execute it in parallel. It is reviewed and verified, and a failed review sends it back for repair. The result is recorded as evidence. A person authorizes it, and only then is it integrated. intent scoped work specialist execution review and verification evidence you authorize authorized integration
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.

How Fleet learns from an outcome An observed outcome is checked by a person. Once verified it becomes a verified correction, which is recorded as one of three things: a lesson, a guard, or an evaluation. observed outcome a person verifies verified correction lesson guard evaluation How Fleet learns from an outcome An observed outcome is checked by a person. Once verified it becomes a verified correction, which is recorded as one of three things: a lesson, a guard, or an evaluation. observed outcome a person verifies verified correction lesson guard evaluation
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.

The path of one release through Fleet A release leaves the repository and is matched against the policy. An independent runner runs it in its own VM, and the runner signs a receipt. A person approves at the human gate, and the publisher turns the signed receipt into a GitHub check. repository policy runner VM receipt you approve publisher GitHub check The path of one release through Fleet A release leaves the repository and is matched against the policy. An independent runner runs it in its own VM, and the runner signs a receipt. A person approves at the human gate, and the publisher turns the signed receipt into a GitHub check. repository policy runner VM receipt you approve publisher GitHub check
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.

Where Fleet keeps its keys On the internet side sits fleet-api (public), which holds no signing key. A dashed boundary separates it from the private network, where fleet-validator (private) holds the signing key and fleet-publisher (private) holds the GitHub App key. fleet-api (public) no signing key fleet-validator (private) signing key fleet-publisher (private) GitHub App key Where Fleet keeps its keys On the internet side sits fleet-api (public), which holds no signing key. A dashed boundary separates it from the private network, where fleet-validator (private) holds the signing key and fleet-publisher (private) holds the GitHub App key. fleet-api (public) no signing key fleet-validator (private) signing key fleet-publisher (private) GitHub App key
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.

Connecting an MCP client to Fleet The client opens the browser and the browser reaches the consent page. The consent page shows identity, organization and scopes. The person approves, and the client is connected. client browser consent approve connected identity organization scopes Connecting an MCP client to Fleet The client opens the browser and the browser reaches the consent page. The consent page shows identity, organization and scopes. The person approves, and the client is connected. client browser consent identity organization scopes approve connected
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.