> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firedog.finance/llms.txt
> Use this file to discover all available pages before exploring further.
# Data processing & residency
> What Firedog processes, where it flows, where it is stored, for how long, and how it is deleted — the basis for your DPA and Article 30 record.
This page describes Firedog's data-processing model: which data is handled, where it travels, where it lives, how long it is kept, and how it is deleted. It is the working basis for a GDPR Article 30 record and a client data-processing agreement.
**One decision governs everything.** Content — prompts, retrieved documents, model responses — never leaves the client's perimeter. Only aggregated metadata reaches Firedog. The analysis that needs to read content runs in place, inside the client's VPC; only the resulting figures are sent. We bring the compute to the data, not the data to the compute.
## Roles under GDPR
**Controller.** Holds the content and decides the purposes of processing.
**Processor**, on usage metadata only.
The **client's** processors — content reaches them from the client, never via Firedog.
## The data, in two categories
| | Category 1 — Metadata | Category 2 — Content |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| **Examples** | Model, tokens (input / output / cache), cost, latency, timestamp, request id, trace context, decomposition counters (retrieved vs. used tokens, static-prefix size), the attribution map (key/service → team/component), and the collaborator identifier | Prompt text, retrieved documents (RAG), model responses |
| **Leaves the perimeter?** | Yes — aggregated, to Firedog | **No — never** |
| **Sensitivity** | Low to moderate | High (the fund's business data) |
| **Where it lives** | Firedog control plane (EU) | The client's VPC only |
No field in the metadata carries prompt, document or response text. Token figures are **counts**, not content. Content is read in place to produce the counters; the counters are what leave.
## Where the personal data actually is
* **Content is confidential business data, not personal data** — and it does not leave the client.
* **Personal data, in the GDPR sense, is limited to the collaborator identifier** attached to their usage. The data subjects are the client's own staff.
* **Recommendation:** pseudonymise that identifier at the collector — Firedog emits it as a salted hash, never the raw identity — which further shrinks the GDPR surface. See [Sensitivity profiles](/sensitivity-profiles).
There is no individual profiling and no HR-evaluation purpose. See [Purposes](#purposes).
## Purposes
Turn one opaque provider invoice into spend filed to the desk and workflow that caused it.
Surface the re-read tax and cheaper-model opportunities, measured — not guessed.
Tie the attributed spend back to the provider's aggregate totals.
No individual profiling. No HR or performance-evaluation purpose.
## The flows
Metadata plus local access to content. Transient, inside the client's network.
Aggregated metadata only. Stored: raw for 30–90 days, aggregates in long retention.
Content is read in place; only the counters leave. Content is not stored by Firedog.
Aggregate totals, reconciled against the attributed spend.
## Retention
| Data | Retention |
| ---------------------- | ----------------------------------------------------------------------------------- |
| Raw metadata | 30–90 days |
| Aggregates | Long retention *\[Placeholder — to fix, e.g. 24–36 months]* |
| Content | **Not retained by Firedog** — held in the client's VPC on the client's own schedule |
| Access / deletion logs | *\[Placeholder — to fix, e.g. 12 months]* |
## Deletion
Deletion is triggered by end of contract, a GDPR request, or retention expiry. It is propagated to subprocessors (hosting, backups), with a deletion log kept as proof.
## Data residency
Hosting is **EU only**. The Firedog platform — the metadata store and the web app — runs on Railway in region **EU West (Amsterdam, Netherlands)**, i.e. GCP `europe-west4`. This is aligned with a finance client base.
**Transfer nuance.** The underlying infrastructure is Google Cloud, whose parent is US-based. Even in an EU region, the transfer mechanism is covered by Railway's DPA and Google's Data Privacy Framework certification and standard contractual clauses.
## Subprocessors
The processing chain is **Firedog → Railway (hosting) → Google Cloud (infrastructure)**. Railway hosts the Firedog platform — the control plane: the ingest API, the metadata database, and the web app. In the in-VPC model, client content does **not** reside on Railway; it stays in the client's VPC.
| Subprocessor | Service | Location | Compliance |
| -------------------------- | ------------------------------------ | ----------------------------- | -------------------------------------- |
| Railway | Platform hosting + metadata database | EU West — Amsterdam (NL) | SOC 2 Type II + SOC 3; GDPR DPA |
| Google Cloud (via Railway) | Underlying infrastructure | `europe-west4` (NL) | SOC 2 / ISO 27001; DPF-certified + SCC |
| *\[Observability / logs]* | Technical monitoring | *\[Placeholder — to specify]* | *\[Placeholder — to verify]* |
## Completeness
Coverage is not asserted — it is measured. Firedog reconciles the metadata it received against the provider's own invoice, so any gap between the two is surfaced rather than hidden. The reconciled difference is shown, not assumed away.
## Internal access
*\[Placeholder — to formalise: who at Firedog can see which data — role-based access control, least privilege, per-client isolation, and access logging.]*
## What this enables
An Article 30 record, a DPIA where required (likely a light one, given content never leaves the client), a client DPA, a privacy policy, and a 72-hour breach-notification procedure.
The split-plane threat model, and the CallRecord vs. CallMetadata boundary in detail.