Public Release - 2026-06-18
Artifact: shadow_pilot_boundary_packet_v1. This page defines the fields required to keep a shadow pilot separate from production deployment, customer automation, and live decision authority.
Artifact
This update defines a public boundary packet for shadow pilots. The purpose is to separate observation from action before a trial, demo, or evaluation is described as evidence.
A shadow pilot may inspect a workflow, compare recommendations, log differences, and support later review. It does not claim production deployment, customer automation, or live decision authority unless a separate promotion gate is passed.
The task surface, environment, data boundary, and time window observed by the pilot.
The read-only route used for logs, recommendations, comparisons, or review artifacts.
The real production route that remains controlled by authorized human or system actors.
The accountable decision point that prevents suggestions from silently becoming actions.
The record of where the pilot recommendation differed from the actual production decision.
The explicit rule required before observation-only behavior can be evaluated for production use.
Boundary
The central field is no_production_effect. It states that the pilot cannot change a customer response, financial action, operational decision, clinical path, moderation result, robot movement, or other live outcome.
If the pilot recommendation is copied into the real workflow by default, the boundary has already moved. The artifact must be reclassified from shadow observation to assisted or production-affecting operation.
Two Tracks
A useful shadow pilot compares what the system would have recommended against what the authorized workflow actually did. That comparison is the evidence surface.
The comparison becomes invalid if the shadow track quietly modifies the action track before the evaluation is complete.
Failure Mode
Many systems do not jump from demo to production in one step. They begin as side-by-side recommendations, then become default drafts, then become copied actions, then become operational assumptions.
The boundary packet forces this drift to be recorded. A pilot may be promising, but promise is not permission.
Matrix
Gate
If a pilot affects the real workflow, then the evidence standard changes. The page count, demo score, or user anecdote cannot substitute for a permission and accountability boundary.
That is why the packet treats promotion as a separate event, not a mood.
Challenge
Point to any claim where a system is described as shadow-only while its recommendations affected a live response, workflow, account, customer, robot, market action, or operational decision.
The strongest challenge names the pilot scope, the action track, the missing no-production-effect guard, and the promotion gate that should have been required.