Governance

Four layers

1. A dedicated, isolated deployment

Each charity gets a dedicated, isolated deployment that we run - its own Firebase project, Vercel project and Cloud Storage bucket, separate from every other charity's. Persistent data lives in europe-west2 (London) for UK residency. There's no shared SaaS layer; we don't aggregate data across charities; we couldn't accidentally leak your responses to another deployment because we never have them in one place.

When the engagement ends - for any reason - your data and your audit log come with you, exported in full. No lock-in.

2. Audit by design

Every action the system takes lands in an append-only audit log. Every reviewer decision lands in the same log. The log is queryable, exportable, and immutable.

When a trustee asks "how did the system decide this?", the answer is a single audit query. When an auditor asks "show me every decision made in March", same answer. When a charity changes agency three years from now, the new agency inherits the same log - and the conversation about why we did what we did doesn't restart.

3. Multi-role human-in-the-loop, where it counts

For high-stakes work - safeguarding triage, funder-report claims, donor briefings for major supporters - the system flags, the human decides. The HITL chain can be one reviewer or four (drafter → reviewer → approver → director). Corrections thread forward; rejections abandon the chain. Every step is attributed.

For low-stakes work - typing up a donor enquiry, summarising a session note - HITL can be lighter. We design the gates per Loop based on what would happen if the system was wrong.

4. Governance generated from the same source

The DPIA, the trustee briefing, and the operational documentation are generated from the same Loop definition that the runtime executes. When the Loop changes, the documentation changes with it. Your compliance evidence isn't a separate Word document drifting out of date; it's a query against the system's own definition.

At a glance - what each stakeholder asks, what you show them

Who	What they ask	What you show them
Trustees	"Can we defend this to the regulator?"	The DPIA, the trustee briefing, the audit log of every action since launch
Data Protection lead	"Where does data go, what gets logged, who has access?"	Architecture diagram, audit log query, IAM roles, named sub-processors
Safeguarding lead	"Will the system make a wrong call?"	The eval against the gold-standard subset, the HITL chain that catches every action before it leaves the building
Funder	"How do you know this report is accurate?"	The claim-source chain - every material number in the report linked to its data row
Finance lead	"What's the rolling cost?"	The token-usage report and the maintenance contract - no per-action billing
Staff using it	"What changes about my day?"	The review surface - they see what the system did, accept or correct, sign off

Data residency

Layer	Where	What it does
App hosting (Vercel)	fra1 (Frankfurt) or dub1 (Dublin)	UI rendering, API orchestration, request routing. Transient processing only - no persistent storage.
Workers + storage (Google Cloud)	europe-west2 (London)	The agent runtime, PII handling, all audit log writes, all binary storage. UK residency, persistent.
Model provider (Anthropic / OpenAI)	EU + non-training enforced	LLM inference. No training on tenant data - hardcoded in the model client wrapper.

PII redaction runs in the GCP worker tier before any LLM call. Vercel never sees a redacted PII payload because the redaction step lives on the worker side.

The simplest mental model: Vercel is the consultant in the meeting room; GCP is the locked filing cabinet. The consultant routes the conversation; the cabinet holds the paper.

Certifications

Make Sense Of It holds Cyber Essentials certification.