The CEO Just Signed for It. Does the Record Back Them Up?

The CEO Just Signed for It. Does the Record Back Them Up?

The BIS connected-vehicles compliance deadline passed on March 17, 2026. What manufacturers submitted was a declaration of systems integrity. Whether they can actually prove it is a different question.

A deadline passed recently that most of the automotive industry noticed, but most of the public did not. The legacy-code carveout protecting existing foreign-developed software in vehicle architectures stopped covering code maintained or altered by covered China- or Russia-linked entities after March 17, 2026. The BIS connected-vehicles rule is no longer incoming. It is in force.

What that rule requires at its center is a Declaration of Conformity submitted to BIS at least 60 days before the first import or sale of each covered model year vehicle. The declaration must be signed by the chief executive officer or any officer with authority to bind the corporation.

That signature is not a formality. It is a legal claim that the system being sold is the system that was certified. That which was left by the factory matches what was described in the safety case. That the chain of custody from design intent to delivered vehicle is intact and traceable.

An SBOM does not make that claim. An SBOM tells you what software is in the vehicle today. It does not tell you how it got there, whether every change along the way was authorized and reviewed, or whether the electromechanical systems the software depends on are still performing within certified parameters. It is a snapshot, not a chain of records.

The executive who signed that declaration either has the record to back it up, or they signed it on an assumption.

Certification Is an Argument, Not a Guarantee

This is the point the industry has not internalized clearly enough.

The safety case does not certify that a system is safe. It certifies that under defined conditions and defined assumptions, the system was demonstrated to be acceptably safe at a specific point in time. The certification rests entirely on the validity of its premises.

Software-defined vehicles invalidate those premises continuously. OTA updates modify behavior. Supplier patches alter threshold parameters. Machine-learned components interact with operational environments in ways that cannot be fully bounded at design time. Hardware degrades. Sensors drift. A braking actuator that has experienced ten thousand more cycles than the test profile anticipated is not a software problem. It is a systems state problem, and no software bill of materials reflects it.

When any of those conditions change materially, the safety case does not fail. It becomes historical. It describes what was once true about the system. The gap between that documented intent and what is actually operating in the field is the assurance gap. It widens silently. Nobody flags it because nobody is watching it continuously.

The audit happened at the factory gate. The field has been accumulating variance ever since.

A Supplier Substitution the SBOM Never Captured

Consider a scenario that requires no hypothetical: a Tier 2 supplier substitutes a sensor component with an electrically equivalent alternative mid-production cycle. The Tier 1 assembler approves it internally. The OEM's SBOM never reflects the change because the software running on the sensor is identical. The replacement component has a slightly different response curve under low-temperature conditions that fall within the vehicle's operational design domain.

The safety case was validated against the original component. The vehicle in production contains the substitute. The software is clean. The provenance is clear. The thread is broken, and no software audit finds it.

Now multiply that across a fleet, across model years, across the OTA update cadence of a manufacturer running monthly releases into safety-adjacent domains. The executive who signed the Declaration of Conformity signed it assuming the record was intact. The record has gaps that they cannot see.

The Building Industry Learned This the Hard Way

In 2017, Dame Judith Hackitt investigated the Grenfell Tower fire and found something that should sound familiar. The failure was not purely technical. It was informational. Records were weak. Audit trails were incomplete. Accountability dissolved somewhere between the architect's desk and the occupied building. When investigators needed to reconstruct what happened and why, the information required to answer that question was not reliably there.

She called the missing infrastructure the golden thread. An unbroken record of what a building was designed to be, how it changed, and who was responsible for every decision along the way. Not a filing system. Not a compliance artifact generated at handover and then forgotten. A living record, continuous and traceable across the entire operational lifecycle.

The Building Safety Act 2022 gave that concept legal force. The construction industry had its reckoning after the fire.

The automotive industry has the opportunity to build the equivalent infrastructure before one.

What Systems Chain of Record Provides

When we developed the methodology behind SCoR, we started with software provenance. The regulatory pressure around SBOMs pointed there, and the industry conversation was focused on code. But every time we traced an actual failure mode back to its root cause, the root cause was not purely in the software. It was in the relationship between the software and the system it was running within.

A vehicle with a verified SBOM and a degraded wheel speed sensor is not a certified vehicle. It is a vehicle with certified software and an uncertified operational state. Those are not the same thing, and treating them as the same thing is the category error that creates liability exposure when something goes wrong.

That realization forced a rename and a broader architecture. Software Chain of Record became Systems Chain of Record. Not cosmetic. A recognition that the problem was categorically larger than the original name described.

LHP OAS Systems Chain of Record tracks the integrity of a software-defined system across every dimension that affects its certified safety envelope. Software state, firmware versions, calibration records, component substitutions, OTA update lineage, supplier change events, and the outcomes of runtime enforcement decisions. Every update carries a fingerprint tied to the hardware revision and operational history of the specific unit it lands on. Lineage breaks trigger a block. When a regulator or legal team needs to reconstruct what changed and when, the chain of record is the answer. Not a reconstruction. The record.

Our Operational Assurance platform runs as an independent governor alongside it. It holds the safety envelopes defined at design time and enforces them against actual runtime behavior, continuously. If ODD Drift is pushing a system toward the edge of its certified envelope, the platform identifies it before the boundary is crossed. If an update modifies behavior in a way that interacts unexpectedly with a specific hardware variant in the field, the governor catches it before it becomes a field event.

Without SCoR and runtime enforcement, certification describes what was once true. With them, certification remains a living, defensible claim.

The Signature Means Something

Dame Hackitt's conclusion was precise. Safety accountability requires an information infrastructure that spans the entire lifecycle of a system, not only the portion that precedes deployment. The construction industry learned that lesson from a fire that killed 72 people.

The automotive world is arriving at the same conclusion through regulatory pressure, legal exposure, and the structural reality that certification models built for a hardware-defined era cannot carry the weight of systems that evolve continuously in the field.

The organizations that have built systems integrity infrastructure can answer the Declaration of Conformity with confidence. The organizations that have not signed it are doing so on an assumption.

That assumption is a liability with no current owner. When it surfaces, the question will not be what the vehicle did. It will be whether the record existed to prove the chain of custody was intact.

LHP OAS builds that record. Before the signature. Before the deadline. Before the reckoning.

About LHP Operational Assurance Systems

LHP Operational Assurance Systems (OAS) was spun out of LHP Engineering Solutions to address a growing gap in safety-critical, software-defined systems: certification at launch no longer guarantees safe operation over time. As complex platforms began receiving continuous software updates and evolving functionality, LHP OAS recognized that traditional "certify-once" models could not prevent runtime drift between validated safety intent and real-world behavior. Drawing on decades of leadership in functional safety, cybersecurity, and systems engineering, LHP OAS was formed to focus exclusively on extending certified intent into live environments and developed a platform, Operational Assurance Sentinel, that embodies this concept. LHP's Operational Assurance Sentinel platform delivers deterministic runtime enforcement, operational assurance scoring, and tamper-evident evidence chains that transform safety from a static milestone into a continuously verifiable discipline, enabling organizations to deploy advanced autonomous and intelligent systems with measurable, provable confidence.

Leave a comment below. We'd love to hear your take on this subject!