Certainty, before
your robots move.
Every release gets a deterministic pass or block decision, backed by a signed, versioned record of exactly what was checked.
On every pull request, Saykai audits your configuration against your Safety Spec (saykai-policy.yml), runs behavioral safety scenarios, and scans for leaked secrets — then blocks changes that fall below your safety bar.
If it can move hardware, it should have to prove it's safe first.
Saykai turns CI into the first safety line before anything reaches production — a versioned, signed decision record for every gated release.
How it fits into your pipeline.
Drop Saykai into your existing CI as a required check.
- Every PR runs Saykai's 3-room audit: secret scan, behavioral simulation, and Nav2 policy check
- Results are checked against your approved Safety Spec (saykai-policy.yml)
- A signed JSON Safety Pack acts as an immutable audit trail
- The PR passes or blocks based on policy, not gut feel
Runs entirely inside your own CI. No data leaves your pipeline.
> Drop in Saykai once, then every change is screened against the same safety bar.
No policy violations detected
Safety Pack sealed: sp-8a7b9c.json (signed)
Start with one CI integration.
Configure your policy (saykai-policy.yml)
Set approved hard limits — max speed, acceleration, and safety buffer — for your robot class. Lives in version control next to your Nav2 config.
Install the GitHub Action
Run Saykai as a required check on every pull request in one critical repo.
If you are not on GitHub Actions, we will help you wire it in during the pilot.
Get a Safety Pack on every PR
Each run produces a signed JSON Safety Pack recording every finding and the exact Safety Spec version used — a clear pass or block decision you can hand to safety and risk.
Gate your next deployment.
The first step is simple: add saykai.yml and the Saykai CI check to one critical pipeline. From there, every change to that system is screened through the same deterministic safety bar.