A visual guide to a check design and a human review step.
Status recorded in the October 6, 2026 audit: the page reports Lite for internal projects and Fortress in development. It does not show which controls are active in each setup.
A tool that edits code can make mistakes. Clear rules and checks can help a person review the result. This page describes a design; it does not show which controls run in each setup.
Danger one
The Saboteur
A code-editing tool could damage files, expose information, or make a risky change. What it can reach depends on its setup.
Danger two: the sneaky one
The Cheater
If the same tool can change both code and its tests, those tests may not give an independent check. This is a risk the Pilot design aims to address.
The Big Idea
The Hard Truth at the Heart of It
A test can miss mistakes, especially if the tool being checked can also change the test. Pilot's diagrams separate machine checks from a person's review. They do not prove that software is correct.
The Machine
Checks the work
The design shows machine checks against stated rules. This page does not run them.
🔒
The Review Tray
The illustration puts finished work in a review tray before a person reviews it.
The Human
Reviews the work
The illustrated flow reserves a review step for a person. It does not show a live approval process.
The Centerpiece
Explore the Gate Illustration
This interactive illustration shows eight design steps and an end marker. It does not run Pilot or test software. Use Play to move the token or choose a gate to show a simulated stop. The flow is an explanation, not evidence that a live setup fails closed.
The cards below describe Gates 1–8 in order. The final end marker is not a gate and does not show work going live.
This is an illustration. It does not run Pilot or software tests. Press Play illustration or choose a gate to show a simulated failure.
Use a pointer or keyboard to choose a gate and show a failure in the illustration.
The Eight Gates
Every Gate, Up Close
These cards describe the eight design steps in the animation. The end marker is not a gate and does not show deployment. The final card describes key revocation as a design concept, not a control verified here.
Buttons in these cards change the drawings only. They do not run Pilot, approve code, or run software tests.
Gate 1 · Trusted time
Trusted time
The design includes an outside time source for work orders that expire. This page does not identify the source or show a live check.
Gate 2 · Watchman awake
Watchman awake
The page labels this check ARM but does not spell out the initials. The drawing shows a heartbeat check intended to stop a run if its signal is lost; it does not show whether the control is active in a live setup.
Gate 3 · Work-order seal
Work-order seal
The design shows a sealed work order with a scope to check. This illustration does not verify a signature or show a live rejection test.
Gate 4 · Ticket + logbook
Ticket + logbook
The design shows a checksummed record and a one-time ticket (a nonce). This page does not verify that records cannot be changed or reused in a live setup.
Gate 5 · Restricted workspace
Restricted workspace
The design diagram shows a restricted work area with network access blocked. The page does not identify the operating-system controls or show that this boundary is active in a live setup.
Gate 6 · Separate measurement
Separate measurement
The design illustrates a separation between editable code and test inputs. The button below changes the drawing only; it runs no real tests and proves no result.
Gate 7 · Review tray
Review tray
The illustration shows a holding area with no deployment action. This page does not include an implementation or test that verifies that boundary.
Gate 8 · Human review
Human review
The design reserves a decision for a person. The button animates this diagram only; it does not sign, approve, or deploy work.
Cross-cutting idea · Key hygiene
Revoking a Lost Key (key revocation)
The drawing shows a key marked revoked and a rejected request. This page does not show key revocation running in a live system.
The Difference
Risks and Illustrated Design
These examples describe possible risks and the checks shown in Pilot's diagrams. They do not certify a live setup.
Without Pilot
A tool may have access to files, networks, and commands allowed by its setup
Private information may be exposed if access and data paths are not checked
Tests may be changed along with the code they check
Deployment options depend on the surrounding tools and permissions
Lost keys need a way to be revoked
Logs can be changed unless the system protects them
With Pilot
Rules and checks appear in the design
The sandbox diagram shows blocked network access; active controls are not verified here
Separate measurement is illustrated; this page does not run tests
The flow places human review before its end marker
Key revocation and a checksummed log are shown as design ideas
No live enforcement test is included on this page
Two Strengths
Reported Pilot Tiers
Status recorded in the October 6, 2026 audit. Lite is described for internal work; Fortress is in development.
Page reports shipping
Lite
The page reports Lite as shipping for Robert Gilbert's internal projects. It does not describe a verified control set for every run.
Rulebook for allowed and forbidden actions, as described on the page
Action blocking is reported; this page does not show a test record
Exact behavior depends on setup
In development
Fortress
Fortress is described as a stricter design in development. The diagrams show planned controls, but this page does not include an implementation record or independent test.
Everything in Lite, plus…
Sandbox walls shown in this design
Cryptographic wax-seal work orders
Awake-watchman heartbeat + trusted clock
Tamper-proof ledger + human crypto-stamp
Illustration counter, not test data
Not shown
Where It Stands
Reported Testing and Use
The flow is an illustration of a human review step, not a live approval test.
Steady Light in the Dark
A lighthouse doesn't sail the ship for you. It just makes sure you don't crash in the dark.
Pilot is an internal explainer of check design and human review for AI-assisted code work. It does not establish which controls are active in every setup.