DATA PROCESSING AGREEMENT — WORKING DRAFT

⚠️ NOT FOR EXECUTION OR PUBLICATION. This is a structured first draft prepared to give

counsel a starting point rather than a blank page. It has not been reviewed by a lawyer.

Every bracketed item is a business decision that must be made before review. Do not link

this from a terms page, send it to a customer, or sign it in this state.

Parties: 2057 Holdings LLC, an Oklahoma limited liability company doing business as

Noevant ("Processor"), and the Customer identified in the Agreement ("Controller")

⚠️ ENTITY NAME — corrected 2026-08-08. This draft previously named "Noevant LLC" as

Processor. No such entity exists. Noevant is a trade name; the contracting legal entity is

2057 Holdings LLC. A DPA naming a non-existent company as Processor is at best ambiguous

about who is bound and at worst unenforceable — and counsel could not have caught it, because

the entity structure was not something the document disclosed.

Every other surface already had this right: the privacy policy, terms and conditions, site

footer and Organization JSON-LD all read "Noevant, a d/b/a of 2057 Holdings LLC". The DPA was

the sole outlier.

Incorporated into: the Fidenta Verify Terms of Service ("Agreement")

Draft date: 2026-08-07 · Revised: 2026-08-08

---

1. Definitions

"Processor" means 2057 Holdings LLC, an Oklahoma limited liability company, trading as

Noevant. References to "Noevant" or "Fidenta Verify" in this DPA, in the Agreement, or on any

Noevant website refer to services provided by that entity. "Fidenta Verify" is a product name,

not a separate legal person.

Terms not defined here have the meaning given in applicable Data Protection Law.

• Data Protection Law — all laws applicable to the processing of Personal Data under this

DPA, including the EU GDPR, UK GDPR, the California Consumer Privacy Act as amended by the

CPRA, and other US state comprehensive privacy laws as applicable.

• Personal Data — any information relating to an identified or identifiable natural person

contained in Customer Data.

• Customer Data — content Controller or its users submit to the Services, including claims

submitted for verification, documents and evidence sources connected to the Services, and

outputs generated from them.

• Processing, Controller, Processor, Data Subject, Personal Data Breach —

as defined in GDPR Art. 4.

• Sub-processor — a third party engaged by Processor that processes Personal Data.

2. Roles

Controller is the controller of Personal Data. Processor processes Personal Data solely on

Controller's documented instructions. Where Data Protection Law designates equivalent roles

under different names (for example "business" and "service provider" under the CCPA),

those designations apply correspondingly.

Processor shall not: sell or share Personal Data; retain, use, or disclose it for any

purpose other than performing the Services; retain, use, or disclose it outside the direct

business relationship between the parties; or combine it with personal information from

other sources except as permitted by Data Protection Law.

3. Scope and instructions

The Agreement, this DPA, and Controller's use of the Services constitute Controller's

complete documented instructions. Processor will notify Controller if it believes an

instruction infringes Data Protection Law.

**Processor does not use Customer Data to train, fine-tune, or improve any artificial

intelligence or machine learning model**, and does not permit any Sub-processor to do so.

✅ SETTLED 2026-08-08: This commitment is now published in the privacy policy at

noevant.ai/privacy-policy, which counsel has reviewed and cleared for launch. It is

contractual in substance already, so it stands here. It does constrain future product

decisions permanently — training on customer verification content is off the table while

this language is live.

4. Sub-processors

Controller provides general authorization for Processor to engage the Sub-processors listed

in Schedule B.

Processor will give at least [30] days' notice before adding or replacing a

Sub-processor, by **[email to the Controller's designated contact / posting to a

subscribable page]**. Controller may object on reasonable data-protection grounds within

that period, in which case the parties will discuss in good faith; if unresolved, Controller

may terminate the affected Services without penalty for the remainder of the term.

Processor will impose data protection obligations on each Sub-processor no less protective

than those in this DPA, and remains fully liable for their performance.

5. Confidentiality

Processor ensures that personnel authorized to process Personal Data are bound by

confidentiality obligations and receive appropriate data protection training. Access is

limited to personnel who require it to deliver the Services.

6. Security

Processor implements the technical and organizational measures in Schedule C, appropriate

to the risk, taking into account the state of the art and the nature of the Personal Data.

7. Data subject rights

Taking into account the nature of the Processing, Processor will assist Controller by

appropriate technical and organizational measures, insofar as possible, in fulfilling

Controller's obligations to respond to Data Subject requests. Processor will promptly

forward any request it receives directly and will not respond substantively except to

confirm the request relates to Controller.

8. Personal Data Breach

Processor will notify Controller without undue delay and in any event within [48] hours

of becoming aware of a Personal Data Breach affecting Personal Data, and will provide

information reasonably available to assist Controller in meeting its own notification

obligations.

9. Deletion and return

Standard retention. Verification records — the submitted text, the claims derived from it,

and the resulting verdicts, reasoning and sources — are retained for **365 days from the most

recent interaction with that record**. Interacting with a record (re-checking the claim, or

rating the result) restarts that period. Records expire automatically at the end of it.

Authentication passcodes are discarded after ten minutes or on first use, whichever is earlier.

Deletion on request. On written request to privacy@noevant.ai, Processor will delete

Customer Data, or return it, within 30 days of the request, except where retention is

required by law. This applies during the term and on termination.

Deletion on termination. Where Controller does not make a deletion request, Customer Data

expires under the standard 365-day retention above. Processor does not currently perform an

additional deletion sweep on account closure; Controller should make a written request if

deletion is required sooner than the standard retention period.

⬜ VERIFIED 2026-08-08: This section was rewritten to match what the system actually

does, and to match the published privacy policy at noevant.ai/privacy-policy, which counsel

has reviewed. The prior draft committed to deletion within 30 days of termination; no

account-closure deletion path exists in the code, so that commitment would have been breached

on signature. Retention is a 365-day TTL from last interaction.

The distinction now drawn — deletion ON REQUEST within 30 days, versus automatic expiry at

365 days absent a request — is the honest version and is what the infrastructure supports.

A customer can verify both. If an account-closure deletion sweep is built later, this section

can be tightened; it must not be tightened before then.

10. Audits

Processor will make available information reasonably necessary to demonstrate compliance

with this DPA. Controller may audit no more than [once per 12 months], on [30] days'

notice, during business hours, subject to confidentiality, at Controller's expense, and

without access to other customers' data or to Processor's multi-tenant infrastructure.

Processor may satisfy audit requests by providing a current third-party report where

available.

11. International transfers

Where Personal Data originating in the EEA, UK, or Switzerland is transferred to a country

without an adequacy decision, the parties incorporate the EU Standard Contractual Clauses

(Commission Implementing Decision (EU) 2021/914), Module Two (Controller to Processor),

with the UK International Data Transfer Addendum where applicable.

12. Liability

Each party's liability under this DPA is subject to the limitations and exclusions of

liability in the Agreement.

13. Order of precedence

In the event of conflict, this DPA prevails over the Agreement with respect to Processing.

---

SCHEDULE A — Details of Processing

Subject matter	Provision of the Fidenta Verify claim-verification service
Duration	Term of the Agreement, plus the retention and deletion periods in §9 (365-day TTL from last interaction; 30 days on written deletion request)
Nature and purpose	Receiving claims and evidence sources; retrieval; automated assessment and audit; returning verdicts with citations; maintaining verification history
Types of Personal Data	Account data (name, email, billing identifiers). Any Personal Data contained within claims or documents Controller submits — determined by Controller, not by Processor
Categories of Data Subjects	Controller's personnel and authorized users; any individuals referenced in submitted content
Special category data	Not requested or required. Controller is responsible for whether it submits such data

---

SCHEDULE B — Authorized Sub-processors

⬜ MUST BE COMPLETED AND ACCURATE BEFORE ANY EXECUTION.

Sub-processor	Purpose	Location
[Infrastructure and edge compute provider]	Application hosting, storage, model inference	[confirm regions]
[Payment processor]	Billing and subscription management	[ ]
[Transactional email provider]	Account and notification email	[ ]
[Retrieval / search providers]	External evidence retrieval for verification	[ ]

Note on model inference. Inference runs on the infrastructure provider's own hardware

within Processor's tenant; there is no outbound call to a model vendor's API in the request

path. Whether the model originator receives or can access any customer input is **pending

written confirmation from the infrastructure provider** — see open item in the positioning

document. Do not make a representation on that point in this Schedule until confirmed.

---

SCHEDULE C — Technical and Organizational Measures

⬜ Draft from actual implemented controls. Do not list an aspirational measure.

• Encryption — TLS in transit; encryption at rest for stored Customer Data
• Access control — least privilege; session-based authentication; API tokens scoped per tenant
• Tenant isolation — per-tenant separation of stored state and vector indices
• Secrets management — centralized secret storage; no credentials in source
• Logging and monitoring — access and error logging
• Backup and recovery — [describe actual cycle and retention]
• Personnel — confidentiality obligations; access limited to those requiring it
• Vulnerability management — [describe actual practice]
• Incident response — documented procedure supporting the §8 notification window

---

Pre-counsel checklist

1. Resolve every ⬜ decision above.

2. ✅ DONE 2026-08-08 — Schedule B complete: 6 sub-processors named, retrieval disclosure

stated, analytics/chat disclosed, non-processors named. Two items still gated: Cloudflare

written confirmation on hosted-model training, and the /app tracker issue in B.3.

3. Verify Schedule C against implemented controls; remove anything not actually in place.

4. ✅ DONE 2026-08-08 — §9 rewritten to match real behaviour (365-day TTL from last

interaction, 30 days on written request) and to match the reviewed privacy policy.

5. Confirm §8 notification window is operationally achievable.

6. Obtain infrastructure provider's written position on model-provider data access.

7. Counsel review — liability, SCCs, audit rights, CCPA service-provider language.

8. Only then publish and link from terms.

Schedule B — Sub-processors

Current as of 2026-08-10. This list is complete: it names every third party that receives

Controller Personal Data or Customer Content in the ordinary operation of the Services.

Two entries below are conditional: Atera receives data only if a user opens a support

ticket, and EZ Texting only if a user supplies a mobile number and requests a code by text.

Neither is engaged in the default path of using the Services. They are listed regardless —

over-disclosure of a sub-processor is recoverable; under-disclosure is not.

B.1 Core service

Sub-processor	Entity / location	What it receives	Purpose
Cloudflare, Inc.	US (Delaware), global edge	All Customer Content and account data	Compute (Workers), storage (KV, Vectorize), authentication for admin surfaces (Access), DNS/CDN
Cloudflare Workers AI	Cloudflare-operated GPUs	Claim text and retrieved evidence	Decomposition, assessment and audit inference
Perplexity AI, Inc. ("Sonar")	US	Search queries derived from claim text	Retrieval leg 1
Exa Labs, Inc.	US	Search queries derived from claim text	Retrieval leg 2
Stripe, Inc.	US	Email address, payment method, billing metadata	Payment processing. Card details go directly to Stripe and never reach Processor
Resend (Plus Five Five, Inc.)	US	Email address, message content	Transactional email — sign-in passcodes and account notices
Atera Networks Ltd.	Israel / EU-US hosting	Name, email address, and the contents of a support request the Controller's user chooses to submit, plus account context (plan, credits remaining, signup date)	Support ticketing. Lazy — nothing is sent unless a user opens a support ticket. No Customer Content is included; verified claims are sent only if the user pastes them into the ticket themselves
EZ Texting (Callfire, Inc. d/b/a EZ Texting)	US	Mobile telephone number and the passcode message body	Optional SMS delivery of sign-in codes, where the user has supplied a mobile number for that purpose

On the conditional sub-processors. Atera and EZ Texting sit outside the verification

pipeline entirely — neither receives claim text, retrieved evidence, or verdicts as part of

normal operation. A telephone number is collected only where a user offers one for sign-in

codes, is recorded as sms_signin consent, and is expressly not used for marketing.

On Workers AI specifically. The models used (@cf/openai/gpt-oss-120b,

@cf/zai-org/glm-5.2) are hosted on Cloudflare infrastructure, not proxied to the model

originator. Inference runs on Cloudflare GPUs; the model authors (OpenAI, Z.ai) do not receive

Customer Content. This is what allows the statement that content is not sent to an external AI

vendor, and it is the reason those models are billed under Cloudflare's neuron system rather

than passed through at an upstream vendor's rate.

Evidence for the hosted claim (checked 2026-08-08). Cloudflare's Workers AI pricing page

lists both models in the neuron pricing table — @cf/zai-org/glm-5.2 at 127,273 neurons per M

input tokens and @cf/openai/gpt-oss-120b at 31,818. Proxied models bypass the neuron system

entirely and are billed at the upstream vendor's rate; presence in the neuron table is

therefore positive evidence of Cloudflare-hosted inference. The separate note that glm-5.2

"requires a paid billing method" is a billing constraint, not a routing one.

B.2 Retrieval — inherent disclosure

Verification requires querying the public web. Search queries are derived from the claim under

verification and will therefore contain its substance. **A claim that is itself confidential

should not be submitted.** This is disclosed in the privacy policy and is a property of the

service, not an incidental transfer.

B.3 Website analytics and chat

Present on Processor's public web pages:

Third party	What it receives	Where
Google (Tag Manager)	Page views, IP, user agent	Public marketing pages
GoHighLevel (LeadConnector)	Chat contents if the visitor initiates chat; visitor identifiers	Public marketing pages
First-party beacon (t.2057hldgs.com)	Page views	Public marketing pages

✅ RESOLVED 2026-08-08. Analytics and chat are now gated off every authenticated page.

Verified live: /, /docs, /compare and /accessibility carry the tags; /login,

/account and /history carry none.

The issue as first written was wrong in both directions and is recorded here because the

correction matters. /app was assumed to be a product surface because it returned HTTP 200 —

it is the catch-all, byte-identical to the homepage, and no browser page ever accepts claim

text. Claims arrive over /mcp and /api/verify, which return JSON and carry no tags at all.

The real exposure was worse and had been missed: /history renders the Controller's own claim

text and verdicts, and the token page renders a live bearer credential — both previously with

Google Tag Manager and a third-party chat widget holding DOM access. That is the finding the

guessed one obscured.

B.4 Distribution and discovery

Listing the server in public MCP directories creates a possible path for Controller data that

does not exist today, so it is disclosed here in advance rather than added after the fact.

Third party	What it may receive	Status
Smithery (smithery.ai)	Potentially: OAuth brokerage and, if traffic is proxied through their Connect layer, tool inputs — which for this service means claim text	Listed; routing not yet confirmed
Official MCP Registry (registry.modelcontextprotocol.io)	Nothing. Public server metadata only — name, description, endpoint URL	Listed

On Smithery specifically. Smithery is a directory, but it also operates a managed connection

layer that brokers OAuth and can sit between a client and a server. Whether a server published by

URL is connected to directly by the client, or proxied through Smithery, determines whether they

receive Customer Content at all. That has not been established.

Named here anyway, deliberately. If they turn out to be pass-through only, this entry costs

nothing but a line of over-disclosure. If they do proxy, a Controller who signed a DPA that did

not name them would have been given an incomplete list — and an undisclosed sub-processor is the

specific failure §4 exists to prevent. Over-disclosing is recoverable; under-disclosing is not.

⬜ RESOLVE: confirm whether Smithery proxies tool traffic for URL-published servers or only

lists them. If listing only, narrow this entry to "directory listing, receives no Controller

data" and move it to B.5. If it proxies, this stays and the notice obligations in §4 apply to

it like any other sub-processor.

B.5 Not sub-processors

Named for completeness because they appear in the infrastructure but do not process

Controller data:

• EZTexting, via jarvis-notify — carries operational alerts to Processor's own staff

(e.g. "retrieval leg down"). Contains no Controller data.

• Microsoft Entra ID — identity provider for Processor's staff access to admin surfaces.

Authenticates Processor personnel, not Controller users or data.