Latitude AI: Building a Functional Safety Organization From Scratch

Ford spun Latitude AI out of its Argo AI acquisition assets in late 2023, giving it a specific and bounded mission: develop the hands-free highway driving technology that would ship in Ford and Lincoln production vehicles. Not a research program. Not a pilot. Production. That mandate shapes everything about how Latitude has to operate.

Hands-free highway driving sits in a regulatory and technical space that is genuinely hard. It is not the Level 2+ supervised driving that Comma.ai or Tesla’s Autopilot occupies. It is not the fully driverless robo-taxi operation that Waymo runs in geofenced urban environments. It is a middle zone—a driver monitoring and engagement system combined with highway-speed longitudinal and lateral control—where both ISO 26262 (functional safety) and ISO 21448 (SOTIF, Safety of the Intended Functionality) apply in full. Teams working in this space cannot pick one standard and gesture at the other.

The Current State of Hands-Free Highway Development

The production hands-free highway space has consolidated significantly over the past two years. General Motors’ Super Cruise remains the most mature production system in North America, with a camera-based driver attention system and a high-definition map dependency that constrains its operational design domain. BMW’s Hands-Free Lane Change debuted on the 5 Series in 2025. Mercedes-Benz’s Drive Pilot operates in a narrower speed envelope—under 40 mph in Germany—but carries formal Type Approval under UN Regulation 157, which gives it a legal status no North American system currently matches.

Latitude is building into this environment with the specific advantages and constraints of being a captive subsidiary. It has guaranteed vehicle integration volume through Ford and Lincoln programs. It has access to Ford’s vehicle electrical architecture, sensor mounting provisions, and ECU platforms. What it does not have is the decades of accumulated process documentation, safety case history, and tribal knowledge that internal OEM programs carry.

That is the actual engineering challenge Latitude faces, and it is worth examining precisely.

What SOTIF Actually Demands From a Development Organization

ISO 21448 is frequently described as a complement to ISO 26262, which is accurate but undersells how different the intellectual exercise is. ISO 26262 asks: what happens when something fails? It drives FMEA, fault tree analysis, diagnostic coverage calculations, and hardware integrity targets like ASIL D for specific safety functions. The discipline is failure-mode reasoning.

ISO 21448 asks a harder question: what happens when everything works exactly as designed, but the system encounters a situation it was not designed for? It is the standard for foreseeable misuse, sensor limitations, edge-case scenario coverage, and operational design domain (ODD) definition. The discipline is scenario reasoning—identifying the universe of situations a system will encounter, characterizing which ones are within its competence, and defining what the system does at the boundary.

For hands-free highway driving, the SOTIF challenge is severe. Highway environments include construction zones, emergency vehicles crossing lanes, debris, degraded lane markings, and weather-induced sensor degradation. Each of these is a known scenario category. The SOTIF work involves exhaustively characterizing them, defining the system’s response policy for each, and then testing sufficiently to demonstrate that the residual risk from unknown scenarios has been reduced to acceptable levels.

The phrase “residual risk from unknown scenarios” is doing significant work in that sentence. There is no mathematical proof of sufficiency for SOTIF coverage. The standard requires reasoned argument supported by evidence—a safety case—that the organization has been thorough. That reasoned argument has to be traceable. Every scenario category, every ODD boundary decision, every test case mapped to a requirement. The traceability burden is substantial, and it has to be built into development workflow from the start. Retrofitting it onto an existing software development process is one of the most painful things a safety engineering organization can do to itself.

The Institutional Knowledge Problem

When an automotive OEM’s internal safety team develops a new feature, it inherits decades of accumulated process infrastructure. There are existing safety plans, established FMEA templates, calibrated relationships with TÜV SÜD or Bureau Veritas or SGS as the functional safety assessor, and engineers who have been through full ISO 26262 assessments before. The organization knows how much work an ASIL D decomposition actually takes. It knows which arguments its assessor will challenge. It knows the difference between a safety case that looks complete and one that will survive a rigorous review.

Latitude had to build all of that from scratch, rapidly, while simultaneously developing the product. That is genuinely difficult. The risk is not that the engineers are incompetent—Latitude attracted strong talent from Argo AI, Aurora, Uber ATG, and Ford’s internal ADAS programs. The risk is that process infrastructure takes time to mature, and immature process infrastructure in safety-critical development produces requirements that are ambiguous, traceability that has gaps, and safety cases that need significant rework before certification.

The specific failure mode to watch is requirements debt. In functional safety development, every system-level safety requirement needs to flow down to subsystem requirements, hardware requirements, and software requirements with documented rationale at each step. The HARA (Hazard Analysis and Risk Assessment) drives ASIL ratings, which drive development rigor requirements across the entire supply chain. If the initial HARA is underdeveloped—if it misses hazard categories or assigns incorrect ASIL ratings—the entire downstream requirement structure is compromised. Fixing that mid-program, when hardware is in validation and software is in system testing, is expensive in time and resources.

New safety organizations often carry this debt because the HARA is done early, under schedule pressure, by a team that has not yet developed its full understanding of the system’s behavior. The HARA that should be a living document anchoring the safety case instead becomes a frozen artifact that no one wants to reopen because reopening it means cascading rework.

The Ford Hardware Interface Problem

Latitude’s other major systems engineering challenge is the organizational boundary with Ford’s vehicle hardware programs. Hands-free highway driving is not a standalone product. It runs on ECUs integrated into Ford’s vehicle electrical architecture, uses sensors mounted in positions determined by Ford’s exterior design teams, and actuates via Ford’s steering and braking systems. The functional safety responsibility for each of those hardware elements sits with Ford’s internal programs. The safety responsibility for the autonomy software stack sits with Latitude.

This is an interface management problem of significant complexity. The standard mechanism for managing it is the SEooC—Safety Element out of Context—framework defined in ISO 26262 Part 10. A SEooC allows Latitude to develop its autonomy software against assumed interface requirements, which then need to be validated against the actual hardware context when integration occurs. This is reasonable engineering practice, but it creates a specific risk: if Latitude’s assumed interface requirements and Ford’s actual hardware capability diverge, the safety case has a gap at the interface.

That gap can show up in several ways. Actuator response latency different from the assumed model. Sensor field-of-view obstructions not captured in the assumed mounting envelope. Power supply characteristics that affect sensor performance at temperature extremes. CAN/Ethernet communication latency higher than assumed under load. Each of these is a potential safety relevance, and each requires a resolved requirements handoff between organizations to close.

Managing these handoffs well requires discipline on both sides of the organizational boundary. Latitude needs rigorous interface requirement documentation. Ford’s vehicle programs need formal acknowledgment of those requirements and traceability to their own safety cases. In practice, this kind of cross-organizational requirements management is one of the harder coordination problems in automotive development. It is an area where tooling and process matter enormously—informal communication and email-chain negotiation do not leave the traceability record that a safety case requires.

What Mature Practice Looks Like

The organizations that execute this well share several characteristics. Their HARA is genuinely living—reviewed and updated as the system understanding matures, with change history that explains why ASIL ratings were revised. Their ODD is formally defined in a structured format, not prose, with machine-readable boundaries that can be referenced in test case specifications. Their requirements management system captures not just requirements but rationale, and not just downstream traceability but upstream traceability to safety goals.

Modern tools have made this more tractable. The shift toward graph-based requirements models—where requirements, hazards, safety goals, test cases, and design elements are nodes in a connected model rather than rows in a spreadsheet—makes the traceability work less manually intensive and more structurally sound. Tools like Flow Engineering have been adopted by systems engineering teams in exactly this space, offering AI-assisted requirements development and graph-based traceability that can surface coverage gaps before they become certification problems. The operational advantage is that engineers spend less time maintaining traceability manually and more time on the engineering judgment that traceability is meant to capture.

The SOTIF scenario management problem also benefits from structured tooling. Scenario libraries need to be linked to ODD boundaries, to test cases, to safety claims in the safety case. That linkage, maintained manually in spreadsheets, tends to degrade as the program grows. Maintained in a connected model, it remains navigable and auditable.

Honest Assessment

Latitude AI is doing something hard. The mission is well-defined and the organizational structure—a focused subsidiary rather than a diffuse internal program—has real advantages for speed and talent attraction. The risks are also real and specific.

The institutional knowledge problem is the one with the longest tail. It does not manifest as immediate failure; it manifests as rework costs in late integration phases and as safety case gaps that surface during assessment. Organizations that recognize this early and invest disproportionately in process infrastructure and safety case quality during the first two years tend to have smoother paths to production. Organizations that prioritize feature velocity over process rigor in the early phases tend to pay a steep price later.

The Ford interface management problem is solvable but requires sustained organizational discipline on both sides. The boundary between an autonomy software subsidiary and a vehicle hardware OEM is not a natural home for clean requirements handoffs. It requires explicit process agreements, named interface owners, and tooling that both organizations can work from.

Whether Latitude emerges as a durable engineering organization or gets reabsorbed into Ford’s mainstream ADAS development will depend substantially on whether it builds the process infrastructure that functional safety development demands—not just the engineering talent, which it clearly has, but the institutional scaffolding that converts good engineers into a certifiable safety case.

That scaffolding is harder to build than it looks, and it has to be built while the product is being developed. That is the actual challenge Latitude is navigating.