Data Processing Agreement

1. Scope, parties, and precedence

This Data Processing Agreement (“DPA”) forms part of the FunkyRouter Terms of Service or another written order or agreement that incorporates it (the “Agreement”). “Customer” is the business or organization that accepted the Agreement. YEETUM LLC, operating FunkyRouter, is “FunkyRouter.” This DPA takes effect when Customer accepts the Agreement or the applicable Order and continues while FunkyRouter processes Customer Personal Data.

If this DPA conflicts with the Agreement about processing Customer Personal Data, this DPA controls. An executed Order controls over this DPA only where it identifies the conflicting provision and expressly states that it overrides it. Standard Contractual Clauses or another mandatory transfer instrument control for the restricted transfer they govern.

“Customer Personal Data” means personal data contained in prompts, messages, tool content, outputs, or other content that FunkyRouter processes for Customer to provide the service (“Customer Content”). It excludes account-administration, billing, fraud, security, product, and legal-compliance data for which FunkyRouter independently determines the purposes and means and acts as a controller or business, as described in the Privacy Notice.

“Data Protection Law” means privacy and data-protection law applicable to the processing, including the Texas Data Privacy and Security Act and, when applicable, the GDPR, UK GDPR, or another law identified in an Order. The terms controller, processor, business, consumer, personal data, processing, and sale have the meanings supplied by applicable Data Protection Law.

2. Roles, documented instructions, and purpose limitation

Customer is the controller or business and FunkyRouter is the processor or service provider for Customer Personal Data. If Customer acts as a processor for another controller, FunkyRouter acts as Customer's subprocessor. Customer instructs FunkyRouter to process the data only to provide, secure, support, meter, and terminate the service as described in the Agreement, Customer's authorized API requests and settings, Schedule 1, and other written instructions that are consistent with the Agreement.

FunkyRouter will process Customer Personal Data only on those documented instructions, including for transfers, unless law requires otherwise. If law permits, FunkyRouter will tell Customer before that required processing. FunkyRouter will promptly inform Customer if, in its opinion, an instruction violates applicable Data Protection Law and may pause that instruction while the parties resolve it.

FunkyRouter will not sell Customer Personal Data, share it for cross-context behavioral advertising, combine it with personal data received from another customer except as law permits a service provider to do so, or use Customer Content to train or fine-tune FunkyRouter's or a third party's foundation model. FunkyRouter will not retain, use, or disclose Customer Personal Data outside the direct business relationship or for a commercial purpose other than providing the contracted service.

3. Customer responsibilities

Customer is responsible for the lawfulness, fairness, accuracy, and transparency of its processing; its notices and legal bases; honoring data-subject rights; and ensuring its instructions comply with law. Customer must obtain all rights and consents needed for Customer Personal Data and must not instruct FunkyRouter to process categories excluded by the Agreement or an applicable model license.

Customer will apply least privilege to its members and keys, secure its applications and credentials, select suitable models and routes, and avoid submitting protected health information, payment-card data, government-classified material, or other specially regulated data unless an executed Order expressly authorizes that category and the required controls.

4. Confidentiality, personnel, and access

FunkyRouter will ensure that personnel authorized to process Customer Personal Data are bound by confidentiality duties, receive appropriate privacy and security direction, and access the data only as needed to perform their assigned function. Those duties survive the end of their access.

Human users, customer API keys, website services, control-plane services, and provider nodes use separate identities. FunkyRouter will apply least privilege and zero-trust principles: no actor is trusted solely because it is on an internal network, in Texas, company-owned, or customer-owned; authorization is tied to identity, permission, resource, and current state.

5. Security of processing

Taking into account the state of the art, implementation cost, the nature, scope, context, and purposes of processing, and the risk to individuals, FunkyRouter will maintain appropriate technical and organizational measures designed to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access. The current measures and explicit launch gates are described in Schedule 2.

FunkyRouter may update the measures as technology and risk change, but will not materially reduce the overall protection of Customer Personal Data during an Order term. No measure guarantees perfect security. The customer-facing Security page distinguishes implemented source controls from controls still awaiting live-path or independent verification.

6. Subprocessors

Customer gives general written authorization for a managed provider in Schedule 3 to act as a subprocessor to the extent that provider processes Customer Personal Data. The Schedule also discloses providers used only for controller-side account or payment data; listing them does not convert that separate processing into subprocessing under this DPA. FunkyRouter will use a written agreement requiring each subprocessor to protect Customer Personal Data to a standard materially equivalent to the obligations applicable to it under this DPA. FunkyRouter remains responsible for a subprocessor's performance of those obligations to the extent required by law and the Agreement.

FunkyRouter will update the Subprocessor and Technology Registerand provide notice through that page and, once enabled, the authenticated service or Customer's verified contact at least 30 days before a new subprocessor is authorized to process Customer Personal Data. Customer may make a reasonable, documented objection based on data-protection risk during that period. The parties will work in good faith on a commercially reasonable alternative. If none is available, Customer may stop the affected processing and terminate the affected Order without penalty before the change takes effect.

An open-source library or locally executed model is not a subprocessor merely because it is part of the stack. A service Customer independently chooses—such as routing through OpenRouter—is not our subprocessor for that customer-controlled part of the path.

7. Data-subject and compliance assistance

Taking into account the nature of processing, FunkyRouter will provide reasonable assistance, including appropriate technical measures, so Customer can respond to requests to access, correct, delete, restrict, port, opt out, or appeal concerning Customer Personal Data. If a person sends such a request directly to FunkyRouter and we can identify the Customer, we will direct the request to Customer and will not respond on Customer's behalf unless Customer instructs us or law requires it.

FunkyRouter will also provide information reasonably needed for Customer's data-protection impact assessment, prior consultation with a regulator, security assessment, and compliance with controller duties under applicable Data Protection Law, considering the information available to FunkyRouter and the nature of processing. Unless an Order includes that work, Customer will reimburse reasonable costs for unusually burdensome assistance that is not caused by FunkyRouter's breach.

8. Personal Data Breaches

“Personal Data Breach” means a confirmed breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Personal Data processed by FunkyRouter. It does not include unsuccessful probes, blocked login attempts, port scans, denial-of-service attempts, or other events that do not compromise Customer Personal Data.

FunkyRouter will notify Customer without undue delay after becoming aware of a Personal Data Breach. As information becomes available, the notice will describe the nature of the breach, affected data and data subjects where known, likely consequences, measures taken or proposed, and a contact for follow-up. FunkyRouter will take reasonable steps to contain, investigate, mitigate, and remediate the breach and will cooperate with Customer's legally required notifications. Notification is not an admission of fault or liability.

9. Return, deletion, and retention

At Customer's documented choice when the affected service ends, FunkyRouter will return or delete Customer Personal Data and direct its subprocessors to do the same, unless applicable law requires retention. If law requires retention, FunkyRouter will isolate the retained data, protect it under this DPA, and process it only for that legal purpose.

The normal inference path is designed not to persist prompt or completion bodies, so there ordinarily is no body-content dataset to export after a completed request. Customer remains responsible for saving Outputs it needs. Content intentionally placed in a support request and any exceptional legally preserved data follow their separate support or preservation lifecycle. Content-free usage, billing, audit, and security records are not Customer Personal Data unless they contain personal data governed by this DPA.

10. Information and audits

FunkyRouter will make available information reasonably necessary to demonstrate compliance with this DPA. Customer should first use current security documentation, questionnaire responses, and any independent reports we make available. If that material is insufficient, Customer may conduct one audit per 12-month period, and an additional audit after a Personal Data Breach or regulator request, on at least 30 days' notice when circumstances allow.

An audit must occur during normal business hours, avoid access to other customers' data or systems, follow reasonable security and confidentiality requirements, and not unreasonably disrupt the service. The auditor must be independent and not a FunkyRouter competitor. Customer bears its audit costs unless the audit identifies a material breach by FunkyRouter. Nothing requires disclosure of credentials, vulnerability details that would create risk, legally privileged material, or another customer's confidential information.

11. International transfers and government requests

The private-beta service is operated from the United States and uses managed providers with global processing locations. Customer will not submit Customer Personal Data subject to a restricted-transfer regime unless the parties have completed the legally required transfer terms. Where applicable, the parties will execute or incorporate the current EU Standard Contractual Clauses, UK Addendum, or another valid transfer mechanism and complete the required annexes and transfer assessment. This DPA alone does not claim that an incomplete transfer instrument has been executed.

If FunkyRouter receives a legally binding demand for Customer Personal Data, it will review the demand, challenge overbroad or unlawful demands where there are reasonable grounds, disclose only what is legally required, and notify Customer before disclosure unless law prohibits notice. If notice is prohibited, FunkyRouter will use reasonable efforts to seek permission to notify Customer.

12. Term and general provisions

This DPA ends when FunkyRouter no longer processes Customer Personal Data, except that confidentiality, security, deletion, audit, transfer, liability, and other provisions that must survive to protect retained data continue for as long as applicable. The liability exclusions and limits in the Agreement apply to this DPA in the aggregate with the Agreement, except where Data Protection Law prohibits that limitation.

We may update this DPA to reflect law, guidance, or the service, but will not materially reduce Customer's protection during an Order term without Customer's agreement. Material changes and new subprocessors receive the notice described in this DPA. During the initial private beta, notices use the verified invitation, Order, account, or authenticated support channel supplied to the parties; public legal and privacy mailboxes remain a launch gate until delivery is tested.

Schedule 1 · Details of processing

Schedule 2 · Technical and organizational measures

The configured shared Texas broker and published Swift MLX node release are shown below. Operator approval and certificate possession authenticate the enrolled Mac; MDM is optional deployment tooling. These checks do not provide hardware attestation or confidentiality from the Mac's administrator. Published source and release availability do not establish installation or live inference acceptance.

Access, confidentiality, and identity

• WorkOS-backed human authentication, organization membership, roles, sessions, and separately scoped organization credentials.
• Inference keys have only inference:invoke; management keys have only api_keys:manage, cannot invoke a model, and cannot mint another management key.
• One-time display of new organization-key plaintext, hashed or provider-managed credential verification, service identities, and revocation paths for users, keys, and nodes.
• Confidentiality duties, role-based access, and separation of customer, application, control-plane, and node identities.

Data minimization and path protection

• TLS protects network transit. The configured beta ingress terminates through a Cloudflare edge and tunnel, so this is not end-to-end encryption from Customer to model memory.
• Checked-in gateway settings disable content logging, raw request and response storage, the persistent log store, object-storage retention, per-request storage overrides, and telemetry for the beta path.
• The authoritative PostgreSQL ledger has purpose-specific account, node, usage, billing, and audit records but no prompt or completion body columns. Usage records are limited to identifiers, model, revision, token counts, timing, terminal status, and charge data.
• Signed Stripe webhook verification, idempotent event handling, bounded request contracts, allowlisted models, and fail-closed control paths reduce spoofing, replay, and unintended data flow.

Availability, review, and launch gates

• In the configured brokered path, health, capacity, quarantine, and revocation state govern node eligibility; Swift MLX nodes connect outbound over TLS 1.3 mutual-TLS WebSockets and receive no customer affinity in the shared pool. Live serving acceptance requires a ready enrolled node and a successful authenticated inference request with settled usage.
• Security events, access changes, key lifecycle events, credit reservation and settlement, and terminal usage outcomes produce purpose-limited audit or reconciliation records.
• Dependency review, code review, testing, incident response, credential rotation, and vendor management form the organizational control process for the beta.
• Live-path canaries, storage/log/trace/crash/backup inspection, restoration exercises, tested legal mailboxes, and independent assurance remain production launch gates. Catalog or health success alone does not prove those outcomes.

Schedule 3 · Authorized subprocessors and managed processors

These are the managed providers currently authorized for the service. A provider is a DPA subprocessor only for processing identified as Customer Personal Data. The linked register is the controlling, updateable disclosure.

See the Subprocessor and Technology Registerfor processing locations, transfer terms, vendor legal links, the first-party stack, and versioned runtime dependencies.