BKPT LabsASSERT · TEST AUTOMATIONDS-0005 · REV B · 2026

Timing is a requirement. Test it like one.

Assert runs your firmware on real hardware inside CI and fails the build when timing regresses: deadlines, jitter, ordering, inversion. Asserted on the trace, not on a simulator's opinion.

assert · ci runillustrative spec
suite motor_control:
  assert task("motor_ctl").period(1ms).jitter < 50us
  assert isr("encoder").latency < 12us
  assert never priority_inversion("motor_ctl")

run on: nucleo_f767zi · trigger: every push
PASS 14/14 · worst jitter 31us · trace archived
REAL SILICON

No simulation gap.

Tests execute on the actual target, over the actual probe. The timing you assert is the timing your users get, including the flash wait states nobody models.

TRACE ASSERTIONS

Assertions on behavior over time.

Beyond pass and fail on return values: periods, deadlines, latencies, ordering constraints, and scheduler pathologies, checked against the captured timeline.

CI NATIVE

A failed build, not a field report.

Runs on every push. When timing regresses, the build fails and the offending trace is archived next to the diff that caused it.

WHAT A RUN LOOKS LIKE

One suite, every board on the bench. Each cell is a single target built a single way: its OS, its transport, its debug server. When a cell goes red the build goes with it, and that run's trace is kept beside the result.

HIL BENCH REGRESSION · 44 PASSED · 0 FAILED · 4 SKIPPED OF 48

SPECIFICATIONS

EXECUTIONHardware in the loop, on your bench or rack
ASSERTIONSPeriod · jitter · latency · ordering · inversion
EVIDENCEEvery run archives its full trace
TRIGGERSPer push · nightly · on demand
DATA LAYERSame capture format as ViewAlyzer
LICENSETeam tier
EARLY ACCESS

Request beta access.

BKPT Studio and the ViewAlyzer visualizer, in private beta. Bring your own debug probe; ours is still on the bench.

IF WE OFFER SUPPORT, WOULD YOU COMMIT TO THE WHOLE STACK?