systems that cannot crash.

Stokes is a CLI tool that checks whether your SQL schemas, Python ETL pipelines, and Rust services actually agree with each other. Think of it as a linter, but instead of checking one language at a time, it reads all three and flags the places where they silently disagree.

The Cloudflare Nov 18, 2025 outage happened because sqlfluff, mypy, and rustc all passed individually, but nobody checked that a schema change pushed 280 features into a buffer sized for 200. Stokes catches exactly that kind of mismatch: it reads the SQL schema, the Python config, and the Rust buffer declaration together, and fails the build if the numbers don't line up.

Stokes uses Bob 2.0's multi-agent architecture to run multiple specialized checkers at the same time (one for SQL, one for Python, one for Rust, one for verification). Bob handles the orchestration, parallel execution, and document understanding so Stokes can focus on the actual boundary checks.

The 7.66 ns number is the time it takes to partition features using in-place selection on a fixed stack buffer. The comparison (29.74 ns for heap vectors) shows why Stokes uses a stack-allocated approach: it's 3.88x faster and doesn't allocate any heap memory, which matters when you're processing packets at line rate.

When Stokes finishes a scan, it writes a lockfile (stokes.lock) with SHA-256 hashes of every boundary-critical file. In CI, `stokes verify --strict` re-checks those hashes and fails the pipeline if someone changed a schema or buffer size without re-running the full verification. It also writes a human-readable CONFORMANCE.md for code review.