Regulatory Framework
UN Regulation No. 156, "Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system," entered into force on 22 January 2021 under the 1958 Agreement administered by UNECE WP.29. R156 establishes two related approval objects: a Software Update Management System certificate of compliance issued to the vehicle manufacturer at the organizational level, and a vehicle type approval that incorporates the SUMS certificate and any vehicle-specific update conditions. In the European Union, R156 is binding under Regulation (EU) 2018/858 and was made mandatory for new vehicle types from 6 July 2022 and for all new vehicles registered from 7 July 2024. Equivalent transpositions have been adopted by other 1958 contracting parties including the United Kingdom, Japan, and the Republic of Korea, with national variation in transitional periods.
The regulation distinguishes RX software updates, which require regulatory authority interaction because they affect type-approval-relevant parameters, from updates that do not. For RX updates, the manufacturer must demonstrate to the Type Approval Authority that the update has been assessed for safety, cybersecurity, and continued conformity, and the SUMS must record the dependencies between updates, vehicle variants, and approved types. Annex 1 of R156 enumerates SUMS process requirements covering configuration documentation, dependency analysis, compatibility verification, integrity protection, target identification, and the recording of update outcomes. R156 is paired operationally with R155 (Cyber Security Management Systems) and references ISO/SAE 21434 for cybersecurity engineering, with ISO 24089 providing the corresponding international standard for software update engineering practice.
R156's runtime expectations are explicit. The vehicle must be capable of identifying its current configuration, of verifying the authenticity and integrity of an incoming update, of executing the update only when preconditions on vehicle state and environment are satisfied, of recording the outcome, and of restoring a known-good configuration on failure. The SUMS must keep a record sufficient to reconstruct, for any vehicle in service, the precise sequence of updates that produced its current configuration. These runtime obligations cannot be discharged by management-system documentation alone; they require architectural support inside the vehicle's electronic control infrastructure.
Architectural Requirement
The architectural requirement R156 imposes on the vehicle is that every update event be a structurally identifiable, integrity-protected object with a recoverable provenance and a defined activation gate. The update payload must be authenticated against a manufacturer-controlled signing identity, dependency analysis must be enforceable in the vehicle and not solely in back-office tooling, and the activation must be conditioned on vehicle-state preconditions including but not limited to ignition, motion, charge state, connectivity quality, and the regulatory status of the destination jurisdiction. Each of these properties is most directly supplied inside the vehicle itself, because the vehicle is the entity against which Type Approval Authority audits are performed.
A parallel requirement applies to AI-enabled functions whose behavior is shaped by deployed models or parameters. Where R157 (Automated Lane Keeping Systems) and forthcoming Automated Driving System regulations interact with R156, model updates and parameter adjustments fall within the SUMS scope and must therefore satisfy the same identity, integrity, and activation discipline as conventional firmware. The described architecture accommodates the higher cadence of model adaptation while preserving the integrity properties R156 inherits from automotive cybersecurity practice. A third regulatory requirement is rollback: the vehicle is expected to return to a previously certified configuration on failure, with the rollback path itself treated as a certified update transition.
Runtime Evidence and Procedural SUMS Implementations
A procedural SUMS implementation discharges the regulation through process artifacts: an update policy, a change-management procedure, a release-approval workflow, and an audit log retained in back-office systems. As publicly reported in audit practice, Type Approval Authorities increasingly request evidence during SUMS audits and Conformity of Production checks that the in-vehicle behavior matches the documented process, including signed update records retrieved from production vehicles, dependency analyses replayed against actual vehicle configurations, and rollback events demonstrated end-to-end. In a procedural posture the connection between the back-office records and the in-vehicle reality is mediated by manual attestation, so the evidence the Authority asks for is assembled at that seam. The described architecture instead emits that evidence from the vehicle as a structural product of the update itself.
The same evidentiary demand appears under post-update incident reporting obligations. When a safety-relevant event occurs after an update, the manufacturer reconstructs the precise update sequence applied to the affected vehicle, the preconditions evaluated at activation, the integrity verification result, and the post-activation outcome record. An update list and a runtime activation context are different artifacts, and it is the runtime activation context that lets the Authority determine whether the SUMS performed as approved; the described architecture records that context at the vehicle. The same pattern applies where R156 interacts with R155: cybersecurity incident analysis relies on an inspectable integrity chain from signing to activation, and the described architecture carries that chain across the vehicle boundary rather than terminating it there.
What the Spatial-Adaptation Primitive Provides
Spatial adaptation models each update, whether firmware, configuration, or model parameters, as a governed observation: a credentialed payload carrying its own authority basis and applicability scope, distributed across the mesh and admitted at the receiving unit only after a composite admissibility evaluation. In automotive terms this is a runtime signed artifact whose signature binds the payload identity, the dependency manifest, the target configuration baseline, and the activation policy into a single verifiable structure. The artifact's authority credential is verified at the moment of activation rather than only at download, validated against the unit's prior firmware-hash history, which closes the gap that R156 auditors have learned to probe. Sandbox pre-activation evaluation ensures that the artifact has been exercised in a sandboxed execution environment against the safety, integrity, and capability-envelope properties associated with its scope before any activation in a production vehicle; an artifact that fails sandbox evaluation is not applied and the failure is itself recorded. The sandbox-evaluation output and the activation outcome are written to the unit's lineage field, so the certification record travels with the artifact rather than living only in back-office tooling.
Applicability-scoped activation addresses the recurring problem that an OEM's vehicle fleet contains many electronic-control-unit variants, sensor substitutions, and model lineages, and that an update certified for one variant should not be applied to another outside its certified scope. The primitive carries an applicability-scope specification with each governed observation and admits the artifact at a receiving unit only when that unit falls within the declared scope, binding the artifact to a configuration envelope and refusing activation outside it. Policy-gated activation extends the same admissibility check to the regulatory state of the destination: because activation preconditions are governance-policy-defined and evaluated against published policy before the update takes effect, the OEM can express jurisdiction, vehicle type approval status, R156 SUMS scope, and any concurrent R155 or R157 obligations as policy and have activation in a context outside the artifact's declared certification scope be withheld by the admissibility gate in the described embodiments rather than merely discouraged by procedure. Every policy transition and update event is recorded in the unit's lineage field, and admission failure triggers reversion to the prior certified state, so the in-vehicle behavior is auditable in a single inspection rather than reconstructed from federated process artifacts.
Compliance Mapping
Mapping the primitive to R156 obligations is direct. The Annex 1 process for unique identification of software is satisfied by the signed artifact identity. The dependency analysis requirement is satisfied by the dependency manifest carried in the signature, which the vehicle evaluates against its current configuration before activation. The compatibility-verification requirement is satisfied by the sandbox certification record, which establishes that the artifact has been exercised against the relevant verification suite. The integrity-protection requirement is satisfied by the signature itself, with key management aligned to the manufacturer's R155 cybersecurity management system. The recording-of-outcomes requirement is satisfied by the activation log, which is signed and retained in a form suitable for Type Approval Authority audit.
The interaction with R155 is similarly direct. The integrity chain from signing to activation is inspectable, supporting the threat-analysis-and-risk-assessment activities required by R155 and ISO/SAE 21434. The interaction with R157 and forthcoming Automated Driving System regulations is supported by the cross-model portability property, which enables AI-relevant updates to inherit the same SUMS discipline as conventional firmware without requiring duplicate governance infrastructure. Finally, the rollback obligation is satisfied because every certified configuration is itself an activation target, and the activation gate can transition the vehicle to a previously certified state under the same integrity discipline as a forward update. ISO 24089's process expectations attach to the primitive without modification, because the primitive's runtime properties are the substrate ISO 24089 process activities produce evidence about.
Adoption Pathway
OEMs preparing or maintaining a SUMS certificate can adopt spatial adaptation incrementally. The first step is to identify every update class currently in scope of the SUMS, firmware, calibration, configuration, model, map data, and to express each as a candidate signed-artifact category with defined activation preconditions. The second step is to deploy in-vehicle signature verification at the activation gate rather than only at the gateway, which immediately strengthens the evidence available to Type Approval Authority audits. The third step is to construct a sandbox certification pipeline that exercises each artifact category against the verification suite required by its scope, producing the certification records that travel with each artifact.
The fourth step is to integrate regulatory-aware activation with the OEM's homologation and sales-channel data, so that activation in any given vehicle is gated on the type-approval status of that vehicle in its jurisdiction. The fifth step is to revise SUMS documentation to reflect the primitive as a first-class architectural element, which produces a coherent submission to the Type Approval Authority during SUMS recertification cycles. OEMs with concurrent R155 obligations should align signing-key management and incident-response playbooks with the primitive's integrity model, because the audit benefit compounds across the two regulations. OEMs with R157 ALKS or upcoming Automated Driving System scope should treat AI artifact governance as part of the same primitive rather than as a separate regulatory track, since this avoids duplicate governance and produces a single defensible architecture across the regulatory portfolio.
Disclosure Scope
This article is an application of the Spatial Adaptation inventive step disclosed in U.S. Provisional Application No. 64/049,409. The patent disclosure is the governed in-field update primitive: distribution of firmware, configuration, model, and policy updates across a governed mesh as credentialed governed observations, each carrying an authority credential and an applicability-scope specification, admitted at the receiving unit through a composite admissibility evaluation, exercised in a sandboxed execution environment before application, validated against the unit's prior firmware-hash history, recorded in a tamper-evident lineage field, and reversible to a prior certified state on admission failure. The mapping of those primitives to UNECE R156 Software Update Management System obligations, to the interactions with R155, R157, ISO/SAE 21434, ISO 24089, and EU Regulation 2018/858, and to the OEM adoption pathway described above is application and regulatory framing provided for context; the named regulations and standards are the property of their respective bodies and are referenced descriptively. No update-latency, rollback-time, or throughput figure is claimed. Nothing in this article expands the scope of the disclosure beyond what U.S. Provisional Application No. 64/049,409 supports.
