Skip to main content
Calybris Core

Calybris Core

CI CodSpeed codecov Crates.io docs.rs License MSRV

A deterministic decision engine: it selects under explicit constraints, and makes the decision verifiable afterwards.

1.0.0: the API and the formats are stable.

The version number is the promise, not a boast. 0.x means expect breaking changes; from 1.0.0 on there are none to expect within 1.x. The public API, the decision semantics, the digest formats and the replay behaviour are documented in docs/DECISION_SEMANTICS.md, specified byte by byte in docs/SPECIFICATION.md, and pinned by tests. A decision made under 1.0.0 replays identically under every later 1.x.

Development continues. New capabilities arrive in 1.x releases as additions; anything that would break a caller or change a digest waits for a major version. docs/COMPATIBILITY.md says exactly what a 1.x release may and may not change.

Given a frozen catalog, a policy snapshot, and a typed request, Calybris returns one action plus an audit bundle that replays to the same answer.

catalog + policy + request  ->  decision + audit bundle

Integer-only Rust hot path. No hosted dependency. No unsafe in the kernel.

What is this?

Calybris is a proof-carrying decision kernel: not an OMS, not an LLM gateway, not a matching engine. You bring the catalog — suppliers, carriers, venues, models — and the kernel evaluates hard constraints, picks the best eligible candidate, and emits digests you can replay and verify offline.

The kernel does not know what a candidate is. Supplier routing, carrier selection, model routing and pre-trade admission are reference mappings onto one API, not four products.

Two claims it does not make. It does not find the best commercial outcome; it selects by the rules you wrote, and a wrong rule produces a wrong decision you can at least see. And it proves the integrity of the trail, not the truth of your inputs.

In this release — 1.0.0

Everything here is something the crate had to settle before it could promise not to break it.

explain() One row per candidate in the catalog: which gate turned it away, what was measured against what limit, and for the ones that survived, the terms that add up to the utility the kernel ranked on. It runs the same evaluation prescribe does, so it cannot become a second opinion about the decision.
Outcome What happened after a decision — applied, abandoned or still running — bound to the policy, the input and the decision together, with the selection probability that an off-policy estimate needs and that cannot be recovered afterwards. The kernel does not read these back; it defines the shape so that two callers write the same one.
Stable semantics Gate order, tie-break, units, ceilings and digest layouts are written down in docs/DECISION_SEMANTICS.md, specified byte by byte in docs/SPECIFICATION.md and pinned by tests, and docs/COMPATIBILITY.md says what a 1.x release may and may not change.

PolicySnapshot::new, deprecated since 0.3.9, is gone: shipping it in a 1.0.0 would have made it permanent. Every public error enum is now #[non_exhaustive] so a security fix can add a variant; the enums that carry decision semantics are exhaustive for the opposite reason. The full list is in the CHANGELOG.

When to use / when not to

Use Calybris when... Do not use it for...
Decisions must be deterministic and replay-auditable Inventory, WMS, label printing, carrier booking
You need hard gates (budget, risk, latency, region, capability) in your control plane A hosted routing API or managed decision service
Post-mortems and compliance need proof bundles, not log grep Live market data, order matching, exchange connectivity
You want to know what a policy change would have done before shipping it Deciding what the policy should be — that is your judgement, not the kernel's

Quickstart (~5 minutes)

pip install calybris

The shortest path to a decision is the typed adapter: fixed quotes in, one selected candidate plus a replay-verified proof out.

from calybris import Candidate, DecisionEngine, DecisionRequest, EngineConfig

day = 86_400_000
catalog = [
    Candidate(candidate_id=1, provider_id=0, quality_bps=9000, risk_ceiling_bps=8000,
              lead_time_ms=8 * day, region_mask=1, quoted_cost_microunits=80_000_000),
    Candidate(candidate_id=2, provider_id=1, quality_bps=9500, risk_ceiling_bps=8000,
              lead_time_ms=3 * day, region_mask=1, quoted_cost_microunits=100_000_000),
]

# Lead time is a hard deadline here, not something to trade off against price,
# so its scoring penalty is switched off. Leave the default on and a delivery
# measured in days outweighs any realistic order value.
engine = DecisionEngine(catalog, config=EngineConfig(latency_penalty_microunits_per_ms=0))

request = DecisionRequest(
    request_sequence=1,
    budget_microunits=120_000_000,
    business_value_microunits=200_000_000,
    maximum_lead_time_ms=5 * day,
)
result = engine.decide(request)

result.status                     # "selected"
result.selected_candidate_id      # 2 — the cheaper quote misses the deadline
engine.verify(request, result)    # recomputed against the same catalog and policy

Quotes, budget and business value are integers in one currency and scale that you choose; nothing converts between currencies. Lead time is milliseconds in a u32, which caps it at roughly 49.7 days. When no candidate clears every gate, status is "rejected" and selected_candidate_id is None — never a fictitious zero.

verify does not read a self-declared flag. It rebuilds the whole result from the catalog, policy and request you hand it, which is why those are what you persist alongside the decision.

python examples/supplier_decision.py runs the full version offline, including a policy comparison. The candidates are suppliers there; the kernel does not know that.

Asking what a policy change would do

from calybris import compare_policies

stricter = DecisionEngine(catalog, config=EngineConfig(
    latency_penalty_microunits_per_ms=0, minimum_confidence_bps=9500,
))
comparison = compare_policies(engine, stricter, historical_requests)

comparison.total            # requests replayed
comparison.changed          # outcomes that moved
comparison.newly_rejected   # requests that now clear nothing
comparison.policy_changed   # True — compares native identity, not just config

This is a replay, not a forecast. It says what the two rule sets do to the same inputs; it does not demonstrate realized savings or supplier performance.

The Rust surface

git clone https://github.com/emirhuseynrmx/calybris-core.git
cd calybris-core
cargo run --example quickstart

That example builds a two-model policy, prescribes one request, verifies replay, and prints an audit bundle.

Budget control

AgentBudget sits beside the decision rather than in front of it: one shared budget across paid calls, with pre-call reservations, explicit uncertain-usage reconciliation, documented corrections for an overrun the budget could not absorb, and bounded immutable reports. python examples/agent_budget.py needs no provider credentials. See docs/AGENT_BUDGET.md for the same-process, non-streaming support boundary.

Use cases

Each is a runnable example in this repository, not a pitch.

Choosing among fixed quotes. Suppliers or subcontractors have quoted a already-priced job. Which one clears the budget, the deadline, the quality floor and the required capabilities — and can you show why, months later? → python examples/supplier_decision.py

Model and provider routing. A gateway picks among premium, fast, and budget providers under quality, latency, risk, provider, and budget ceilings. Every decision is verified before it enters the audited WAL, so "why did this request get the premium model" is answered from the proof rather than from log archaeology. → cargo run --example llm_routing

Pre-trade admission. A desk runs a VWAP algo at the cash open. Each child order clears a policy gate (an eligible venue under risk, latency, quality, and fee caps) and an exposure gate (notional reserved against the desk budget, routing fees committed on admit). The ledger carries the conservation proof remaining + reserved + committed == initial, in checked integers. Calybris owns the two gates and the proof — not the OMS, the market-data feed, or the matching engine. → cargo run --example pretrade_guard

Fulfillment and supplier routing at volume. 10,000 orders across 8 courier networks with distinct SLAs, regional coverage, and risk tolerances. Substitutions are recorded as decisions, so "why this courier, for this order" stays answerable months later. → python bindings/python/examples/orion_market.py

Defending a policy change with numbers. The same catalog evaluated under strict, medium, and relaxed profiles, reporting fulfillment and substitution rates, cost percentiles, batch and single-decision throughput, resident memory, and the audit success and tamper-detection counts for the resulting trail. → python bindings/python/examples/novamart_benchmark.py

The domain objects differ. The kernel, the digests, and the replay contract do not.

What gets proved

Calybris binds the full decision path:

policy digest + input digest + decision digest + replay result

The proof format is a written contract, not an implementation detail. docs/CALY_PROOF.md specifies every digest and chain byte-exactly, golden and conformance vectors pin them across versions and platforms so an independent reimplementation can prove itself against a fixed reference, and the bundled calybris-verify CLI lets an auditor check a decision trail without running your engine.

cargo install calybris-core   # ships the calybris-verify binary
calybris-verify chain decisions.wal.jsonl
calybris-verify chain decisions.wal.jsonl --anchor trusted-head.json
calybris-verify audit decisions.wal.jsonl --policy policy.json
calybris-verify audit rotated.wal.jsonl --policy policy-v1.json --policy policy-v2.json --json

What the trail carries:

  • Receipts. receipt::verify_receipt_full verifies replay, claims, trusted signature, state anchor and WAL anchor as one fail-closed operation.
  • Trusted policies. Construction canonicalizes catalog order, reserves model ID 0 as the rejection sentinel, and refuses catalogs that cannot fit the public decision counters.
  • State trajectories. state_digest_before/after per decision; verify_complete_trajectory binds genesis and the expected terminal step, while verify_trajectory remains an unanchored fragment check.
  • Ledger and checkpoints. Ledger digests bind WAL watermarks and reservation allocator state; coordinated checkpoints commit immutable snapshot and anchor generations behind one atomic manifest, with a loader that verifies the actual WAL.
  • Policy rotation. Library and CLI WAL replay resolve the exact policy per record across rotations.
  • Truncation. WalAnchor detects a cleanly removed WAL suffix when the trusted head is stored outside the WAL file.
  • Signed provenance. Ed25519 policy signatures are domain-separated, so a signature is non-transferable across policies, signers and timestamps.

Python exposes the same signed policies, state-chain transitions, decision receipts, keyed audited WAL, durable anchors and replay verification. The verification path builds for wasm32-unknown-unknown (--no-default-features).

docs/THREAT_MODEL.md is explicit about scope: the system proves trail integrity, not confidentiality, policy quality, or input truth.

Architecture at a glance

Module Role
kernel Integer-only decision kernel (~115 ns/decision); prescribe, prescribe_with_trace for per-constraint rejection counts
digest Canonical tagged byte digests — policy / input / decision / ledger / state
verify Full replay verification and audit bundles; fail-closed verified_audit_bundle
receipt Canonical claims digest + verify_receipt_full binding replay, signature, state, and WAL evidence
state Domain-state trajectories; complete genesis/final-step verification plus anchored fragment verification
provenance Ed25519-signed policies, domain-separated (feature)
wal Hash-chained WAL; keyed HMAC, trusted head anchors, and single-writer enforcement
budget CAS reserve/commit/release; remaining + reserved + committed == initial (Loom + Miri)
finance Ledger digests, conservation proofs and certificates
certificate / proof CALY-PROOF v1 compatibility envelopes; new integrations should use receipt
builder / config Hard-to-misuse constructors with validation
persistence Atomic snapshots, bounded artifact reads, and WAL-verified generation checkpoints; the directory-fsync guarantee is platform-specific
async_wal / instrument Tokio WAL (feature async), tracing spans (feature observability)

On the Python side, calybris.decisions is the typed fixed-quote adapter and calybris.agent is the shared budget. Both call the Rust implementations rather than reimplementing security-sensitive logic.

Ships a calybris-verify auditor CLI (chain / audit / policy, --json) so a third party can verify a decision trail without running your engine.

Stability model

Layer Status Notes
calybris-core (Rust) Stable crates.io: this is the contract
calybris (Python) Production-capable / stable API Decisions, policy comparison, shared budget, signed policy provenance, state proofs, receipts, keyed WAL, anchors and replay
calybris-ffi (C) Stable ABI The decision path over a stable C ABI, for callers that are neither Rust nor Python. Adds no behaviour; a C caller decides the same way and recomputes the same digests. See calybris-ffi/README.md.
calybris_commerce (Python) Experimental Thicker adapter (orders, suppliers, batch routing), still calls the same Rust kernel; API may change

Rust owns correctness and replay semantics. The core Python package exposes the production trust boundary and is tested as an installed abi3 wheel. Its runtime integrity guarantees match the Rust core, and as of 1.0.0 its API is stable — pin the exact version anyway, so that a rebuild is a decision rather than a surprise. docs/PYTHON.md covers the production path and the CALY-PROOF v1 compatibility boundary.

Install

# Rust (stable surface)
cargo add calybris-core

# Python (production-capable core binding; stable API)
pip install calybris

Local Python build: maturin develop --release or see docs/PYTHON.md.

Examples & adapters

Reference integrations that map domain objects onto the kernel:

Question Rust Python
Which fixed quote wins? - examples/supplier_decision.py
What would this policy change have done? - examples/supplier_decision.py
What has this run spent, and what is still open? - examples/agent_budget.py
Which model/provider? cargo run --example llm_routing quickstart.py, batch_routing.py
Which venue admits an order? cargo run --example pretrade_guard pretrade_budget_guard.py
Which supplier fulfills, at volume? - orion_market.py, novamart_benchmark.py

Full command list and code samples: docs/ADAPTERS.md

Performance

CodSpeed CI (Linux x86_64, release): ~8.6M prescribe/sec, ~115 ns/decision, 22-model synthetic catalog. Hardware and workload dependent — provenance and a reproduction recipe are in docs/BENCHMARKS.md; run cargo bench --bench kernel_bench on your own hardware.

A release-blocking production torture suite, introduced in 0.5.7 and still enforced, covers a 64-model checked kernel, state trajectories, signed receipts, keyed audited WAL, suffix-truncation detection, contended budgets, and a 25,000-tenant ledger.

Security posture

  • #![forbid(unsafe_code)] in calybris-core — the kernel cannot contain unsafe, and the compiler enforces it rather than a review convention. The one exception is calybris-ffi, which exists to be a C boundary and therefore handles raw pointers; it is a separate crate for exactly that reason, so the unsafe is confined to a few hundred reviewable lines instead of being available everywhere.
  • Fail-closed audit boundaries: verified_audit_bundle / append_verified_audited refuse to emit or log a decision that does not replay exactly.
  • Tamper-evident WAL: SHA-256 hash chain, optional HMAC-SHA256 with constant-time comparison (subtle). Keyed WAL APIs reject keys shorter than 32 bytes.
  • Trusted WalAnchor verification detects a cleanly removed WAL suffix; the hash chain alone validates only the records still present.
  • Anchored recovery APIs refuse to build a recovery plan from a valid but incomplete WAL prefix.
  • visit_verified_wal* streams verified entries, so CLI audit and recovery planning do not retain the complete log in memory.
  • Sync and async WAL writers enforce one active writer per file.
  • prescribe_checked and the checked batch and trace APIs validate untrusted Rust inputs.
  • Signed decision receipts bind optional state and WAL evidence to the exact replay-verified decision.
  • Byte-exact proof contract (docs/CALY_PROOF.md) locked by golden and conformance vectors, cross-checked in Rust and Python.
  • Concurrency and UB: 7 Loom exhaustive interleavings on budget ops; Miri on nightly for the library tests.
  • Security CI: Semgrep Rust/Python/secrets/security-audit, cargo-audit, and cargo-deny; feature matrix covers default / no-default / async / full.
  • Documented boundaries: docs/THREAT_MODEL.md (what it does not guarantee) and docs/KEY_MANAGEMENT.md (key custody and rotation).

Deployment security remains the caller's job: key storage, tenant isolation, inventory/capacity freshness, and an external audit.

Deep dive

Doc Contents
docs/SPECIFICATION.md Every digest layout, byte by byte — what a second implementation would be written against
docs/INVARIANTS.md Every property the crate promises, with the test that fails when it stops being true
fuzz/README.md The fuzz targets, what would count as a finding in each, and why they only run on Linux
docs/COMPATIBILITY.md What a 1.x release may and may not change, and how a defect that needs a format change is handled
docs/DECISION_SEMANTICS.md Decision API, units, identities, policy comparison and its limits
docs/AGENT_BUDGET.md Shared budget, reservations, corrections, lifecycle report, support boundary
docs/ADAPTERS.md Every reference mapping with its commands and code
docs/AUDIT_GUIDE.md Module map, audit commands, external review checklist
docs/CALY_PROOF.md CALY-PROOF v1 digest and proof contract
docs/THREAT_MODEL.md Assets, trust boundaries, attackers
docs/KEY_MANAGEMENT.md HMAC / Ed25519 key custody and rotation
docs/SECURITY_INVARIANTS.md Invariants I1-I10 and test mapping
docs/BENCHMARKS.md Throughput provenance and reproduction
docs/MIRI.md UB detection scope in CI
docs/PYTHON.md Python wrappers vs Rust core, commerce API notes
SECURITY.md Vulnerability reporting, supported versions
CONTRIBUTING.md Dev setup, test gate, PR expectations

License

Apache-2.0. See LICENSE.

Release files for calybris 1.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for calybris 1.0.0
File Size Uploaded
calybris-1.0.0.tar.gz 314.1 kB Details

Built distributions (wheels)

Table of built distributions (wheels) for calybris 1.0.0
File
calybris-1.0.0-cp310-abi3-win_amd64.whl CPython 3.10 abi3 Windows x86-64 Details
calybris-1.0.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl CPython 3.10 abi3 Linux glibc 2.17+ x86-64 Details
calybris-1.0.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl CPython 3.10 abi3 Linux glibc 2.17+ ARM64 Details
calybris-1.0.0-cp310-abi3-macosx_11_0_arm64.whl CPython 3.10 abi3 macOS 11.0+ ARM64 Details
calybris-1.0.0-cp310-abi3-macosx_10_12_x86_64.whl CPython 3.10 abi3 macOS 10.12+ x86-64 Details

Total release size: 4.1 MB

Release files / calybris-1.0.0.tar.gz

Download URL calybris-1.0.0.tar.gz
Size 314.1 kB
Tags Source
SHA-256 checksum
How to use checksums
c468bd21758da9df8b91b1f53343ba22d67044a1c63879e9c801526f64ecb60d
BLAKE2b-256 checksum
How to use checksums
5b2a77710efc1b848d126100377b52552249a34b53fbd460b5f8a5b37654d162
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / calybris-1.0.0-cp310-abi3-win_amd64.whl

Download URL calybris-1.0.0-cp310-abi3-win_amd64.whl
Size 704.8 kB
Tags CPython 3.10 Windows x86-64 abi3
SHA-256 checksum
How to use checksums
a072476328fffc51a8c6453b3fa2926726ba59fee8bc564619887cce9c5e950b
BLAKE2b-256 checksum
How to use checksums
23bb7c7db94e4d255d6d35a06a8d748822c4b8fb36e4aef12617516946e05b8d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / calybris-1.0.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

Download URL calybris-1.0.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Size 807.2 kB
Tags CPython 3.10 Linux glibc 2.17+ x86-64 abi3
SHA-256 checksum
How to use checksums
67ac4fee8d14664d2898e808574d2f6f0a6b656922ceebd4b23c3d67032b223a
BLAKE2b-256 checksum
How to use checksums
cf800edf6f22f379c8a7ccfc2694c467080fd97a5350b0ccf698fc2fed857ba3
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / calybris-1.0.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl

Download URL calybris-1.0.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Size 770.1 kB
Tags CPython 3.10 Linux glibc 2.17+ ARM64 abi3
SHA-256 checksum
How to use checksums
fd0c770d4fc26928183f9bba27c5fdfdc5fad122fc75d9d9bc9d263289de9462
BLAKE2b-256 checksum
How to use checksums
ceec05bca6254dc4ef09ab405f32dc2a562bcdd4b82d0d3e2a1260ddfbf92229
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / calybris-1.0.0-cp310-abi3-macosx_11_0_arm64.whl

Download URL calybris-1.0.0-cp310-abi3-macosx_11_0_arm64.whl
Size 739.8 kB
Tags CPython 3.10 abi3 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
ecea454a2d0838994db5bf68a98b778422fc0c01fecba310e6f00250ebd176c8
BLAKE2b-256 checksum
How to use checksums
4011a2be6b355d7145b2d0dea7950b1a7e471d77ba1ccd94339eec2612045a7c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release files / calybris-1.0.0-cp310-abi3-macosx_10_12_x86_64.whl

Download URL calybris-1.0.0-cp310-abi3-macosx_10_12_x86_64.whl
Size 772.8 kB
Tags CPython 3.10 abi3 macOS 10.12+ x86-64
SHA-256 checksum
How to use checksums
a6da3f026a2fa746084cecf45527ae42849bf0845a1652d52a47e59f0e0d32f4
BLAKE2b-256 checksum
How to use checksums
1f464cf21a0b5ef68c34592ace14c5ea24e8f286f06ff4216cae68949f1d8b95
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 19, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

1.0.0 This release

6 release files

0.6.0

6 release files

0.5.7

6 release files

0.5.5

6 release files

0.5.0

6 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page