Architecting Autonomy The How Behind the Rhythm Innovations Operating System

Hi, everyone. Welcome back. Thank you for joining us for part 2 of our tech webinar series. Our first session, we explored the why of growing liability exposure in fleet operations and what happens when risk is visible but not governed. Today, we're shifting the conversation to the how. How do you actually operationalize a defensible safety model? How do you move from fragmented systems to a unified governed operating system? That's exactly what we're gonna unpack today. Now, before we get started, just a few housekeeping notes. The session is being recorded and a replay will be shared with all registrants. If you have a question, please type it in the Q&A panel at any time throughout this presentation. And we'll answer those questions at the end. We have a Q&A section at the end for us. Here you'll see an overview of our 2026 webinar series. As a reminder—

We're not seeing the month.

No. Okay. Can you see it now?

I see it. Yep.

Okay. Perfect. You can see the screen. Okay.

Mm-hmm.

Okay, so sorry about that. Here you see our 2026 webinar series. As a reminder, we're running 2 flagship tracks, our Safety Masterclass series, which is focused on leadership and governance, and our Tech webinar series, where we go deeper into execution and architecture. Today's session is, again, part 2 of that Tech track, and it really builds directly on what we introduced in part 1. So if you missed part 1, definitely register, use the QR code, and you can gain access to that session as well. And then of course register for anything that you'd like through rhythminnovations.com/webinars. And with that, it's my pleasure to introduce JC Novoa, our Chief Technology Officer at Rhythm Innovations. JC, the floor is yours.

Welcome back everyone, and thank you for joining our technology webinar series. I am JC Novoa, Chief Technology Officer at Rhythm Innovations. In our last session, we talked about the why, the legal and financial urgency of closing the liability gap. We focused on why nuclear verdicts rise when governance is weak and what a modern risk-based fleet safety model looks like, grounded in 4 pillars, aware of FNCSA optics and aligned with ISO 39001 principles. Today, we'll cover our governance framework, fragmentation and signal overload, how our 5-pillar architecture supports a unified risk posture, how you can incorporate FMCSA data as an external reference signal, and how Rio Safety Copilot works— retrieval, explanation, and action orchestration— and how you can deploy this in crawl, walk, run phases, Without disrupting operations. Before we open the hood to look at the architecture today, I want to summarize the outcomes of session 1 into a single unified framework. What you're looking at here is a governance loop that prevents latent risk from accumulating across your drivers, vehicles, and compliance processes. It is broken down into 4 distinct control gates. Gate number 1 is fit to work. This is a formal determination that a driver or operator is medically, cognitively, and administratively clear to perform their assigned duties. We are checking personnel records, license verification, hours of service compliance, and medical certification. Operationally, this is your pre-dispatch control gate. It prevents unsafe deployment by answering the fundamental question: Is this individual legally and physically authorized to operate right now? Gate number two is fit to drive. This is narrower and more immediate than fit to work. It is a real-time confirmation that the driver and vehicle are safe for the specific trip. We are validating DVIR inspections. Telematics monitoring, and defect tracking. Here's the operational distinction: fit to work is your status of eligibility; fit to drive is your immediate operational readiness for this specific movement. It is a moment of use control. Gate number three is staying standard. This describes our control-bound operating philosophy. The operation runs inside controls. Drift creates exceptions and forces decisions. Standards are not aspirational; they are enforced constraints. If a medical card is nearing expiration, or we see repeated hours of service age violations, that drift triggers an exception state. Drift forces a binary decision. Remediate and return to standard or escalate and suspend eligibility, there is no silent tolerance of degradation. Operationally, this prevents the normalization of deviance. Gate number 4 is return to ready. When a driver or vehicle falls out of a standard and enters an exception state, they become not ready. A corrective action is required. This phase represents closure discipline. Eligibility is reset only after proof is validated. There are no open loops and no silent reopens here. It requires proof-based restatement, incident management, remedial training, and verification sign-offs. This structure creates deterministic eligibility and traceable safety governance. It is a control integrity model, not a compliance checklist model. It assumes that risk accumulates gradually through drift, and that drift must be surfaced early. Eligibility is earned and re-earned, not assumed. Closure requires proof and actions, not just intentions. So the question for today is, how do you actually build a governance operating system that enforces this loop? How do you take high-velocity telematics data, transactional MVR records, and unstructured video and turn them into autonomous governance system? How do you build an operating system that can ingest telematics events at scale to monitor staying standard, integrate MVR updates to verify fit-to-work, Track training completion to manage return to ready. Translate all of that into a single fit-to-drive decision and generate evidence that supports certification readiness and litigation defensibility. We do it through a specific 5-layer architecture. Before we look at the architecture, we have to look at the problem. Most fleets have more technology that they can operationalize. They have telematics, cameras, NVR monitoring, training platforms, dispatch tools, and incident workflows, but the stack is fragmented. In fleet technology, the biggest friction point is the double entry problem. Managers hate having to add a driver to their HR system, then to a continuous driver monitoring platform, Then to the telematics platform. It leads to data decay and security risk. The roster is duplicated, data is inconsistent, and because each system is best of breed, nobody owns the end-to-end governance outcome. That creates 3 predictable failure modes: roster decay, alert fatigue, and the absence of an enforceable Decision layer. Before we move on, why don't we take a poll to learn more about your organization? We'll give you a minute to answer, and then we'll comment on your answers. I think, uh, uh, do we have some answers, Mina? Um, do we get the results?

Very good.

Very good, right? So if you look at one consistent gap there is that some of you did not find that you have a system in place to help the driver or the vehicle return to ready. So we're going to look into some of those details next. Now, our architecture solves this through 5 actionable layers: integrate, orchestrate, unify, comprehend, and experience. If you look at the bottom of the stack, we start with integrate. Layer 1 ingests signals from telematics, NVR, LMS, and history. Telematics is high velocity. MVR is transactional. LMS is competency state. Historical data is longitudinal context. We build separate ingestion paths, then converge them into a decisioning. We aren't just doing simple API calls here. We are ingesting near real-time streams from the telematics platform's GPS capabilities, monitoring non-compliant harsh events, and engine diagnostics. At the same time, we're pulling transactional state of the license data from a continuous driver monitoring platform. A common mistake is pushing raw events straight into workflows. A better pattern is to compute derived indicators such as speeding minutes per 100 miles in the last 7 days, hard braking events per 1,000 miles in the last 14 days, Night driving percentage in the last 30 days, route risk exposure based on roadway type and congestion or load. Now, the trend slope may be improving, stable, or worsening. Derived indicators are more actionable than individual events and easier to explain and defend. The challenge at this layer isn't just getting the data. is the frequency and the format. This leads us to our next layer. Layer 2, orchestrate, powered by MuleSoft. This layer synchronizes identities and lifecycle events across systems. In Rios, we implemented roster management logic. When a supervisor adds a driver in our platform, MuleSoft acts as the nervous system. It triggers a people and license call to the continuous driver monitoring platform while simultaneously provisioning the asset and driver ID in the telematics platform. We create once and provision everywhere. We have automated the lifecycle of the human asset. If a driver is terminated in the core, we automatically unenroll them in the continuous driver monitoring platform to stop unnecessary MVR costs and deactivate the telematics platform credentials. We terminate once and deprovision everywhere. We update a supervisor once and ownership is updates everywhere. This reduces cost leakage and reduces negligent entrustment risk. This is an integration as a strategy platform, not just a feature. Layer 3 is unify. A governance system needs a trusted source for artifacts that matter. Driver profiles, vehicle profiles, posture decisions, task records, coaching logs, training assignments, incident investigations, and approvals. We must maintain a clean system of record for governed artifacts. This is the convergence of Salesforce and AWS. We use Salesforce as our system of record for structured data. This is where your driver master and your vehicle master live. This is where the roster hierarchy, your parent-child relationships between regions and sites, is enforced. But Salesforce isn't built to store 10,000 raw telematics pings per second. That is where we leverage AWS for the knowledge lake. We use AWS S3 buckets for raw logs and video snippets. We use the AWS EventBridge to handle high-volume event routing, the noise. When a harsh event occurs in the telematics platform, it hits EventBridge. If that event meets a certain threshold, we push a summary event into Salesforce. That is the signal. This keeps our Salesforce org lean and fast, while ensuring we never lose the granular context stored in AWS. We keep raw telemetry out of the system of record, store it separately, and elevate only what is relevant. Because NVR and safety data can be sensitive, a mature system includes role-based access controls. Drivers see explanations and actions they need. Supervisors see posture, rationale, and tasks. Executives and insurers see trends, and improve without exposing unnecessary personal data. This mirrors security governance principles, least privilege, and auditable access. Now, let's talk about the 4th layer, the brain of the system, comprehend. This is powered by our Safety Copilot. We compute posture and determine next best actions here. Fit to drive is an evaluated posture incorporating telematic patterns, MVR severity, training completion, and trend trajectory. The output is either fit, fit with conditions, or not fit at all. Behind it, evidence, thresholds, policy rules, actions, approvals, and what happened next. Fit with conditions avoids false binaries. Conditions translate policy into day-to-day controls such as mandatory pre-dispatch checklist for the next 10 shifts, supervisor ride-along within 30 days, restriction from high-density urban routes until coaching is complete, mandatory training module completion before next dispatch, increased review frequency for MVR and telematics patterns. Because conditions are logged, they become audit evidence and litigation-proofing artifacts. We are moving past simple if-then logic. We are using AI and the Model Context Protocol, MCP. I want to be very specific about what MCP means for Rios. We view MCP not as a set of tools, but a set of autonomous skills. Let's review a few of our Safety AI Copilot core skills. One, the context fetcher. When a supervisor asks, why is Aaron's rhythm risk index score dropping? The AI uses retrieval augmented generation to fetch context from the knowledge lake managed by Amazon Bedrock. It looks at the specific harsh braking events and compares them against the company's safety policy stored in our vector DB. 2, the task creator. This is an autonomous skill. If the AI detects a reckless driving violation in the continuous driver monitoring platform sync, it doesn't just alert a human, it autonomously creates a coaching task in Salesforce and assigns the relevant learning management system module. Our safety copilot translates MVR like a medical copilot translates a lab report and recommends interventions. It executes workflows, tasks, notifications, and closure tracking with guardrails, permissions, and logging. 3, the alert dispatcher. This skill manages the management of exception loop. It determines if a signal is an emergency by calling a supervisor or a nudge by sending an SMS to the driver. Finally, we have the experience layer. This 5th layer delivers governance into the workflow where people live. This is the glass the user sees. Whether it's the command center web console for supervisors or the Rhythm Go mobile app for drivers. Because we use an omnichannel approach— voice, video, SMS, WhatsApp, email, and chat— the AI is where the people are. If a driver is on the road, the copilot can use a voice skill to provide a real-time safety reminder. If a supervisor is in a meeting, they can get a high-level video summary of the morning's risk via SMS. We are eliminating the swivel chair effect. You no longer go to the data; the data, processed and understood by the AI, comes to you. This visibility allows us to align closely with regulatory and compliance entities like DOT. And FMCSA. For example, we use FMCSA as an external reference where their safety measurement system categories inform where they tighten internal controls. Internal governance should produce measurable external improvement over time. This also guarantees ISO 39001 enablement. Auditors expect evidence of risk assessment, controls, performance monitoring, corrective actions, and management review. A digital operating system makes that evidence consistent and easy to produce. We recognize that you can't flip a switch and become an autonomous fleet overnight. That is why we follow a crawl, walk, run deployment model. Crawl, establish the foundation. Unify data and roster management. Sync your masters and get visibility. Walk. Start the orchestration. Implement roster management. Launch the AI copilot and compute posture. Run. Total governance. Enforce dispatch permissioning, automated insurance reporting, and full-loop coaching. Technologist. Our goal with Rios was to build a platform that will help you manage by exception by design. We ingest the massive historical data from regulatory and compliance entities like DOT and FMCSA. We separate noise streams of data from the telematics platform and the continuous driver monitoring platform into signals to diagnose and unify them under a secure foundational core. We comprehend them with AI to predict and prescribe actions through a mobile-first experience. We ingest, we orchestrate, we unify, we comprehend, we experience and act. That is the how behind a certifiable fleet governance operating system. That is the Rhythm Innovations operating system. For the technologists in the room, I want to leave you with this high-level architectural view. Building a 5-layer cloud architecture from scratch, solving the double-entry problem, unifying AWS and Salesforce, and training an AI copilot to execute autonomous skills is a massive resource-heavy undertaking. It is complex, and the stakes for getting it wrong are incredibly high. But you shouldn't have to build it. You already know the why and the what. You know you need to govern risk, close your liability gap, and generate undeniable proof of your safety standards. Our invitation to you today is simple: partner with Rhythm Innovations. Let us handle the how. We already built the outcome engine. We have done the heavy technical lifting of integration and orchestration so that your team can focus on what actually matters: running a safe, efficient, and profitable fleet. Let me show you what I mean. This single architectural diagram visualizes exactly how our 5-layer governance model— integrate, orchestrate, unify, comprehend, and experience— maps to physical cloud infrastructure. If you follow the data from right to left, you will see exactly how we separate noise from signal. Number 1, the source, where we integrate and orchestrate. Starting on the far right, you have your fleet infrastructure. This is the data exhaust we ingest. The high-velocity raw telemetry from your IoT devices, telematics providers, and external systems. This is the noise. Number 2, the filter, where we unify. That raw data flows directly into the center column, our AWS infrastructure. We use AWS as our heavy-lift knowledge lake. This is where we store unstructured data, manage the cloud trust architecture, and deploy scalable compute power. Crucially, this is where we leverage native AWS AI services like Amazon Bedrock, Lex, Amazon Connect, and SES to process the massive volume of raw pings and only expose the signals as a conversation. AWS acts as a massive filter, ensuring that we don't overwhelm your supervisors and drivers with irrelevant data. Number three, the brain where we comprehend. AWS funnels only the actionable derived signals over to the left side of the diagram, our Salesforce infrastructure. This is where the governance actually happens within Salesforce Data Cloud and the AI Trust Layer. We evaluate that signal against your core data model. If an anomaly is detected, the action and orchestrate engine takes over. To compute the risk posture and assign tasks. Number 4, the glass, where we experience. Finally, those governed actions are pushed to the top of the stack, the user experience layer. Because Salesforce serves as our presentation layer, we can deliver a true omnichannel experience. Whether it's through a driver app or safety manager CRM, we can reach your team exactly where they are. Using WhatsApp, SMS, voice, chat. Ultimately, this architecture allows us to do one thing very well: we capture the noise in AWS and we deliver the governance signal to your people in Salesforce. But don't let the technical complexity of integration stand in the way of protecting your organization's balance sheet. Partner with us and let us implement operating system for safety Mina, with that said, thank you for joining our session today. Let's open up for questions.

Perfect. That was a really insightful presentation, JC. We've got some questions in here. The first one is, this is exactly what I'm dealing with right now. We've got telematics in one system, MVR checks happening somewhere else, and training tracked in another platform. My safety manager is trying to piece it all together manually. Where does this actually become a liability for us?

Ah, yes, of course. You know, liability begins when your systems observe a risk but fail to trigger an action. Disconnected systems create a liability gap. We talked a little bit about that in our previous webinar, you know, where behavioral data and legal compliance live in total isolation. Creating massive blind spots. Risk isn't just the crash itself. It is the foreseeable risk you failed to act on. In litigation, a plaintiff's attorney will point to your fragmented data and ask, you had the data, why didn't you act? RIOS solves this by unifying those isolated signals into a single risk posture. It enforces consistent real-time decisions and logs both the action and the rationale, converting signals into proof of governance. Hopefully that helped.

Perfect. Looks like we have a question about Fit to Drive in practice. This person says, I've got a driver who had 2 harsh braking events this week, just got a minor violation on their license, and they're scheduled for a high-risk route tomorrow morning. Today the decision is on my dispatcher. How would your system handle that?

Yeah, that's— I mean, you know, harsh braking happens to all of us, especially some of us that live in Florida. Our system, you know, evaluates all of those predictive signals together before dispatch. It takes inputs from telematics patterns, MVR severity, training completion, and trend trajectories. Instead of relying on a dispatcher's manual judgment, the driver is automatically evaluated as fit to drive, fit with conditions, or not fit at all. For a driver with a minor violation and harsh braking, they will likely be classified as fit with conditions. This automatically triggers guardrails like route restrictions, required coaching modules, or supervisor review. Now, because this decision is standardized and every condition is logged, it becomes traceable audit evidence, removing inconsistent human error. And hence is the solution, right? The visibility end-to-end. Any other questions, Mina?

Excellent. Yep, we've got another question. This one says, my team is already overwhelmed. We're getting alerts from telematics all day long— speeding, braking, everything. If we add more systems and more data, how does this not make things Yeah, and in fact, that is effectively what we're trying to solve.

Rios is built to reduce noise and alert fatigue, not increase it. You know, a common technical mistake is pushing high-velocity raw telematic events straight into workflows, actions, emails, alerts. Instead, our system focuses on computing derived indicators like heartbreaking events every 1,000 miles or speeding minutes per 100 miles. Whatever that threshold is that our customer would like to focus on, by aggregating this into meaningful risk patterns, we only surface the exceptions that actually require intervention. This management by exception loop allows your managers to focus solely on high-risk situations, instead of drowning in raw alerts.

Excellent. Okay, next question. Question a lot of people have about how much they can trust AI and its accountability. This one says, I like the idea of AI but can't have a black box making decisions about who can drive and who can't drive. If something goes wrong, I'm accountable. How do I trust this?

Yeah, you know, the reality is that I think all of us are learning to understand the boundaries of AI and when to trust it and when to call out the hallucinations, right? But in our case, you know, the AI does not operate in a vacuum. It executes workflows with defined guardrails, permissions, and logging. Its decisions are grounded strictly in known inputs across our 4 pillars: telematics patterns, NVR data, training completion, and historical trends. Because the AI uses retrieval augmented generation to fetch context, we talked about those skills during the session, every recommendation it makes includes a clear rationale. Now, the system logs the decision, the rationale, and the follow-up actions. This means it is an explainable governance model, not a black box. It actually strengthens accountability by providing a clear auditable record of why a decision was made, something that you can trace back. Anything else, Mina, on the chat?

We have time for one more question, and if we haven't gotten to any other questions that were in the Q&A box, we'll circle back to those individuals after the webinar. This one does say, this all makes sense conceptually, but here's where I'm stuck. We've invested in a lot of current— in a lot in our current stack, which includes telematics, MVR training, even some internal dashboards. At what point do you stop trying to stitch this together internally and decide you actually need something? Yeah.

You know, I think a lot of our customers have gone through that journey, and the reality is what we have learned is that most organizations hit a ceiling when they try to stitch systems together internally because that only creates visibility. The truth is visibility without governance is liability. Records that can be subpoenaed in the future, right? Internal builds struggle with orchestration lifecycle events across systems and enforcing policy decisions at scale without manual delays. You know, our platform, RIOS, is not just another tool. It is a digital governance layer, right? It unifies, as we reviewed just now, right? It unifies all of your fragmented signals into a single risk posture. The critical shift is moving from managing tools to governance, governing outcomes. Let's call it that, right? Most fleets already have the data. Everybody has the data, maybe too much data, but in a courtroom or in front of an insurance underwriter, that doesn't protect you. Proof does, right? This traceability does. RIOs is the difference between simply monitoring risk and generating the continuous audit-ready evidence to prove that you govern with that data and that you act on it.

Excellent.

Anything else, Mina, for today?

I think that's it. Any final thoughts from you, J.C.?

No, you know, I think, you know, that the, you know, we're excited to kind of peer a little bit behind the green curtain, as they say, and kind of share with you guys how we have built our platform to help you and your drivers and your entire workforce, your assets, your vehicles remain compliant and safe. We're looking forward to hear from you and see how we can help you implement our solution and get you to where you need to be.

Excellent. Thank you so much. Thank you to everyone who joined us today. If you're looking at your current environment and thinking, we have pieces but they're not all connected, Or we're seeing the signals, but we're not confident in the follow-through. That is really exactly what the system is designed to close that gap. Before you leave, we encourage you to scan the QR code on your screen so you can register for our next masterclass or explore any of our previous sessions in this series. And of course, this tech series— this is the part 2 of the 2-part series. If you missed one, you can go back at any time. And if you'd like to continue the conversation and just connect with J.C. or anyone at Rhythm. We can support you by implementing this model. Reach out to J.C. directly, connect with us on LinkedIn, or visit rhythminnovations.com. And final reminder, we're going to be sending the recording to your— to this session shortly, so you can watch your inbox for that. And enjoy the rest of your day. Thanks, J.C.

Thank you, everybody.