PULSAR Engine

PULSAR is the mirror that reveals what you built

It reconstructs how the system is built and how it behaves — which components speak to which, in what order, and how an effect travels onward — into one model engineers can finally reason about.

Get started

A vehicle produces data while it runs. That data arrives as trace files — `run_4711_trace.mf4` and its companions — which stream into the platform and assemble into the mirror: the same system, rebuilt from its own recordings, with the domains the runs observed named against the regions they occupy and one path traced straight through it.

The challenge

Generic LLMs can sound just as confident when they’re wrong. The missing piece isn’t more data — it’s the intelligent layer between the data and the reasoning.

Without PULSAR

→ grep run_4711 "ChargeState"
// 2.4 M lines matched
→ feed the slice to an LLM
⚠ 0.015% of the run fits in context
“The charge controller likely published a stale
value. Check CAN timing on the gateway.”
// cites nothing. “likely” is doing the work.
engineer hunts the failure by hand

0.015%of the run it could read

~200ktokens burned on every question

0components, owners or baselines it knows

With PULSAR

→ ask("why did the cluster show the wrong
       charge state on run 4711?")
✓ answered from the model · 128 runs
CAUSE   gateway forked ChargeState.Update
        hmi branch +5 ms, after the render tick
EVIDENCE 4 lines, run 4711
OWNER    Supplier B · Powertrain Gateway
// open any of it in the Explorer

100%of the run in the model

0logs re-read per question

allruns of learned normal behind it

Inside the engine

The architecture, derived from the running system — not from documentation

PULSAR reconstructs what actually exists: the components, processes, services, interfaces, and state machines involved, and how they relate to each other. An engineer moves from the whole system down to a single interface, without ever needing a specification.

PULSAR is the mirror of the integration you actually achieved

On top of that structure, PULSAR learns what actually happens: which components speak to which, in what order, with what timing, and how an effect travels onward from there. The system model and the behavior model together are what the PULSAR engine is. Every analysis works on that one pair — which is why an answer always reflects the specific implementation.

System modelBehaviour model run 4711 Software 7.4

4 units · 6 partitions · 36 processes · 69 services · derived from 128 runs

Ask the system

Or skip the walk and just ask

You don’t need to know where to look. Ask in plain language, and every claim comes back with the line it rests on.

Ask

grounded in the model · all runs

PULSAR

The value was never wrong. It arrived late.

The published ChargeState.Update at .412 with a valid value — charge=82%.
The forked it: at +19 ms, at +24 ms.
The cluster had already begun its render tick at +18 ms, so it drew the previous value. Nothing failed — the two branches are not ordered against the tick.