Saykai
Safety Spec

Safety Spec in.
Safety Pack out.

Your Safety Spec (saykai-policy.yml) is how you write down what "safe enough" means. The Safety Pack is the proof of what happened. Saykai enforces the Spec in CI and emits a signed Pack on every run.

  • > Safety Specs live in your repo next to your Nav2 config.
  • > Packs are generated in CI.
  • > Together they turn every pull request into a safety decision.
.YML
SPEC
CI GATE
.JSON
PACK
Jump to: Overview Examples CI Integration

Two artifacts, one gate.

Saykai is built around a simple idea: you write down what "safe enough" means in a Safety Spec, and Saykai turns that into a repeatable gate on every change.

Safety Spec

A versioned configuration file in your repo that defines:

  • Which Nav2 rules and behavioral scenarios must pass
  • The approved hard limits for your robot class (max speed, acceleration, safety buffer)
  • Which findings block a PR, and which only warn

Safety Pack

A signed JSON artifact emitted on every CI run that captures:

  • Which Safety Spec version was used (via checksum)
  • Every finding from the audit, with severity and evidence
  • The final pass or block decision, cryptographically signed

Your Safety Spec: what "safe enough" means.

Your Safety Spec (saykai-policy.yml) is the single source of truth for what you consider safe enough for one robot class. It is written as YAML, stored in git, and reviewed like any other change.

What goes into a Safety Spec

Robot Class

Which class of robot this Spec applies to (for example, class_b, a mid-size AMR).

Hard Limits

The approved max speed, acceleration, and minimum safety buffer for that robot class.

Rules

Which Nav2 parameter checks and behavioral scenarios are enabled, and how severe each one is.

Actions

Whether a violated rule blocks the PR, warns, or goes to manual review.

/repo/saykai-policy.yml

Example Safety Spec

This is a simplified example for a warehouse AMR fleet.

saykai-policy.yml
policy: name: "Warehouse AMR Safety Policy" mode: "customer_approved" decision_authority: "customer" thresholds: class_b: hard_limits: max_speed: 0.45 min_bubble: 0.15 max_accel: 2.50 max_angular_speed: 2.50 rules: nav2_max_speed_exceeded: enabled: true severity: high action: block

> LOGIC EXPLAINED

  • max_speed and the other hard limits are approved values, not suggestions — here, 0.45 m/s for this robot class.
  • Any Nav2 config that exceeds an approved hard limit blocks the PR (action: block).
  • Lower-severity issues can be set to review or warn instead of block, per rule.

Safety Pack Result

What actually happened on this change.

safety_pack.json
{ "trace_id": "b3f1e2c4-8a91-4c3d-9f2e-1a2b3c4d5e6f", "status": "BLOCK", "policy_file": "saykai-policy.yml", "policy_sha256": "9f86d081884c...0a08", "evaluation": { "findings": [ { "rule_id": "nav2_max_speed_exceeded", "severity": "high", "action": "block", "math_evidence": { "observed": 0.60, "limit": 0.45 } } ] }, "integrity_seal": "sha256:4e3f...", "signature": "ed25519:7c1a...", "signed_by_key_fingerprint": "SHA256:ab12cd34", "timestamp": "2025-12-03T10:24:00Z" }
status PASS or BLOCK, based on your Safety Spec.
evaluation.findings every rule that fired, with severity and evidence.
signature cryptographic proof the result wasn't altered.

How Safety Specs and Safety Packs fit into CI.

Once you have a Safety Spec and Saykai wired into CI, every pull request gets the same treatment.

01 // PROPOSE

Engineer opens a change.

The pull request includes code, plus any Safety Spec changes if the safety bar needs to move.

02 // EXECUTE

CI runs Saykai.

Saykai audits the Nav2 config, runs behavioral scenarios, scans for secrets, and compares findings to your Safety Spec's approved limits.

03 // DECIDE

Gate returns pass or block.

If it passes, the Safety Pack is attached to the run. If it fails, the build is blocked with a clear reason based on Safety Spec rules.

Why Safety Specs and Safety Packs beat ad hoc checks.

Repeatable

The same rules and hard limits run on every change, not just big releases.

Versioned

When incidents or requirements change, you update the Safety Spec through a pull request and the new bar applies to every future change.

Shareable

You can share a Safety Pack with risk or leadership without giving them raw system access.

"Here is the Safety Pack for Release v4.2"

Download JSON

Start defining your first Safety Spec.

We usually start with one robot class. We define the hard limits and rules that matter most, and turn that into your Safety Spec (saykai-policy.yml).

Talk about your Safety Spec