A Complete Vehicle That Cannot Yet Think

Part 3 closed on a megacast, pack-bridged chassis wrapped in unpainted flax-fibre and digital film — mechanically and materially a finished vehicle, but not yet an intelligent one. Software is where a sub-£30k programme is most tempted to make the same mistake a Gigafactory-scale plant makes with capital: build everything in-house, on the theory that vertical integration is always the defensible position. It is the wrong instinct here for the same reason it is the wrong instinct in the body shop. This installment sets out the vehicle's software architecture as a deliberate split: what is bought, and what is built.

The Software Strategy: Stripping Out Infotainment R&D Overhead

Legacy automakers have spent the last decade demonstrating, at enormous and well-documented cost, what happens when a car company decides to build its own infotainment operating system, its own mapping and navigation stack, and its own app ecosystem from scratch. Multi-billion-pound software programmes routinely ship years late, land with interfaces a generation behind the smartphone the customer already owns, and carry ongoing maintenance and update costs that never fully amortize — because the car company is, at that point, competing directly against companies whose entire business is building consumer software platforms, with a fraction of the engineering headcount and none of the platform economics.

This programme does not make that mistake. The vehicle's control software is specified as a Dual-Layer Software Architecture, and the boundary between the two layers is drawn deliberately along the line between "consumer experience" and "vehicle physics":

  1. Layer 1 — the cabin: an off-the-shelf, licensed platform handling everything the driver and passengers directly see, touch, and speak to.
  2. Layer 2 — the powertrain: proprietary, in-house code handling the vehicle's physical control logic — battery, motor, and inverter — where safety certification and chemistry-specific tuning make an off-the-shelf platform unsuitable at any price.

The commercial rationale for Layer 1 is direct. Licensing Android Automotive OS (AAOS) with Google Automotive Services (GAS) delivers a smartphone-grade, responsive cabin interface, natively integrated navigation, and access to an existing, massive third-party developer ecosystem, from the vehicle's first day of production — for effectively zero upfront infotainment software R&D capital expenditure. The engineering budget this frees up is redirected entirely into Layer 2, which is where this vehicle's actual technical differentiation, and actual safety liability, sit.

The Cabin Experience: Google Built-In and Gemini Integration

Because the cabin runs AAOS with Google Automotive Services natively, the vehicle inherits Google's Gemini AI model built directly into the operating system core, not bolted on as a third-party app competing for background resources. Gemini handles multi-modal conversational voice commands — natural-language requests that combine destination, preference, and context in a single utterance rather than requiring a rigid command syntax — dynamic route optimization drawing on live Google Maps telemetry for real-time traffic and charging-network conditions, and smart home device syncing over the air, letting the cabin act as a control surface for the driver's connected home without any bespoke integration work on this programme's side.

The cabin's connection to the physical car itself runs through the Vehicle Hardware Abstraction Layer (VHAL), the standardized interface AAOS exposes for vehicle-specific hardware control. Through VHAL, the Google platform natively addresses climate zone control, seat configuration profiles, and digital lighting cluster states directly, without this programme having to write and certify a custom middleware layer to translate between Google's software and this vehicle's hardware. What VHAL explicitly does not expose, by design, is anything touching the vehicle's high-voltage or motion-control systems.

The Core Powertrain Brain: Proprietary Wide-Input BMS AI

Everything below the dashboard runs on different rules. Google's software stack is deliberately, physically isolated from the vehicle's physics and safety-critical systems through secure hardware firewalls — dedicated, non-bypassable boundaries between the infotainment domain and the powertrain domain, so that a fault, a crash, or a malicious input anywhere in a consumer software platform running third-party apps can never propagate into motor control, battery management, or braking-adjacent systems. No amount of Layer 1 platform maturity changes this boundary; it is architectural, not a software permissions setting.

Behind that firewall sits the code this programme's internal AI software team actually had to write from nothing: the wide-input Battery Management System (BMS) machine-learning models that govern the sodium-ion pack specified in Part 2. These models run a continuous, real-time regression against three coupled inputs — instantaneous voltage sag under load, the cell's internal resistance as it changes with state of charge and cycle count, and ambient temperature, including the specific case of the pack operating in freezing UK winter conditions, where sodium-ion's low-temperature behavior diverges most sharply from lithium chemistries.

The output of that model is not a dashboard readout — it is a live control signal into the pack's bi-directional DC-DC booster circuits. Sodium-ion cells discharge along a characteristically sloping voltage curve, from roughly 4.0V down to 1.5V per cell across the usable state-of-charge window, a far steeper discharge slope than a flat-plateau lithium chemistry presents. Left uncorrected, that slope would mean the motor sees a steadily falling supply voltage as the pack depletes. The wide-input BMS model instead recalibrates the DC-DC booster circuits continuously, in real time, to hold a flat, unwavering 400V rail to the motor regardless of where the pack sits on its discharge curve — the specific piece of proprietary code that makes a steeply sloping sodium discharge curve invisible to everything downstream of it.

Inverter Switching Algorithms and the Vehicle-to-Home (V2H) Matrix

The same in-house team owns the low-level, high-frequency switching code controlling the vehicle's 120kW Silicon Carbide (SiC) inverter — the power electronics translating the stabilized 400V DC rail into the precisely timed AC waveform the rare-earth-free motor specified in Part 1 actually runs on. Because that motor generates torque through reluctance rather than permanent-magnet flux, extracting maximum efficiency depends on switching algorithms that manage reluctance torque precisely through a rotor speed range exceeding 20,000 RPM — timing that has to be computed and corrected far faster than a human-tunable control loop, and that has to be specific to this motor's geometry rather than borrowed from a permanent-magnet motor's control tables.

The same inverter and DC-DC hardware, controlled by a different code path, is also what makes Vehicle-to-Home (V2H) power routing possible without adding a single additional power-electronics component — a hardware-free V2H architecture built entirely on capability the vehicle already carries for driving. Because the 200 Wh/kg pure sodium matrix specified in Part 2 has a materially higher cycling stability than a comparable lithium pack, the vehicle can run as a domestic energy storage asset during peak grid tariff windows — discharging back into the home during expensive demand periods and recharging during cheap off-peak hours — without the incremental cycling this adds to the pack falling outside the depth-of-discharge and C-rate envelope the factory warranty is written against. The same wide-input BMS model governing motor supply during driving governs V2H discharge the same way, which is what lets this feature ship without a separate warranty carve-out.

Where the Intelligence Goes Next

A vehicle with a licensed cabin, an isolated powertrain brain, and inverter code tuned to its own motor is a complete, intelligent product — but it is still only a product once it can be built, at volume, on a brownfield micro-factory floor with the capital discipline the first three installments of this report have insisted on throughout. The fifth and final installment turns entirely to that floor: the proprietary factory operating system, the dynamic AMR pathfinding algorithms that route parts and sub-assemblies without fixed conveyor infrastructure, and the computer-vision quality validation gates that let a low-capex line hold OEM-grade tolerance. That is where Part 5, The Automated Orchestra, begins.