The bounded executor
Every call runs inside qexec, the runtime that governs memory and work with explicit resource budgets. Nothing executes unbounded.
The q* stdlibqpkgs
The shared foundation under every Qirava product. Two crates form the substrate — qexec, the bounded executor, and qvalue, the value model and ABI — and eleven focused utilities sit on top. Crypto, encoding, regex, and arbitrary-precision numbers are all written from scratch. Products depend on q*; q* never depends on a product.
What it is
The q* stdlib is everything the products need that would otherwise come from crates.io — built first-party instead. Thirteen small crates: a bounded executor, a shared value model, and eleven utilities that own their own crypto, encoding, regex, and big-number math.
Every call runs inside qexec, the runtime that governs memory and work with explicit resource budgets. Nothing executes unbounded.
One unified Value and Record codec is the language every function speaks. It is the contract shared across the whole ecosystem.
array, object, string, math, number, convert, crypto, encoding, regex, time, and uuid — each replacing a third-party package with first-party code.
What's inside
These are the building blocks the products actually call. Each one is std plus first-party code only — the supply chain is exactly the team that ships it.
Resource budgets bound memory and work per call, so a runaway function is stopped by the runtime rather than the host.
One representation encodes and decodes every value and record — the single shape that crosses every function boundary.
SHA-256, HMAC, and SHA-1 implemented in-house behind a Crypto trait — the one dependency seam, kept first-party to avoid lock-in.
Encoders and decoders for base64 and hex, written from scratch — no pulled-in encoding crate.
A real regular-expression engine — a compiled pattern run on a small virtual machine, not a wrapper around an external crate.
Arbitrary-precision number math, plus UUID v4 and v7 generation and parsing — both implemented directly on the value model.
How it works
The whole stdlib follows one calling convention and one wiring pattern. Once you have seen a single function, you have seen them all.
Every function takes its arguments positionally as a Record and returns its answer as a Record with a {result} field. Same shape in, same shape out — across all thirteen crates.
Each utility crate exposes a single register() that adds its functions to the executor's registry. Wiring the stdlib in is a handful of register() calls — nothing hidden.
The executor stays independent of the value model, so the substrate has no circular dependency. The arrow only ever points up: products → utilities → substrate.
Architecture
The substrate sits at the bottom — qexec and qvalue, each independent. Eleven utilities layer on top of the value model, and the products sit above everything. The dependency arrow only points one way, so the graph is acyclic by rule.
Status
All 13 crates are shipping and in use across the products. The substrate and every utility are first-party and zero-dependency; a few areas are still maturing.
Read the concepts behind the value model and the bounded executor, or see how the products are composed from these crates.