Decision proposals
rustev
An embeddable Rust engine that proposes decisions without granting authority.
Observed 2026-10-03 · Producer spec-spine 0.28.0
1c713a61033279ce9b81d11d683bdf551f7a3769 ↗18 specifications. Verification and deployment qualification are unknown in this export.
Bootstrap spec system
Foundational contract: authored truth lives only in markdown (+ YAML frontmatter); machine-consumable truth is compiler-emitted JSON only; every artifact is a deterministic function of (config, file contents); a typed authority graph governs who-owns-what.
Ecosystem boundaries, proposals versus authority, and product principles
What Rustev owns and refuses to own within the ecosystem (spec-spine, Aicortex, Rahi, statecraft-cli, applications), the rule that Rustev produces proposals and never grants, the provenance classes of Rustev outputs, the dependency layout that keeps contracts transport-neutral and the core free of integrations, and the product principles that are the constitution's principles VI onward. Owns the workspace manifest, the Makefile and the boundary check that enforces the dependency rules.
Decision contract and pure core
Increment 1: the versioned wire contract (`rustev-contract`) and the pure core (`rustev-core`). Bounded parsing, canonical form and identities, value kinds without silent conversion, fixed-point decimals and millisecond time, input validation with provenance, freshness and conflict, a closed versioned exact-operator registry, decision definitions entered through a typed builder or canonical JSON, the plan compiler with capability matching, declared fallbacks and typed refusals, calibration binding, deterministic selection policy with explicit unresolved handling, and derivation classes with lineage. No I/O, no clock, no async executor, no model.
Runtime execution and evidence emission
Increment 2: `rustev-runtime` drives the pure core's staged evaluation through backend seams on Tokio (R-03) under explicit bounds: injectable monotonic time and one end-to-end deadline, bounded admission and concurrency, cost budgets reserved before dispatch with honest settlement, bounded retries and runtime fallback declared in an identified execution policy that is part of plan identity, cancellation that never claims more than the backend acknowledged, and evidence delivery under a declared sink policy. Amends spec 002: plan schema 2, the execution-policy and run-record documents, a pre-supply output check, and the backend and sink seams. Batching, duplicate suppression and caches are deferred by name.
Evaluation and replay
Increment 2: offline reproduction from bounded, host-retained replay bundles; configurable tenant-only or principal-scoped equivalence for candidate comparison; explicit availability, coverage and abstention; named dataset splits and temperature fitting. Amends 002 with replay and request documents and typed loading diagnostics, and 003 with opt-in bounded capture of supplied values. Live re-execution is deferred. Synthetic fixtures establish mechanics only, never empirical quality.
Deterministic rules backend
Increment 2: `rustev-backend-rules`, a deterministic, in-process backend that implements the backend seam of spec 003 by evaluating a bounded, versioned rules program (`rustev.rules/1`): typed field access into the canonical projection, ordered rules with explicit precedence and no-match behavior, constant, linear and lookup contributions to authored logits in exact fixed-point arithmetic, and a descriptor derived from the program so the program's digest is the artifact identity plans bind. Metered logical cost units, bounded work, local cancellation observed at declared points. Narrowed by owner decision R-13; the semantic backend is spec 011.
CLI surface
Increment 2: `rustev`, a command-line host over the library. Plan check, compile and show against descriptor, rules-program, calibration and execution-policy files; run one snapshot through `rustev-runtime` on rules-program backends with a file evidence sink and optional bounded capture into a replay bundle; offline replay under an explicitly supplied trusted scope; evaluation reports with their detail and configuration companions, regression gates, and temperature fitting with its lineage record, through `rustev-eval`. Bounded file access, stable JSON output and distinct exit codes. No network, no hosting, no live inference beyond the deterministic rules backend.
Reference package: support routing
The first domain package of increment 3 (design section 16.1, roadmap ordinal 007): `packages/rustev-pkg-support-routing`, a library that publishes the support-routing decision definition, its golden canonical documents, a declarative task adapter and evaluator configuration, and a synthetic labeled dataset, depending only on `rustev-contract` and `rustev-core`. It demonstrates that a domain is a package and not a core change, and that swapping the semantic backend (the rules backend's synthetic head against the Jev integration, spec 012) produces comparable reports with no change in any authority path. Approved (A-12, 2026-09-25) and amended by 016 (A-13, 2026-09-26); implemented.
Reference package: lodging recommendation
The second reference domain package reserved by the architecture roadmap: `packages/rustev-pkg-lodging`, containing a bounded lodging-recommendation definition, canonical documents, synthetic mechanics fixtures, and evaluation material. The package preserves exact eligibility, explicit trust treatment, bounded semantic fan-out, abstention, lineage, offline replay, partial adoption, and backend-swap comparison without claiming semantic quality, external readiness, or authority to book lodging.
Remote adapter protocol
Increment 3 (design roadmap 17.1, ordinal 009): what every decision backend reached across a network must guarantee, and a versioned, transport-neutral protocol (`rustev.remote/1`) for backends served by another process. Covers capability description and negotiation at setup, attempt identity and idempotency, one total time budget per attempt, cancellation that never claims more than the remote side confirmed, validation of responses into `RawOutput` without inventing mass, a closed error taxonomy mapped onto spec 003's failure classes, explicit served-model identity (unknown is a value, never an omission), cost reporting, retained exchange records for audit and replay, and privacy options passed through and recorded. Protocol messages live in `rustev-contract`; every network implementation lives under `integrations/`. Amends no approved behavior. Approved (A-08); implemented.
First semantic backend (deferred)
Deferred roadmap item split out of spec 005 by owner decision R-13: the first semantic backend candidate of R-01, frozen embeddings plus a task-specific linear head, with ONNX Runtime through `ort` preferred only after a bounded compatibility, licensing, operator, linking, packaging and resource check. Claims no code and adds no dependency until that check is recorded and this spec is made concrete and approved.
Jev integration (remote decision backend)
A remote decision backend under `integrations/` that answers Rustev's `proposition`, `classify` and `rubric` steps by calling TypeSafe's Jev model, through the Vercel AI Gateway by default or TypeSafe's own API as an alternative transport, as an ordinary integration. It conforms to Part A of spec 009: explicit served identity (unknown on the Gateway), one total budget, unconfirmed cancellation once sent, closed error codes, estimated cost, requested privacy options, and exchange records. Many Rustev questions over one state go in one request. Provider confidence is recorded, never treated as calibrated. `rank` is not declared. No Jev wire-compatible surface is exposed. Paid inference for smoke and qualification is authorized by R-27 (zero data retention, synthetic and independently labeled data only); testing is capped at USD 5 in total and production at USD 25 per month (R-29), and production requires a pinned model version (R-28). Approved (A-09); implemented.
Remote state on attempts that end without a stop (amends 003)
A separately reviewable amendment of approved spec 003 (R-16), chosen by the owner in R-28 for the gap spec 009 5.1 records: the runtime derives `possibly_continuing` only from cancellation, so an attempt whose request left the process and whose connection then failed is recorded as `finished` although remote work and charges may continue. This adds one field to the attempt report through which an adapter states that remote work may continue, and one derivation rule in the runtime. The `rustev.run/1` schema and every existing record's bytes are unchanged. Approved (A-07) and implemented.
Task adapter rules bound into evaluation identity (amends 004)
An amendment of approved spec 004 (R-16). The evaluator configuration names its task adapter only by name and version, so the configuration identity a report carries does not change when the adapter's correctness rules change under the same version, and a gate can compare two reports that judged correctness differently. Spec 006 closes this for the CLI alone, by writing the adapter document beside each report and comparing bytes. This amendment binds a digest of the adapter's rules into a new evaluator configuration version, so the report identity itself covers correctness, and makes a gate unknown whenever either side's rules are unbound. Approved (A-10, 2026-09-25) and implemented.
Per-case reporting of unusable replay bundles (amends 004)
An amendment of approved spec 004 (R-16). Evaluation takes parsed replay bundles only, so a retained bundle whose bytes cannot be read, exceed their limit or do not parse cannot be reported as one incomparable case: a host must either stop the whole evaluation (the CLI's choice, spec 006 E-31) or leave the case out, which the library then reports as `bundle-missing`, misstating corruption as absence. This amendment lets the caller supply a typed bundle-load failure per case, reported as incomparable with its own reason, counted in coverage and excluded from quality. Approved (A-11, 2026-09-25) and implemented.
Declared uncalibrated threshold in support-routing swap test (amends 007)
A proposed amendment of approved spec 007 (R-16). Spec 007 3.4.3 and section 5 require the backend swap test to assert identical compiled plans' policy sections across the rules backend and Jev backend. Under owner decision R-31 (approving Q-1), Jev returns an uncalibrated distribution and declares `uncalibrated_threshold` on `topic`'s `top_mass_below` condition with a margin rule. The reference definition keeps `uncalibrated_threshold: not_declared` to match the golden document byte-for-byte (3.1.3). Because `uncalibrated_threshold` is part of the condition inside the policy section, the compiled plans' policy sections cannot be strictly identical under equality. This amendment amends 3.4.3 and section 5 so that the swap test asserts identical policy rules, conditions, thresholds, adjustments and output declarations, accounting for Jev's declared uncalibrated threshold on `topic`. It also resolves two further conflicts found while preparing 007's delivery: where the swap test can live given spec 001 3.4.4, and how priority can be a separately labeled field given the declarative task adapter's one-label-per-case shape (spec 006, 3.8). Approved (A-13, 2026-09-26) with both open questions settled as recommended (R-33); implementation complete, delivered with spec 007.
General runtime batching, duplicate suppression, and caches
A separately reviewable amendment to runtime execution for general runtime-planned batching, concurrent duplicate suppression, bounded memory caches, and opt-in persistent caches. Optimized execution must be judgment equivalent to independent uncached execution, isolate authorized scopes, preserve each waiter's deadline and cancellation, attribute one charge and every liability exactly once, invalidate on correction, revocation and erasure, and record every shared-call or cache effect. Existing adapter-scoped batching remains a special case, not evidence that this general contract is implemented or qualified.
Adopt Statecraft profile revision 14 with the ordinary Rust code gate
Authorizes the narrow migration from Statecraft github-actions-rust revision 13 to revision 14 after the spec-spine 0.28.0 bridge and pin sequence. Rustev keeps its exact engine pin and ordinary Rust code gate, boundaries and verify jobs. The managed authority files are regenerated by the revision 14 producer using the retained setup parameters.