Fronset — Privacy Policy

KAPUA Labs LLC, doing business as Fronset 30 N Gould St Ste R, Sheridan, WY 82801, United States

This policy explains what the Fronset service stores, where, for how long, who else sees it, and what a deletion request can and cannot reach. It is written to be checkable. Where the honest answer is uncomfortable — §5 in particular — it is stated plainly rather than softened.

Every factual statement below describes the service as built on 2026-11-05, not as planned.

1. Scope

This policy covers the personal data KAPUA Labs LLC handles for Fronset:

• the Fronset inference API service: the OpenAI-compatible gateway, its management console, and the evaluation and benchmark machinery behind it;
• the public Fronset Benchmark site and its journal (published until September 2026 as llm-bench), including the journal’s email list;
• the waitlist, and sign-up and onboarding;
• our outreach to prospective customers and the trials we run for them (§4.8);
• our community activity on social media: finding public posts about language models and benchmarks, replying to some of them, and measuring clicks on the links we post (§4.8);
• our own social media pages.

2. Who we are

3. Our two roles

The service handles two materially different kinds of data, and our role differs between them.

If your personal data reached us inside a customer’s prompt and you want to exercise a right, the customer is the controller for its use of the service, and we will pass your request to it and help it answer. For the two own-purpose uses in the second row we are the controller: write to us and we will answer you ourselves (§8.4). Note the practical limit: prompt content is unstructured and we apply no schema to it, so we cannot search a customer’s account for the records relating to a particular individual. Where we cannot identify you in the data, we will tell you so (GDPR Article 11(2)).

We do not require, expect or ask for personal data in prompt content, and we have no means of detecting it. Terms of Service §4 prohibits any personal data on the free tier, personal data in a Template on any tier, and — on any tier, absent a signed amendment — HIPAA-regulated health information, PCI cardholder data, GLBA-regulated information, government identification numbers, biometric identifiers, and the personal data of children under 13.

3A. Why we use personal data, and on what legal basis

Where we rely on consent you may withdraw it at any time, as easily as you gave it. Withdrawing does not make earlier processing unlawful.

3B. The legitimate interests we rely on

Where the table in §3A gives basis (f), the interest is the one named in the row. We have weighed each against your interests and rights and written the assessment down; you can ask us for it. The ones you are most likely to ask about:

• Outreach. We contact people at businesses that may need a model-routing service, using their work address and public information about their work. Every message says who we are, links this policy and tells you how to say no. If you say no, we keep only what we need to make sure we never contact you again.
• Community activity. We read public posts about language models, reply to some of them, and keep a short record of who we have talked to so we do not repeat ourselves or reply to someone who asked us not to. We do not build a profile of you beyond that record.
• Our own uses of customer content. On the free tier, prompt text is kept and re-sent to newly introduced models so we can measure them, and on free and shared_anon template text is compared with our library. Our terms prohibit personal data in both. If personal data reaches us there anyway, we use it only for those purposes, keep it only as long as §6 says, and delete it on request.

You have the right to object to any processing based on legitimate interests (§8.4). You may object to direct marketing at any time, without giving a reason, and we will stop.

3C. Where the data comes from, what you must give us, and automated decisions

Sources. Most data comes from you. We receive data from others in these cases: from Stripe, about payments and bank transfers; from your organisation, when a colleague invites you; from public sources (company websites, professional profiles, public posts and public code repositories) when we research a prospective customer; from social media platforms and a third-party search service for X, for public posts we read; and from TinyURL, for clicks on our links.

What you must give us. To open an account we need an email address, and to buy credit we need what Stripe asks for. Without them we cannot provide the service. Nothing else is required.

Automated decisions. We make no decision about you based solely on automated processing that has legal or similarly significant effects on you. Our routing and evaluation decide about models, not people. In our community activity, software sorts public posts to suggest which ones we might reply to.

4. What the service stores

Everything below is a real store in the running system.

4.1 Account and identity

4.2 Customer provider credentials

The service supports two access modes, and this section is about the first. In bring-your-own-key mode a customer supplies their own API key for a model provider and we call that provider as them. In operator-supplied mode we supply the model access on our own provider credentials and bill the customer for the usage — it is the mode the service, the portal and the documentation call managed; the two names describe one arrangement, and this policy uses “operator-supplied” throughout. §7.2 sets out what that changes, and the bullet at the end of this list explains why it is not a fallback.

• Stored under envelope encryption: a fresh 256-bit data key per credential, AES-256-GCM over the secret, and the data key wrapped by that account’s own key-encryption key in Azure Key Vault using RSA-OAEP-256. Ciphertext and wrapped data key live in our database; the key-encryption key never leaves Key Vault.
• Plaintext exists only in worker memory, cached for a configurable period, currently about five minutes (at most 330 seconds), which is also the bound on how long a revocation at the provider takes to take effect in a warm worker.
• Decryption fails closed: a Key Vault outage or a failed unwrap raises an error. It never falls back to a stored or operator value.
• We store the last four characters for display only.
• Every materialization of plaintext writes an append-only credential-access record (purpose, provider, capability — never key material).
• A customer account never falls back to our provider keys. Where a capability is served in the operator-supplied access mode, our keys are used by design and disclosed on the capability (§7.2) — not as a fallback when the customer’s own credential is missing, which always fails the call instead.
• Where the service accepts a key supplied on a per-request header rather than from the vault, that key is used for that request only and is never persisted.

4.3 Call content

Every API call writes one append-only call record. What that record holds depends on the account’s tier.

Prompt content. In an OpenAI-compatible request, the record’s prompt-variable field holds the messages for a capability that takes free text, and the request’s variables for any other capability — so that field is the customer’s prompt text. Whether it is written at all is decided at a single write chokepoint:

The gate fails closed: an unknown, missing or unreadable tier is treated as private, the most restrictive setting. It governs every write path — synchronous calls, batch enrolment, image calls, judge calls, fan-out sibling records and internal repair calls — because there is exactly one call-record creation site.

What “not written” does and does not mean. It means the prompt is not persisted on the call record. It does not mean the prompt never exists in our systems: it is necessarily present in worker memory while your call is being served, including when we retry or fail over to a second model within the same request. And for batched calls it is persisted, on every tier, for the operational window — see Batch working copies below. That is the one place this guarantee is qualified.

Model output. The parsed output — the validated result on success, or the raw response on a parse failure — is written on every tier, including private, because the delivery paths rebuild your result from it. How long it then lives depends on the tier: on shared_anon and private it is deleted once delivered and evaluated. See §5.

Everything else on the record is metadata rather than content: capability, model, provider, token counts, latency, cost, error category and message, service tier, and a pointer to the exact prompt-template snapshot used.

Batch working copies. A batched call cannot be served without keeping its rendered request: the provider submission reads it back, and a retry or a resubmission needs it again. So for batch traffic, on every tier including private, the rendered messages are held on the call record’s operational metadata for the operational window. They are stripped when the batch finalizes, and again by a daily sweep that catches anything left behind and strips any record still in flight after 72 hours. A batch also carries a hard 24-hour expiry backstop. In practice the window is hours to a couple of days.

4.4 Batch API files

A batch itself expires after a hard 24-hour backstop.

4.5 Webhooks

• A customer registers a destination URL, validated at creation as HTTPS-only and public-IP-resolving, plus a signing secret shown exactly once and stored in the vault; the endpoint row holds a pointer, never the secret.
• Delivery records are deliberately content-free — the payload is rebuilt from the call record at send time. This is precisely why §5’s output retention exists.
• Undelivered records dead-letter after 24 hours.

4.6 Billing

• The service is prepaid: a customer buys credit and usage draws it down. Metering, the credit balance and invoicing run through Metronome (§7.3); the card is held by Stripe, and so is the bank account a customer can pay credit into by transfer, where that is offered.
• We store Stripe and Metronome customer identifiers, subscription identifiers and plan state. A full card number, card security code or bank account number never reaches our systems. A card is entered in a Stripe-hosted form. Stripe’s record of it, which we receive and keep, includes the card’s brand, last four digits and expiry date and any billing name, email and address entered with it.
• For a credit purchase by bank transfer, Stripe tells us the sender’s name as the sending bank reports it, the network (ACH or wire), the amount, the date and the reference the sender attached. We keep them with the purchase they paid for. We use them to match the transfer to the account, to hold a transfer sent from an account in another name until the customer confirms it, and to make any refund to the account that sent it. Where we must make a refund ourselves rather than through Stripe — an international wire, for example — we ask the customer for the account to send it to, and use those details for that refund.
• Metronome receives an account identifier, per-request usage records and invoice amounts. It does not receive prompt content, model output or an email address.
• Usage and cost aggregates derived from call records, and the card and bank-transfer records above, are retained for billing and legal-retention purposes and survive erasure (§8). We keep invoices and the records behind them for 10 years after the end of the financial year they relate to, which is the longest period tax and accounting law may require of us. A bank-transfer sender’s name that never became credit is deleted after 90 days. We keep copies of Stripe’s webhook messages for 90 days.

4.7 Operational and security data

4.8 Waitlist, journal, outreach and community data

5. Model output — the honest statement

We write the model’s output on every tier, including shared_anon and private, and on those two tiers we delete it once you have it. Both halves of that are deliberate, documented decisions, and we will not describe them any other way.

Writing it is delivery-driven: three paths rebuild the customer’s own deliverable from that field after the call has finalized.

1. Webhook delivery. Delivery records are content-free by design, so the payload is rebuilt from the stored output at send time. Without it, the delivery is lost.
2. Batch API output files. The OpenAI-compatible output file is rendered from stored output at finalization.
3. Retrieval by the customer. We serve the result back on request, for as long as we still hold it — which is also the recovery path when a webhook is lost.

Beyond those three, stored output is used for the evaluation and judging operations the customer instructs, and — on the free tier only — as a comparison baseline in model-introduction replay (§7.2A), which we perform for our own purposes as the consideration for that tier. It is used for nothing else.

On shared_anon and private, retention is bound to delivery. We delete the output of a call promptly — typically within minutes — once it has been delivered to the customer and any evaluation of it has finished. An output we could not deliver is held for retrieval for at most 72 hours, then deleted. There is no retrieval of a past output beyond that. The one exception is the evaluation evidence a customer elects to keep for review of their own criteria (§6). This is a schedule we enforce with a continuous sweep and monitor; if it lengthens, that is a new version of these documents.

On free, output is retained until erasure or account closure, because it is the replay baseline. Once delivery is complete we may also delete it at our own discretion to manage storage.

We do not say, because it would not be true:

• “We do not retain the content of your requests or responses." — on free we do, verbatim, and on every tier we hold the output for the time it takes to deliver it.
• “On the shared and private tiers no raw content is retained." — a batch working copy and the output until delivered and evaluated are both raw content held for a bounded time.
• “Outputs are discarded immediately after delivery." — “promptly, once delivered and evaluated, backstopped at 72 hours” is the true sentence, and the difference is the evaluation and the undelivered case.

Erasure is a separate matter. It is real, it covers model output on every tier, and it is not governed by the retention matrix below — see §8, including §8.2 on what it does not reach.

6. Retention by tier

This is the authoritative statement of what we keep. It is enforced in code at a single write chokepoint, and it fails closed.

One thing this table does not cover: it applies by tier from the moment a tier takes effect: an account that moves to free limits is handled under the free column from the time of the move, whether or not it has since accepted the free-tier data grant (Terms §6.1 and §14).

Two points that matter:

• Two categories we use for our own purposes, not just to run the service. free-tier prompt text (re-executed against newly introduced models, and used for taxonomy) and template content on free and shared_anon (compared with our library, and possibly adopted under Terms §9). For those two categories we are a controller under the GDPR and the UK GDPR, not the customer’s processor, and we are not acting as a “service provider” under the CCPA. Our basis is our legitimate interest in measuring models on real traffic and maintaining our library (§3B). We keep free-tier prompt text for as long as we use it to measure models, and we will publish a period, and template text we adopt for as long as it is in our library. Our terms prohibit personal data in both. If it reaches us anyway, we use it only for those purposes, you can write to us directly (§8.4), and we delete it on request. We do not sell or share either. A customer that needs processor and service-provider treatment for everything it sends should use the private tier. See DPA §6.4.
• Verdicts on our capabilities, on free and shared_anon, pool globally. Their verdicts and cost/quality signals feed a shared pool used to rank models. A capability of your own never pools, on any tier, and private keeps its own statistics. This pooling is the economic basis of the free tier, and it is disclosed at signup — which is what the version-stamped consent record exists to evidence.
• Tier changes are forward-only. Moving from free to private does not retroactively un-pool verdicts already contributed; it changes what happens from that point on. Verdicts already pooled will not be un-pooled. We word that as a commitment rather than as an impossibility: re-tagging and recomputing is technically possible, we reserve it for repairs and for honoring erasure requests where we determine it is required, and we do not offer it as a customer-triggered right. Saying “cannot” would be false.

7. Who else sees the data

7.1 Model providers under customer keys — not our subprocessors

Where a task runs in bring-your-own-key mode, a customer’s prompt is sent to the model provider using that customer’s own API key, under that customer’s own contract with that provider. We never substitute our key, with one exception: unless the customer turns it off for a capability of their own, we adapt that capability’s template once for each model it runs on, on our own credentials and through providers we contract with (which are our subprocessors for that call, §7.2). The adaptation is sent the template text, the capability’s description and its evaluation criteria — never the customer’s prompt variables. The provider is therefore the customer’s processor, not our subprocessor, and the provider’s own terms govern what it may do with that content.

This has a consequence customers must act on: at least one provider (Google’s Gemini API) applies materially different data-use terms to unpaid projects, under which it uses submitted content and generated responses to improve its products and human reviewers may read, annotate and process API input and output. The service does not detect the billing status of a supplied credential. Choosing a paid provider project is the customer’s responsibility, and no confidentiality commitment we make can override the terms of a provider the customer chose.

The current registered provider set is listed, with each provider’s contracting entity and location, in the Subprocessor Register. Several are established outside the United States, the EU and the UK, including in Singapore and the People’s Republic of China. We do not restrict which providers serve a customer’s data. A customer decides which models serve its data through the model group of a task of its own, which it can create, or copy from one of our shared tasks where that task can be copied; a task of its own is billed like any other. A shared task runs only on models in the model group we set for it, and a call cannot change that group. Wherever models and model groups are selected, the selector sees each model’s provider, establishment, serving region, transfer basis and data-use terms. For our shared tasks and our own workloads we select the providers, and each shared task’s current providers are listed.

7.2 Operator-supplied serving — model providers are our subprocessors

Operator-supplied is the access mode the service, the portal and the documentation call managed (§4.2). The two names describe one arrangement, and nothing else answers to either.

Where a capability is served in the operator-supplied access mode, we supply the model access on our own provider credentials and bill the customer for the usage. On that path the model providers are our subprocessors, because the content travels to them under our account and on our instructions.

• It serves the customer’s own request and returns them the result, unlike the replay in §7.2A.
• It is available on every tier, and the tier retention rules in §6 apply unchanged — the access mode decides who contracts with the provider, not what we keep.
• The customer cannot constrain the provider set by their choice of credentials, because the roster is ours. The 30-day notice and objection rights below apply to it in full.

7.2A The other path on our credentials: free-tier model-introduction replay

One further operation runs on our provider credentials rather than the customer’s, and is distinct from operator-supplied serving: model-introduction replay, in which we re-execute free-tier prompt text against a newly introduced model to measure it. On that path the model providers are our subprocessors, because the content travels under our own account.

• It applies to the free tier only. No shared_anon or private content travels this path — on those tiers prompt text is not retained, so there is nothing to replay.
• The customer cannot constrain which providers are reached on this path, because the roster is ours. A customer that does not want its content to travel this path should not use the free tier.
• The work returns the customer nothing and is not billed to them. It is the consideration for the free tier.
• The replay corpus is strictly the account’s own calls — one customer’s prompts are never replayed for another customer’s benchmark. Likewise, judge reference examples are scoped to the account, so one customer’s outputs do not appear inside another customer’s judge prompt, and we never judge one customer’s output in the same request as another’s.

Benchmark-set inputs are, however, exempt from tier retention limits: an uploaded set is retained on every tier including private, so that it can be re-run. The service records the uploader’s acknowledgement of that retention — who, and when — and refuses to execute a set for which no acknowledgement exists. Benchmark sets are covered by erasure (§8.1).

7.3 Who else receives personal data

Stripe is not our subprocessor. Billing contact and payment data are collected by Stripe — card data through a Stripe-hosted checkout, and bank transfers into an account Stripe holds for the customer; no full card number reaches our systems. For that data Stripe acts as an independent controller, determining its own purposes and means, and its processing is governed by Stripe’s own terms rather than by our DPA. For the records Stripe returns to us (§4.6), we are the controller.

We will give at least 30 days’ notice before adding or replacing a subprocessor, by updating the register and by email to the account address. A customer may object on reasonable data protection grounds within that period; if we cannot resolve the objection, the customer may terminate the affected service without penalty.

8. Your rights, and the honest limit on erasure

8.1 What we delete

On a verified erasure request, or on account closure, erasure completes within 30 days and produces a certificate listing exactly what was erased and what survived. It is a real, implemented, idempotent operation with a dry-run mode, and it refuses to run against our own operator account.

It blanks or deletes, for that account:

• every call record’s prompt text, content-bearing metadata, and model output — the last of these on every tier, because the retention matrix governs what we keep by default while erasure is the customer overriding it;
• evaluation dispatch input and output snippets, and the evaluation evidence kept for a customer’s review, which is deleted outright;
• fan-out judge candidate and winner payloads (the same model output, multiplied across the roster);
• the text of every template and every stored version of it — the record of which version ran a call survives, without the text;
• Batch API content at rest: every uploaded input blob and every rendered output and error file is deleted and its row tombstoned, and every per-line request body is blanked;
• uploaded benchmark sets: their items and uploaded files are deleted, and the set’s own row is retained, emptied of your content and deactivated, because operator records of benchmark runs reference it;
• vaulted provider credentials, which are destroyed, and service API keys, which are disabled;
• support data, other than the records §8.3 identifies as surviving. Your account and its API keys are deactivated rather than deleted: key rows hold only a one-way hash and never key material, and all API access stops immediately at the authentication layer.

Because several of these tables are append-only by design, erasure overwrites fields rather than deleting rows. A blanked row no longer matches the erasure query, which is what makes the operation safe to re-run. The procedure defaults to a dry run, cannot be executed against our own operator account, and is followed by a verification query whose report is available to the customer.

Before we erase, you get your data out. Following termination we give at least 7 days’ written notice before erasure begins. On written request made before then, we will provide within 14 days a copy of retained prompt text, model output, Batch API input files, benchmark sets and templates in a structured, machine-readable format; while such a request is outstanding erasure does not begin, and the 30-day period is extended. Provider credentials and webhook signing secrets are not exported.

8.2 What erasure does not reach

We list these because the alternative is a promise we would break. We make no warranty that customer content is absent from them.

If you require any of the retained items above to be erased, contact us and we will treat it as a specific request rather than declining it. We do not represent it as automatic.

8.3 What survives, and why — the asymmetry

Capitalized terms in this section have the meaning given in Terms of Service §1; this section is worded identically to Terms of Service §12.3 by design.

We can delete your content. We cannot un-derive an Aggregate. This asymmetry is stated identically here and in the Terms of Service; DPA §8.4 states it subject to the qualification below. It is not a hedge; it is a structural property.

These survive an erasure request by design:

• Verdicts, and the Aggregates computed from them. A Verdict is a fact about a model — “model X scored 0.72 on Capability Y” — computed across many contributors. Once a free or shared_anon Account’s Verdicts have been folded into the global pool, the pooled Aggregate cannot be un-derived: we can recompute the average without them, and will where erasure requires it, but the recomputed number is a new number. It does not undo routing decisions already made, models already retired, or rankings already published. Our erasure report counts these rows explicitly rather than silently omitting them. One qualification, and it now runs in your favour: a Verdict also carries the judge model’s written rationale, which is free text produced by a model that saw your Output and can therefore restate or quote part of it (“the answer omitted the revenue figure…”). Erasure blanks that rationale, on every tier. What survives a Verdict is the score, the failure mode and the counts — the numbers the comparison rests on — and no free text.
• Aggregate usage and billing records, retained for the period required by applicable tax and accounting law.
• Access and audit records, including the append-only record of every time one of your Provider Credentials was decrypted and by which subsystem.
• Acceptance records. The record that you accepted a specific version of our terms on a specific date is our evidence of the agreement and of what we told you. These records are append-only and survive Account closure; withdrawal is recorded as a new superseding record, never as an edit or a deletion. On erasure we purge the incidental metadata attached to them (IP address, user agent) and retain the fact of acceptance.

8.4 Your rights, and how to use them

Whoever and wherever you are, you have these rights over personal data we hold as a controller:

• Access: a copy of your data and information about how we use it.
• Correction of inaccurate data. You can change your name and email address yourself in the console.
• Erasure, where the law allows it (for example, once we no longer need the data, or you withdraw consent or object and we have no overriding reason).
• Restriction: asking us to keep your data but stop using it while you contest its accuracy or object to our use of it, where our use is unlawful but you want the data kept, or where we no longer need it but you need it for a legal claim.
• Portability: receiving data you gave us, which we process by contract or consent, in a common machine-readable format, or having it sent to someone else.
• Objection to processing based on our legitimate interests. To direct marketing you can object at any time and we will stop.
• Withdrawal of consent, where consent is our basis, at any time.

How. Write to privacy@fronset.ai. We answer within one month of receiving your request. If a request is complex, or you send many, we may extend that by up to two further months; we will tell you within the first month and say why. We do not charge, unless a request is manifestly unfounded or excessive. We ask you to verify your identity only when we have a reasonable doubt, usually by replying from the address on the account. Someone may act for you with your written authority.

Complaints. You may complain to a data protection supervisory authority, in particular the one in the EU Member State of your habitual residence, your place of work or the place of the alleged infringement. In the UK you may complain to the Information Commission (which replaced the Information Commissioner on 30 September 2026 and still uses the name ICO). You can also complain to us: we will acknowledge a complaint within 30 days and tell you the outcome without undue delay, and the Information Commission may expect you to have raised it with us first.

US state privacy laws. Under the California Consumer Privacy Act and the comprehensive consumer privacy statutes of other US states, you may also have rights to know, correct and delete, to opt out of sale or sharing, and to not be discriminated against for exercising them. We do not sell personal information and we do not share it for cross-context behavioral advertising.

Two practical limits, stated plainly. First, for call content we act as a processor on our customer’s instructions, except for the two own-purpose uses in §3 and §6. If your data reached us inside a customer’s prompt, that customer answers for it and we will pass your request on and help. Second, prompt content is unstructured and we apply no schema to it, so we cannot search an account for the records relating to a particular individual. What we can do is erase a whole account, erase or amend a record identified to us by identifier, and provide the compliance information in DPA §13.

Customers can retrieve their own call records through the API, which covers much of access and portability in practice, and can export their content before erasure under §8.1.

9. Security

Each item is a description of the running system:

• Tenant isolation is enforced at the data-access layer. Models are account-scoped by default, and every deliberate cross-account read must appear in a reviewed allowlist that an automated test enforces — both new entries and stale ones fail the test suite.
• Credentials at rest: per-credential data key, AES-256-GCM, data key wrapped by a per-account key-encryption key in Azure Key Vault, fail-closed decryption, no plaintext at rest.
• API keys at rest: SHA-256 digest only; the raw token is unrecoverable.
• Webhook URLs validated HTTPS-only with public-IP resolution as a server-side request forgery guard; signing secrets vaulted and shown once.
• Error reporting scrubbed at two composed layers with a fail-closed fallback (§4.7).
• Retention decisions enforced at one write chokepoint that fails closed on an unknown or unreadable tier.
• Traffic in transit is carried over HTTPS.

Security incidents. If there is a breach leading to accidental or unlawful destruction, loss, alteration or unauthorized disclosure of or access to customer content or to the data we hold as controller, we notify affected customers at their registered account email address without undue delay, and in any event within 48 hours of becoming aware of it. Our detection is alert-driven rather than a continuously monitored security operations function, so the 48 hours run from our actual awareness.

For personal data we hold as a controller, we notify the competent supervisory authority within 72 hours of becoming aware of a breach unless it is unlikely to result in a risk to people, and we tell the people affected without undue delay when the risk to them is high. We keep a record of every personal-data breach.

What we do not have, and do not claim. No SOC 2 Type II or ISO 27001 certification. We do not represent that we conduct third-party penetration testing, formal business-continuity or disaster-recovery testing, or that we maintain documented recovery point or recovery time objectives. Our hosting provider encrypts the disks and file storage we use at rest, with keys it manages. The additional encryption described above protects provider credentials specifically. We will say so here when any of this changes.

10. Where your data is, and international transfers

Where it is. KAPUA Labs LLC is a United States company (§2). Our production systems (servers, database, file storage, key vault and backups) are hosted by Microsoft in Azure Central US, in the United States, and so is the copy we use to test releases, from which customer and personal data are removed or scrambled. Our personnel may administer those systems remotely from outside the United States. During development we also hold copies on a computer outside Azure.

Transfers. Customers and individuals in the EU and the UK who send personal data to us, in the United States, make a transfer under Chapter V of the GDPR or the UK GDPR; for customers, the Data Processing Agreement incorporates the European Commission’s Standard Contractual Clauses and the UK Addendum for it (DPA §12). When we pass personal data on to a recipient in another country, for each recipient §7.3 and the Subprocessor Register name the safeguard: in most cases the European Commission’s 2021 Standard Contractual Clauses, and, where the recipient is certified, also the EU-US Data Privacy Framework. For transfers from the UK we use the UK’s International Data Transfer Addendum to those clauses. You can ask us for a copy of the safeguard for any recipient at privacy@fronset.ai.

Model providers: establishment and serving location are different questions.

• Establishment is the domicile of the entity we or you contract with, and decides which legal system can compel it to disclose data wherever the data sits. Several providers contract through a company in Singapore whose group is based in the People’s Republic of China, and some are established in the People’s Republic of China itself; the register names each one. A provider whose group is based in another country may remain subject to that country’s laws.
• Serving location is where inference actually runs. It does not follow from establishment, and the register says what we know of it for each provider.
• What the selector sees. For every provider, the register states its contracting entity, establishment, serving region (as known), transfer basis and data-use terms. The serving region of each model is shown where models and model groups are selected and in the register.

Who chooses, and how you control regions. We do not restrict which providers serve your data. You control which models, and therefore which providers and serving regions, receive your content by the model group of a task of your own, which you can create, or copy from one of our shared tasks where that task can be copied, and which is billed like any other task of your own. The transfer to those providers is then made on your instruction, and in bring-your-own-key mode under your own agreement with each provider. A shared task runs only on models in the model group we set for it, and a call cannot change that group. For our shared tasks and our own workloads (free-tier replay, template adaptation, evaluation and judging, community activity and trials), we choose the providers; for those we are the exporter, we hold a transfer safeguard and a transfer assessment for each provider we use, and we list each shared task’s providers.

11. Children

The service is not directed to children. You must be at least 18 to open an account, and the Terms of Service prohibit submitting the personal data of children under 13 through the service. We do not knowingly collect personal data from children, and we will delete it if we learn we have.

12. The public benchmark site

The public Fronset Benchmark site publishes per-model quality bands, cost figures and rankings, generated from an immutable snapshot of the aggregate statistics described in §6.

The published artifact contains no customer prompt or output text — judge-derived scores are numbers. Published rankings name the providers’ models; that is comparative commentary about third-party products, not a disclosure about any customer.

Visitors to the public site. Our public sites are hosted by Cloudflare, which processes each visitor’s IP address and request to deliver the page. Requests to the management console, the sign-up pages and the API are recorded in our web server logs (§4.7). We use those records to operate and secure the service.

Cookies and similar technology. Our public sites use no analytics and no third-party tracking scripts, and set no cookies. The management console uses only strictly necessary cookies. We do not use advertising or cross-site tracking on any surface.

13. Changes to this policy

This policy is versioned by date (this version: 2026-11-05). Exactly one version is current at any time, and we record the URL of the published text, and, where we do not control the bytes of the published page, a SHA-256 digest of it, alongside the version.

This policy is versioned on its own: a new version of it does not change the Terms of Service or the Data Processing Agreement, and a new version of those does not change it.

We publish a new version on this page and in the console. Before we use personal data for a new purpose, we tell the people concerned first: account holders by email to the account address, waitlist and journal subscribers by email to their list, and everyone else on this page.

14. Contact

KAPUA Labs LLC, doing business as Fronset 30 N Gould St Ste R Sheridan, WY 82801 United States

Privacy and data requests: privacy@fronset.ai

Version 2026-11-05. Prepared by KAPUA Labs LLC, doing business as Fronset. This version supersedes 2026-10-10. It states how the GDPR and the UK GDPR apply to our processing; adds why we use personal data and on what basis, our legitimate interests, everyone who receives personal data and where, how long we keep it, and your rights under the GDPR and the UK GDPR, including the right to complain to a supervisory authority; states that our public sites use no analytics; covers the waitlist, the journal email, outreach, prospect trials, community activity, link clicks and our social pages; and corrects what we said about where data is held, transfers, provider establishment and how serving regions are controlled. Verified against the running system on 2026-11-05.