DOC. TRS-002 — PLATFORM / CAPABILITY AREAS — REV 2026.08

The control system around the model.

Abstract

Models are components. Tresonant builds everything a regulated organisation needs around them: specification, evaluation, runtime constraint and evidence. Three capability areas, one architecture.

Area 01: AI reliability engineering — deterministic pipelines around probabilistic parts; §01
Area 02: Evaluation & guardrails — prove the boundary, then enforce it; §02
Area 03: Regulated deployment — shipped with the evidence attached; §03
Model coupling: Agnostic across all three areas; every component disclosed and approved; SPEC.05

Pick the claim you'd want proven · Industry scenarios →

§01

Deterministic pipelines around probabilistic parts.

A language model is not an architecture. We wrap probabilistic components in engineering that makes the whole system's behaviour specified, bounded and repeatable.

01.1 — What we build

Systems whose behaviour is written down before it is shipped.

Typed I/O contracts: Every model call has a schema; malformed output is a handled failure, not a surprise downstream.
Constrained generation: Structured decoding, allow-listed actions and bounded tool use, so the model can only do what the specification permits.
Deterministic orchestration: Control flow lives in reviewable code, with pinned model and prompt versions and reproducible configuration.
Failure budgets: Defined behaviour for timeouts, low-confidence outputs and rejected responses: retry, degrade or escalate to a human.
Change control: Prompts, policies and models are versioned artefacts; every change is diffable, reviewed and traceable to a release.

§02

Prove the boundary. Then enforce it.

Evaluation demonstrates that the system meets its specification; guardrails hold that specification against live traffic. We build both from the same source: your policies and your edge cases.

Fig. 05 — Evaluation loop: the suite is permanent, the gate is mandatory

Schematic. Not to scale.

02.1 — Evaluation

Test suites derived from policy, not vibes.

Policy-derived assertions: Each clause of your operating policy becomes testable checks against real and synthetic cases.
Regression gates: Every prompt, model or policy change re-runs the full suite; regressions block release by default.
Adversarial suites: Prompt-injection, data-exfiltration and jailbreak batteries maintained as living test sets.
Calibrated grading: Automated grading is itself audited against human judgement on sampled cases, with disagreement tracked.

02.2 — Guardrails

Runtime enforcement of the same specification.

Input screening: Malformed, out-of-scope or adversarial inputs are rejected or quarantined before any model call.
Output verification: Schema validation, policy filters and consistency checks between model output and source data.
Bounded tool use: Models act only through allow-listed, permissioned tools with per-action audit records.
Mandatory escalation: Low-confidence or policy-adjacent outputs route to a named human owner; the system never quietly guesses.

Isometric exploded diagram of five stacked filter planes of increasing density; most vertical paths are stopped at an intermediate layer while two blue paths pass cleanly through every layer and terminate in square nodes below. — Fig. 06 — Guardrail strata (conceptual)

§03

Shipped with the evidence attached.

In a regulated organisation, deployment is not the end of engineering — it is a submission of evidence. We build systems whose controls can be inspected, and we write the documentation ourselves.

03.1 — Controls & evidence

Designed to survive an audit, not just a demo.

Decision-level audit trails: Inputs, versions, guardrail verdicts and human sign-offs recorded for every output, with a documented log schema.
Data-residency options: UK/EU deployment patterns, client-cloud and on-infrastructure delivery where obligations require it.
Human-in-the-loop checkpoints: Approval steps placed where accountability actually sits in your organisation, not bolted on afterwards.
Access & segregation: Least-privilege service boundaries; no shared credentials between environments.
Documentation packs: System descriptions, control mappings, evaluation reports and residual-risk statements written for risk committees and auditors.

03.2 — Deliberate exclusions

What we will not build.

No unaccountable autonomy: We do not ship systems that make regulated decisions without a named human owner and an escalation path.
No undisclosed components: Every model, vendor and sub-processor in the chain is disclosed to you and approved by you.
No training on your data: Client data is used only as your written instructions permit.

§04

Walk us through your architecture.

Bring the diagram you already have — whiteboard photo is fine. We will tell you where the verification layer belongs and what the evaluation suite should test first.

Pick the claim you'd want proven · Contact details →

sales@tresonant.co — we reply within one business day.