ADD is a pre-constraint rule engine — it defines the safety-feasible space before optimisation begins. Three interlocking pillars: white-box judgment, hot-swap modules, and full traceability.
The central question: does this judgment depend on relationships between multiple objects, or on behavioural change over time? If yes → Type 2.
Simple conditions trigger directly. Written as YAML rules. Analogous to a conditioned reflex — no deliberation needed.
Involves relationships between multiple objects or behavioural history. Uses relational primitives like faster_than(A,B) — cross-vehicle, cross-region, no retraining.
Global, fixed priority bands — no magic numbers. Conflict detection runs statically at rule load time. New rules must pass Priority Conflict + Action Conflict gates before entering the library.
Cannot be overridden by any other rule. Mandatory execution — no exceptions.
Railway crossing · collision warning · emergency braking
Driver may override — requires audit log entry. Jurisdiction-specific, hot-swappable.
Right-of-way · traffic signals · regional laws · school bus stop
Strong recommendations. Driver decision can override — no audit required.
Yielding to pedestrians · defensive driving experience · gap management
Weak supervision — record only or mild suggestion. Comfort and efficiency optimisation.
Comfort optimisation · efficiency enhancement · status monitoring
ADD replaces the Safety Check in a conventional pipeline — gaining white-box auditability while preserving the planning layer's freedom to optimise.
Compatible with end-to-end systems. ADD can replace the Safety Check layer in an E2E pipeline — retaining implicit generalisation while adding white-box auditability. OEM teams regain control over driving policy design without returning to the supplier for model retraining.
VS-03 · Incident trace example
Given any historical frame, ADD reproduces the complete rule_id trigger sequence — matched against the actual execution path — within 100ms.
Unlike end-to-end neural systems, ADD's decision chain is not reconstructed or approximated after the fact. It is the original record — every rule that fired, in sequence, with timestamps.
The output format is structured for direct ingestion by safety validation suites and regulatory reporting tools, reducing type approval documentation overhead.
Each scenario activates a different perceptual bridge — zero overhead for inactive bridges on any given frame.
Road surface state + roadside participant type → multi-rule concurrent activation.
Continuous 10-frame velocity trend → yielding(A) = true. Recognises intent before action.
ETA per vehicle + assertion priority → unique right-of-way sequence. Symmetric tie broken deterministically.
CN ↔ UK rule set switch in 0.08ms — same intersection, different outcomes. Zero retraining.
A-IV trajectory → B-III compression → Ego. Two-hop indirect threat made visible before contact risk.
ADD Studio (Scene Development Studio) is the engineering workbench that turns ADD's rule engine into a complete behavior design platform. Your team uses it to author scenarios, write rules, run regression, and manage jurisdictions — without writing engine code.
| Capability | ADD | End-to-End Neural | Legacy Rule-Based |
|---|---|---|---|
| Decision explainability | Full white-box | Black box | Partial |
| Runtime rule updates | Hot-swap · zero downtime | Full retrain required | System restart required |
| End-to-end latency | 0.03 ms | 10–50 ms | 1–5 ms |
| ISO 26262 path | Direct — no wrapper tooling | Complex secondary tooling | Moderate effort |
| Incident traceability | Full chain · structured log | Approximation only | Manual reconstruction |
| Jurisdiction switching | 0.08ms · no restart | Retrain per region | Manual config reload |
| OEM integration mode | Shadow + live switchover | Live only | Shadow capable |
| Implicit generalisation | Depends on host perception | Strong (E2E) | None |
ADD is compatible with E2E systems — replacing only the Safety Check layer to gain auditability while retaining implicit generalisation.