GB/T 45312—2025 · Evidence-first registry

OpenODC

A public, machine-readable registry for AD operating boundaries.

OpenODC does not rank AD systems. It asks a narrower question: how much of a system's operational boundary is backed by public manuals, official pages, government rules, clearly marked community extraction, boundary combinations, or public gaps?

Browse Gallery → Road-Rule Mapping → Read Method →
Current public sample status
6 high-confidence samples 346 element-level references 97 official / manual / government-backed items 20 traceable road-rule obligations

All current samples are community extractions from public sources, not vendor-confirmed ODC declarations; there are no vendor-confirmed records yet.

ODC × ROAD RULES × EVIDENCE

How Operating Boundaries Connect to Road Rules

Open Road-Rule Mapping →

ODC describes the roads, environment, traffic, and system states in which a function is designed to operate. Road rules describe the behavioral obligations of vehicles, drivers, and other actors in a traffic situation. OpenODC connects both through shared ODC element identifiers, then traces them to scenario triggers and candidate verification evidence.

  1. 01ODC BoundaryRoads, facilities, environment, objects, and system states
  2. 02Road-Rule ObligationRequired, prohibited, and applicable behavior from public sources
  3. 03Scenario TriggerTurns semantic relations into executable traffic situations
  4. 04Candidate EvidenceRequirements, models, simulation, proving ground, road, and review
20bilingual obligations 52ODC semantic mappings 4current public sources

These mappings support engineering research, requirements traceability, and test design. They are not legal advice, certification, or a compliance determination for any vehicle.

PUBLIC SAMPLE LIBRARY

Six Public-Reference ODC Samples

Open Gallery →
L2Tesla FSD Supervised · USv14.2+ official note + 2026.14 manual L2Tesla Assisted Driving · ChinaChina 2026.14 owner manual L2AITO M9 · ADS 4Public evidence verified in 2026-05 L2XPeng P7+ · XNGPOfficial product page + configuration table L4Apollo Go · WuhanWuhan government operating rules L4Pony.ai Gen-7Official IR release + Qianhai government page

Public value

Turn “when can this feature be used, when should it exit, and what is not publicly stated” into a verifiable list, reducing the risk of confusing L2 assistance with automation.

Industry value

Use one 144-element national-standard vocabulary to compare public boundaries across OEMs, automation levels, and robotaxi domains, while highlighting typical boundary combinations that single elements cannot express.

Engineering value

Provide JSON Schema, an editor, compare views, a matrix view, and a vendor intake workbench so manuals, configuration tables, and operating rules become reviewable ODC tables and trigger-condition candidates.

WORKFLOW

A Workflow from Reading to Contribution

View all tools →
01GalleryBrowse ODC samples by vehicle, feature, and level 02CompareSelect 2–4 samples and review boundary differences 03Road-Rule MappingTrace ODC elements to obligations, scenario triggers, and evidence 04ODC EditorCreate submit-ready JSON from the 144-element taxonomy 05Vendor IntakeImport source excerpts and generate an ODC draft table 0620-Minute BriefExplain OpenODC with a full-screen web deck

OPEN STEWARDSHIP

Help Turn OpenODC into a Shared Industry Platform

OpenODC now has a standard schema, sample gallery, comparison matrix, and intake workbench. To become real-time, credible, shared, and open, it cannot depend on one person’s spare time. We are looking for contributors with standards, ADAS / ADS development, safety, testing, data engineering, or open-source operations experience.

Read the Stewardship Plan → Open an Issue →

OPEN AD SAFETY STACK

Connected with ROAM and DRIVEResearch

Boundary combinations are not meant to turn OpenODC into a full SOTIF platform. They provide the shared interface: OpenODC proposes public-source-supported combined boundaries, DRIVEResearch estimates how often those combinations appear in real traffic and with what parameter ranges, and ROAM records what happens when boundaries are exceeded or operational interventions occur.

Design boundary

OpenODC

Turns manuals, feature pages, and operating rules into traceable single-element ODC entries and combined-boundary candidates.

Real exposure

DRIVEResearch

Uses naturalistic driving data to estimate how frequent these combinations are and how their parameters are distributed on real roads.

Anomaly outcome

ROAM

Uses robotaxi remote-operation anomalies and incident records to see which combinations lead to takeover, degradation, or intervention.

ROAM website → DRIVEResearch website → OpenODC GitHub →