Self-Driving &
AV Systems

Why end-to-end monoliths fail AV certification

Current end-to-end neural AV systems bundle perception, motion planning, and traffic-rule reasoning into shared weights trained jointly. This is attractive for raw performance — joint training allows the system to discover cross-component representations — but it creates three structural problems that compound as fleets scale and geographies expand.

• Any update is a full-stack revalidation event. Adding traffic rules for a new city, improving pedestrian tracking for an edge case, or correcting a planning bias all require retraining and revalidating the entire system. The validation surface area does not shrink as the system matures — it expands with every new capability and every new geography.
• Post-incident explanation is opaque. When a monolithic system makes a wrong manoeuvre decision, attributing the cause — was it a perception failure? a planning error? a misapplied traffic rule? — requires gradient attribution through shared weights that do not cleanly decompose by function. Regulators increasingly require this attribution, and the architecture cannot provide it cleanly.
• Error repetition has no mechanism to fix it. A system that makes a wrong decision on a pedestrian crossing at a specific junction will make the same decision at the same junction tomorrow, and in every vehicle in the fleet, until the next full training cycle — which may be months away. There is no feedback loop between a detected error and the system's behavior in the interval between releases.

The framework addresses all three directly: specialist isolation narrows the update surface, the utility log produces attribution-grade audit trails, and the continual correction loop reduces repeated errors between releases. For AV companies, the strongest argument is not hardware cost but independent updateability, auditable behaviour, and principled abstention. See §2.7 of the full whitepaper for the AV framing in context.

Context-adaptive utility weights: how and when they shift

The central mechanism that makes the framework useful for real-world driving scenarios is the field-weighted utility function. Instead of hard-coded rules for each scenario type, a single formula governs all decisions — but its weights shift automatically with context, producing different priorities in different situations without a separate rule set for each one.

U = w_e(f)·E + w_c(f)·C + w_k(f)·K

E — Efficacy:    performance relative to expected safe behavior in this scenario class
C — Confidence:  internal consistency, penalized by detected contradictions
K — Curiosity:   exploration bonus (near-zero in operational AV; applies in simulation/testing)
f — context field, determining weights and minimum competence thresholds

The key property: the same formula produces different decisions across contexts because the weights, not the logic, change. No pre-written rules are needed for "school zone behavior" versus "emergency transport behavior" — only the weight vector is different, and that difference flows through to every downstream decision.

Weight profiles across AV operating scenarios

The following scenarios are worked examples from §2.1 of the full whitepaper, with context-specific weight derivations:

Comparable field weights table from the whitepaper

For context, the full whitepaper defines field-weight profiles across all safety-critical domains. Aviation autopilot is the most comparable AV-adjacent entry:

AV operating scenarios map closest to aviation autopilot: confidence-weighted, high penalty multiplier, tight minimum competence thresholds. Source: §5.1 of the full whitepaper.

Confidence gates and the abstention decision rule

The confidence gate is the most operationally important single mechanism in the framework for AV deployment. It is a hard gate — not a soft penalty — that enforces a formal abstention when the system's confidence falls below the field-specific minimum. The decision rule is:

act = argmax U     if C ≥ C_min(f)  AND  E ≥ E_min(f)
act = abstain      otherwise   → trigger escalation chain

The key distinction: below C_min, the system does not produce a lower-quality answer. It produces no answer and escalates. In an AV context, a confidently wrong answer is more dangerous than an acknowledged abstention. The gate is what makes that safety property formally verifiable — it is not a soft preference for caution, it is a hard decision boundary with a defined behavior on both sides.

For the AV domain, the recommended confidence minimum is C_min = 0.85, derived from the aviation autopilot profile. This means:

• When sensor fusion uncertainty drives confidence below 0.85, the vehicle abstains from the manoeuvre rather than proceeding at reduced reliability.
• When a specialist produces a confidence value below the threshold for its decision class, the query does not get a specialist answer — it gets escalated.
• The confidence minimum is field-specific: it can be tightened for high-stakes decision classes (collision avoidance: C_min = 0.90) and relaxed for lower-stakes ones (route planning: C_min = 0.65).

Illustrative thresholds. Must be validated against the operator's specific ODD and safety case before operational deployment. See §5.1–5.2 in the full whitepaper for the threshold derivation methodology.

Specialist decomposition for the AV decision stack

The Micro-Expert model decomposes the AV reasoning stack into independently deployable domain submodels, each with its own weights, calibration cycle, and utility tracker. The decomposition maps naturally onto the functional architecture that AV teams already reason about:

The inter-specialist interface is a structured protocol — the same data structure the wrapper layer already produces, requiring no new design:

Request:  { query, context, field, confidence_floor, session_id }
Response: { answer, confidence, assertions[], uncertainty_flags, U_score }

Each specialist's response includes its confidence value and any uncertainty flags raised during generation. The Arbiter consumes these structured responses, not raw text outputs. This is what enables formal contradiction detection — contradictions are detected between structured claims with associated confidence values, not between free-form text strings.

The Arbiter: structured contradiction resolution between specialists

When two or more specialists produce contradictory outputs — for example, the perception specialist reports a pedestrian in the vehicle's path while the motion planning specialist generates a proceed decision — the Arbiter runs a structured resolution process rather than silently averaging or arbitrarily overriding. See §10.5 of the full whitepaper for the full Arbiter specification.

Contradiction resolution order

1. Logical check          — does one output contradict the other on formal grounds?
                            Cost: O(1) for formal domains. Available for traffic rules,
                            physics constraints, geometry.

2. Mathematical check     — is one output numerically inconsistent?
                            (e.g., claimed trajectory radius vs actual geometry)

3. Cross-session check    — does the assertions store contain a prior correction
                            for this scenario class? Apply it.

4. Empirical check        — compare against simulation-validated scenario library.
                            Costlier but definitive for known scenario classes.

→ If resolution found:    apply most conservative safe output; log correction event;
                          feed verified correction to relevant specialist via DPO pipeline.

→ If no resolution:       trigger escalation chain (see below).

The VCG arbitration mechanism

The Arbiter's incentive structure is formally addressed through a game-theoretic treatment in the whitepaper. Treating domain specialists as players in a cooperative game with the Arbiter as the external social planner, three theorems are proved. Under the Vickrey-Clarke-Groves (VCG) mechanism, truthful reporting of confidence values is the weakly dominant strategy for every specialist (Theorem S1) — eliminating the incentive for a specialist to overstate its confidence to "win" a contradiction. The Arbiter selects the social optimum with Price of Anarchy exactly 1 (Theorem S2), and no specialist prefers to abstain from the arbitration process (Theorem S3). See §10.6 of the full whitepaper for the full proofs.

The practical implication for AV teams: the arbitration outcome is not determined by whichever specialist is loudest or most recently calibrated — it is determined by the formal mechanism that elicits honest confidence reporting and selects the outcome that maximizes the joint utility of all specialists. This is the property that makes the arbitration result defensible in a post-incident review: the Arbiter's decision follows a formally verifiable process, not a heuristic.

Escalation chain: intra-stack → human → minimum-risk condition

The framework defines a three-stage escalation chain for the AV context. Each stage has a defined trigger, a defined behavior, and a defined packet that flows to the next stage.

Edge hardware deployment: Jetson-class specialists and pipeline parallelism

For AV deployment, the hardware-adaptive decomposition argument is stronger than for datacenter deployment — not a cost argument, but a physical feasibility argument. A monolithic frontier model is not merely more expensive than a Micro-Expert graph on vehicle hardware; it cannot be deployed within a vehicle's power envelope at all.

Hardware specs and pricing from NVIDIA and published sources (2025). See §10.9.6 of the full whitepaper for the full edge deployment analysis and Jetson-specific worked examples.

Pipeline parallelism: specialists run concurrently, not sequentially

A critical point that is often missed: in the Micro-Expert deployment on vehicle hardware, the domain specialists do not run one after another — they run in a pipeline. Total added latency is the pipeline stage depth, not the sum of inference times.

Standard pipeline (sequential — naive assumption):
    Perception  → Planning  → Traffic Rules  → Decision
    [50ms]         [40ms]       [20ms]           [5ms]
    Total: ~115ms

Micro-Expert pipeline (parallel — actual architecture):
    Perception        [50ms] ──────────────────────────────┐
    Planning     ←──────────── [40ms, from perception] ────┤→ Arbiter → Decision
    Traffic Rules     [20ms running in parallel] ──────────┘
    Total: ~55ms + arbitration overhead ≈ 60–65ms

This is the same architecture that production AV stacks — Tesla FSD, Waymo's neural network pipeline — already use for their perception and planning modules. The Micro-Expert model applies the same parallelism at the model-graph level, where each parallel element is a domain specialist rather than a fixed computational stage. The result is that a three-specialist deployment on Jetson hardware adds less end-to-end latency than the sequential assumption suggests, and remains within real-time control requirements for most AV decision loops (typically <100ms for non-emergency decisions).

Independent updateability and narrower certification scope

The most important certification argument for the specialist decomposition is what it does to the revalidation scope of individual updates. In a monolithic system, every change — even a traffic rule update for a new geography — carries the full validation burden of the entire system. In the specialist decomposition, updating the traffic rules specialist does not automatically force revalidation of perception or planning, provided the interfaces between specialists remain stable.

Mapping to ISO 26262 and ASIL decomposition

The framework's specialist architecture is compatible with ISO 26262 ASIL decomposition reasoning: safety goals are allocated to components, and component-level validation can satisfy the overall system safety case if the decomposition is sound. Specifically:

• Each specialist can be assigned an ASIL level appropriate to its decision class — the traffic rules specialist may carry a different ASIL rating than the comfort optimization layer.
• Interface specifications between specialists define the safety contract that must hold for the decomposition to be valid — formally the same reasoning as hardware/software interface requirements in the standard.
• The utility log provides the behavioral record required for safety case evidence — utility values, confidence gates, arbitration results, and escalation events are all logged with session context.

The framework is not a replacement for the full ISO 26262 process. But it is compatible with that reasoning pattern in a way that a monolithic model is not, because it produces the modular structure and the behavioral records that the standard's evidence requirements depend on. See §12 Phase 9 for the planned safety-critical deployment validation work.

Shadow mode as blue-green deployment at vehicle scale

Shadow mode testing — already standard practice for AV validation — maps directly onto the framework's blue-green deployment protocol. A new submodel can run silently beside the production model, its utility compared against the live path before promotion. The blue-green trigger condition for AV specialists:

Trigger when ALL of:
    |U_current - U_baseline| > δ(field)     [significant deviation]
    deviation sustained for ≥ T interactions  [not transient noise]
    held-out scenario library available        [can evaluate candidate]

δ(aviation/AV)  ≈ 0.005–0.010   [very sensitive — small changes matter]
T(aviation/AV)  ≥ 246 interactions  [high confidence window required before promotion]

The high T value for safety-critical fields means that a specialist must prove sustained improvement across a statistically significant sample before any traffic is shifted from the production model. This is more conservative than standard software blue-green deployment and is calibrated to the error cost of the domain. See §10.7 of the full whitepaper for the full deployment lifecycle.

Fleet-level correction propagation from edge encounters

One of the structural problems with deployed AV systems is that an edge case encountered by one vehicle takes months to improve behavior across the fleet — because the correction path goes through a full retraining cycle. The framework provides a faster, narrower-scope correction path through the assertions store and DPO calibration pipeline.

When an edge case is encountered and the escalation packet is reviewed:

1. The reviewed case is logged as a structured correction in the assertions store — not as raw text, but as a typed, confidence-annotated assertion with the scenario context and the verified correct behavior.
2. The correction is routed to the relevant specialist only. A rare pedestrian behavior updates the perception specialist's assertions store; a new traffic law in a new jurisdiction updates the rules specialist. The other specialists are unaffected.
3. At the next calibration cycle, the correction becomes a DPO training pair — (incorrect behavior, reviewed correct behavior) — weighted by the field penalty multiplier. For AV decision classes with a high penalty multiplier, this correction is trained proportionally harder than corrections in lower-stakes domains.
4. The updated specialist is promoted via blue-green protocol — canary at 5% of fleet, gradual expansion as utility improves, full promotion only after the statistical confidence window is satisfied.
5. Future encounters with similar scenarios benefit immediately from the assertions store injection — even before the DPO calibration cycle completes — because the correction is injected into the specialist's context at session start.

MVP shape: shadow-mode validation before any live control

A practical MVP for an AV team adopting this framework does not start with any live vehicle control role. It starts in shadow mode, building a logged track record against the production system before the framework influences any real decisions. This follows the same validation logic as standard AV disengagement analysis, but with structured utility and confidence metrics rather than binary disengagement events.

Where to read next

Configure this domain today

AUA v1.0 handles the arbitration, correction, and audit layer. Configure safety-critical fields with high c_min thresholds and the append-only audit chain. Physical vehicle integration is via the AUA REST API.

1. Install

pip install adaptive-utility-agent

2. Scaffold for this domain

aua init my-self-driving-vehicles-agent --preset medical-safe --tier macbook
cd my-self-driving-vehicles-agent
aua doctor

3. Key config for this domain

# aua_config.yaml
specialists:
  - name: aviation
    model: qwen-coder-7b-awq
    port: 11434
    field: aviation

safety:
  abstention_enabled: true
  require_arbiter_for_high_risk: true
  min_confidence_for_direct_answer: 0.95

security:
  encryption: {enabled: true, key_secret: AUA_ENCRYPTION_KEY}

audit:
  enabled: true
  hash_chain: true

Generate your encryption key: python3 -c "import os; print(os.urandom(32).hex())" or openssl rand -hex 32 — 64-char hex string. See Tutorial §12.4 for key management.

4. Start and query

aua serve

curl -X POST http://localhost:8000/query \
  -H "Authorization: Bearer $AUA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "...", "session_id": "demo"}'

5. What AUA handles vs. what you bring

Full instructions: AUA Tutorial · Framework v1.0 · GitHub ↗