Tracing One Prompt End to End: A Data-Flow Checklist Before You Trust a Residency Claim

Why a residency claim needs a paper trail

"Your data stays in region X" is an architectural statement, not a promise. Between your client and the model that generates the answer there are usually several hops, and each one can store, copy, or forward payloads. The only way to trust a residency claim is to trace a single request through every hop and check the evidence at each one.

This checklist is vendor-neutral. It works for any aggregator, including one that accepts USDC top-ups and fronts multiple model vendors behind a single key.

Step 0: Define the claim precisely

Before auditing, write down what you think is being claimed. Ambiguity hides problems.

• Which data is in scope — prompt text, attachments, response text, metadata, or all of them?
• Residency of storage, processing, or both? They can differ.
• Is the claim about the aggregator's own infrastructure, the model vendor's, or the whole path?
• What is explicitly out of scope (e.g., abuse-monitoring logs, billing records)?

If the vendor's wording cannot answer these four questions, that is your first finding.

Step 1: Map the hops

Sketch the path a prompt takes. A typical aggregator request looks like this:

1. Client → aggregator ingress. Your HTTPS request terminates at a load balancer or API gateway.
2. Ingress → application layer. Auth, quota checks, request parsing, sometimes prompt rewriting or a moderation pass.
3. Application → any cache or queue. Response caches, deduplication layers, async job queues, retry buffers.
4. Application → vendor egress. The aggregator calls the upstream model vendor's API from its own outbound infrastructure.
5. Vendor region. The vendor schedules the inference in a specific region or set of regions.
6. Response path back. Vendor → aggregator → client, potentially through the same caches and logs in reverse.

Every arrow is a place where data can be persisted. Number them and keep the diagram; you will annotate it with evidence.

Step 2: Pin down ingress and egress locations

Ask for the actual network facts, not marketing language.

• Which cloud provider and region host the ingress endpoints? Is there any anycast or global edge that terminates TLS elsewhere?
• From which regions does the aggregator make outbound calls to each vendor? Egress region often determines the vendor region you land in.
• Are there failover paths? A request that normally goes to one region may silently retry in another when the primary is degraded.

A residency claim that ignores failover is incomplete. Ask explicitly: "If the primary region is unavailable, where does my request go, and is that disclosed?"

Step 3: Audit the cache and queue layer

Caches are the most common gap between a stated policy and real behavior.

• Is there a response cache? If so, is it keyed per tenant, and is prompt text stored as part of the key or value?
• Are cached entries encrypted at rest, and what is the retention window?
• Do async queues or retry buffers persist the full request body, and for how long?
• Are logs of request/response bodies captured for debugging? Where are those logs stored, and who can read them?

Request the retention schedule for each of these stores. "We don't cache" is a testable claim — ask how they would prove it.

Step 4: Resolve the vendor question

An aggregator that fronts many models cannot make a single residency statement that covers all of them. The vendor and the vendor's serving region are part of your data path.

• For each model family, which upstream vendor is called, and in which region does that vendor process requests?
• Does the aggregator pin a specific vendor region, or let the vendor route?
• Are requests to different model families sent to different vendors with different policies?
• What does the vendor's own data-processing addendum say about retention and training use?

If the answer is "it depends on the model," that is acceptable — but the mapping must be documented per model, not averaged into one sentence.

Step 5: Check what is stored after the response

Residency is not only about processing. Ask what remains once the answer is returned.

• Prompt and response bodies: retained, truncated, hashed, or discarded?
• Billing and usage records: what identifiers are kept, and for how long?
• Abuse and fraud monitoring: does it inspect payloads, and where does that data live?
• Deletion: can you request erasure, and does it propagate to caches, logs, and the vendor?

For a pay-as-you-go service funded by crypto top-ups, billing records are unavoidable, but they should contain identifiers rather than prompt content. Confirm which is true.

Step 6: Run a live trace on one prompt

Now test the map against reality with a single, non-sensitive prompt.

• Send it through the API and capture timing, response headers, and any request IDs returned.
• Ask the provider to correlate that request ID with their internal routing logs and tell you which ingress region and which vendor region handled it.
• Compare that answer to your Step 1 diagram. Discrepancies are the findings that matter.
• Repeat with a deliberately failing request (e.g., an invalid parameter) to observe error paths — these often reveal regions and services not mentioned in the happy-path docs.

A provider that cannot correlate a request ID to a routing decision is telling you something important about its observability.

Step 7: Turn answers into a scorecard

Record each hop with three fields: what is claimed, what evidence was provided, and what remains unverified. Keep it short — one row per hop.

• Claims backed by documentation or a live trace: green.
• Claims backed only by a support reply: amber.
• Hops with no answer, or answers that contradict the diagram: red.

You do not need every row green to use a provider. You need to know which rows are red before you send data that matters.

Red flags worth escalating

• Residency described only in marketing pages, with no region names anywhere in the technical docs.
• No request IDs or correlation mechanism for support investigations.
• "We don't log prompts" stated alongside a debugging feature that clearly requires prompt logs.
• A single residency statement covering all models, with no per-vendor breakdown.
• No documented failover behavior.

A note on payment and identity

Payment method and data residency are separate questions. A service that accepts USDC on Base without KYC is making a statement about onboarding and billing, not about where inference runs. Audit the two independently: confirm how top-ups and credits work, then trace the prompt path on its own terms. Neither answers the other.

Summary checklist

• Define the claim: which data, which operation, whose infrastructure.
• Draw the hop diagram: ingress, application, cache/queue, egress, vendor region, return path.
• Get region names for ingress and egress, plus failover behavior.
• Enumerate every cache, queue, and log store with retention windows.
• Map each model family to its upstream vendor and vendor region.
• Confirm post-response storage and deletion propagation.
• Run one live prompt and correlate its request ID to a routing decision.
• Score each hop as green, amber, or red, and revisit when the provider changes architecture.