Where is the safety gap?איפה פער הבטיחות?

Overview

A simulation produces numbers. Engineers need events.

A self-driving programme runs hundreds of thousands of simulations to argue that its vehicle is safe enough for public roads. A verification engineer has to know what happened in them: did a car cut in, did the vehicle brake, and how often across the whole regression.

That is step four of Foretellix's flow, Check and measure. Product defined the interval: a named event with a start and an end, recorded during the simulation. I designed how people see intervals, find them, define their own and count them toward coverage.

My role. From 2023 to 2026, as Senior UX Designer and then UX Lead, I owned the interaction model for intervals: the timeline, the filter, the editor for new ones and the path back from coverage. The concepts were product's. I shaped the data model with product and engineering, and directed a designer on my team.

Four design decisions shaped the answer to the title's question.

---

The problem

Reading a line to guess an event

Before intervals, a run's results were values plotted over time: speed, distance, acceleration. To know a cut-in happened, an engineer inferred it from the lines, like reading a heart-rate chart to guess when someone started running. An interval says it outright: cut-in, 1.8 to 4.7 seconds.

That works for one run. One workspace held over two million intervals, and the system was built for hundreds of millions. A query mixing two kinds of interval came back empty.

---

Background

Events you plan before the run

An interval exists only if someone planned for it. The engineer writes into the scenario's code what to look for: checkers, and scenario matching that recognises a manoeuvre such as a cut-in.

These usually come from the verification plan, the list of situations the programme must cover and measure. Foretify computes them during the run, and every value they carry is counted against that plan.

Under every coverage item in the plan sit its buckets, ranges of a value such as speed at the start of a cut-in, each hit or not against a target. The plan rolls them up into a grade, and the empty buckets are the safety gap.

Anything not planned in advance can't be found afterwards. So users later asked to define new events after the run, from data that already existed. That became compound intervals, in decision 3.

---

How I worked

The brief said draw it

My first brief was to visualise intervals. Drawing them served one run, already found. The real job was analysis across hundreds of thousands of runs, where people query, combine and count. So the work moved from making intervals visible to making them findable, definable and countable.

I started by mapping what an interval could be, with the product team's definitions on one board. Then I looked at tools that already show events over time: animation timelines in After Effects and Maya, Gantt views in project tools, the Visual Studio and Chrome debuggers, and transaction debug views from chip verification.

Interviews and quick usability sessions with application engineers, who worked with customers daily, stood in for the user access I didn't have.

March 2023, first sketches: event rows over time, an inspector for the selected one, and the map on the same screen.

---

Design decision 1

One timeline, in step with the car

Once intervals existed, people had to see them, next to the car doing them.

My part was the layout: rows over time, the shared cursor and the tree. Two other designers worked on the first wireframes with me. Application engineers were split on mixing value traces with intervals, so the two started apart and joined a release later.

Every new kind of event then wanted its own look. I treated visual channels as a budget. Each type gets one look and a legend entry that filters it, and the only pattern, stripes, marks intervals users upload.

---

Design decision 2

Which event, then what happened inside it

Engineers' questions have two parts: which event, and what happened during it. For example, cut-ins where the speed during the cut-in was over 60.

The first interval filter couldn't ask that. It couldn't say which kind of interval to return, so a query mixing two kinds came back empty, and it couldn't reach the values measured inside an interval. Product led a revamp of all the app's filters to fix this, with a two-level filter at its core. Engineering capped it at two levels, for speed and for usability.

---

Design decision 3

Pairs, then compose

Planned events answered the questions people knew to ask before the run. Coverage and validation engineers then had new ones after it: a cut-in during a junction approach, say, built from intervals that already existed. Product's answer was compound intervals, and a customer asked for up to five intervals in one rule.

My research showed two were enough, because nesting covers the rest. And I was wary of ambiguity. A time relation is always between two intervals. With three in one rule, the form must say which pair each relation joins, and with four, six pairs.

Supporting five from day one meant a far heavier UX and backend for a need nobody had tested. Better to start lean and see whether users could work with two.

Applying a rule to all the data took over an hour, so the tech lead and I designed a playground: the first matches on real data in about a minute, before saving.

I also said early that compounds would need a rules manager. It came later, with my column wording.

---

Design decision 4

A bucket hands back what filled it

The plan showed where the gap was, but a bucket was only a number. Nothing connected it to the runs and the moments behind it.

---

Process

From Figma to a code branch

Most of this work was designed in Figma and handed over in Zeplin, with the filter's keyboard model written as a specification. When a delivery review found designs changing after planning, its two fixes were mine: a review with developers after each upload, and a mark for when a design is final.

By 2026 I designed in a code branch, with AI tools, on the shared components in Storybook. Moving compound rules to the project, shared by every workspace, reached engineering as a working branch, and developers kept testing and stability.

---

Outcome

Where is the safety gap? The plan now shows it

The model shipped in steps from 2023 to 2026: intervals on the timeline, the two-level filter, compound intervals with the playground, buckets that open their evidence, and rules shared across the project.

Finding a moment, before and after

• Before: Open one run at a time, read the lines, and hope the right run is in front of you.
• After: Filter by the event and a value inside it, define your own and preview it in a minute, then follow a bucket back to what filled it.

How widely it was used, I can't say: one month on two internal servers shows the debugger drew about five times the views of the interval pages, which fits the reframe. Measuring it was partly my job: my ticket to define analytics events stayed open.

What I would do differently

Skip the separate rule editor. Users already found things in the debugger and the filtered table. A blank form asks them to describe what they were looking at. Better: select what you found and name it, because naming it makes it a rule. I proposed this early, and a principal engineer argued the same.