Abstract: ASIL E is not a published standard. Its real value is not the name of a higher integrity level, but the question it forces Level 4 and Level 5 autonomous-driving safety arguments to answer: when there is no human fallback, can the safety case still credit a human controller? For me, the useful translation is not “ASIL E compliance.” It is a no-human-fallback review lens, four evidence fields in ADSafetyPilot, and a feedback loop connecting ROAM, DRIVEResearch, and a field-monitoring-backed safety case.

A few weeks ago I read a functional-safety proposal shared by a practitioner on LinkedIn:

The Case for ASIL E.

The local PDF I read is a 79-page guidebook with the subtitle A Sixth Integrity Level for L4/L5 Autonomous Systems. Its core argument is straightforward: ISO 26262 stops at ASIL D, but the controllability axis was calibrated in a world where a human driver remained part of the residual-control story. For SAE Level 4 and Level 5 systems, that assumption can break.

My first reaction was not: “ASIL E is coming.”

It was almost the opposite:

This is not primarily a new-standard story. It is an old L4 safety-case problem finally being named.

No-human-fallback safety evidence chain

First, the boundary

As of June 3, 2026, ASIL E does not appear in the published ISO 26262 series, ISO 21448, or UL 4600.

The guidebook itself is careful about this point: it is a proposal, not a standard.

So if ASIL E is presented as “already added to ISO 26262,” “mandatory for L4,” or a compliance certificate, I would be cautious.

Safety standards deserve slower language.

A higher label does not make a system safer. The useful question sits underneath the label:

Can an L4 safety case still rely on the implicit assumption that a human driver is the final fallback?

That is the part of the proposal I find valuable.

ASIL D is not wrong. It is just not the whole question.

In ISO 26262 HARA, ASIL is derived from three dimensions:

  • Severity.
  • Exposure.
  • Controllability.

Severity and exposure are relatively easy to explain. How bad can the harm be? How often does the operational situation occur?

Controllability is more delicate.

It is not “can the system control the hazard?” It is, in simplified language, whether a typical driver can avoid harm once the hazardous event occurs.

For many L2 and L3 contexts, that question still makes sense. The driver may be distracted, slow to respond, or overloaded, but the role still exists. In L3, the fallback-ready user remains a major part of the argument.

In L4, the question changes shape:

If no human is expected to take over, whose controllability are we classifying?

The common conservative move is to classify such cases as C3, the most severe controllability category in the existing framework. That is understandable.

But it does not fully answer the question.

C3 means “difficult or impossible for the driver to control.” L4 driver-out operation is not merely “difficult for the driver to control.” It is “there is no driver to control.”

One word changes the engineering meaning.

If that difference is not explicit in the safety case, HARA, FMEA, FTA, SOTIF analysis, simulation coverage, and validation evidence may all keep building on an unstable assumption.

This is not a replacement for SOTIF or UL 4600

I do not read ASIL E as “replace SOTIF and UL 4600 with a higher ASIL.”

That would be the wrong lesson.

I read it as a calibration problem.

ISO 26262 is primarily about functional safety of E/E systems, including random hardware failures and systematic failures. ISO 21448 addresses unreasonable risk caused by functional insufficiencies or performance limitations of the intended functionality; the public ISO page explicitly includes operation-phase activities and notes that remote users or back-office communication can be in scope when they affect vehicle decision-making and can lead to safety hazards.

UL 4600 is again a different style of standard. It is built around the safety case: the structured argument that an autonomous product is acceptably safe in its intended context.

So the L4 no-human-fallback problem should not be squeezed into one document.

The better engineering framing is:

  • ISO 26262 asks: if this hazard is tied to an E/E malfunction, how are the safety goals and integrity targets allocated?
  • ISO 21448 asks: if the system is not malfunctioning, but functional insufficiency, performance limitations, foreseeable misuse, or remote/back-office effects create risk, how is that risk identified, validated, monitored, and updated?
  • UL 4600 asks: can the safety case connect system definition, ODD, evidence, arguments, and field feedback into a credible whole?
  • The ASIL E proposal asks: inside those arguments, are you silently crediting a human controller who is not actually there?

That is why I prefer to call it a no-human-controller review lens.

Not a new safety religion.

A lens for finding hidden assumptions.

L4 needs a shared language

Across L3 and L4 programs I have worked around or followed, practitioners already know this problem exists.

They just call it different things.

Fail-operational.

MRM.

Remote operations.

Safety redundancy.

Safety-case argument.

SOTIF trigger condition.

Field monitoring.

All of those are legitimate pieces of the answer.

But I increasingly feel we are missing a short shared sentence:

The system cannot credit a person who is not part of the fallback path.

This is why the ASIL E proposal is interesting.

It may not be the final answer, but it names the question.

Many engineering methods start not by solving the problem, but by forcing people to admit they are discussing the same one.

I translated it into four product fields

These days I read technical proposals less like a pure academic and more like someone trying to turn insight into reusable assets.

If I read 79 pages, nod, and move on, the idea disappears into the feed.

So I ask three questions:

  • Can it become a one-page internal memo?
  • Can it become fields in a product?
  • Can it become a research question that compounds?

That is partly a constraint of my current working rhythm in the UK. My deep-work window is short, and after that I switch back into parenting mode. Screen time is also something I have to manage carefully.

So I have learned to accept a simple rule:

Seventy percent is enough if the insight becomes reusable.

For this proposal, I first translated the idea into four fields in ADSafetyPilot.

The first field is no_human_controller.

It asks whether this hazardous event is being argued without crediting a human driver.

The second is fallback_credit.

It forces the case to say who or what is being credited: an in-vehicle driver, a remote operator, a remote assistant, field staff, infrastructure, or no one.

The third is policy_coverage_gap.

This is where I think L4 teams can underestimate risk. Many failures are not “the vehicle did not see it.” They are “the vehicle saw it but did not know what to do.”

For example:

  • An emergency vehicle approaches from behind.
  • A construction zone changes the path temporarily.
  • A police officer’s hand signal conflicts with the HD map.
  • The passenger, remote support, and field staff provide different signals at the same time.

Those are not only perception problems. They are policy-coverage problems.

The fourth field is field_monitoring_evidence.

An L4 safety case should not be frozen before SOP. Once the system is on the road, operational events, anomaly handling, remote-operation records, and software updates must feed back into the evidence chain.

These four fields are modest.

But they help me avoid missing one question when reviewing an L4 safety case:

Has this program explicitly argued what happens when no one is in the vehicle to take over?

ROAM is the operation-phase version of the same problem

Over the last few months I have been working on ROAM.

ROAM now stands for Remote Operations & Anomaly Management. It is no longer limited to robotaxi-only operations; the scope is broader L4 autonomous-mobility remote operations and anomaly management.

At first it looks like an incident database.

But the real point is not collecting incident gossip. It is turning operation-phase anomalies into safety evidence.

For example:

  • A batch of vehicles stops abnormally in one region.
  • Remote assistance response is delayed.
  • Emergency vehicles, construction, or infrastructure disruption push the fleet into an abnormal state.

These events are not purely ISO 26262 random hardware failures. They are not just isolated perception bugs either.

They are operation-phase safety-management objects.

ISO 21448 already emphasizes monitoring, trigger-condition identification, and issue resolution during operation. If a remote user or back-office system affects vehicle decision-making, it cannot be kept outside the safety analysis just because it is “operations.”

What I want ROAM to do is structure these events:

  • What happened?
  • In which ODD?
  • How many vehicles were affected?
  • Was remote operation involved?
  • Which response layer handled it?
  • Which new trigger condition was identified?
  • Which test case should be updated?

Then the operation phase is no longer just a place where reports are written after incidents. It becomes a source of evidence that continuously updates the safety case.

This is the same problem as the ASIL E proposal, seen from the other side.

The development-side question is:

How do we express integrity when there is no driver fallback?

The operation-side question is:

Once the system is on the road, how do anomalies flow back into the safety evidence chain?

My earlier post, When the Robotaxi Fails, Who Catches It?, focused on the second question. This post fills in the first.

DRIVEResearch supplies the statistical baseline

The other missing piece is naturalistic driving data.

“L4 should be safer” is not an engineering statement.

Safer by how much?

In which scenarios?

Which behaviours are common, and which are boundary cases?

This is where DRIVEResearch matters.

We have accumulated 800+ hours of drone-based naturalistic driving data and 10.5M+ trajectory fragments. The point is not to say “we have a lot of data.” The point is to answer more concrete questions:

  • How do normal human drivers behave in this scenario?
  • What are the lateral-speed, gap, TTC, and THW distributions for cut-in events?
  • Is a test point a P50 mainstream behaviour or a P95 boundary behaviour?
  • Has the percentile distribution converged as new data is added?

Those questions fit naturally into SOTIF and scenario-based test evidence.

No human fallback does not mean every scenario should be tested with the most extreme parameter values possible.

It means we need to know which scenarios are reasonably foreseeable, which are known unsafe, which remain unknown unsafe, and which are simply under-sampled.

Without a real distribution, safety targets become slogans.

With a real distribution, the safety argument starts to touch the ground.

This is also why I see the ASIL E proposal and OpenODC as part of the same content stack.

OpenODC asks:

Has the system’s operating boundary been described in a public, queryable, comparable, traceable way?

The ASIL E proposal asks:

Inside that operating boundary, when the system has no human fallback, has the safety case made that fact explicit?

DRIVEResearch asks:

Can the boundary and scenario parameters be supported by real traffic-behaviour distributions?

Together, those three questions start to look like an L4 safety evidence chain.

The review checklist I would actually use

If I take this proposal back into a project review, it is not a position statement. It is a checklist.

For HARA, I would ask:

  • Is this hazard a no-human-fallback hazard?
  • Can the MRM actually be completed?
  • Is remote operation being incorrectly treated as a real-time controller?
  • If the document says “the driver can intervene,” does that driver exist inside the L4 ODD?

For policy coverage, I would ask:

  • Has policy coverage been analysed separately from perception?
  • Have scenarios where perception is correct but policy is undefined been listed?
  • Are emergency vehicles, construction zones, police hand signals, map conflicts, passenger behaviour, and field-staff instructions inside the policy space?

For operation-phase monitoring, I would ask:

  • Does field monitoring update the safety case?
  • Does each anomaly record trigger conditions, system state, policy response, human involvement, recovery action, and follow-up change?
  • Can operation-phase events generate new test cases?

For research and standardization, I would move “Is ASIL E the right label?” slightly downstream and first work on more concrete questions:

  • How should no-human-fallback scenarios be classified?
  • How should remote-operation intervention time budgets be modelled?
  • How can policy coverage be quantified?
  • How can operation-phase events generate test cases?
  • How can naturalistic driving distributions support L4 safety cases statistically?

Those questions sit closer to engineering practice. They can become papers, tools, standardization material, and review workflows.

My next step

I do not want this to remain a reading note.

I have already written a one-page internal memo translating the proposal into an “L4 no-human-fallback review checklist.”

Then I added four fields to ADSafetyPilot’s evidence-chain design:

  • no_human_controller
  • fallback_credit
  • policy_coverage_gap
  • field_monitoring_evidence

My next step is to choose an L4 emergency-vehicle interaction scenario and turn it into a full evidence gap report.

I will choose that scenario not because it is flashy, but because it is sufficiently messy.

It contains perception, policy, remote operations, traffic rules, field handling, and operation-phase monitoring at the same time.

It exposes more of the L4 system problem than a standalone AEB pedestrian-at-night example.

It also lets ROAM, DRIVEResearch, and ADSafetyPilot connect:

  • ROAM records operation-phase anomalies.
  • DRIVEResearch supplies real behaviour distributions.
  • ADSafetyPilot connects scenarios, hazards, tests, and evidence chains.

That is what content stacking means to me.

Not publishing one post and moving on, but using each post to move a tool, a dataset, a standardization question, or a research direction one step forward.

Closing

I do not know whether ASIL E will ever become part of ISO 26262.

Honestly, that is not the question I care about most.

I care more about whether the L4 autonomous-driving community can build a shared language for “there is no human driver to catch this.”

Until that sentence is made explicit, ASIL D, SOTIF, UL 4600, safety cases, simulation tests, and field monitoring will keep speaking past each other.

Every document may look complete.

The most dangerous assumption may still be hiding between them.

Standards do not catch the system for you.

What catches the system is whether you can turn “no one will take over” into an auditable, testable, traceable evidence chain.

References