DATA PROCESSING AGREEMENT

KAPUA Labs LLC, doing business as Fronset — Fronset Inference and Evaluation API

Version 2026-11-05 (date-based versioning) · Effective as of the date of Customer’s acceptance

Version 2026-11-05 supersedes 2026-10-10: this DPA now sets out the terms Article 28(3) of the GDPR requires; it incorporates the European Commission’s Standard Contractual Clauses (Modules 2 and 3, with Processor as data importer) and the UK International Data Transfer Addendum, with Annexes I to III, for every Customer and every Service Tier, including on acceptance at sign-up; it deletes the shared-judging exception; it states that Processor acts as a controller for its own uses of free-tier Prompt Content and of Registered Template content; it corrects the statements about where Processor’s infrastructure and Subprocessors are, how Customer controls which models and serving regions receive its content, benchmark runs on Evaluation Inputs, and error monitoring; it shortens the breach notice period to forty-eight hours; and it adds a commitment on requests from public authorities.

Version 2026-10-10 supersedes 2026-10-03: Section 7.1’s payment-processing paragraph covers bank transfers into an account Stripe holds for Customer, and states that the billing records Processor receives from Stripe are processed by Processor as a controller, not under this DPA. No other term changed.

Version 2026-10-03 supersedes 2026-09-15: Section 3.1 defines Prompt Content for a capability that takes free text and for any other capability, and Section 3.4(a) applies to instructions Customer places in a Registered Template; Section 6 withdraws the derived request embedding (the matrix row, Sections 6.3, 6.4 and 6.6, and Section 8.2(d), which is now unused); Registered Template content is evaluated once for taxonomy and possible adoption only, and verdicts pool only for capabilities Processor provides (Section 6.1); Section 6.7 applies to Customer’s own evaluation criteria on a capability of Customer’s own; Section 7.2 states that evaluation of Customer’s traffic runs on the same credentials, that a call no credential can judge is not evaluated, that a re-evaluation Processor chooses to run is never charged, and that Processor adapts the Registered Template of a capability of Customer’s own on its own credentials unless Customer turns it off; and Section 7.2A(b) lets Customer choose the models of a capability of Customer’s own.

Version 2026-09-15 superseded 2026-09-14: the Service is renamed Fronset and the trading name is added to the Processor’s entity line; the register and version-history addresses in Sections 7.4 and 15.4 and Annex B move to fronset.ai/legal/. No term changed.

Version 2026-09-14 supersedes 2026-09-08: Section 6 now states that Model Output on the shared_anon and private Service Tiers is retained only until delivery and evaluation (the fixed expiry Section 6.2 previously said would be notified — this version is that notice), that a Registered Template’s taxonomy evaluation is one-time and bounded and that Customer may then delete the Template text, and that evaluation evidence is retained for Customer’s review only on Customer’s own criteria and for a window Customer controls; Section 8.1’s retrieval and export rights are narrowed to match; the Section 8.3(a) exclusion of Registered Template content from erasure is withdrawn — Template text is now erased; and Section 9.4 describes the continuous retention sweep.

Version 2026-09-08 superseded 2026-08-21: Section 7.1’s Model Providers row and Annex B’s enumeration are brought into line with Section 7.2A (operator-supplied serving), which they contradicted; Metronome, Cloudflare and tawk.to are added to the register; and Section 9.5’s error-monitoring description is corrected to state what the configuration does. This DPA was previously versioned 1.0 and 1.1. From version 2026-08-21 it shares the date-based version namespace used by the Terms of Service and the Privacy Policy, so that one version string identifies one text across all three documents and across the consent record. Version 2026-08-21 carries the same terms as 1.1.

This Data Processing Agreement (this “DPA”) forms part of and is incorporated into the Terms of Service between KAPUA Labs LLC, doing business as Fronset, and Customer (the “Agreement”) governing Customer’s use of the Fronset inference and evaluation API (the “Service”). In the event of a conflict between this DPA and the Agreement with respect to the processing of Customer Content, this DPA controls.

1. Definitions

“Customer” means the entity identified in the Order Form or account record that accepts the Agreement.

“Customer Content” means Prompt Content, Model Output, Batch Input Files, Evaluation Inputs, Registered Templates, Provider Credentials and Webhook Destinations, as each is described in Section 3.1.

“Personal Data” means any information relating to an identified or identifiable natural person, and includes “personal information” and “personal data” as defined under Applicable Privacy Law, to the extent contained within Customer Content.

“Applicable Privacy Law” means all privacy, data protection and data security laws applicable to a party in its role under this DPA, including the GDPR, the UK GDPR, the California Consumer Privacy Act as amended by the California Privacy Rights Act and its implementing regulations (together, the “CCPA”), and the comprehensive consumer privacy statutes of other U.S. states.

“GDPR” means Regulation (EU) 2016/679, and the law of any Member State that supplements it. “UK GDPR” means the GDPR as it forms part of the law of the United Kingdom, together with the Data Protection Act 2018.

“Controller” means Customer, whether Customer acts as controller of the Personal Data or as a processor for its own controller. “Processor” means KAPUA Labs LLC. Where the CCPA applies, Customer is the “business” and KAPUA Labs LLC is the “service provider.”

“SCCs” means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021. “UK Addendum” means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued under section 119A of the Data Protection Act 2018 (version B1.0, in force 21 March 2022), as amended or replaced.

“Personal Data Breach” has the meaning in Article 4(12) GDPR.

“Model Provider” means a third-party provider of large language model inference accessible through the Service.

“Subprocessor” means a third party engaged by Processor that processes Customer Content on Processor’s behalf.

“Service Tier” means the retention and use tier (free, shared_anon, or private) selected by Customer and recorded in Processor’s append-only consent record.

“Operator-supplied access mode” means the mode in which Processor supplies the model access on its own Provider Credentials and bills Customer for the usage (Section 7.2A), as opposed to the bring-your-own-key access mode, in which Customer supplies the Provider Credential and contracts with the Model Provider directly (Section 7.2). It is the mode the Service, its portal and its documentation call managed: the two names describe one arrangement and nothing else, and this DPA uses “operator-supplied” throughout.

2. Parties, Subject Matter and Duration

3. Categories of Data

3.1 Customer Content

3.2 Data Subjects and Categories of Personal Data

The Service imposes no schema on Prompt Content and Processor has no technical means of detecting whether Personal Data is present within it. Customer is solely responsible for determining what Personal Data, if any, it submits and to which data subjects that data relates. Annex I.B states the categories of data subjects and Personal Data the Service is built to receive. Customer shall tell Processor before it submits Personal Data of a kind Annex I.B does not describe.

3.3 Data Processed by KAPUA Labs as Controller

Account, authentication, consent, billing and support data are processed by KAPUA Labs LLC as a controller in its own right. That processing is governed by the KAPUA Labs Privacy Policy and is otherwise outside the scope of this DPA, except that Section 8.2(g) applies to its erasure and Section 10 applies to a security incident affecting it.

3.4 Prohibited Content

Customer shall not submit to the Service:

(a) on the free Service Tier, any Personal Data (see Section 6.4), and on any Service Tier, any Personal Data within a Registered Template or a registered output schema (see Section 6.4; Template content on free and shared_anon is evaluated for and may be adopted into the canonical library under Section 6.1, and a registered schema is an erasure exclusion under Section 8.3(a) on every tier including private), including instructions Customer places in a Registered Template rather than sending them as Prompt Content;

(b) on any Service Tier, protected health information subject to the Health Insurance Portability and Accountability Act, cardholder data subject to the Payment Card Industry Data Security Standard, information subject to the Gramm-Leach-Bliley Act, government-issued identification numbers, biometric identifiers, special categories of personal data within Article 9(1) GDPR, personal data relating to criminal convictions and offences within Article 10 GDPR, or the personal data of children under the age of thirteen, unless the parties have executed a written amendment expressly permitting it. That amendment is available only where this DPA is executed under Section 15.2.

Processor has no technical means of detecting a breach of this Section and relies on Customer’s compliance.

4. Processor Obligations

4.1 Processing on Documented Instructions

Processor shall process Customer Content only on Customer’s documented instructions, including with regard to transfers of Personal Data to a third country or an international organisation, unless required to do so by Union or Member State law to which Processor is subject; in that case Processor shall inform Customer of that legal requirement before processing, unless that law prohibits it on important grounds of public interest. Customer’s API calls, together with the Service Tier selection and the configuration Customer maintains on the management plane, and this DPA, constitute those instructions. The processing Processor performs consists of executing those calls and, in addition:

(a) the model-judging and evaluation operations that Customer instructs by requesting an evaluation or benchmark, which take Prompt Content and Model Output as inputs and produce content-free verdicts and cost and latency statistics;

(b) Service Tier-dependent retention and use as set out in Section 6;

(c) retention of Evaluation Inputs beyond Service Tier limits, so that an uploaded evaluation set can be re-executed on Customer’s request (Section 7.3); and

(d) on the free Service Tier only, retention of Prompt Content and its use in model-introduction replay, and on the free and shared_anon Service Tiers, comparison of Registered Template content with Processor’s library. Customer instructs Processor to retain that content; Processor’s use of it for model-introduction replay and for its library is not processing on Customer’s behalf, and Section 6.4 sets out Processor’s role for it.

Retention is enforced at a single write chokepoint in the Service, which fails closed: an unknown, missing or unreadable Service Tier is treated as the most restrictive tier.

Processor shall immediately inform Customer if, in its opinion, an instruction infringes the GDPR, the UK GDPR or other Applicable Privacy Law.

4.2 No Cross-Customer Processing

Processor warrants that:

(a) where an evaluation or benchmark draws on historical calls, it draws only on Customer’s own call history, enforced by tenant-scoped data access at the persistence layer;

(b) evaluation reference examples are scoped to the evaluating tenant; and

(c) Customer Content is never submitted within another customer’s evaluation prompt or judge prompt.

Every deliberate cross-tenant read path in the Service is enumerated in a controlled allowlist enforced by an automated test in Processor’s build pipeline, which fails on both unregistered new reads and stale entries.

4.3 Confidentiality of Personnel

Processor shall ensure that each person authorised to process Customer Content is bound by a written obligation of confidentiality that survives the termination of their engagement, and shall limit access to Customer Content to those personnel who require it to perform Processor’s obligations under the Agreement.

4.4 Assistance to Customer

Taking into account the nature of the processing and the information available to it, Processor shall provide reasonable assistance to Customer in:

(a) responding to requests from data subjects to exercise their rights under Chapter III GDPR and the UK GDPR, and verified consumer requests under the CCPA, by appropriate technical and organisational measures, insofar as this is possible, to the extent and by the means described below;

(b) ensuring compliance with Articles 32 to 36 GDPR (security, notification of Personal Data Breaches, data protection impact assessments and prior consultation), taking into account the nature of processing and the information available to Processor; and

(c) meeting Customer’s own record-keeping obligations.

Limits Customer must account for in its own compliance programme. Processor cannot identify which stored records relate to a given individual, because Prompt Content is unstructured and Processor applies no schema to it. Processor’s assistance with individual requests is therefore limited to: tenant-wide erasure under Section 8; erasure or amendment of a specific record that Customer identifies to Processor by record identifier; and the provision of the information described in Section 13. Processor cannot perform a content search for an individual across Customer’s tenant, and cannot action an access, correction, or restriction request at the level of an individual data subject. Customer is responsible for maintaining whatever record-level mapping its own obligations require.

4.5 Notice of Inability to Comply

Processor shall notify Customer promptly, and in any event within five business days, if Processor determines that it can no longer meet its obligations under this DPA or under Applicable Privacy Law.

4.6 Further Processor Obligations

(a) Security. Processor shall take all measures required under Article 32 GDPR. The measures in place are described in Section 9 and Annex II. Processor shall not materially reduce the overall security of the Service during the term.

(b) Records. Processor maintains a record of the processing it carries out on Customer’s behalf as required by Article 30(2) GDPR.

(c) Cooperation with authorities. Processor shall cooperate, on request, with the competent supervisory authority in the performance of its tasks.

(d) Information. Processor shall make available to Customer all information necessary to demonstrate compliance with Article 28 GDPR, as set out in Section 13.

5. Controller Obligations and Warranties

Customer warrants and undertakes that:

(a) it has a lawful basis for, and has provided all notices and obtained all consents required for, the Customer Content it submits and the processing instructed under this DPA;

(b) it will not submit Customer Content outside the scope agreed in Section 3, including the prohibitions in Section 3.4;

(c) it maintains its own agreements with each Model Provider whose Provider Credentials it stores with the Service, and its use of those credentials through the Service complies with those agreements;

(d) its processing instructions comply with Applicable Privacy Law; and

(e) it will select the Service Tier appropriate to the sensitivity of the Customer Content it submits, having read Section 6.

6. Retention and Service Tiers

6.1 The Retention Matrix

Customer selects a Service Tier at signup, which is version-stamped in an append-only consent record. The Service Tier determines retention and use as follows.

6.2 Model Output

Model Output is retained on every Service Tier. Retention is necessary because three delivery paths reconstruct Customer’s own deliverable from the stored response after a call finalizes: webhook payloads are rebuilt at send time, Batch API output files are rendered at finalization, and Customer’s own retrieval endpoint serves the response back, which is also the recovery path for an undelivered webhook.

Processor retains Model Output for the period necessary to deliver the result to Customer, to serve Customer’s own retrieval requests, to perform the evaluation and judging operations Customer has instructed under Section 4.1(a), and, on the free Service Tier only, as a comparison baseline in model-introduction replay under Section 4.1(d). Processor does not use Model Output for any other purpose.

On the shared_anon and private Service Tiers, that period is bound to delivery. Processor deletes the Model Output of a call promptly — ordinarily within minutes — once it has been delivered to Customer and any evaluation of it has completed. Model Output that could not be delivered is retained for Customer’s retrieval for no more than seventy-two hours and then deleted. No retrieval or export of Model Output is available on these tiers beyond that, and Customer is responsible for retaining what it fetches. The single exception is the evaluation evidence Customer elects to retain under Section 6.7. Batch input files on these tiers are deleted once every line of the batch has reached a terminal state, and in any case within the same seventy-two hours.

On the free Service Tier, Model Output is retained until erased on Customer’s request or on termination in accordance with Section 8; once delivery is complete Processor may also delete it at its own discretion to manage storage.

This Section is the notice of a fixed expiry period that the prior version of this DPA undertook to give. A later lengthening of the retention of Model Output on shared_anon or private is an amendment to this DPA under Section 14; a shortening is not.

6.3 Prompt Content on the free Tier

On the free Service Tier, and only on that tier, the request body of Prompt Content is retained and used by Processor for its own purposes, namely re-execution against newly introduced models and taxonomy development. This use is the consideration for the free tier.

On the shared_anon and private tiers, the request body is not written to persistent storage. Customer should note that this guarantee attaches to the request body and not to every artifact in which request content could appear. Specifically:

• Registered Template content, including verbatim system-prompt text, is retained on every tier under Section 6.1; and
• Section 8.3 identifies further stores that may contain fragments of request content on any tier.

6.4 Where Processor Acts for Its Own Purposes

Processor uses two categories of Customer Content for its own purposes rather than solely to perform the Service:

(a) free-tier Prompt Content, as described in Section 6.3; and

(b) Registered Template content on the free and shared_anon tiers, which Processor compares with its library and may adopt as shown in Section 6.1.

For that use of those two categories, Processor determines the purposes and means of processing and is a controller under the GDPR and the UK GDPR (Article 28(10) GDPR), and does not act as a “service provider” under the CCPA; Section 11 does not apply to them. Processor’s legal basis is its legitimate interest in measuring models on real traffic and maintaining its library (Article 6(1)(f)), and Processor informs data subjects through its Privacy Policy. Processor retains free-tier Prompt Content for that use for as long as Processor uses it to measure models, and text it adopts into its library for as long as that text is in the library. Customer shall not submit Personal Data within either category, as required by Section 3.4(a). If Personal Data is submitted there despite that prohibition, Processor shall use it only for the purposes in this Section, shall handle a data subject’s request about that use itself, and shall delete that Personal Data on Customer’s request.

Notwithstanding that Section 11 does not apply to those two categories, Processor shall not sell or share them, as “sell” and “share” are defined under the CCPA, and shall use them only for performing the Service and for the additional purposes stated in Section 6.3 and Section 6.1 respectively.

Customer requiring service-provider treatment under Section 11 for all Customer Content should select the private Service Tier, on which the request body is not retained and Registered Template content is used only within Customer’s tenant.

Customer should note that Section 3.4(a) prohibits Personal Data in Registered Templates on all tiers: on free and shared_anon Template content is evaluated for, and may be adopted into, the canonical library under Section 6.6, and on every tier the content-free record of which Template version ran a call survives erasure (Section 8.2(a)).

6.5 Tier Changes Are Forward-Only

A change of Service Tier applies to Customer Content processed after the change takes effect. Content-free verdicts already pooled across customers will not be withdrawn from that pool on a tier change, save that Processor reserves the right to re-classify pooled verdicts to correct an error.

6.6 Registered Templates — One-Time Evaluation and Customer Deletion

On the free and shared_anon Service Tiers, Processor compares each Registered Template with its canonical library once, within a bounded period of the capability’s creation, to decide whether to adopt it (Agreement §9). When that evaluation is complete Processor deletes the material it retained for the purpose, and Customer may thereafter delete the Template text through the Service. On the private Service Tier no such evaluation takes place and Customer may delete the Template text at any time. Deletion removes the text of every stored version; the content-free record of which version ran a given call is retained. Deletion does not withdraw a licence already exercised under Agreement §9.

6.7 Evaluation Evidence Retained for Customer’s Review

Where Customer sets its own evaluation criteria for a capability of Customer’s own, Processor retains, for that capability only, a copy of each evaluated exchange — the material shown to the judge, the candidate Model Outputs and the resulting verdicts — for a review window that Customer controls through the Service, not exceeding the maximum Processor publishes there, and deletes it when the window closes. Customer may shorten the window at any time, including to nil. The retention is for Customer’s own review and is processed on Customer’s instruction under Section 4.1(a); it does not extend the retention of any other Customer Content and is erased under Section 8.2.

7. Subprocessors

7.1 Authorised Subprocessors

Customer grants Processor general written authorisation to engage the Subprocessors listed in Annex III and in the current Subprocessor register at https://fronset.ai/legal/subprocessors/. Annex III states, for each, the entity, its location, the processing it performs, the Customer Content that reaches it and the transfer mechanism. The primary datastore and the task broker are self-hosted by Processor on Microsoft Azure and are not separate Subprocessors.

Payment processing. Customer’s billing contact and payment data are collected by Stripe, LLC — card data through a Stripe-hosted checkout, and bank transfers into an account Stripe holds for Customer. Cardholder data does not reach Processor’s systems. For that data Stripe acts as an independent controller determining its own purposes and means, not as Processor’s Subprocessor, and its processing is governed by Stripe’s own terms with Customer and with Processor rather than by this DPA. The billing records Processor receives from Stripe, including the sender’s name of a bank transfer, are processed by Processor as a controller under its Privacy Policy and not under this DPA.

7.2 Model Providers Accessed with Customer Credentials

This Section describes the bring-your-own-key access mode. Where a capability is served in the operator-supplied access mode, Section 7.2A applies instead. The access mode is declared on each capability and is visible to Customer.

In bring-your-own-key mode, each call is made using Customer’s own Provider Credentials, under Customer’s own agreement with that Model Provider. This is structural rather than customary: in this mode credential resolution for a customer tenant reads only that tenant’s stored credentials and does not fall back to Processor’s own credentials. A missing or revoked credential causes the call to fail rather than to be executed on Processor’s account. The Service additionally supports a zero-custody mode in which a Provider Credential is supplied on a per-request header and is never persisted.

For this path, the Model Provider acts as Customer’s own processor under Customer’s agreement with that Model Provider, and Processor acts as a conduit. The Model Providers are not Processor’s Subprocessors on this path.

Customer control over the provider set and the serving region. Because credential resolution does not fall back to Processor’s credentials, Customer determines which Model Providers can receive its Customer Content on this path by choosing which Provider Credentials to supply. The eligible model pool for any capability is the intersection of that capability’s models with the providers for which Customer has supplied a credential, whether stored in the vault or presented on a per-request header, and this constraint is enforced by the Service. Customer controls which models, and therefore which Model Providers and serving regions, receive its Customer Content by the model group of a task of its own (Section 12.3). The serving region of each model is shown where models and model groups are selected and in the Subprocessor register. The models that evaluate and judge that Customer Content, and that adapt the task’s prompt template (which Customer can switch off for a task of its own), are selected by Processor as part of Processor’s own workloads. This path covers ordinary serving traffic, the evaluation of that traffic, and benchmark execution on Evaluation Inputs against a task that uses it (Section 7.3). Where none of Customer’s credentials can run a judge model, the call is not evaluated and no alternative models run. Where Processor chooses to re-evaluate one of Customer’s calls, the evaluation runs on the same credentials as the call, and Processor does not charge Customer for it. One operation on this path runs on Processor’s own credentials: unless Customer turns it off for a capability of Customer’s own, Processor adapts that capability’s Registered Template once for each model it runs on, through Model Providers Processor contracts with, which act as Processor’s Subprocessors for that operation. The adaptation is sent the Registered Template text, the capability’s description and its evaluation criteria, and no Prompt Content, and it is not billed to Customer in this mode. The control does not constrain the free-tier replay described in Section 7.3, which executes on Processor’s own credentials.

The Model Providers available through the Service are listed in the Subprocessor register with each provider’s contracting entity, establishment, serving region, transfer basis and data-use terms. Processor does not restrict which Model Providers serve Customer Content. Customer decides which models serve its Customer Content through the model group of a task of its own, which Customer may create, or copy from a shared task where that task can be copied, and which is billed like any other task of Customer’s own; that model group is part of Customer’s documented instructions under Section 4.1. A shared task runs only on models in the model group Processor sets for it, and a call cannot change that group.

7.2A Model Providers Accessed with Processor Credentials — Operator-Supplied Serving

The operator-supplied access mode is the mode the Service, its portal and its documentation call managed (Section 1). The two names describe one arrangement, and nothing else answers to either.

Where a capability is served in the operator-supplied access mode, Processor supplies the model access on its own Provider Credentials and bills Customer for the usage. On this path the Model Providers are Processor’s Subprocessors, because Customer Content is transmitted to them under Processor’s own account and on Processor’s instructions.

Three consequences follow:

(a) The notice and objection rights in Section 7.4 apply to this path in full. The Model Providers reached in this mode are listed in the Subprocessor register, and Processor gives the thirty days’ notice required by Section 7.4 before adding or replacing one.

(b) For a capability Processor provides, Customer cannot constrain the provider set by its choice of Provider Credentials, because the roster is Processor’s. For a capability of Customer’s own, Customer selects the models from those Processor makes available in this mode. Where a Model Provider operates region-scoped endpoints, the serving region is Processor’s choice and is surfaced with the model under Section 12.3.

(c) The Service Tier retention terms in Section 6 apply unchanged. The access mode determines who contracts with the Model Provider; it does not alter what Processor retains, what it may reuse, or Customer’s rights under Sections 8 and 11.

Unlike the free-tier replay in Section 7.3, this path serves Customer’s own requests, returns Customer the result, and is billed to Customer. It is available on every Service Tier.

7.3 Model Providers Accessed with Processor Credentials

One further operation executes on Processor’s own Provider Credentials, pinned explicitly rather than inherited from the calling tenant, and is distinct from the operator-supplied serving described in Section 7.2A: model-introduction replay, in which Processor re-executes free-tier Prompt Content against newly introduced models as described in Section 6.3. On this path the Model Providers are Processor’s Subprocessors, because Customer Content is transmitted under Processor’s own account.

This operation is performed for Processor’s own purposes, returns Customer no result, and is not billed to Customer. It applies only to the free Service Tier. No Customer Content on the shared_anon or private tiers travels this path.

Customer cannot constrain the Model Providers reached on this path by its choice of Provider Credentials, because the roster is Processor’s. A Customer that does not wish its content to travel this path should not use the free Service Tier.

Evaluation Inputs and benchmark execution are not on this path. Benchmark execution on Evaluation Inputs is not yet available. The Model Providers are therefore not Processor’s Subprocessors for benchmark execution on any Service Tier.

Customer should note that Evaluation Inputs are nonetheless exempt from Service Tier retention limits: an uploaded evaluation set is retained on every tier, including private, so that the set can be re-executed when Customer requests a further benchmark. The Service records Customer’s acknowledgement of that retention at the time Evaluation Inputs are uploaded, capturing the identity of the uploading user and the time of upload, and refuses to execute an evaluation set for which no acknowledgement is recorded. Evaluation Inputs are erased under Section 8.2.

7.4 Subprocessor Obligations and Changes

Processor shall engage a Subprocessor only by a written contract that imposes on it, in substance, the same data protection obligations as this DPA imposes on Processor, in particular sufficient guarantees to implement appropriate technical and organisational measures. Where a Subprocessor offers only standard terms, Processor shall engage it only if those terms meet that standard. The Subprocessor register states, for each Model Provider, whether its terms allow it to use content for its own purposes. Processor remains fully liable to Customer for the performance of each Subprocessor’s obligations.

The Model Providers identified in Section 7.2 are not Subprocessors on that path and this Section does not apply to them in that capacity.

Processor maintains the current Subprocessor register at https://fronset.ai/legal/subprocessors/. Processor shall give Customer at least thirty days’ notice before adding or replacing a Subprocessor, by email to Customer’s registered account address and by updating the register. Customer may object on reasonable data protection grounds within that period, in which case the parties shall discuss in good faith; if the objection cannot be resolved, Customer may terminate the affected Service without penalty.

8. Deletion and Return

8.1 Return of Customer Content

During the term, and following termination until erasure commences under Section 8.2, Customer may retrieve through the Service’s retrieval endpoints whatever Model Output and Batch API output files Processor still retains under Section 6.2 — on the free Service Tier, all of it; on the shared_anon and private Service Tiers, only an undelivered result within the seventy-two hours Section 6.2 allows, since delivered Model Output is deleted. Processor shall give Customer at least seven days’ written notice before commencing erasure following termination, so that Customer may exercise its rights under this Section.

On written request made before erasure commences, Processor shall provide Customer, within fourteen days of the request, with a copy of its retained Prompt Content, Model Output, Batch Input Files, Evaluation Inputs, evaluation evidence retained under Section 6.7 and Registered Templates in a structured, machine-readable format — “retained” meaning what Section 6 retains on Customer’s Service Tier at the time of the request; on shared_anon and private, delivered Model Output and Prompt Content are not retained and cannot be exported. Where such a request is outstanding, Processor shall not commence erasure until it has been fulfilled, and the erasure period in Section 8.2 is extended accordingly. This Section does not apply to Provider Credentials or Webhook Destination signing secrets, which Processor does not export.

8.2 Erasure

At the end of the provision of the Service, Processor shall, at Customer’s choice, delete or return all Customer Content and delete existing copies, unless Union or Member State law requires storage. Processor shall erase Customer Content within thirty days of Customer’s verified written request, or of termination of the Agreement, and shall issue Customer a written statement identifying what was erased and what was retained under Sections 8.3 and 8.4. Customer’s retrieval rights under Section 8.1 end when erasure commences, subject to the notice Processor must give and to any outstanding export request under that Section. The erasure procedure is idempotent, defaults to a dry run, cannot be executed against a Processor-owned tenant, and is followed by a verification query, the report of which is available to Customer under Section 13. Evaluation Inputs are erased on request even though no run has used them.

Erasure covers, for Customer’s tenant:

(a) all Prompt Content and content-bearing metadata held on call records, all Model Output, and the text of every Registered Template and every stored version of it (the content-free record of which version ran a call survives);

(b) evaluation dispatch input and output snippets, and the evaluation evidence retained under Section 6.7, which is deleted outright;

(c) judge run candidate and winner payloads across the evaluated model roster;

(d) [not used];

(e) Batch API content at rest, comprising every stored file blob — both Customer-uploaded input and service-rendered output and error files — with the corresponding records tombstoned, and every per-line parsed request body blanked; and

(f) Provider Credentials, which are destroyed, and Customer’s service API keys, which are disabled; and

(g) Customer’s account, authentication and support data held by Processor as controller under Section 3.3, other than the records identified in Section 8.4 as surviving.

8.3 Erasure Exclusions

Customer acknowledges that the erasure described in Section 8.2 does not extend to the following, and Processor makes no warranty that Customer Content is absent from them:

(a) Registered output schemas. The structure Customer authored to describe a valid answer is retained; it is configuration rather than content. Customer shall not place Personal Data in a registered schema (Section 3.4(a)). Registered Template content, which this item excluded in prior versions, is now erased under Section 8.2(a).

(b) Provider error messages recorded on call records, which may echo fragments of request content returned by a Model Provider.

(c) Application log files and, where enabled, error-monitoring events. Customer Content is not intentionally written to either, but neither is within the scope of the erasure procedure. Application logs are deleted after thirty days and error-monitoring events after thirty days.

(d) Dormant storage locations — cached idempotency results and unused file-reference columns on call records — which no current Service code path writes to. If Processor brings any such location into active use, Processor shall bring it within the scope of Section 8.2 before doing so.

(e) Backups. Customer Content in a backup taken before erasure is kept until the backup expires, after thirty days, and is never restored into use without the erasure being repeated.

Processor shall notify Customer if it brings item (a) or (b) within the scope of Section 8.2. Item (a) as it stood in versions before 2026-09-14 — Registered Template content — has been brought within scope; this version is that notice.

8.4 What Survives Erasure

Content-free aggregated verdicts and statistics survive erasure. These carry no prompt or response text; they are scores and counts. On the free and shared_anon Service Tiers, those verdicts have already been incorporated into a cross-customer statistical pool, and an individual customer’s contribution to that pool cannot be identified or reconstructed by a third party from the pooled figures. The erasure certificate reports the number of such records explicitly.

The following also survive erasure: aggregate usage and billing records, retained for the period required by applicable tax and accounting law; and audit-log entries, including the append-only consent record, of which only the request metadata fields are purged.

9. Technical and Organisational Measures

9.1 Tenant Isolation

Customer Content is scoped to Customer’s tenant at the persistence layer by default; access outside that scope requires an explicit, enumerated exception. Every such exception is registered in a controlled allowlist enforced by an automated test that fails the build on both unregistered new cross-tenant reads and stale entries.

9.2 Provider Credentials at Rest

Provider Credentials are protected by envelope encryption. A fresh 256-bit data-encryption key is generated per credential; the secret is encrypted under AES-256-GCM; and the data-encryption key is wrapped by Customer’s own dedicated key-encryption key in Azure Key Vault using RSA-OAEP-256. Ciphertext and the wrapped key are stored in the primary datastore; the key-encryption key never leaves Key Vault. No secret plaintext is stored. Decryption fails closed: a Key Vault outage or a failed unwrap causes the operation to fail rather than to proceed.

Plaintext exists only in worker memory, cached for about five minutes (at most 330 seconds). That is also the upper bound on revocation latency in a warm worker. Every materialisation of plaintext writes an append-only audit record capturing purpose, provider and capability, and never key material. Only the final four characters of a credential are retained for display.

9.3 Service API Keys

Service API keys are stored as a SHA-256 digest of the full token, which also serves as the lookup index. The raw token is returned once at issue and is not recoverable. Keys carry a scope, a revocation flag, an optional expiry, and rotation timestamps.

9.4 Retention Enforcement

A single write chokepoint determines retention for every code path, including serving, judging, repair, prompt adaptation and fan-out siblings. It fails closed on an unknown or unreadable Service Tier. Batch working copies of rendered messages are stripped at finalization and again by a daily sweep, which additionally strips records that remain in flight beyond seventy-two hours. The delivery-bound retention of Model Output in Section 6.2 is enforced by a continuous automated sweep keyed on the delivery and evaluation state of each call, with a seventy-two-hour backstop for undelivered results; Processor monitors that the sweep is running and alerts on any call that outlives the schedule.

9.5 Error Monitoring

Error monitoring is enabled only where a reporting endpoint is configured. Where enabled, Processor operates it with default personally-identifiable-information capture disabled and request-body capture disabled — the mechanism by which Prompt Content would ordinarily reach an error event. Local variables are retained in stack traces except for modules that handle credentials, plaintext secrets or Customer Content, whose entire local-variable set is discarded before an event leaves the process. Two composed scrubbing layers then apply: a recursive name-based scrubber extended with the Service’s secret-bearing field names, followed by a pass that redacts dynamic per-request provider-key headers in both HTTP and WSGI forms. Scrubbing fails closed: a scrubbing error causes the carrying fields to be destroyed, and if that fails the event is dropped.

Where error monitoring is enabled, Sentry engages its own subprocessors under its own agreements. Sentry publishes its current subprocessor list at sentry.io/legal/subprocessors.

9.6 Webhooks

Webhook destinations are registered in advance rather than accepted per call. URLs are validated at registration as HTTPS-only and as resolving to a public IP address. The signing secret is generated server-side, displayed once, and stored in the credential vault; the endpoint record holds a reference rather than the value. Delivery records are content-free by design, as the payload is reconstructed at send time, and undeliverable messages are dead-lettered after twenty-four hours.

9.7 Measures Not Currently in Place

Processor does not currently hold SOC 2 Type II or ISO 27001 certification. Processor does not represent that it conducts third-party penetration testing, formal business continuity or disaster recovery testing, or that it maintains documented recovery point or recovery time objectives. Processor’s hosting provider encrypts the disks and storage Processor uses at rest with provider-managed keys; the measures in Section 9.2 additionally protect Provider Credentials.

Processor shall notify Customer if any of the foregoing changes. Processor’s audit and information obligations are set out in Section 13.

Annex II sets out the measures in the form the SCCs require.

10. Security Incident Notification

Processor shall notify Customer without undue delay, and in any event within forty-eight (48) hours, after becoming aware of a Personal Data Breach affecting Customer Content, or of a breach of security affecting the data Processor holds as controller under Section 3.3.

The notification shall be sent to Customer’s registered account email address and shall describe, to the extent known: the nature of the breach, including the categories and approximate number of data subjects and of records concerned; the likely consequences; the measures taken or proposed to address it and to mitigate its possible adverse effects; and a contact point. Where not all of this is known at once, Processor shall provide it in phases without further undue delay.

Processor maintains an append-only audit record of every materialisation of Provider Credential plaintext (Section 9.2), which supports post-incident review of credential access.

Processor’s detection is alert-driven and is not a continuously monitored security operations function. The forty-eight hour period accordingly runs from Processor’s actual awareness of an incident.

11. CCPA and U.S. State Privacy Law Terms

This Section applies to all Customer Content other than the two categories identified in Section 6.4, which Processor uses for its own purposes and to which this Section does not apply. With respect to the Customer Content within its scope, Processor is a “service provider” or “processor” as those terms are defined under Applicable Privacy Law, and:

11.1 Customer discloses that Customer Content to Processor solely for the limited and specified business purposes described in Section 2 and Section 4.1.

11.2 Processor shall not sell or share that Customer Content, as “sell” and “share” are defined under the CCPA.

11.3 Processor shall not retain, use, or disclose that Customer Content for any purpose other than the business purposes specified in Section 4.1, including for any commercial purpose other than those business purposes, and shall not retain, use, or disclose it outside the direct business relationship between the parties, except as permitted by Applicable Privacy Law.

11.4 Processor shall not combine that Customer Content with personal information it receives from another source or collects from its own interaction with a consumer, except as necessary to perform a business purpose permitted under Applicable Privacy Law. The cross-customer statistical pooling described in Section 6.1 operates only on content-free verdicts and statistics and does not combine Personal Data.

11.5 Processor shall comply with the obligations imposed on service providers and processors under Applicable Privacy Law and shall provide that Customer Content the level of privacy protection required by it, subject to the erasure exclusions Customer has acknowledged in Section 8.3 and to the assistance limits in Section 4.4.

11.6 Customer may take reasonable and appropriate steps to ensure that Processor uses that Customer Content in a manner consistent with Customer’s obligations under Applicable Privacy Law, including through the assessments described in Section 13, which Customer may exercise no more than once in any twelve-month period absent a security incident or a reasonable belief of non-compliance.

11.7 Customer may, on notice, take reasonable and appropriate steps to stop and remediate any unauthorised use of that Customer Content by Processor.

11.8 Processor shall notify Customer in accordance with Section 4.5 if it determines that it can no longer meet its obligations under Applicable Privacy Law.

11.9 Processor shall assist Customer in responding to verified consumer requests as set out in Section 4.4, subject to the limits stated there.

12. International Transfers

12.1 Where Processing Takes Place

Processor is a limited liability company organised under the laws of Wyoming, United States. The Service’s production systems, including the primary datastore, the task broker, object storage, key management and backups, are hosted on Microsoft Azure in the Central US region. Processor’s personnel may administer the Service remotely from outside the United States. Subprocessors and their locations are listed in Annex III. Processor shall not process Customer Content at any other location without updating Annex III under Section 7.4.

12.2 Model Providers: establishment and serving location

Where a Model Provider is established and where it serves inference from are separate matters. Establishment is the domicile of the entity that contracts with Processor (or, in the bring-your-own-key access mode, with Customer). Several Model Providers contract through companies established in Singapore whose groups are based in the People’s Republic of China, and some are established in the People’s Republic of China itself; Annex III names each. A provider established in one jurisdiction and serving from another may remain subject to the laws of the jurisdiction in which it, or its group, is established. Serving location is where inference is executed; Annex III states what Processor knows of it for each provider, and where Processor does not know it.

12.3 Who selects providers, and control of serving regions

Processor does not restrict which Model Providers serve Customer Content. Customer controls which models, and therefore which Model Providers and serving regions, receive its Customer Content by the model group of a task of its own, which Customer may create, or copy from a shared task where that task can be copied, and which is billed like any other task of Customer’s own. That model group is Customer’s documented instruction under Section 4.1, including as to the transfer, and in the bring-your-own-key access mode the transfer to each provider is made under Customer’s own agreement with it. A shared task runs only on models in the model group Processor sets for it, and a call cannot change that group. Annex III and the Subprocessor register state each provider’s contracting entity, establishment, serving location, transfer mechanism and data-use terms, and the serving region of each model is shown where models and model groups are selected. For Processor’s shared tasks, on free-tier replay, in template adaptation, in evaluation and judging and in Processor’s other own workloads, Processor selects the providers, is the exporter, and lists each shared task’s providers.

12.4 Transfers by Processor

Processor shall not transfer Customer Content to a Subprocessor in a third country unless a transfer mechanism under Chapter V GDPR (and, for UK data, the UK GDPR) applies to that transfer, as stated for that Subprocessor in Annex III. For each Model Provider Processor selects under Section 12.3, Processor holds a transfer mechanism under Article 46 GDPR and a recorded transfer impact assessment.

12.5 Standard Contractual Clauses and UK Addendum

(a) Incorporation. To the extent that the transfer of Personal Data from Customer to Processor, or Processor’s processing of it, is a transfer subject to Chapter V GDPR, the SCCs are incorporated into this DPA by reference and form part of it, completed as follows, with Customer as “data exporter” and Processor as “data importer”:

• Module Two (controller to processor) applies where Customer is a controller, and Module Three (processor to processor) where Customer is a processor;
• Clause 7 (docking clause) applies;
• Clause 9(a): Option 2 (general written authorisation) applies; the time period for prior notice of changes is thirty days, as in Section 7.4;
• Clause 11(a): the optional wording does not apply;
• Clause 13(a): the competent supervisory authority is the one determined under Clause 13(a) by reference to the data exporter, as stated in Annex I.C;
• Clause 17: Option 2 applies: the law of the EU Member State in which the data exporter is established; where that law does not allow for third-party-beneficiary rights, the law of Ireland;
• Clause 18(b): the courts of the EU Member State whose law governs under Clause 17;
• Annexes I, II and III of the SCCs are Annexes I, II and III of this DPA.

(b) UK. To the extent the transfer is a restricted transfer under the UK GDPR, the UK Addendum is incorporated into this DPA by reference and completed as follows: Table 1, the parties’ details in Annex I.A; Table 2, the Approved EU SCCs incorporated under paragraph (a), with the modules and options selected there; Table 3, Annexes I, II and III of this DPA; Table 4, neither party may end the UK Addendum when the Approved Addendum changes.

(c) Onward transfers. Processor relies, for each onward transfer to a Subprocessor, on the mechanism stated for it in Annex III, which in each case requires the Subprocessor to provide a level of protection equivalent to that of the SCCs.

(d) Precedence. If the SCCs or the UK Addendum conflict with this DPA or the Agreement, the SCCs or the UK Addendum prevail.

(e) Execution. The SCCs and the UK Addendum apply on Customer’s acceptance of this DPA, under Section 15.1 or Section 15.2, without further signature.

12.6 Requests From Public Authorities

If Processor receives a legally binding request from a public authority, including judicial authorities, for disclosure of Customer Content, Processor shall: (a) notify Customer promptly, unless the law that governs the request prohibits it, in which case Processor shall use its best efforts to obtain a waiver of the prohibition; (b) review the legality of the request and challenge it where, after careful assessment, there are reasonable grounds to consider it unlawful, including by seeking interim measures; (c) disclose no more than the minimum the request requires, on a reasonable interpretation of it; and (d) keep a record of each request and its handling and provide it to Customer on request, to the extent the law allows. Processor has not received any such request as of 2026-11-05.

13. Audit and Compliance

Processor shall make available to Customer the information reasonably necessary to demonstrate compliance with this DPA. On Customer’s written request, Processor shall provide: its then-current architecture and security documentation; the Subprocessor register; and, for Customer’s own tenant, the erasure certificate and the verification query report described in Section 8.2.

Processor shall allow for and contribute to audits, including inspections, conducted by Customer or by an independent auditor Customer mandates who is bound by confidentiality. Customer shall give thirty days’ written notice, and audits take place no more than once in any twelve-month period, at Customer’s expense, during normal business hours and without access to the data of any other customer, save that Customer may audit more often following a Personal Data Breach affecting Customer Content, where a supervisory authority requires it, or where Customer has a reasonable and documented belief that Processor is not complying with this DPA. Where the SCCs apply, Clause 8.9 prevails.

14. Liability, Term and Governing Law

14.1 Term. This DPA takes effect on Customer’s acceptance of the Agreement and continues until the later of the termination of the Agreement and the completion of Processor’s obligations under Section 8.

14.2 Liability. Each party’s liability under this DPA is subject to the limitations and exclusions of liability set out in the Agreement, save that nothing in this DPA or the Agreement limits (a) either party’s liability to data subjects under Article 82 GDPR, the UK GDPR or the third-party-beneficiary rights in the SCCs, or (b) any liability that cannot be limited under applicable law.

14.3 Governing law. This DPA is governed by the law specified in the Agreement, and the parties submit to the jurisdiction specified in the Agreement, save that the SCCs are governed by the law and subject to the courts specified in Section 12.5, and nothing in this DPA or the Agreement affects a data subject’s right to bring proceedings in the courts of the Member State of their habitual residence (Article 79(2) GDPR; SCC Clause 18(c)).

14.4 Amendment. Where Customer has accepted this DPA under Section 15.1, Processor may amend it on thirty days’ notice to Customer’s registered account address to reflect a change in Applicable Privacy Law or in the Service; if an amendment materially reduces the protections afforded to Customer Content, Customer may terminate the affected Service without penalty by notice given before the amendment takes effect. Where Customer has executed this DPA under Section 15.2, no amendment takes effect without Customer’s written agreement, save that Processor may on thirty days’ notice make an amendment strictly necessary to comply with a change in Applicable Privacy Law.

14.5 Notices. Any notice, request, objection or acknowledgement under this DPA is given in writing to the address stated for the receiving party in Section 2, and takes effect on the day of transmission if sent on a business day, and otherwise on the next business day. Customer is responsible for keeping its registered account email address current.

14.6 Severability. If any provision of this DPA is held unenforceable, the remaining provisions remain in full force.

15. Acceptance and Execution

This DPA is accepted in one of two ways, according to the Service Tier. Both create a binding agreement on identical terms; they differ only in how acceptance is recorded.

15.1 Acceptance on sign-up — free and shared_anon tiers

Customer accepts this DPA electronically at sign-up, by taking the affirmative action the Service presents for that purpose, having been given the opportunity to review this DPA in full beforehand. No signature is required.

The Service records that acceptance in its append-only consent record, capturing the identity of the accepting user, the time of acceptance, and the version of this DPA accepted. That record is the evidence of the agreement between the parties, and Processor shall make Customer’s own record available to Customer on request under Section 13.

Where this DPA is accepted under this Section, the amendment referred to in Section 3.4(b) is not available, and Customer’s rights and obligations are those stated in this DPA as published, including the SCCs and the UK Addendum incorporated under Section 12.5, which apply on acceptance without signature.

15.2 Execution by signature — private tier

Customer on the private Service Tier executes this DPA by signature. It may be executed in counterparts, and by electronic signature, each of which is an original and which together constitute one agreement. Execution may be recorded in or annexed to the Order Form.

15.3 Authority

Each person accepting or executing this DPA warrants that they are authorised to bind the party on whose behalf they act. Where an individual accepts under Section 15.1 on behalf of an entity, this DPA binds that entity.

15.4 Version

This DPA is versioned. The version accepted or executed by Customer governs the relationship between the parties until it is amended under Section 14.4 or replaced by a later version Customer accepts or executes. Processor maintains the current and superseded versions at https://fronset.ai/legal/dpa-versions/.

15.5 Order of precedence

Where the parties have executed a negotiated data processing agreement, that agreement prevails over this DPA to the extent of any inconsistency. Otherwise this DPA prevails over the Agreement in respect of the processing of Customer Content, as stated in the preamble.

Annex I — Description of the Processing

A. List of parties

B. Description of the transfer

C. Competent supervisory authority

The supervisory authority determined under Clause 13(a) of the SCCs for the data exporter: where Customer is established in an EU Member State, the authority of that Member State responsible for Customer; where Customer is not established in the EU but has appointed a representative under Article 27(1) GDPR, the authority of the Member State where the representative is established; otherwise the authority of the Member State where the data subjects are. For UK transfers: the Information Commission.

Annex II — Technical and Organisational Measures

Annex III — Subprocessors

The current Subprocessor register at https://fronset.ai/legal/subprocessors/ carries the same rows as this Annex; where the two differ, the register governs.

Infrastructure and business subprocessors

Model providers (every provider a task can be served by: selected by the customer through the model group of a task of its own, or by us through the model group of a shared task and for our own workloads; D-8/D-8a: no provider is restricted, and a call cannot change a shared task’s group). Endpoint = what we call. Per owner ruling R3 no provider is excluded; each row states the facts the selector needs (K13), and where we select, the row’s transfer mechanism and our TIA must exist (R3(c), O6). “None found” is stated as such, never presented as transfer-safe.

Providers with no active models are listed for bring-your-own-key only: Groq, Perplexity, Meta (direct), MiniMax (direct).

Signatures

This block applies only where this DPA is executed by signature under Section 15.2. On the free and shared_anon Service Tiers this DPA is accepted under Section 15.1 and is binding without signature; the block below is left unexecuted and the consent record is the evidence of acceptance.

KAPUA LABS LLC, DOING BUSINESS AS FRONSET

By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

CUSTOMER

Entity: ______________________________________

By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

Service Tier: private · DPA version: 2026-11-05