Use Case · #1

The maintenance tech and the transport vehicle.

Full Metal in practice. Operator authority. Change that stays.

The Scene

You are a maintenance tech. You report to a yard. You have a personal device on your arm. The vehicles you maintain run on our platform.

You don't think about any of that. You think about the truck.

The Sequence

step 01 NOUS → tech

You walk up to a transport vehicle. The device on your arm reacts — NOUS pushed an alert because the vehicle reported a hardware issue. The alert lands on you specifically because you're the tech assigned, in proximity, with the right credential. No login. No app to open. The system already knew.

step 02 tech → vehicle

You diagnose the hardware fault. You fix it — physically. Belt, sensor, fluid, whatever it is. Your hands on the work, your judgment in the loop. (See thesis paragraph 1.)

step 03 NOUS → tech

While you work, NOUS is reading the same telemetry you are. It surfaces operational changes it would recommend given the fault pattern: power usage curve, user-limit thresholds, duty-cycle adjustments. Three options, side by side, with the predicted second-order consequences of each.

step 04 tech → system

You read NOUS's options. You don't pick one. You write your own. You know this truck. You know this driver. You know this route. You describe the change you want — in your own words, dictated to the device on your arm.

step 05 NOUS → tech

NOUS reviews your change against the constraints (safety envelopes, regulatory bounds, fleet-wide invariants). NOUS agrees. If it didn't, you'd see why and decide whether to override or revise.

step 06 tech → system

You confirm the change. Your authority. Not a checkbox — an act of judgment by someone who was there.

step 07 system → future

The change holds. Next time the system reasons about a vehicle in this state, your call is part of the input. Your judgment travels with the fleet.

What's Powerful Here

The operator has authority. The change didn't go through a ticket queue, an engineering review, or a quarterly release cycle. The tech in the field with hands on the truck was the one who changed the system — because he knew the task better than anyone above him in the hierarchy.
You speak the way you speak. Operator describes the change in their own words. The system handles the rest.
NOUS is a peer, not a gatekeeper. It surfaced options, evaluated the change against the constraints, agreed when it agreed, and let the tech proceed. It would have flagged disagreement if there was one — but the final authority was the human.
The change persists. Not as a setting that gets overwritten on the next deploy. As a permanent piece of how this system thinks about this vehicle. The system is now different because the tech said so.
No middleware. No SaaS layer between the tech and the vehicle. No "vehicle management portal." The runtime is the portal. The operator is the engineer.

How It Works

Pantheon end-to-end, running on the manufacturer's hardware. NOUS read the telemetry, surfaced the options, reviewed the tech's call against the constraints. The platform delivered the alert to the device on the tech's arm and propagated the change across the fleet. The operator never opens any of those layers — their interface is the conversation.

The tech is, in this moment, their own digital self — their judgment, their expertise, their authority moving forward into a system that carries the decision when they're not there. Build Your Digital Self, in practice.

What This Replaces

Today: a tech finds a fault, files a ticket, ticket goes to engineering, engineering schedules a fleet-wide config push, weeks later the change ships everywhere — if it ships at all. The tech's expertise is filtered through three layers of people who weren't there.

Full Metal: the tech with hands on the truck is the same person whose call enters the system. The hierarchy is collapsed. The expertise lives where the work happens.

Nobody knows the task better than those doing the task. That's the thesis. Use Case 1 is what it looks like in practice when the system actually believes it.

What's Out of Scope (for now)

Cross-fleet, cross-manufacturer governance — how a manufacturer accepts (or rejects) modifications across their whole installed base. Future use case.
Conflicting calls — what happens when two techs make opposing changes for the same vehicle on the same day. Future use case.
Reverting a change — the operational shape of "undo." Future use case.
Liability and regulation — who's accountable when a change leads to a downstream incident. Whole separate doc.