How we turn a safety standard into software you can audit — and why no AI model ever makes a compliance-critical decision at runtime.
AI does the heavy lifting where AI is strong — and is forbidden where determinism is mandatory. Three steps, one gate each.
The standard's text, tables, formulas and worked examples are extracted into structured, machine-readable datasets — every extracted value reviewed against the source, page by page.
An independent verification pass re-reads the source clause by clause and challenges every implemented rule — wrong threshold, missed exception, misread table, unit error. The loop repeats until zero findings remain. Then golden tests, taken from the standard's own worked examples, must pass 100%.
What ships is pure, versioned, auditable code: same inputs, same outputs — always. Every result traceable to the clauses that produced it. Engines run server-side, behind APIs.
| Engine | Scope | Status |
|---|---|---|
| EN 378 | Refrigerating systems — refrigerant charge limits, room sizing, safety classification (EU). Validated against the standard's own worked examples. | In production |
| EU F-Gas 2024/573 | Leak-check obligations logic — frequency, thresholds, detector-presence effects. | In production |
| ASHRAE 15 | Safety standard for refrigeration systems (US). Golden-tested, cross-language port with 100% parity. | Verified, ready |
| ISO 817 | Refrigerant designation and safety classification. Golden-tested, cross-language port with proven parity. | Verified, ready |
Anything short of full verification — golden tests, adversarial audit to zero findings, clause traceability — is a draft, not an engine, and is never exposed to a client instance.
Every regulatory update to a delivered engine is logged, versioned and communicated: what changed in the standard, what changed in the engine, which tests re-passed. Every client-facing calculation records the engine version that produced it, so historical calculation sheets remain reproducible and defensible — even years later.
Each change enters the ledger with its source: the edition, amendment or correction that triggered it.
New editions open a new engine version line; the old line stays available, because installed equipment is often assessed against the edition in force at installation.
You are told what moved and why — regulatory maintenance within delivered modules is our responsibility under the annual license, not a ticket in your backlog.
We build the second kind. An LLM answering compliance questions at runtime cannot guarantee the same answer twice, cannot cite the exact clause chain behind a number, and cannot be regression-tested against a standard's worked examples. A SpecSell engine can — because the intelligence was spent at build time and frozen into auditable, deterministic code. AI builds the engine; the engine never guesses.
Not every engineering problem deserves the same amount of AI — and choosing the level is itself an engineering decision. Every solution in the portfolio states its level, and why.
No AI at runtime. Pure, versioned, auditable code — same inputs, same outputs, always. This is where compliance-critical calculation lives.
AI builds, engineers validate, and the runtime stays deterministic. The intelligence is spent before your customer ever sees a result.
Autonomous agents work at a pace no manual process matches — always under engineering supervision, never left to guess unattended.
Tell us which standards govern your products — we'll show you what a verified engine for them looks like, on your catalogue.