THE PLATFORM

One engine. Three product surfaces. Zero magic.

FieldSpace is a deterministic evaluative methodology mapped to the behavioral acceptance criteria framework. The same engine produces per-claim safety case evidence, counterfactual incident replay, and actuarial inputs for fleet underwriting.

Pick the wedge that fits your program

Full-stack replacement is not the first phone call. Start with the observer, prove value on your own logs, then expand only where the evidence supports it.

MODE 1 · SHADOW

Validation observer

Consumes your fused tracks and ego state, emits hazard objects and a risk cost-map at 20 Hz. Runs in parallel to your planner, with no actuator authority in the default evaluation scope.

  • Zero retraining. Works with whatever detector/tracker you already ship.
  • Bit-identical replay of every hazard decision. Same bytes in, same bytes out.
  • Side-by-side metrics against your stack on your own driving logs.
  • Fastest path to standards-mapped evidence without touching production code.
MODE 2 · BENCHMARK PLANNER

Closed-loop evaluation

Route-aware trajectory generation for simulation and controlled benchmark work. Useful for nuPlan-style comparison, safety metric analysis, and failure-case review.

  • Lane and route context for benchmark trajectory candidates.
  • Map-aware motion prediction feeds the reactive PDE traffic field at every tick.
  • Safety-observer outputs remain inspectable beside planner metrics.
  • Appropriate for simulation, shadow-mode pilots, and bounded research programs.
ASSESSMENT-READY PATH

Standards alignment without claiming premature certification.

The platform is being packaged for scoped third-party gap assessment as an observer, replay system, and possible validation-support tool-use case. Vehicle-level approval remains OEM-owned.

Review security and standards readiness →
ISO 26262

Supplier safety plan, SEooC assumptions, requirements traceability, verification evidence, and tool-confidence review.

ISO 21448 / SOTIF

Triggering-condition inventory, ODD assumptions, false-positive / false-negative analysis, and replayable edge cases.

ISO 3450x

Scenario taxonomy, source dataset, trigger type, ODD tags, review status, and scenario-evaluation structure.

ISO/SAE 21434

Threat analysis, SBOM, vulnerability process, access controls, and customer-log handling readiness.

The five stages that make it deterministic

Each stage is a pure function with a typed contract. Replay the same inputs on the same binary, get the same outputs, forever.

01

Perception

YOLOv8n or your tracker. Class + bbox + velocity into the ego frame.

02

HD Map

Lanelet2 graph localization, route planner, ODD polygon gate.

03

Prediction

Map-aware constant-velocity + Frenet projection, 1.5 s horizon, confidence half-life.

04

PDE Field

Traffic density field on a 256×64 grid. Continuity + velocity + potential.

05

Output

Observer warnings or bounded trajectory candidates, depending on evaluation mode.

20 Hz
Default control loop
<2 ms
Field solve per tick (256×64)
Raspberry Pi 5
Reference target, no GPU
Rust + no_std
Core crates, deterministic build
API CONTRACT

A planner-friendly output, not a black box

The validation observer emits a strict schema your existing planner can consume as an extra constraint layer. Every hazard has a TTC, a risk score, a position, and a trigger reason you can trace back to the source pixel or track.

  • Reference ROS 2, gRPC, or UDP bindings are available for pilot integration review.
  • Cost-map compatible with occupancy-grid planners out of the box.
  • Deterministic replay: bring your MCAP, get the same hazards every run.
hazard_output.json
{
  "t_s": 1734567890.251,
  "frame_id": 4821,
  "hazards": [
    {
      "id": "h_001",
      "source_track": 17,
      "kind": "moving_vehicle",
      "risk": 0.82,
      "ttc_s": 2.3,
      "pos_ego_m": [12.5, -3.2],
      "vel_ego_m_s": [5.0, 0.5],
      "trigger": "predicted_path_intersects_ego"
    }
  ],
  "cost_map": {
    "nx": 256, "ny": 64,
    "dx_m": 0.2, "dy_m": 0.625,
    "encoding": "u8_base64"
  },
  "mrm_phase": "Idle"
}

What it needs, what it runs on

No training cluster is required for the observer path. A commodity CPU and scene state are enough to start replaying logs.

REQUIRED INPUTS
  • Ego pose (x, y, heading)
  • Ego velocity (longitudinal + lateral)
  • Fused object tracks or benchmark scene state
  • Wall-clock timestamp
  • Optional lane / route context for richer closed-loop evaluation
COMPUTE TARGETS
  • BenchRaspberry Pi 5
  • Devx86 laptop, 4c/8t
  • SimulationJetson Orin / i7
  • RAM≥ 2 GB
  • GPUoptional
INTERFACES
  • ROS 2 (Humble, Jazzy)
  • gRPC with protobuf contracts
  • Simulation and replay interfaces by pilot scope
  • MCAP + comma openpilot rlog replay
  • Argoverse 2 · nuScenes · Waymo · nuPlan adapters
  • CARLA 0.9.14 · NHTSA 37 · Euro NCAP batteries

Bring your logs. Get your numbers.

We run the validation observer against agreed logs or benchmark scenes and send back a side-by-side evidence report your technical team can challenge.