The CI safety gate
for ROS 2.
Saykai audits every configuration change and behavioral scenario against your Safety Spec before it merges. Nav2 coverage today, with more of the stack landing as pilots run. The result is a deterministic pass or block, not a suggestion someone has to remember to check.
Saykai Gate
Secret Scan
Behavioral Sim
Nav2 Policy Audit
> You keep your tools. Saykai turns the pipeline around them into a safety gate.
Use the tools you already trust.
Saykai doesn't replace your CI or restructure your repo. It reads your Nav2 config and Safety Spec directly, evaluates them against physics and your own approved limits, and makes the merge decision enforceable instead of advisory.
Inputs
Nav2 parameter changes, behavioral logic updates, and any new secrets or credentials committed to the repo.
Saykai gate
Audits the Nav2 config, scans for secrets, and runs your behavioral scenarios, then compares every finding against your Safety Spec.
Outputs
Approved deploys, blocked changes with the exact rule and value that failed, and a signed Safety Pack for every gated run either way.
What most config checkers miss.
A linter can tell you a YAML file parses. It can't tell you that a velocity_smoother node is missing, so the max_vel_x your team thinks is the real commanded limit never actually gets clamped, and a wildly unsafe speed passes clean. Saykai catches exactly that class of gap: it checks whether the safety-relevant node your config depends on actually exists before deciding which values matter, not just whether the file is well-formed.
The same discipline runs through every rule: stopping distance is checked against the buffer your policy actually defines, not a fixed number. Inflation radius is checked against your robot's own footprint. Goal tolerance is checked against whether your robot can physically achieve it. Every finding ships with the observed value, the limit, and the exact line, not just a rule ID.
This is what a safety gate looks like when it's built by someone who has shipped robot code and watched what actually breaks - not adapted from a generic static-analysis template.
The CI engine: Spec, Runner, Safety Pack.
These three pieces turn your safety rules into a hard gate on every pull request.
Safety Spec (saykai-policy.yml)
A versioned contract for what safe enough means: approved hard limits for speed, acceleration, and safety buffer, and which Nav2 and behavioral rules block a release. Stored next to the code it protects, reviewed the same way you review the code itself.
Runner (GitHub Action)
Audits your Nav2 config, scans for secrets, and runs behavioral scenarios inside CI, then returns a signed pass or block decision. The binary is checksum-verified before it runs, every time. If it can't be verified, it fails closed instead of installing anyway.
Safety Pack
A signed JSON artifact that proves why a version passed or was blocked. Contains the decision, every finding with its evidence, and the exact Safety Spec version used, hashed so a historical run's thresholds are provable even after the policy changes. Built to hand to an auditor or an insurer, not just read in a CI log.
Integrate in minutes
github-token is the credential we provide during pilot onboarding, scoped only to downloading the Saykai binary - it can never see your source. repo-token is your own workflow's default token, used only to comment on your own PR.
Don't guess at your own thresholds
Most safety policies start as a manual guess: someone picks a max speed and writes it down.
Saykai's calibrate tool derives a suggested max speed from your robot's actual physical specs - sensor detection range, perception latency, and real achievable braking deceleration - solved from the same stopping-distance physics the gate itself enforces.
It never writes your policy file for you. It hands a qualified safety engineer a worksheet with the full derivation, so the number in your policy has a traceable origin instead of a guess nobody can defend six months later.
Built for Gradual Rollout
You don't have to enforce blocking on day one.
- Start in shadow mode (--observe): findings are recorded, but the build won't fail while you build trust in the gate
- Known, reviewed exceptions can be explicitly allowlisted, with the reason and source recorded in every Safety Pack, not silently ignored
Saykai reports first, and only blocks once you tell it to.
How Saykai handles rolloutReady to gate one system?
Start with one pipeline. We'll define the first Safety Spec together and wire the CI gate.
Request pilot access