Privacy

Finest is operated by PM Frontier LLC, a Wyoming limited liability company. For your account, this website and our own operations, PM Frontier LLC is the controller. For Customer Content that passes through the Door 1 gateway, you are the controller and we are a processor acting on your instructions; the data processing addendum governs that relationship and is the operative document if the two ever disagree about it.

One cookie, and only if you allow it. Until you answer the banner, and for as long as you decline, nothing is written to your device at all: analytics still counts the page, cookielessly, because a page being read is a fact about us and not an identifier about you. Allowing it stores one first-party cookie so a visit today and a signup next week are one person rather than two. There is no cross-site tracking pixel, no advertising tag and no social widget, and the Content-Security-Policy this site serves would block one if somebody added it.

Product analytics run through PostHog, proxied through this domain. Before you answer the banner, and if you decline, it runs in cookieless mode: no identifier is stored on your device and PostHog derives a rotating pseudonymous hash server-side instead. If you allow it, one first-party cookie holds that identifier so it lasts across visits. Either way we record page paths and never query strings, which on this site carry sign-in return targets, along with which sections of a page were reached, how far a reader scrolled, and web vitals. We do not record form contents, and session replay is switched off.

The console is measured too, under a narrower rule, because its screens show your workspace name, your job names and your money. What leaves the console is a screen name from a closed list published in our source, never a URL and never an identifier: a route id, a receipt id and a key id cannot be expressed in the format at all. We record which state a screen rendered, so we can see how often you meet a failure; whether a step such as issuing a key or adding credit succeeded; and amounts only as coarse buckets, never a figure. Workspaces are counted under a per-workspace HMAC derived on our servers, unrelated to every other identifier we hold, so the analytics account cannot be joined to anything else. Nothing derived from a prompt or a completion is sent, and no model trains on any of it.

If your browser sends Global Privacy Control or Do Not Track, analytics does not start at all. Nothing is collected and nothing is queued for later. We do not sell personal information, and we do not share it for cross-context behavioural advertising, so there is no opt-out to give you for something we do not do.

We store your email address, the workspace you belong to, your role in it, and the authentication records needed to keep you signed in. That is the whole set. We do not ask for a phone number, a job title or a company size, because we would have no use for them. Production has no password: sign-in is a one-time link, so there is no password of yours for us to hold or lose.

If you buy credits, Stripe collects and holds the payment details. We receive the billing contact, the last four digits and brand of the instrument, and the outcome. We never receive or store a card number.

Door 1 is a gateway: you point a client at us, and your prompts and completions pass through our infrastructure. This is the door where a privacy promise actually costs something, so here is precisely what happens to that content.

Request and response bodies are used in memory to serve the request, to run any validator that decides whether to escalate, and to compute the receipt. Then they are gone. No table in this system has a column for gateway prompt or completion content, and there is no encrypted content store to keep it in, so this is a property of the schema rather than a retention setting somebody could change. The receipt that persists is metadata: the requested and served model, task class, decision, evidence label, token counts, both prices, savings, fee and outcome.

We do not train models on your content, we do not sell it, and we do not share it with anyone other than the model provider you addressed and the sub-processors we publish. Section 8 of the terms states that as a contractual limit on the licence you give us, not just as a practice.

Verification runs against a frozen corpus. In this release only public-reference, synthetic and CI corpora can be admitted; content-bearing uploaded, staging and production corpora are refused, and no configuration value enables them. That refusal is the protection for content in verification today. It is not an enclave and we will not describe it as one.

Our services write operational logs to AWS CloudWatch: request identifiers, route and status, timings, and the IP address a request arrived from, which is what rate limiting is measured on. Logs are not a copy of your traffic, and provider credentials and key material are excluded from them by construction.

Errors are reported to Sentry, and the event is rebuilt from an allowlist before it leaves the process rather than having known-dangerous fields deleted from it. Request bodies, local variables, breadcrumbs, cookies and authorization headers are not copied into the event at all. They are absent by construction, not by vigilance, which is what makes the promise survive an SDK upgrade.

Transactional email, which means sign-in links and workspace notifications, is sent through Resend. Message bodies are built from codes and identifiers and never contain prompt or completion content.

We process account data to give you an account and to let you sign in; Operational Metadata to run the service, produce evidence and receipts, compute what is owed and detect abuse; payment data to take payment; and log data to keep the service up and secure. We use aggregate, de-identified statistics about model performance to improve the product, and those never contain your content and are never attributable to you.

Where UK or EU data protection law applies, our legal bases are performance of a contract for account and service data, legitimate interests for security, abuse prevention and service improvement, consent for optional analytics where consent is required, and compliance with a legal obligation where one applies. You can object to processing based on legitimate interests, and we will stop unless we have grounds that override your objection.

We do not use your personal data for automated decisions that have legal or similarly significant effects on you. The routing decisions this product makes are about model configurations, not about people.

The third parties we use are named individually, with what each one touches, on the sub-processor page, and that page is updated before a new one is switched on. On Door 1, the model provider you address sees the request you addressed to it, and the providers available to you are listed on the same page with the region each publishes.

We disclose data to a regulator, court or law enforcement only where we are legally required to, and we will tell you unless we are prohibited from telling you. If Finest is involved in a merger, acquisition or sale of assets, data may transfer as part of it, subject to this policy or a successor no less protective; we will give notice before it becomes subject to a different policy.

The control plane, the database, backups and the gateway run in AWS US East (N. Virginia), us-east-1. There is no per-workspace region selection: we are one region today, and saying otherwise would be a residency commitment we could not keep. Sub-processors are in the United States unless the sub-processor page says otherwise.

If you are in the UK, the EEA or Switzerland, that means your data is transferred to the United States. Those transfers rely on the European Commission’s Standard Contractual Clauses and the UK International Data Transfer Addendum, which are incorporated by the data processing addendum. On Door 1, sending content to a provider outside the United States is a routing choice you make and control, and you decide whether it is lawful for your data.

Account records are kept while your workspace exists. Receipts, evidence records, the cost ledger and audit events are kept while your workspace exists and for as long afterwards as we need them to substantiate an amount that was billed or could be disputed, because a bill you cannot audit is not a bill. Several of those journals are append-only by database constraint, so a correction is written as a new record rather than an edit to an old one. Operational logs and error events roll off on their own schedule, currently 30 days or less. Aggregate, de-identified statistics are kept indefinitely and cannot be traced back to you.

You can export everything at any time and verify that the export stands on its own: that is what /v1/eject and its independence report are for.

Deletion is honest about being partly manual. Ask us to delete a workspace and we will erase its records within 30 days, through a controlled path that is separately privileged in the database precisely because erasing evidence should not be something ordinary application code can do. The audited self-service version of that job is not built yet, which is why the request goes to a person. Encrypted database backups continue to contain deleted records until they age out of the 14-day point-in-time-recovery window; we do not surgically edit backups, and a policy that claimed otherwise would be describing something nobody does.

If you are in the UK, the EEA, Switzerland, or a US state with a comparable statute, you have the right to access, correct, export and delete your personal data, to object to or restrict processing, to withdraw consent, and not to be discriminated against for exercising any of them. Because the personal data we hold about an individual is essentially an email address and a role, most of these resolve to the same short action, and you can perform much of it yourself from the console.

For anything the console cannot do, write to [email protected]. We answer within 30 days, and if we need longer we will say so and why. We do not charge for a request and we will not ask you for more identifying information than is needed to be sure the request is yours. You may use an authorised agent. If you are unhappy with the outcome you can complain to your supervisory authority, and in the UK that is the Information Commissioner’s Office; we would rather you came to us first.

Where we act as a processor for content you sent through Door 1, a request from one of your own users should come to you, and we will help you answer it under the DPA.

The service is for organisational use by adults. It is not directed at children, we do not knowingly collect data from anyone under 18, and you must not send us data about children through the gateway. If you believe a child’s data has reached us, tell us and we will delete it.

Tenant isolation is enforced in the database rather than in application code, policy signing keys are held in AWS KMS and are not extractable, provider credentials are referenced by pointer rather than value, and identifiers that would tie a stored record to an individual are pseudonymized before storage. What we have, what we do not have, and how to report a vulnerability are on the security page, including the parts that are not built.

Material changes will be dated at the top of this page and announced in the changelog, and where the change affects how we handle data we already hold, we will notify workspace owners before it takes effect. We will not quietly widen what we collect and re-date the page.