Zenprexi Bio-Risk™ scores driver physiological readiness continuously and resolves it into a banded signal dispatch can act on — before the truck rolls, not after the event report. The outcomes it is built to move are the ones your safety organization already owns: fatigue events, preventable crashes, CSA BASIC performance, and driver retention.
A complete operator-state picture has three components. Fleets have mature instrumentation for two of them. The third — physiological readiness during the work period — has been structurally invisible to dispatch until now.
Speed, hard braking, cornering, lane discipline, hours of service. Captured at the vehicle. A mature category — most fleets have run it for a decade or more.
Posture, lift mechanics, repetitive-motion patterns on the dock and in the cab. Captured by wearables and video. An established loss-control category, especially where workers’ compensation exposure is heavy.
Continuous fusion of heart-rate variability, cardiovascular load, movement coordination, and sleep debt — resolved into a banded readiness state on a normalized 0–100 scale.
Telematics tells you how the truck was driven. Bio-Risk™ tells you whether the driver should roll.
One is a record of the trip. The other is a decision you can make before the trip starts. They are not substitutes — the readiness signal sits upstream of every system you already run.
“My drivers will never wear a company health tracker.”
They are not being asked to. The company never receives a health record. Raw heart-rate variability, sleep data and numeric scores stay on the driver’s device and are never transmitted. What reaches your dispatch system is a banded operational signal — green, yellow or red — that the driver authorized and can revoke. The credential belongs to the driver, not to the carrier.
HRV, heart-rate, accelerometer data, and behavioral telemetry are processed on-device. The transmission boundary is downstream of calculation — there is no upstream copy to request or disclose.
Participation is opt-in and the authorization is revocable. Withdrawal propagates within fifteen minutes across every platform receiving the signal. Verification is refreshed continuously through the work period, never stored as a static record.
Your supervisors receive Green / Yellow / Red operational signals. Not numeric scores, not HRV, not sleep stages. Fleet-level views are aggregated.
The same engine that produces your operational signal produces a credential the driver owns. That is the difference between a monitoring program drivers tolerate and one they ask to join.
In spring 2026, 58.1% of drivers surveyed reported actively looking for another driving job — up from 46.8% a year earlier.⁶ A credential the driver earns and keeps is designed to work in both directions: as something to hold onto, and as something a good driver can carry to you.
A credential earned at your terminal is a universal identifier, not a carrier-specific record. If a driver moves to another ZBR Verified™ carrier, the credential moves too — without re-baseline. Verified drivers are a recruiting argument, not a retention lock.
A driver can revoke authorization at any time, and a withdrawn credential resolves to “not found” — the architecture deliberately does not disclose that a credential previously existed.
Bio-Risk™ is fitness-for-duty support, contractually scoped away from hiring, termination, wage and discipline decisions. Pilot participation agreements are written to say so in plain terms.
The driver application and the supervisor dashboard are complete. A pilot is a deployment of a finished product into your terminal with a defined measurement plan around it — not a build cycle you are asked to fund.
The supervisor dashboard is live today. We walk it screen by screen in the pilot conversation — the terminal overview, the intervention queue, and the gated post-incident retrospective channel — against your own deployment shape rather than a canned demo.
Two scores run in parallel: a Risk Score⁴ estimating likelihood, and CARI™⁵ measuring how much confidence to place in it. They are evaluated together rather than in isolation. The system produces three categories of response — from passive monitoring, to a supervisor-facing data-verification request, to a Direct Intervention PANT™ reaching the driver — calibrated so that the strongest action requires the strongest combined evidence.
The result is a system that escalates carefully. False positives don’t reach the driver, and supervisor attention is reserved for events the platform is confident enough to stand behind.
One terminal or division. A fixed window. Written criteria signed before go-live, so the decision at the end is a reading rather than an argument.
Your platform is sensor-agnostic. Why does the pilot ship with a specific wearable?
Because those are two different statements. The platform is sensor-agnostic by architecture — it ingests from any wearable that exposes raw biometric data, and the business remains a software layer with no device capex in its operating cost. That does not make procurement your problem. Pilot deployments ship with provisioned, fleet-ready Polar 360 wearables, configured and covered by the setup fee, so the pilot starts with zero hardware evaluation on your side. At full-fleet scale you can stay on provisioned devices or bring your own supported sensors — the architecture doesn’t care, and the commercial model doesn’t change.
What does my dispatch team actually see?
A banded readiness state per driver — Green, Yellow or Red — plus a data-quality indicator showing whether the signal is currently reliable. No numeric score, no heart-rate variability, no sleep data. Fleet-level views are aggregated.
Does this replace our telematics or ELD platform?
No. It sits upstream of them. Telematics describes the trip that happened; Bio-Risk™ informs the dispatch decision that precedes it. Nothing in your existing stack is displaced, and integration is a signal feed rather than a migration.
What happens when a driver takes the wearable off?
Wear compliance is treated as a data-quality measure, not driver behavior. When the signal falls below the reliability threshold the credential moves to a suspended state and simply stops producing an operational signal — it does not produce a bad one. Reinstatement is automatic when data quality recovers.
Do you have fleet case studies?
Not yet, and we won’t imply otherwise. The pilot program described above is how the first ones get made. What exists today is a finished product, a patent estate covering the architecture, and a measurement plan we will agree with you in writing before anything is deployed.
Four filed U.S. provisionals covering the engine, the privacy hierarchy, the banded disclosure framework, and the signal architecture.
Zenprexi, Inc. · Delaware C-Corporation · Charlotte, NC. SOC 2 Type II in preparation.
A pilot at this stage is run by the founders, not handed to an account manager. These are the people your safety organization would be working with.
Enterprise sales and business development background. Built the demonstration system. Leads pilot scoping and partner relationships.
20+ years in risk intelligence and technology delivery. Founded a profitable government contracting firm. Operational discipline for regulated environments.
25+ years in enterprise IT. Scales MVP to production. Engineering leadership and enterprise security.
IBM PC co-inventor. 45+ U.S. patents. National Inventors Hall of Fame. Provides IP strategy, technical validation, and enterprise architecture guidance.
Insurance industry veteran with deep expertise in the captive insurance market. Holds the CRIS (Construction Risk and Insurance Specialist) designation. Advises on alternative risk transfer structures and carrier-segment strategy.
Thirty minutes, the real product on screen, and an honest read on whether your terminal is the right first one.
mpeck@zenprexi.com · Charlotte, NC
We respond within one business day. Tell us a bit about who you are and we’ll route the conversation to the right person.
We’ll respond within one business day. If your inquiry is time-sensitive, you can also reach Michael directly at mpeck@zenprexi.com.
Zenprexi, Inc. (“Zenprexi,” “we,” “our,” or “us”) respects your privacy and is committed to protecting your personal data. This Privacy Policy explains how we collect, use, disclose, and safeguard your information when you visit zenprexi.com or otherwise interact with us.
Personal data you provide: name, email address, organization, and any context you include when contacting us via email.
Derivative data: information automatically collected by our servers such as IP address, browser type, operating system, access times, and pages viewed.
We use information collected to respond to inquiries, schedule discovery conversations, send relevant follow-up communication, and improve the website experience.
We do not sell, trade, or rent your personal identification information to others. We may share information only as required by law or to protect our rights.
The Zenprexi Bio-Risk™ platform operates under a separate, structurally privacy-preserving architecture. Raw biometric data is processed on-device and never transmitted off the edge layer. Federated learning gradients are encrypted and bounded by a per-transmission privacy budget ε ≤ 1.0. Subject-authorized banded signals are the only data shared with platform partners.
We use administrative, technical, and physical security measures to help protect your personal information. While we have taken reasonable steps to secure information provided to us, no security measures are perfect or impenetrable.
We may update this Privacy Policy from time to time to reflect changes to our practices or for other operational, legal, or regulatory reasons. We will notify you of any changes by updating the “Last Updated” date above.
Zenprexi, Inc.
Charlotte, NC
mpeck@zenprexi.com
These Terms of Service constitute a legally binding agreement between you and Zenprexi, Inc. (“Zenprexi,” “we,” “us,” or “our”) concerning your access to and use of zenprexi.com and any related communications. By accessing the site you agree to be bound by these terms.
The site is our proprietary property; all source code, copy, designs, graphics, and trademarks are owned or licensed by us and protected by applicable intellectual-property laws. Zenprexi™, Bio-Risk™, CARI™, PANT™, ZBT™, and ZBR Verified™ are trademarks of Zenprexi, Inc.
Aspects of the technology described on this site are the subject of pending U.S. provisional patent applications, including US 63/919,896, US 63/976,499, US 64/064,692, and US 64/065,722. Nothing on this site is to be construed as conferring any license under any patent or other intellectual-property right of Zenprexi, Inc.
Statements regarding deployment timelines, validation milestones, regulatory approvals, and underwriting outcomes are projections, not guarantees. Zenprexi does not currently offer any product or service that is contingent on a specific underwriting or pricing decision by any third party.
The site is provided on an as-is and as-available basis. To the fullest extent permitted by law, we disclaim all warranties, express or implied, in connection with the site and your use thereof.
In no event will we or our directors, employees, or agents be liable to you or any third party for any direct, indirect, consequential, exemplary, incidental, special, or punitive damages arising from your use of the site, even if we have been advised of the possibility of such damages.
These terms shall be governed by the laws of the State of Delaware, U.S.A., without regard to its conflict of law principles.
Zenprexi, Inc.
Charlotte, NC
mpeck@zenprexi.com