The labs ship models. We ship the harness
Value in production AI accrues to the layer around the model: what an agent remembers, what it may touch, what it must never do, and what an auditor sees afterwards. ORCA is that layer. We run our own business on it.
Built because we needed it.
ORCA exists because running AI systems responsibly involves a set of problems that are tedious to solve and expensive to get wrong: knowing where an answer came from, keeping personal data out of places it should never reach, controlling who can write to shared knowledge, and being able to show an auditor the trail afterwards.
We built it for our own practice first. We still run our own business on it, which is why the security posture we present is measured from a live system rather than described in a document.
| Provenance | Where an answer came from, and which sources contributed to it |
| Personal data | Detected and replaced at the boundary, ahead of storage and inference |
| Access control | Role-gated reads and writes, enforced server side rather than in the client |
| Interface | An MCP server. Any surface that speaks the Model Context Protocol, Claude included, connects to the same six role-gated tools; authorisation is enforced at the gateway, never in the client. |
| Approval flow | Nothing reaches a shared store without a named approver accepting it |
| Audit | A durable record of what was asked, answered, stored and approved |
What the boundary actually does
Type anything into the left pane, including things you would never normally paste. The right pane shows what a model or a store would receive instead. Nothing leaves this page.
A demonstration of the principle, not the production classifier. The real gate runs server side, is not bypassable by a caller, and holds the mapping in an encrypted store so the original can be recovered by those entitled to see it.
How it is offered
Three depths. The difference is who operates it, not what it does.
You run it
Deployed into your tenant, operated by your team. We install, configure and train, then step back.
We run it, in your tenant
Your infrastructure and your data boundary, our operational responsibility, against agreed service levels.
Fully managed
We host and operate it end to end. The heaviest lift for us, the lightest for you.
Whichever depth you pick, the data, the configuration and the audit record are yours, and the exit procedure is documented from the first week.
Where your data lives, and what can touch it
One boundary decides everything: personal data is detected and replaced before anything leaves for storage or inference. The gate is structural. It cannot be skipped by a caller in a hurry.
Everything at rest lives in your own tenant, personal-data originals vaulted and encrypted. The only thing that ever crosses the boundary is tokenised, PII-safe content, and it crosses only for inference.
The questions a review asks
Short answers here. Longer ones on request, with the evidence attached.
Where is our data?
At rest in your own tenant, Azure UK South, including the encrypted vault that holds personal-data originals. Only tokenised, PII-safe content leaves, and only to Azure AI Foundry in Sweden Central for inference. Nowhere else, and never used to improve anything outside your engagement.
What terms govern processing?
UK GDPR Article 28 processing terms, available on request. A data protection impact assessment is completed and maintained for our own processing.
Are you certified?
We operate an information security management system aligned to ISO/IEC 27001 and Cyber Essentials, internally audited on a managed GRC platform, and we are working towards certification. No certificate is held today; when one is, it will be published here. We use the framework's words precisely: aligned is not certified, and we will never let you infer otherwise.
What happens if you are unavailable?
Every engagement documents what you hold, where it lives, and how to continue without us. Exit is written before the work starts, not negotiated at the end.
Who owns the work?
You do. Code, models, evaluation sets, runbooks and documentation, throughout and afterwards.
Subprocessors
Who processes what, for what purpose, and where. Reviewed annually and whenever a supplier relationship changes.
| Subprocessor | Purpose | Data handled | Location |
|---|---|---|---|
| Microsoft Azure | Infrastructure and platform hosting: compute, storage, database, key management | All service data at rest | UK South |
| Microsoft Azure AI Foundry | Model inference and embeddings | Tokenised prompt content only. Personal data is replaced before it reaches this boundary. | Sweden Central, EEA |
| Cloudflare | Edge routing, DNS, and delivery of this website | Request metadata. Contact form submissions in transit. | Global edge |
| GitHub | Source control and continuous integration | Source code. No client data. | Microsoft, covered by OST |
The vector database is software we run, not a service we buy
Self-hosted inside our own Azure subscription. No data reaches the vendor, so they are not a processor. The same position a client holds when running our platform in their own tenant.
Model providers are reached through Microsoft, not directly
Inference runs through Azure AI Foundry, so the model provider sits in Microsoft's subprocessor chain under the Microsoft Online Services Terms. We hold no direct data relationship with any model provider for service data.
- OpenAI
- Anthropic
- Google Gemini
- Meta
- Mistral AI
- xAI
- DeepSeek
- Cohere
- Qwen
- Ollama
- Hugging Face
- NVIDIA
the model layer we work across · routing, evaluation and fallback Marks are the property of their owners, shown to describe our own stack. No endorsement, sponsorship or partnership implied.
Tell us what you are accountable for.
The useful first conversation is usually about the thing that worries you, not about our capabilities. If it turns out we are the wrong firm for it, we will say so.
One reply from a person who has read what you sent.