Questions teams ask before they gate changes.

Saykai is a CI safety gate for Nav2/ROS 2 robots: on every pull request it audits your policy thresholds, runs behavioral safety scenarios, and scans for leaked secrets, then blocks the pull request (PR) if it breaks your safety rules.

If you want the longer version, see the Product page.

You need three things: a CI system (we start with GitHub Actions), a Nav2/ROS 2 configuration to audit, and a clear idea of the approved safety thresholds for your robot class. If you already have approved limits in mind, we can usually plug Saykai in without new infra.

We aim for weeks, not quarters. A typical pilot is: define the first Safety Spec (saykai-policy.yml) in a working session, wire a single CI job with the Saykai GitHub Action, then run for a few weeks until you are seeing Safety Packs on every PR. If it is not catching useful issues in the first month, you stop.

No. Saykai runs in CI, not in the runtime path. It never sits between your robots and the real world. If the gate passes, your deployment runs as it does today.

You should keep your tests and simulations. Saykai does two extra things: it forces you to write down what "safe enough" means in a Safety Spec (saykai-policy.yml), and it turns that Spec into a consistent gate that runs on every change and produces a Safety Pack. You go from "we ran some tests" to "here is the signed artifact that shows exactly what we tested and why this passed."

A Safety Spec is one versioned file (saykai-policy.yml) that defines approved hard limits — max speed, acceleration, minimum safety buffer — for a robot class. It is designed to be read by both engineers and risk owners, and it is the only thing the gate uses to decide pass or block.

You can see a full example on the Safety Spec page.

A Safety Pack is a signed JSON artifact per CI run that records which policy version was used (via a checksum), every finding from the audit, and the final pass or block decision. Engineers use it to debug why a change was blocked. Safety and leadership use it as evidence for why a change was allowed to ship.

The policy page has a real Safety Pack example.

Today we focus on Nav2, the standard ROS 2 navigation stack, with checks built around its parameter conventions (velocity, acceleration, inflation radius, and related limits). If you're on a different navigation stack, talk to us — the policy and audit model isn't Nav2-specific in principle, we just haven't built out parameter mappings for other stacks yet.

The Use Cases page has concrete examples.

We start with GitHub Actions and a CLI runner that can be called from any CI system. Under the hood it is just a process that reads saykai.yml, runs your commands, and returns a pass or non‑zero exit code. If your pipeline can run a script, we can usually drop the gate into it.

No. Saykai reads your existing Nav2/ROS 2 configuration directly, and if you have a behavioral simulation script, it runs that too. You keep using your existing setup as-is. Saykai aggregates the results into a Safety Pack automatically.

Safety Specs live in your repo next to the Nav2 config they protect. Safety Packs are emitted by CI and stay in your own workflow artifacts — Saykai does not store them on any control plane. That way a reviewer can click from a run to the Pack and see exactly what was audited.

Engineers still open pull requests, push code, and watch CI. The main difference is that a Saykai check now shows up in the PR. If it passes, you get a green Safety Pack attached to the run. If it fails, the PR is blocked and you get a clear reason based on Safety Spec rules and findings.

Engineering usually drafts and maintains the Safety Spec, since they know the stack and thresholds. Safety, risk, and operations help define hard limits and sign‑off rules. The Spec is versioned in git so any change to the safety bar goes through the same review process as code.

Good. Saykai is not a replacement for that. It gives those teams a standard artifact for each change instead of one‑off screenshots or slide decks. Incidents become scenarios or threshold adjustments added to the Safety Spec so they're checked on every future change.

No. The GitHub Action runs entirely inside your own CI. We never receive or store your Nav2 configs, scenarios, or Safety Packs — everything stays in your own repo and artifact storage.

Right now we are in private beta and focus on getting a small number of high quality pilots live. Pricing is simple and based on the number of systems you gate with Saykai. We talk about it openly when we scope a pilot with you.