Azimuth Subprocessor Register

Version 1.3 — 4 September 2026 · Owner: Sean Higgins Status: live register. Verified against the running system and each provider's current published terms, EXCEPT where a row says otherwise — three rows below are explicitly marked unverified rather than filled in, and every gap is listed at the end.

This register lists the third parties that receive, process, or store customer data as part of delivering Azimuth. For each: provider, purpose, region, the data classes it receives, and its training and retention position.

Maintenance rule: no new third party enters the request path or receives customer data until it has a row here. Every provider's terms are re-verified quarterly, and on any pricing-tier change, since a tier change can alter data-handling terms.

1. Active subprocessors — platform

Providers that receive, process, or store customer data as part of delivering the product.

Amazon Web Services (AWS)

• Purpose: all hosting — compute, database (PostgreSQL), object storage, secrets management, and transactional email.
• Data classes: all data — account data, customer content, transcripts, prompts, outputs, audit logs, backups.
• Region: United States. No cross-region replication.
• Encryption: database and volume storage encrypted at rest with KMS; object storage with SSE-AES256; TLS in transit.
• Training on customer data: No. AWS is infrastructure, not a model provider, in our usage.
• Assurance: SOC 1/2/3, ISO 27001, FedRAMP-authorized regions.

Anthropic

• Purpose: text generation, analysis, compliance screening, and market research. The primary AI provider.
• Data classes: prompts; business profile; Knowledge Base extracted text; content drafts and generated copy; voice-transcript text during profile extraction.
• Region: United States.
• Training on customer data: No. Commercial Terms of Service §B: "Anthropic may not train models on Customer Content from Services." Same section: "Customer (a) retains all rights to its Inputs, and (b) owns its Outputs."
• Retention: inputs and outputs are deleted from the provider's backend within 30 days. Content flagged by automated trust-and-safety systems may be held up to 2 years; safety classification scores up to 7 years.
• Path: server-side calls direct to the provider API. No middleware, no aggregator, no logging proxy in the data path.
• Notes: calls are on standard commercial API terms. The research feature uses the provider's server-side web search, so a search query derived from the customer's brief leaves the system when it runs — no documents are sent.

fal (Features & Labels, Inc.)

• Purpose: AI model hosting. All video and still-image generation runs through fal's inference queue. fal is our contracting counterparty for rendering — the model operators below are fal's subprocessors, not ours.

• Data classes: render prompt text, plus any Knowledge Base extract selected as visual reference for that prompt. No documents are uploaded, no profile data, no contact data. Generated media is stored on fal's CDN (see retention).

• Region: United States.

• Output ownership: Customer retains it. ToS §6(b): "Customer owns and retains all right, title, and interest in and to the Customer Input."

• Training on customer data: Qualified — read this row rather than summarising it. fal's DPA §1.7.2 limits model improvement to de-identified data: "Company may Process Deidentified Data to improve the Services." Personal data is excluded. Separately, ToS §6(c) reserves "Usage Data" — anonymised and aggregated — to "design, develop, and offer Company products, services, and AI models."

  So the accurate statement is: identifiable customer content is not used to train models, and de-identified or aggregated usage data may inform model development. That is a weaker position than Anthropic's flat contractual bar above, and it is written out rather than rounded up to match it.

• Retention: No default published. fal exposes retention as a per-request control (X-Fal-Object-Lifecycle-Preference), and input uploads and output media are subject to the same control. Azimuth does not currently set that header, so generated media persists on fal's CDN with no expiry we have specified. This is an open item, not a control we operate — see Open items. DPA §1.6 covers deletion of client personal data after termination of the agreement.

• Path: server-side calls from the API to fal's queue. The browser never calls fal, and no proxy or logging layer sits in between.

• fal's own subprocessors: DPA §4.1 incorporates a published list at trust.fal.ai/subprocessors. Not yet retrieved and verified — see Open items.

MiniMax — model operator, reached through fal

• Purpose: text-to-video generation (MiniMax H3). Reached through fal, not directly. Azimuth holds no agreement with MiniMax and sends them nothing directly.

• Data classes: the render prompt, as passed on by fal.

• Training and retention: NOT INDEPENDENTLY VERIFIED. MiniMax's published terms are a framework that defers to product-specific terms we have not been able to retrieve and cite. Because they are fal's subprocessor rather than ours, the obligations binding them flow through fal's agreement with them, which we have no visibility into.

  Asserting a training or retention position here without that citation would be inventing evidence in the document a reviewer relies on most. A customer asking this should be told exactly that, and pointed at fal's DPA §4.1 subprocessor list.

OpenAI — model operator, reached through fal

• Purpose: still-image generation (GPT Image 2). Reached through fal, not directly.
• Data classes: the image prompt, as passed on by fal.
• Training and retention: governed by fal's arrangement with OpenAI, not by any agreement of ours. Not independently verified — same position and same caveat as MiniMax above.

Lightricks (LTX) — REMOVED FROM THE REQUEST PATH

• Status: not a subprocessor. Left the request path on 22 August 2026 when rendering moved to fal. No customer data has reached Lightricks since.
• Kept as a row rather than deleted because the previous version of this register described a direct Lightricks API relationship, with citations to their licence agreement, for thirteen days after it ended. A reviewer comparing versions should see that it was removed deliberately rather than wonder whether it was dropped by accident.

LiveKit

• Purpose: real-time voice transport for the onboarding interview agent.
• Data classes: live audio during the call; transcript in transit. Media is not persisted on LiveKit servers — decrypted in memory for forwarding, then discarded. We store the transcript text; we do not store audio.
• Region: United States.
• Training on customer data: No. LiveKit does not use customer content to train its own models, does not log or retain inference payloads, and deletes session data after 30 days.

Cloudflare

• Purpose: DNS, TLS termination, DDoS absorption, bot filtering, WAF.
• Data classes: all traffic metadata — IP addresses, request headers, URLs. Sees request content in transit at TLS termination.
• Region: global edge.
• Training on customer data: No.

Google Fonts

• Purpose: web font delivery to the browser.
• Data classes: visitor IP address and user agent on page load. No account or content data.
• Region: global.

2. Configured but not enabled

Present in the codebase but not active in production. No customer data reaches them today. Listed so the register stays complete if they are switched on.

3. Business subprocessors — not in the product path

These do not process customer data as part of delivering the platform. They are listed because a thorough reviewer will ask where company communications live.

4. What we do not use

Stated affirmatively, because absence is a selling point with this buyer:

• No analytics, telemetry, or session-replay in the product. No Google Analytics, Segment, PostHog, Mixpanel, Hotjar, or equivalent. Nothing observes how a customer uses the product, and nothing fires on a successful page view. Verified against the frontend bundle.
• Crash reporting is self-hosted, and is the one thing in this list that is not simply absent. The product reports uncaught errors to a GlitchTip instance running on our own AWS infrastructure, alongside the rest of the platform. GlitchTip is Sentry-API compatible, so the open-source Sentry SDK is what talks to it — but no third party receives the data, which is why it does not appear in §1. Session replay, performance tracing and profiling are disabled in code rather than merely unused, and the payload is stripped before it leaves the application: no request bodies, no query-string values, no credentials, no email or IP. A user is identified by id only.
• No advertising or tracking pixels. No advertising identifiers.
• No data broker, enrichment, or audience-profiling service.
• No AI middleware, orchestration SaaS, or prompt-logging proxy. Model calls go server-side direct to the provider.
• No payment processor holding card data on our behalf — when Stripe is enabled, cards go to Stripe directly.
• No offshore or subcontracted support with access to customer content.

5. Change log

Open items — v1.3

Recorded here rather than left as silence. A register that looks complete is more dangerous than one that names its gaps, because the gaps are what a reviewer finds.

1. fal's subprocessor list is not retrieved. DPA §4.1 points at trust.fal.ai/subprocessors. Until it has been read, we cannot tell a customer who sits behind fal beyond the two model operators we know we invoke.
2. MiniMax and OpenAI terms are not independently cited. Both are reached through fal. Closing this needs either their product-specific API terms, or a written statement from fal about what binds its model operators. Until then those rows stay marked unverified.
3. Media retention is unspecified by us. fal publishes no default; retention is a per-request header Azimuth does not set, so generated clips and images persist on fal's CDN indefinitely. This is a control available to us that we have not taken — setting the header would turn this row from a gap into a number.
4. The Privacy Policy is slightly too strong. It states that inputs and outputs are not used by Model Providers to train their models. That is precise for Anthropic and overstated for fal, whose terms permit de-identified and aggregated usage data to inform model development. The policy wording should be narrowed to match the fal row above.

How this register went wrong last time, so it does not repeat. The render provider changed on 22 August and this document was not touched, so it described a direct Lightricks relationship — with contract citations — for thirteen days. The provider is chosen by an environment variable, and nobody thinks of an environment variable as a legal edit.

An automated release check now compares the configured render model against the provider named in the Privacy Policy and refuses a release where the two disagree, so that document can no longer go stale the way this one did. This register is not yet covered by that check. Extending it here is the durable fix: it would turn a thirteen-day gap into a failed release.