How Saykai Handles Nondeterminism

Safe CI gating for systems that aren’t perfectly repeatable.

Modern systems are not deterministic.

Robots, agents, simulations, and real-world workflows all exhibit noise, variance, and timing drift.

Today, Saykai gives you two tools to manage that without becoming a source of CI flakiness: a shadow mode to build trust before enforcing, and explicit, auditable overrides. Richer behavioral-regression detection (below) is on our roadmap.

THE CORE PRINCIPLE Roadmap

Gate on behavioral regressions, not noise.

This is where we're headed: evaluating whether system behavior has changed outside an accepted baseline, rather than requiring bit-for-bit identical replays.

The goal is enforcing safety in CI without introducing instability — today that's handled by shadow mode and overrides (03 and 05 below), not yet by regression detection itself.

What This Means in Practice

01 // BASELINES Roadmap

Behavioral Baselines, Not Exact Matches

The plan: compare runs against behavioral envelopes, not single frozen traces. Baselines would include acceptable outcome ranges, invariant conditions, and tolerance bounds defined by the team.

This would preserve natural variation while still detecting regressions — not yet built.

STOCHASTIC BEHAVIOR SAFETY SPEC CHECKING ENVELOPE PASS Within Bounds BLOCK Regression

Roadmap: behavior would be evaluated across multiple runs, not against a single expected output.

02 // CONSISTENCY Roadmap

Consistency Over One-Offs

Planned:

  • scenarios could be re-run automatically
  • a gate would fail only when regressions are consistent
  • single noisy failures wouldn't block merges

The goal is dramatically reducing false positives while preserving signal — not yet built.

03 // VISIBILITY Roadmap

Variance Is Recorded

Today, every Safety Pack records a pass/fail rationale for each finding. Planned additions:

  • observed variance across runs
  • comparison against baseline bounds

The goal is for nondeterminism to be explicit and reviewable, not buried in logs.

04 // ENFORCEMENT

Enforcement Can Start Soft

Today, Saykai can run in:

  • report-only / shadow mode (--observe): findings are recorded, the build doesn't fail
  • enforce mode (default): a blocking finding fails the build

This lets trust build before enforcement becomes mandatory. A distinct warn-on-fail tier is on our roadmap Roadmap, not available yet.

05 // OVERRIDES

Explicit Overrides

No safety system should silently halt progress. Saykai supports:

  • explicit human overrides (allowlisting)
  • documented rationale, recorded per finding
  • permanent traceability in every Safety Pack

Overrides preserve accountability without bypassing safety.

What Saykai Does Not Claim

Saykai does not claim:

  • perfect determinism
  • zero false positives
  • autonomous judgment without human context

Saykai provides structured evidence and enforcement, not blind automation.

Designed for High-Stakes Systems

This approach is built for:

  • robotics and simulation-heavy systems
  • autonomous and semi-autonomous agents
  • workflows where regressions are expensive
  • environments where “just rerun it” is not acceptable

If your system must change safely, nondeterminism must be handled explicitly.

BOTTOM LINE

Saykai blocks unsafe change.
Not natural variation.

That's the standard we're building real safety gates in CI toward.

Run Saykai against your own scenarios.

See how behavioral gating works in your CI pipeline.

Request Pilot Access