RuForecast 0.2.0 puts spend approval in front of forecasting

What RuForecast is

RuForecast predicts several correlated signals at once — load, demand, temperature, whatever your system emits — and does it in Rust, locally, without shipping the series to a third party.

The privacy governance is the point of difference. Where a run touches an external provider, that has to be authorised rather than assumed.

What changed in 0.2.0

Version 0.1.0 landed on September 2 as the first release. A day later v0.2.0 added governance verification and spend enforcement, following commit 16c18aa which made fal.ai governance verification and spend approval mandatory.

In plain terms: a training or inference path that costs money now has to pass an approval gate first. That is a small change with a large operational effect.

Get started

A Rust toolchain and a checkout. Build the CPU trainer:

cargo build --release -p ruforecast-train --no-default-features --features cpu,cli --bin ruforecast

Expected result: a ruforecast binary in target/release that can train and evaluate locally.

No documented MCP server. The supported surface is the Rust crate and the CLI binary.

Use it today

Practical case: capacity planning on data you are not allowed to send anywhere. Input is a multivariate CSV of your own metrics. Workflow is train locally, evaluate against a held out window, read the error. Output is a forecast plus the evaluation that tells you whether to trust it.

Acceptance test: run a path that would call an external provider without approval configured. It should refuse.

Push it further

Experimental commentary. RuForecast already feeds ruv-drone as a predictive advisory. The wider idea is forecasting as a service inside a fleet, where each vehicle carries its own model rather than phoning home.

Limitation: edge inference cost and accuracy on constrained hardware is unproven here. Falsifiable test: run the same evaluation on your target device and compare error and latency against the workstation run.