Product

A CI safety gate wired into your stack.

Saykai plugs into your CI and audits your Nav2/ROS 2 configuration and behavioral scenarios. Every change is evaluated against your Safety Spec and returns a deterministic pass or block decision.

Request pilot access code View GitHub reference examples

System architecture

Existing Stack

Code / Config

Nav2 / Scenarios

Saykai Gate

Secret Scan
Behavioral Sim
Nav2 Policy Audit

Gate Decision

Production

Safety Pack

> You keep your tools. Saykai turns the pipeline around them into a safety gate.

Use the tools you already trust.

Saykai does not replace your CI or your repo structure. It reads your Nav2 config and Safety Spec directly, evaluates them, and makes the merge decision enforceable.

Inputs

Nav2 parameter changes, behavioral logic updates, and any new secrets or credentials committed to the repo.

Saykai gate

Audits the Nav2 config, runs behavioral scenarios, scans for secrets, and compares findings against your Safety Spec.

Outputs

Approved deploys, blocked changes with clear reasons, and a signed Safety Pack for every gated run either way.

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 (speed, acceleration, safety buffer) and which Nav2 and behavioral rules block a release. Stored next to the code it protects.

Runner (GitHub Action)

Audits your Nav2 config and runs behavioral scenarios inside CI, then returns a pass or block decision.

Safety Pack

A signed JSON artifact that proves why a version passed or was blocked. Contains the decision, every finding, and the Safety Spec version used.

Integrate in minutes

.github/workflows/safety.yml

- name: Saykai safety gate
  uses: saykai-systems/saykai-action@v1
  with:
    repo-token: ${{ secrets.GITHUB_TOKEN }}
          

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

Saykai reports first, and only blocks once you tell it to.

How Saykai handles rollout

Ready to gate one system?

Start with one pipeline. We’ll define the first Safety Spec and wire the CI gate.

Request pilot access