Most monitoring tools answer one question: what is happening right now? A greenhouse is idle. A reefer truck is warming. A power plant is breathing dust. The dashboard turns red, and someone has to work out whether there is still time to do anything about it.
We built QAI Connect around a different question:
How much time is left to make a safe and useful decision before our options run out?
We call that number the Decision Reserve. This post covers how we compute it from open data, how we fine-tuned LAYA, a 0.5B-parameter Qwen, to explain it, and how we run LAYA in the browser on a Hugging Face Space behind a governance layer we call TAILSTRIKE.
👉 Try it: LAYA on Spaces
The Decision Reserve
Every decision has a clock. A planting window closes. A load of lettuce crosses its safe temperature. A plant hits a heat or dust constraint. We split that clock into parts:
DR = Tf − Td − Ta − Te − Tb
| Term | Meaning |
|---|---|
| Tf | time to failure or critical constraint |
| Td | time to detect and validate the problem (data latency lives here) |
| Ta | time to approve a decision |
| Te | time to execute the intervention |
| Tb | a safety buffer |
Nothing in that list is certain, so we report a probability rather than a single number:
P(DR > 0) = P(Tf > Td + Ta + Te + Tb)
We estimate it with a normal model, or with Monte Carlo draws for the location engine.
The useful part is Td. Data latency goes straight into lost decision time. Here is one of our live cold-chain examples, a truck of lettuce at 10 °C with about 60 minutes before it is lost:
| How often we see the data | Decision Reserve | P(DR > 0) |
|---|---|---|
| Manual check every 30 min | −5 min | 0.31 |
| Telematics poll every 15 min | +10 min | 0.84 |
| Streaming | +24 min | 0.99 |
Same truck, same cold store, same approval process. Only the data speed changed, and that alone decides whether the load can still be saved.
Built on open data
QAI Connect is an integration layer. It connects partners' existing systems (ERPs, spreadsheets, sensors, government data) instead of replacing them. For the prototype, every number comes from public sources:
- Hugging Face dataset
Inzinion/power-plant-climate-exposure-index: 42k power plants with fuel, capacity and climate exposure. - Open-Meteo: live forecast, apparent temperature and ET₀ for farm water budgets.
- ERA5 (historical weather) and CAMS (air quality: PM10, dust, NO₂).
- OpenStreetMap for buyers and cold stores, OSRM for real road drive times, Copernicus DEM for elevation.
Type any place into the app and it builds a heat map, finds the energy sites in range and computes each site's Decision Reserve. For Ras Laffan in Qatar that is 4 sites and 7,113 MW, with Ras Rakan as the binding site at about 229 hours (P50), limited by airborne dust.
Why fine-tune a 0.5B model?
The maths is deterministic code; we never let a language model produce the numbers. People still need the result in a sentence: which site binds, why, what can be done, and by when. Large hosted models do this well, but we wanted:
- Exact numbers. The explanation has to repeat the engine's figures, not "about 230 hours".
- On-device inference. Partner data should not have to leave the browser.
- Low cost. We wanted the whole thing to run on the cheapest tier we could find.
So we fine-tuned the smallest Qwen chat model.
Data: 1,780 rows, every target computed by the app's own engines
We used the app's own engines to write the training targets. Every number in a target was computed, not invented.
| Slice | Rows | Source |
|---|---|---|
| Location (real) | 900 | Plants from the HF dataset with real ERA5 weather and CAMS air quality on random days from 2022 to 2025 |
| Location (stress) | 400 | Synthetic heatwaves and shamal dust storms, for extremes that real days rarely hit |
| Fleet sites | 480 | 8 farm sites × 60 days of real weather, scored for growing method and planting window |
The prompts are byte-for-byte the strings the app sends at inference time, so the model sees exactly the input format it was trained on.
Training: TRL + LoRA on HF Jobs
- Base:
Qwen/Qwen2.5-0.5B-Instruct - Method: TRL
SFTTrainerwith LoRA (r=16, alpha 32, all linear layers), 2 epochs, learning rate 2e-4, max length 1024; adapter merged into the weights - Hardware: HF Jobs
t4-small, about half an hour per run
| Metric | Result |
|---|---|
| Eval loss | 0.18 |
| Token accuracy | 94% |
| Exact numeric match, held-out (real locations) | 11 / 12 |
| Exact numeric match, held-out (stress) | 10 / 12 |
"Exact numeric match" is the metric we cared about most: greedy decoding on held-out cases, where every number in the answer must equal the engine's number.
Running it in the browser: what went wrong
We exported to ONNX for Transformers.js. Three things went wrong first, and they may save you a few hours:
rope_thetasilently fell back to the default. We trained with transformers 5, which storesrope_thetainsiderope_parameters. The exporter ran transformers 4.46, which did not find it and used 10000 instead of Qwen2.5's 1e6. The ONNX model behaved like the base model, with the fine-tune lost. Fix: copyrope_thetaback to the top level ofconfig.jsonbefore exporting.- int8 broke the model. Every int8 (q8) variant we tried produced garbage or base-model text: per-channel or not, MatMul-only or not. The 4-bit build (
MatMulNBits, block size 32) kept the fine-tune intact, so we ship q4 only (855 MB). It runs on WebGPU, with a WASM fallback. - We now verify before publishing. The export job generates on held-out cases with PyTorch and with each ONNX build, and refuses to push a build that does not reproduce the numbers. That gate caught all of the problems above before anything reached users.
The Space is a free static Space. The page and its scripts are a few kilobytes. The weights load from the ONNX repo, jonathan4e/qai-laya-qwen2.5-0.5b-onnx, pinned to the exact revision that passed verification. LAYA runs in a Web Worker so the page stays responsive.
TAILSTRIKE: the model proposes, the gate decides
A model that suggests "shift 154 MW of dispatch to another plant" must not be able to do it. TAILSTRIKE is a small governance kernel in front of LAYA. Its design follows the governed-runtime pattern: proposing, admitting and acting are separate steps.
- LAYA only proposes. Its output is treated as untrusted.
- A frozen rulebook decides. Every request and answer passes a fail-closed gate with 11 rules. Anything not explicitly allowed is denied.
- IN-03: context fields are screened for prompt injection before the model runs.
- OUT-01: at least 80% of the figures in an answer must appear in the input data, or the answer is held.
- OUT-02: any sentence that proposes an action (shift, divert, reroute…) becomes a proposal that only a named human approver can sign. Signing is advisory; nothing is executed.
- LIFE-01: after two ungrounded answers in a row, LAYA is quarantined until an approver releases it.
- INT-01: the model's config and tokenizer files must match a SHA-256 manifest for the pinned revision before anything loads.
- Every decision is recorded. Requests, verdicts and approvals go into a SHA-256 hash-chained ledger. Edit one record and verification fails at that record. You can verify and export the ledger from the page.
- The page is locked down. A content security policy allows no inline script and loads code only from the Space and a pinned CDN.
Try the "Try an injection" button on the Space. The gate denies the request before the model runs, and the denial shows up in the ledger.
What's next
- Inference Endpoints: a scale-to-zero T4 endpoint for the PyTorch model, so server-side apps can use the same fine-tune.
- More chains: the same reserve applies to water reuse, cooling headroom and gas feedstocks.
- Pilots: three permissioned datasets per chain before scaling: capacity, inputs and buyer demand for farms; load trace, warehouses and sales for logistics.
The measure we care about is simple: did someone find the problem early enough to still respond?
Links: - Space: jonathan4e/qai-laya - Browser model (ONNX, q4): jonathan4e/qai-laya-qwen2.5-0.5b-onnx - Base model: Qwen/Qwen2.5-0.5B-Instruct - Power-plant dataset: Inzinion/power-plant-climate-exposure-index