Checks

Every firmware in the Hub is run headless before it gets a Checked badge. The checks live in the SDK's Node runtime (runtime-node) and run locally as og verify, so there are no surprises when you submit.

What we check

Check Passes when
boots The module instantiates with only the imports the ABI allows, and init succeeds.
sound After pad presses the output is not silent, and it contains no NaN or Inf samples.
fuzz Random pads, knobs, buttons, jog and touch for the whole run, without a trap.
deadline Audio renders faster than real time on the checker, so blocks are ready before they are due.
state State saved by the firmware loads back into the same state (save/load round trip).
level Output level is sane: audible after pad presses, and not clipping.

The checks run for every profile the firmware lists. The SDK is adding to this list. The Hub renders whatever the checker reports: a new check appears on firmware pages as soon as the checker produces it, and the raw JSON report is published on each firmware page.

A check is tied to a binary and a checker

A result records three things:

  • the sha256 of the exact .wasm it ran against,
  • the checker version (the runtime-node version plus a hash of the checker's source),
  • the date it ran.

A new binary has no checks until it is checked. A new checker version re-checks existing firmwares, so a badge can change when the checks get stricter.

What a check does not prove

Be clear about this when you share a badge:

  • It does not say the firmware sounds good or that its controls make sense.
  • It does not review the code. Random input finds a lot, but not every bug.
  • deadline is measured on our checker machine. A slower device has less headroom.
  • It does not say the firmware works on hardware nobody has tested it on.

Read the source: every Hub entry links to it.

Run them yourself

sh
og verify build/my-box.wasm
og verify build/my-box.wasm --profile fire --seconds 30

og verify prints a JSON report per profile and exits 1 if any check fails, which makes it a good loop for an AI agent: build, verify, fix, repeat.

Common failures

  • Unknown import. Only the host functions in the ABI and a small WASI subset are provided. See the ABI reference.
  • Init fails. Usually a device the firmware didn't expect. Adapt to the device description instead of rejecting it.
  • Silent output. Check you write to the audio output buffer in the layout the ABI describes, and that a pad press starts a sound.
  • NaN in the output. Typically a filter fed a zero or negative frequency, or an uninitialized state variable.
  • Trap under fuzz. Bounds-check pad, knob and button ids against the device counts, and touch coordinates against the display size.
  • Missed deadline. Move work out of the audio callback, precompute tables at init, and avoid per-sample divisions and transcendental calls where you can.