Built on bare metal: why E3 Driver Authentication isn't a wrapper

"Is this just ChatGPT reading a photo?" No. The models that make the E3 Driver Authentication decision are models E3 builds, tunes and runs on GPUs we control, with no outside AI company's API in that decision path.

We call that "built on bare metal." It's our shorthand, and we'll define it plainly below, because what sits under a vendor's AI decides three things you'll feel: what each load costs, where your drivers' documents go, and how quickly the system learns new fraud.

Because we own the model layer, our cost tracks GPU time instead of another company's markup, driver documents don't pass through a third-party model provider, and the models keep learning freight fraud specifically.

An AI wrapper resells someone else's model, and that sets your price

A wrapper is a product built on top of another company's AI model. Your request goes to that provider's API, a general-purpose model returns an answer, and the vendor packages the answer and sells it back to you.

That's a reasonable way to build plenty of software. We help customers put tools like Claude and ChatGPT to work ourselves. But for a decision as specific as who is standing at your dock, the architecture has three consequences:

• Every request is metered. Model providers charge by usage, per token or per image (see the OpenAI and Anthropic pricing pages). A wrapper pays that on every check, then adds its own margin.
• Your data leaves for a third party. A CDL photo, a selfie or a picture of a truck door goes to the model provider's servers to be processed, under that provider's terms as well as your vendor's.
• The vendor can't change how the model works. It can rewrite its prompts. The model itself, its version and when it changes belong to the provider.

None of this is visible from a demo. A wrapper and a purpose-built system can look identical on screen. The difference shows up in the invoice, the security review and the next new fraud pattern.

"Built on bare metal" means we run our own models on GPUs we control

Strictly, bare metal means a physical server dedicated to one tenant, with no virtualization layer between the software and the hardware. We run our own models on GPUs we control, not someone else's API.

What matters is what runs on that hardware, and all of it is ours: the models, their weights, the serving software and the decision. In the terms of NIST's definition of cloud computing, we consume infrastructure and deploy our own applications on it. A wrapper consumes a finished service that someone else runs.

The models

E3 Driver Authentication uses vision and text-reading models trained to read a CDL, a truck door and a cab card. It decodes the barcode on the back of US driver's licenses, the format set by the AAMVA DL/ID Card Design Standard. And it uses patent-pending biometric matching to compare the face in a selfie with the face on the license.

These are the models that make the authentication decision. Some checks also call outside data sources, such as insurance lookups. Those are data lookups, not another company's AI model deciding for us.

The inference layer

Inference is the step where a trained model runs on new input: a driver's photo arrives, and a model produces an answer. Our own serving software routes each request to GPUs we run, carrying models we deployed. No request is sent to a general-purpose AI provider to be answered.

Tuned on freight

A general-purpose model sees a picture of a truck. Ours are trained on the fraud we see at pickup: paper taped over a DOT number, magnetic decals, AI-generated truck photos, and a different person showing up than the driver who was dispatched. New fraud patterns are added every week.

Because we own the weights, a new pattern becomes training data for our next model. It isn't a request we file with someone else and wait on.

Owning the model layer lowers your cost per load

A company built on top of AI tools pays the model provider for every image and every call. Then it adds its own margin, because it has to. The price you pay carries two companies' costs and two companies' margins.

Our cost is GPU time on models we run. There's no per-request fee to an outside AI provider and no second company's markup inside every load. When our engineers make a model faster, the same GPU handles more authentications, so that work lowers our cost directly instead of waiting on a provider's price change.

Low price isn't a lesser product. It's a different cost structure.

That matters most to brokers who want to authenticate every pickup, not only the high-value ones. A check that's priced per call to someone else's model gets rationed. A check priced on our own compute doesn't have to be.

Your legal and security teams get a shorter answer

Every serious AI evaluation reaches the same question: where does the data go? For shippers, the security team's answer can decide the deal before price comes up.

• Driver documents stay inside E3's stack. CDL photos, selfies and truck images are processed by our models on our infrastructure, not sent to a third-party model provider.
• Private deployments are an option. "Some of our customers want private set ups," as Caleb put it when asked why E3 would keep running its own models even if an outside API got cheaper. Running our own models is what makes that possible.
• Decisions are consistent and traceable. We control which model version runs and when it changes. A decision on a given load can be traced to the model that made it, which is part of the audit trail your SOPs depend on.

That last point is where infrastructure meets liability. Your SOP says what has to happen before a load is released. The record shows it happened, the same way, on every load. We covered why that record matters in Your driver conversations are evidence now. Is there a record?

None of this is about collecting more on drivers. Authentication exists to confirm the real driver and protect their identity from the people borrowing it. Keeping their documents in fewer hands is part of that.

Running our own models doesn't slow the pickup

Self-hosting can sound like a trade: more control, less speed. It hasn't worked out that way. Drivers get a result in under a minute, and in internal tests the image check itself takes a fraction of a second.

The process also has to work for the driver, or it doesn't work at all. 96% of drivers complete E3 Driver Authentication. We explain why in Why 96% of drivers complete E3 driver authentication.

A freight-security company runs its own inference because the problem required it

We didn't set out to run GPUs. General-purpose models aren't trained to notice tape over a DOT number, and per-call pricing works against checking every load. To get models that know freight fraud, at a cost that lets brokers use them on every pickup, we had to build and serve them ourselves.

The team that does this is about 20 people globally. Engineers take a feature from the customer call to the live product, and nothing counts as done until it works for customers. They tune their own models and optimize down to the hardware: from the model to the transistor.

Four questions to ask any AI vendor about its stack

You don't need to read code to tell what's under a vendor's AI. Ask these four questions, and listen for specifics.

For what the system checks at pickup, see Eight questions that separate driver vetting tools and the types of freight fraud it's built to catch.

The answer to "is this just ChatGPT?" should be specific

Every AI vendor should be able to tell you what's underneath. Ours is models built for freight fraud, running on GPUs we control, so your price tracks our compute, your drivers' documents stay out of third-party model providers, and the models keep learning the fraud you face.

Bring us the lane that keeps you up at night. We'll show you what's under the hood. Book a demo