DOC. TRS-003 — INDUSTRIES / SECTOR CONSTRAINTS — REV 2026.08

Built for sectors where "usually right" isn't enough.

Abstract

Finance, healthcare and the public sector share a property most AI vendors avoid: someone is accountable for every output. We design for that accountability from the first line of the specification.

Financial services: Model risk management, applied to language models; §01
Healthcare: Assistive by design, accountable by construction; §02
Public sector: Transparent enough to be questioned in public; §03
Scenarios: Illustrative capability descriptions — the architecture we build, not client case studies; NOTE

§01

Model risk management, applied to language models.

Banks and insurers already know how to govern models — the discipline exists; generative systems simply arrived faster than the tooling. We bring LLM-based systems inside your existing model-risk framework rather than around it.

A long colonnade of pale stone piers receding in strict rhythm, overlaid with fine ruled register lines and tick marks in the manner of an audit ledger, with a single blue hairline marking three registration points. — Fig. 00 — Regulated institutions: repetition, record, registration

01.1 — What matters here

Committee-grade evidence, decision-grade trails.

Model-risk alignment: Documentation and validation artefacts structured to fit model inventory, validation and periodic-review processes.
Decision traceability: Every system output reconstructable: inputs, retrieved documents, model versions, guardrail verdicts, human sign-off.
Explainability: Outputs carry structured rationales a credit or risk committee can interrogate.
Data boundaries: Client and counterparty data handled under strict residency and retention constraints, disclosed sub-processors only.

Illustrative scenario

A lender wants LLM assistance summarising document-heavy credit files. The pipeline that answers this cites its source passages in every summary, fails closed when a document is missing, logs each step to an audit record, and leaves final judgement with the credit officer — whose sign-off is part of the trail.

§02

Assistive by design. Accountable by construction.

In clinical settings the boundary is not negotiable: AI drafts, humans decide. We engineer systems that reduce administrative burden while keeping clinical accountability exactly where it belongs — with the clinician.

02.1 — What matters here

Special-category data, human sign-off, provable restraint.

Hard scope limits: Systems constrained to administrative and documentation support; diagnostic conclusions are architecturally out of bounds, not merely discouraged.
Clinician sign-off: No AI-drafted artefact enters the record without review by an identified professional.
Special-category data: UK GDPR Article 9 obligations reflected in architecture: minimisation, residency, retention and access control designed in.
Source-bound generation: Drafts trace to the underlying encounter data; unsupported statements are flagged for review, never silently included.

Illustrative scenario

A provider wants to reduce the time clinicians spend writing discharge summaries. The drafting pipeline that answers this works only from the structured record, marks each statement with its source, routes every draft to the responsible clinician for correction and sign-off, and keeps the full draft-and-revision history as evidence.

§03

Transparent enough to be questioned in public.

Public bodies operate under freedom-of-information duties, judicial review and algorithmic-transparency expectations. A system that cannot explain itself to a citizen has no business making decisions about one.

03.1 — What matters here

Auditability as a public duty, not a feature.

Disclosure-ready records: Audit trails and system documentation structured so transparency and FOI responses are an export, not an archaeology project.
Transparency standards: System descriptions written to support algorithmic transparency reporting obligations from day one.
Triage, not verdicts: AI assists ordering and preparing casework; determinations remain with accountable officers, recorded as such.
Procurement documentation: Architecture, data flows and residual risks documented in plain language for governance boards and oversight bodies.

Illustrative scenario

A department wants help triaging a high-volume correspondence backlog. The classification and routing pipeline that answers this carries published category definitions, per-item confidence and audit records, sampling-based quality review by staff, and one standing rule: anything ambiguous routes to a human queue.

§04

Different regulators. Same engineering answers.

Table 01 — Common obligations mapped to architecture

Obligation	Architectural answer	Where it lives
Every decision must be explainable	Source-bound outputs with structured rationales and citations	Verification layer
Every decision must be reconstructable	Decision-level audit log: inputs, versions, verdicts, sign-offs	Audit log
A human must be accountable	Named-owner escalation and sign-off checkpoints	Policy gate
Behaviour must not drift silently	Permanent evaluation suite re-run on sampled production traffic	Evaluation loop
Data must stay where it belongs	Residency-constrained deployment; disclosed sub-processors only	Deployment pattern

§05

Tell us which regulator reads your audit trail.

Sector constraints are where our work starts, not where it stalls. Bring your obligations; we will bring the reference architecture.

Pick the claim you'd want proven · See the platform →

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