UK-sovereign inference with receipts you can check
Your model serves from UK data centres under a UK-only contract. Every request returns a signed receipt — and this page tells you plainly what’s live, what’s manual, and what’s still roadmap.
The residency question is now a procurement question.
For UK public sector, NHS-adjacent health, and regulated finance buyers, “where does the data go?” stopped being a security-questionnaire footnote. It gets asked before the pilot, not after.
The question moved up the stack
Deals that used to turn on latency and price now turn on residency. The person who decides isn’t always the person who codes — and they don’t accept adjectives.
A region label isn’t evidence
A dropdown that says London tells your DPO where a server probably is. What they need to file is who processes what, where, under which contract — with something they can check themselves.
Your DPO needs inputs, not assurances
The DPIA is signed by your DPO, not by us — no vendor can promise approval. What we provide is the processor-side inputs: data-flow diagram, subprocessor list, residency attestation, DSPT mapping.
Live, manual, or roadmap — nothing rounded up.
An honest setup has real caveats, and we’d rather show them than hide them. Every row is the claim at full strength.
| Capability | Status | Notes |
|---|---|---|
| UK-pinned serving | LIVE | Serves from LON1, London. UK-only processing is written into the contract — not set in a region dropdown you have to trust was configured correctly. |
| Signed receipts | LIVE | An ed25519-signed record per request: model, content hash, timestamp, data centre, GPU. Retained for the life of your contract plus 6 years. |
| Independent verification | LIVE | Each response returns its own salt — recompute the content hash and check the signature against our published keys and test vectors, without trusting us. |
| Single-tenant isolation | LIVE | One customer per dedicated GPU VM. Your model never shares a card with anyone else’s traffic. |
| Residency evidence pack | MANUAL | Data-flow diagram, subprocessor list, residency attestation, NHS DSPT mapping. Hand-assembled for each pilot today — we’d rather tell you that than pretend it’s a button. |
| Second-supplier failover | STANDBY | A second UK supplier is on standby with a documented failover procedure. Dual UK supplier accounts; failover today is manual, and documented as such. |
| Certifications | ROADMAP | Cyber Essentials Plus underway; ISO 27001 and NHS DSPT on the published roadmap. We name what we hold — and we hold none of these yet. |
| Hardware attestation | ROADMAP | Residency today is contractual and attested by signed platform logs. TEE attestation — the silicon proving what ran where — is an active R&D line, not a shipping feature. |
We run the metal — and sign for what it does.
FOHS is not a reseller wrapping someone else’s API. We operate the serving stack ourselves, on dedicated UK GPUs — which is exactly why we can sign for what happens on it.
No prompt retention
Request and response bodies are not persisted by default. They never appear in our logs or storage — there is no transcript of your traffic sitting on a disk.
Retention, numbered
What we do log: timestamps, token counts, latency, receipt hashes. Committed retention: 30 days. Receipts outlive the logs on purpose — life of contract plus 6 years.
Disclosed, end to end
All logs and the weight cache are UK-resident, and every system that touches them is named in the subprocessor list — including AWS KMS in eu-west-2 (London), which sees only salted content hashes, never text.
Run the check yourself.
The receipt is the product. Every response returns its per-request salt, so your DPO recomputes the content hash and checks the signature against our published keys — from the CLI or at fohs.ai/verify. No account, no asking us.
About the public verify page$ fohs deploy acme-triage-v3 ✓ endpoint live · https://api.fohs.ai/v1 · LON1 $ curl https://api.fohs.ai/v1/chat/completions … → response includes "fohs_receipt": "req_8f3a…c21e" $ fohs verify req_8f3a…c21e ✓ signature valid · ed25519 model acme-triage-v3 content hash ✓ recomputed from returned salt data centre LON1 · London, UK gpu H100-80GB timestamp 2026-07-16T14:02:11Z
What a receipt proves — and what it doesn’t.
A receipt is evidence, not magic.
Four things, cryptographically
- This exact request and response pair existed at this timestamp — the hash binds them together.
- FOHS’s key signed the record, naming the data centre and the GPU that served it.
- The signature verifies against published keys — your auditor checks it without asking us.
- Nobody, including us, can alter the pair afterwards without breaking the hash.
And we won’t pretend otherwise
- That the hardware itself attested to the run. The receipt attests to our signed platform logs — hardware attestation is the roadmap row above.
- That no copy of your data exists anywhere. No-retention-by-default is a contractual commitment, not a cryptographic one.
- Anything about the content of your prompt. The receipt carries a salted hash — never the text.
Three steps to a signed-off deployment.
One scoping call
A half-hour call with the founder. You leave with a draft data-flow diagram and a clear read on whether FOHS fits your assessment.
Deploy; receipts accumulate
Your model goes live at api.fohs.ai/v1 from LON1. Every request is signed from day one — the audit trail builds itself while you pilot.
Evidence pack to your DPO
Data-flow diagram, subprocessor list, residency attestation, NHS DSPT mapping — shaped to drop into the DPIA. Your DPO signs; we supply the inputs.
The questions your DPO will ask.
Answers for UK teams evaluating data residency, receipts, and UK-hosted inference with FOHS.
Do you train on our data?
Your weights are used only to serve your endpoint — never shared, never trained on. Prompt and completion bodies are not persisted by default, so there is no stored transcript to train on.
Are you ISO 27001 certified?
Not yet, and we won’t imply otherwise. Cyber Essentials Plus is underway; ISO 27001 and NHS DSPT are on the published roadmap. What we have today is the evidence pack and the receipts — pilots start there while the certifications catch up.
What happens if LON1 fails?
A second UK supplier is on standby with a documented failover procedure. Failover today is manual — we say that plainly rather than promise automated routing we haven’t shipped. Either way, serving stays in the UK.
Can we verify receipts without trusting FOHS?
Yes — that’s the point of the design. Every response returns its per-request salt, so you can recompute the content hash yourself and check the signature against our published keys and test vectors. The public verify page shows signature validity, timestamp, data centre, site, and operator — never model names, never customer metadata.
Do you serve frontier models?
No. FOHS serves the model you bring — fine-tuned or open-weight, from a Hugging Face ID or a direct weight upload. If your workload is a closed frontier model, we’re not your platform. If it’s your own model that has to stay in the UK, we are.
Will you get our DPIA approved?
No vendor can promise that, and you should be wary of any that does. Your DPO signs the DPIA. We supply the processor-side inputs — data-flow diagram, subprocessor list, residency attestation, DSPT mapping — shaped to drop into the assessment.
Is residency proven by hardware?
Not yet — and we’re precise about this. Residency today is contractual, attested by signed platform logs: the receipt proves our systems recorded the run at LON1, and we sign for that record. Hardware attestation via TEEs is an R&D line on the roadmap.
Bring your DPO to the demo.
A half-hour call with the founder: a live deploy, receipt verification end to end, and the evidence pack walked through page by page. Billing is per GPU-minute.