An inference pool inside the airport perimeter

An apron is a shared floor with many operators on it. The airport owns the stands, the ground handlers bring the tugs, the dollies, and the baggage carts, the cargo tenants bring their own terminal equipment, and each arrives with its own vision system and its own cloud behind it. The models an autonomous tug needs when it reaches an unfamiliar stand are too large for the vehicle to carry and too urgent to send off the airfield and wait for. A pool inside the perimeter, on the airport's own network, answers all of them from one place.

What is on the apron

The machines that ask for perception on an airfield are more varied than on most floors. Baggage systems run in the terminal basement, reading tags, tracking bags through the diverts, and flagging the ones that have fallen or jammed. Autonomous tugs and dollies move between the baggage hall and the stands, crossing service roads shared with fuel trucks, catering lifts, and people on foot. In the cargo terminal, build-up and break-down stations inspect pallets and containers, read labels, and check cargo doors before a hold is closed. Fixed cameras on the stands watch the aircraft, the equipment around it, and the markings on the apron that the vehicles steer by.

Several ground-handling vendors work the same stands, often on the same turn. Each has a reason to want its own system and none has a reason to share perception with the next.

Why the cloud and a GPU on every vehicle both fail

Every ground-handling vendor arrives with its own AI system and its own uplink. On an airfield that is a security question before it is a cost question: each uplink is a path out of the perimeter carrying footage of stands, aircraft, and cargo doors, which is the airport's data and not a vendor's.

The cloud also fails on time. An apron vehicle approaching a stand it has not seen, with a catering truck parked where the model expected clear apron, cannot wait for a model in a distant region to answer.

The usual answer is a larger GPU on every vehicle, sized for the worst moment the vehicle will meet. That compute sits idle most of the day, through every routine run between the hall and the stand, and it has to be bought, powered, and maintained on every vehicle of every vendor.

What the pool serves

Czar Grid is several Czar nodes joined into one inference pool for the airfield. Baggage systems, autonomous tugs and dollies, and cargo-terminal inspection from several ground-handling vendors are served from that one pool, over the airport's own network. Each vendor's fleet software calls the pool with its own requests and its own latency budget. The vendors do not have to share anything with one another, because the pool is the airport's and not theirs.

Apron, stand, and cargo-door vision runs on site. Footage from the stands and the cargo terminal goes to the pool and no farther: the inspection models run on it, the captures it keeps are the airport's, and nothing crosses the perimeter to be analyzed. A finding on a cargo door is in the airport's record before the hold is closed.

The third thing the pool serves is the unfamiliar moment. A tug carries a small, fast model for the ordinary run. When it meets something that model cannot resolve, an object on the service road, a stand laid out differently from the map, a hand signal from a marshaller, it asks the pool. A larger model on the pool answers the question the onboard model cannot, inside the time budget the vehicle has, because the pool is on the same network and not across a region. Safety, stops, and motion limits stay on the robot as the vendor built them; the pool answers questions, it does not drive the machine.

What stays on site and who holds the record

Everything the pool reads and learns stays in the airport's rack. Substrate runs on the Grid: Inference serves the models, Retrieval and Memory hold what the site knows about its own stands and equipment, Adaptation improves the models on the airport's own captures, Evaluation checks them before they are served, Watchman verifies the integrity of what is running, and Local Bridge permits only the routes the airport declares, such as the handlers' fleet software, the baggage system, and the airport's own operational systems, with egress denied by default. An airfield that chooses to be air-gapped has no route out at all.

Tasks that cross handlers, a stand inspection before a turn, a sweep of a cargo area, a check of the baggage hall after a jam, are authored in Agency Studio on the Grid, bounded to what they may touch, approved by a named role at the airport, and recorded. A run can be replayed when a question is asked later. The record is the airport's and sits on the airport's hardware.

How it is placed and bought

The Czar nodes go in the rack in the operations building, in the conditioned, secured space where the airport already keeps its network equipment, and the airport's network carries inference to the basement, the stands, and the cargo terminal. The airport holds one subscription for the configured Grid, hardware, platform license, and sustainment in one line, fixed for the term, and more vehicles joining the pool do not move it. Where a ground-handling vendor or integrator prefers to ship the pool under its own name with its fleet, it does so as Czar Chassis. It is the same Grid, held by the vendor instead of the airport.

An airfield has always been a shared floor with one owner. The pool makes the perception on it behave the same way: many operators, one place where the models run, one record of what they saw, and nothing leaving the fence.