A CI safety gate wired into your stack.
Saykai plugs into your CI, simulation harnesses, and log replays. Every behavior change is evaluated against a versioned Safety Spec and returns a deterministic pass or block decision.
Saykai Gate
Spec Check
Regression Test
Drift Analysis
> You keep your tools. Saykai turns the pipeline around them into a safety gate.
Use the tools you already trust.
Saykai does not replace CI, sims, or logging. It orchestrates what you already run, compares results to the Spec and baseline, and makes the merge decision enforceable.
Inputs
New models, prompts, policies, tools, configs, and firmware that can change behavior.
Saykai gate
Runs scenarios and log replays through your stack, compares results against the Safety Spec, and returns a decision.
Outputs
Approved deploys, blocked changes with reasons, and a Safety Pack for every release that passes the gate.
The CI engine: Spec, Runner, Safety Pack.
These three pieces turn your safety rules into a hard gate on every pull request.
Spec (saykai.yml)
A versioned contract for what safe enough means: scenarios, metrics, thresholds, drift limits, and when to block. Stored next to the code it protects.
Runner (GitHub Action)
Executes scenarios and log replays inside CI, collects metrics, and submits results for a gate decision.
Safety Pack
A JSON artifact that proves why a version was safe. Contains the decision, metrics, and diffs.
Integrate in minutes
Built for Nondeterministic Systems
Saykai is safe to run in CI, even when systems aren’t perfectly repeatable.
- Gates trigger on consistent behavioral regressions, not one-off noise
- Scenarios can be re-run to reduce flakiness
- Teams can start in report-only mode before enforcing blocks
- Overrides are explicit and auditable in every Safety Pack
Saykai blocks unsafe change, not natural variation.
How Saykai handles nondeterminismReady to gate one system?
Start with one pipeline. We’ll define the first Spec and wire the CI gate.
Request pilot access