StandGuard reads your hardware-in-the-loop bench configuration and flags the wiring, voltage, interlock, and sampling mistakes that destroy devices under test and silently invalidate campaigns — before current flows.
Industry literature on hardware-in-the-loop testing is blunt: preparing a test configuration often takes longer than executing it. One transposed pin or an amplitude over the rail turns that preparation into scrap hardware and data nobody can sign off on. These are the six mistakes StandGuard catches before they reach the bench.
Every rule in the corpus comes from a failure mode that has actually burned a bench. The linter is one auditable Python file — your safety officer can read the entire rule engine in a sitting.
Anything that can emit JSON can be linted, and the exit code is the gate. No platform to adopt and nothing leaves your network — the linter is one file you can read before you run.
$ standguard.py example > bench.json
$ standguard.py lint bench.json --strict
exit 1 → BENCH UNSAFE TO POWER
{
"bench": { "name": "rig-A-avionics", "campaign_window_s": 3600 },
"channels": [
{ "name": "bus_power", "pin": "P1.3", "kind": "power",
"voltage_v": 28.0, "max_voltage_v": 32.0, "max_current_a": 10.0,
"interlock": "estop_loop_1" },
{ "name": "actuator_cmd", "pin": "P2.1", "kind": "analog_out",
"voltage_v": 10.0, "max_voltage_v": 12.0 },
{ "name": "imu_spi", "pin": "SPI0", "kind": "digital",
"sample_rate_hz": 1000, "max_signal_freq_hz": 400 }
],
"interlocks": [
{ "name": "estop_loop_1", "type": "hardware_estop", "cuts": ["bus_power"] }
],
"sequences": [
{ "name": "bit_sequence", "steps": [
{ "action": "energize", "channel": "bus_power", "duration_s": 5 },
{ "action": "stimulate", "channel": "actuator_cmd",
"amplitude_v": 9.5, "duration_s": 30 }
] }
]
}
Known limits, because you would ask: POSIX only today (Windows via com0com is on the roadmap); JSON only, deliberately — one parser, no YAML edge cases; rules are checks, not proofs. StandGuard will not tell you the bench measures the right thing. It tells you the config won't hurt it.
No score to interpret, no dashboard to check. StandGuard ends every run the way a pre-flight checklist ends: with a call.
Priced to sit under corporate card thresholds — a receipt, not an approval chain. Every license covers unlimited benches, includes the full 20-check corpus, CI gating, and activates fully offline. There is no enterprise tier, because there is no sales team to call.
No. It is one auditable file with zero dependencies. JSON in, verdict out, and it runs fully offline — the linter never leaves your network. Every license activates offline too; there is no server to phone home, on any tier.
For the same reason code review never replaced the compiler. Reviews drift — at 11 pm
before a campaign, on the third rewire of the week, the checklist stops being read.
StandGuard runs the same 20 checks the same way every time, and it never gets
tired, rushed, or embarrassed to ask.
Each failure mode is encoded as a small, readable rule in the open spec — voltage limits, interlock coverage, sampling aliasing, pin-map conflicts. The corpus is public and MIT-licensed at github.com/HanchoPOW/standguard-spec. If you have a failure mode we don't cover, that's a contribution, not a feature request.
A non-zero exit code and a JSON verdict naming the rule, the channel, and the fix. That means it drops straight into CI: your pipeline can refuse to power the rig until the config is clean — the same gate you already trust for firmware.
That's the design. Solo is $149/yr — under the no-approval threshold at most
companies, the same category as a book or a dev tool subscription. You get a receipt by email,
not a procurement ticket. There's no enterprise tier and no "contact sales" button, because
there's no sales team to contact — the person who wrote the checks answers the email.
Never. Evaluation runs on your machine against your config file. The only thing this site stores is the email you put in the form above — and that lives in our waitlist, nowhere else.
Join the early-access list for verification teams. First rule packs ship for avionics power rigs and actuator benches — bring your own failure modes and we'll encode them.