Privacy Policy

1. The short version

• In the synchronous lane, your source material is not stored. Files, pasted text and fetched URLs submitted through the app are processed inside the request that carried them and are never written to storage we own.
• The durable lane is the exception, and it is a real one. A run started at POST /api/jobs persists your content while it is in flight — see section 3. We put it here rather than in a footnote because it contradicts what the rest of this summary would otherwise imply.
• Without an account we store no account, no source material and no dataset — but not literally nothing: a rate-limit counter keyed by a salted digest of your IP address is written, so that the free lane cannot be used to exhaust the service (section 5).
• Signed in, we keep a reference to each run — the number of sources, the profile, the quality score, billable counts and hashes — not the dataset and not the source filenames.
• Your datasets go to your own Google Drive or your own download. Drive access uses the narrow drive.file scope. Within that scope DATAtokeniz both writes and reads: it creates the dataset files you ask it to save, and it reads a file you have explicitly handed it. The scope reaches nothing else in your Drive (section 6).
• Analytics carry no cookie, no device id and no IP address, and the only cookies the site sets are the ones that keep you signed in.

2. Who is responsible

For account, usage and billing data, the controller is Numen Labs LLC, [REGISTERED ADDRESS], contactable at [PRIVACY CONTACT EMAIL].

For the material you choose to process, the roles are the other way round: you are the controller and we act as your processor, handling that material only on your instructions and only for the duration of the run. If you process personal data in the Service at any scale, put a data processing agreement in place with us first: [DPA CONTACT OR LINK].

Data protection officer: [DPO NAME AND CONTACT, OR “none appointed”]. EU or UK representative under Article 27, if one is required: [ARTICLE 27 REPRESENTATIVE].

3. The material you process

“Material” means the files, pasted text and URLs you submit, and the datasets, reports and records produced from them.

• Synchronous runs are held only for the request. Everything you submit through the interface takes this path: the material is read into memory, transformed, streamed back to your browser, and released. Nothing is queued and nothing is written to object storage we own.
• Durable runs are persisted while they are in flight. The durable lane (POST /api/jobs, authenticated, input given as a Google Drive file id) exists so that a job too large or too slow for a single request can still finish. It is built on a workflow runtime that executes the run as a sequence of steps and writes each step’s result down — that is what allows a run interrupted by a crash, a retry or a platform timeout to resume from where it stopped rather than start again. Two of those results contain your content:
  • the source bytes fetched from your Drive, returned by the fetch step and therefore stored by the runtime for the run; and
  • the compiled dataset, returned by the compile step and stored the same way.
  The run’s stage-event stream is retained alongside them so that a client which disconnects can reconnect and replay the run from the beginning.
• How long durable run state is kept, and by whom. It is held by the workflow runtime the application is built on (section 9), not in a DATAtokeniz-owned database or bucket, and its lifetime is set by that runtime rather than by application code we control. We are not going to state a period we have not verified: [DURABLE RUN RETENTION PERIOD — CONFIRM WITH THE WORKFLOW RUNTIME PROVIDER, THEN STATE IT AND THE DELETION ROUTE HERE]. Until that is confirmed and filled in, treat the durable lane as unsuitable for material you need a guaranteed deletion timeline for, and use the synchronous lane instead. While it is held, that content is used only to complete your run: it is not read for any other purpose, not used to train anything, and not sold or shared.
• Not used to train anything. We do not use your material — or the datasets you produce — to train, fine-tune or evaluate any model, and we do not sell or share it.
• The profile guide never sees your content. When the model-backed guide is enabled, it receives only source names, types and sizes.
• Model-assisted steps do send excerpts out. When enrichment, image analysis or transcription is enabled on the deployment, the relevant text, image or audio is transmitted to the configured provider (section 9) solely to produce your output. With no provider keys configured, the pipeline still runs deterministically and no content leaves the deployment.
• URLs are fetched by our servers, not your browser. The site you point at sees a request from our infrastructure. Requests to private, loopback and reserved network ranges are refused, on every redirect hop.
• Video landmark extraction runs in your browser. Where that step is used, the video is decoded locally and only a small numeric landmark track is sent — the video itself never leaves your machine.

4. Account, usage and billing data

When you sign in with Google, the following is stored in our database (hosted by Supabase). Every row in a table DATAtokeniz defines is readable only by the account that owns it, enforced at the database layer by owner-scoped row-level security rather than by application code alone. The first row of the table below is the exception worth naming: it lives in the authentication provider’s own managed schema, which DATAtokeniz does not define and whose contents are set by that provider and by what Google returns at sign-in.

Payments are handled by Stripe. Card details are entered on Stripe’s systems and never reach us; we hold only the customer reference and the resulting plan.

5. What is not collected

• No analytics identifiers. Product events are first-party and store no cookie, no device id, no advertising id and no IP address. Only a fixed allowlist of event names and a handful of low-cardinality properties (profile, plan, a bucketed record count, a coarse quality band, a reason code) are accepted; anything else is discarded. Record counts are bucketed precisely because an exact number starts to behave like an identifier.
• No third-party trackers or advertising tags. The application ships a strict Content-Security-Policy and loads no vendor analytics script.
• No raw IP addresses in the tables DATAtokeniz defines. To rate-limit abuse we derive a keyed HMAC-SHA-256 digest of the client IP and use that digest as the counter key, so the address itself is never written into a DATAtokeniz table. Where no database is configured, the counter lives in process memory only. Two honest qualifications: this counter is the one thing a run without an account does write, and it is written under the digest, not under any account; and the counter row persists after its window closes — a later request under the same digest resets it in place rather than creating a new one, and there is no scheduled purge of expired rows. [DECIDE AND STATE A PURGE INTERVAL FOR EXPIRED RATE-LIMIT ROWS].
• But the authentication provider does record IPs.Sign-in runs through Supabase Auth, which keeps its own audit log of authentication events in the same project and records the client IP address of each one (section 4). That is the provider’s managed schema, outside the code described here, and it is retained under its terms rather than ours: [SUPABASE AUTH AUDIT LOG RETENTION PERIOD]. We would rather name this than let “no IP addresses” stand as a claim that is only true of the part we wrote.
• No cookie banner, because there is nothing to consent to beyond the essentials. The only cookies are the Supabase authentication cookies that keep you signed in. Your light/dark preference is held in page memory and is not persisted.
• No sale or sharing of personal information for cross-context behavioural advertising, under any name, in any jurisdiction.

Note the honest exception: our hosting provider processes ordinary connection metadata, including IP addresses, in its own infrastructure logs in order to deliver and protect requests, under its own retention terms (section 9). The application’s own logs contain the allowlisted event names and properties described above.

6. Google Drive, and how to revoke it

DATAtokeniz requests exactly one Google scope: drive.file. That scope grants access only to files DATAtokeniz itself creates and files you explicitly hand to it through Google’s own picker. It does not allow listing, searching or reading the rest of your Drive, and DATAtokeniz never asks for a broader scope.

Within that scope the integration runs in both directions:

• Writing.When you choose “Save to Drive”, DATAtokeniz creates a new file containing the dataset you just produced. It does not modify files it did not create.
• Reading.DATAtokeniz can also download a file you identify to it — this is how the durable lane takes its input (section 3), which is referenced by Drive file id rather than uploaded. It reads the file’s name, MIME type, size and contents, and only for the file whose id you supplied. drive.file is what bounds this: the grant covers files DATAtokeniz created and files you have explicitly opened to it, and gives no ability to list, search or read anything else in your Drive. A file you never handed over cannot be read even if its id were known.
• The long-lived Google refresh token is stored server-side only, used solely to obtain short-lived access tokens for the actions you request, and never returned to the browser.

To revoke access, open your Google account’s third-party access page and remove DATAtokeniz. The next Drive action then fails with a revoked grant and the stored credential is deleted on our side, so nothing is replayed. You can also ask us to delete it immediately at [PRIVACY CONTACT EMAIL]. Revoking Drive access does not delete your DATAtokeniz account or anything already saved in your own Drive.

DATAtokeniz’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. [CONFIRM LIMITED USE ATTESTATION WITH COUNSEL].

7. Automated PII and secret detection

During a run the quality stage scans extracted records for patterns that look like personal data (email addresses, national-insurance/SSN-shaped numbers, phone numbers, IPv4 addresses, and card numbers that pass a Luhn check) and for credential formats (API keys, tokens, private key headers). Matches are recorded as flags on the record and counted in the quality report.

Records carrying a personal-data or secret flag are excluded from every export. That is a safeguard, not a guarantee: the scan is pattern-based, it will miss personal data it does not recognise and flag text that is perfectly fine, and it does not make you compliant with anything. You remain the controller of personal data in your own material and are responsible for reviewing output before you use it. This detection happens during the run and the flags travel in your output. In the synchronous lane they are not stored by us; in the durable lane they are part of the compiled dataset and so are persisted with it as a step result (section 3), which also means a durable run can end up holding content the scan flagged even though that content is excluded from every export.

8. Legal bases (GDPR Article 6)

• Article 6(1)(b) — performance of a contract. Creating and running your account, processing your material as instructed, metering usage against your plan, and providing support.
• Article 6(1)(f) — legitimate interests. Keeping the service secure and available (rate limiting, abuse prevention, SSRF protection, webhook verification) and understanding aggregate product usage through non-identifying event counts. Our interest is in running a service that is not abused; the impact on you is minimal because none of it is tied to an identifier.
• Article 6(1)(c) — legal obligation. Retaining invoice and tax records for the period required by [APPLICABLE TAX LAW].
• Article 6(1)(a) — consent. Connecting Google Drive, which you grant explicitly at sign-in and can withdraw at any time (section 6).

Special-category data (Article 9) and criminal-offence data (Article 10). DATAtokeniz is not designed for them and applies no additional safeguards for them. If your material contains such data you must have your own condition for processing it, and you should assess whether this service is appropriate before uploading. [CONFIRM POSITION ON SPECIAL-CATEGORY DATA WITH COUNSEL].

9. Sub-processors and recipients

Each of these is used only when the deployment is configured to use it. A deployment with no provider keys performs no model calls and no transcription at all.

Current provider list, entities and their own privacy terms: [SUB-PROCESSOR PAGE OR ANNEX LINK]. We will give notice of a new sub-processor at [SUB-PROCESSOR CHANGE NOTICE PERIOD]. We may also disclose data where required by law or to establish or defend legal claims.

10. Retention

• Your material and outputs, synchronous lane: for the duration of the request only. Not retained.
• Your material and outputs, durable lane: retained by the workflow runtime as persisted step results for as long as it keeps the run record, because that is what makes an interrupted run resumable. [DURABLE RUN RETENTION PERIOD — NOT DETERMINABLE FROM THE APPLICATION CODE; CONFIRM WITH THE WORKFLOW RUNTIME PROVIDER].
• Demo runs (no account): no account, no source material and no dataset is written. The rate-limit counter is: one row per salted subject digest, reset in place on the next window, with no scheduled purge today (section 5).
• Profile, usage counters and run references: kept while the account exists and deleted with it. Note that run references form a hash chain whose purpose is to make removals detectable, so deleting an individual run is not offered — deleting the account removes the chain entirely. [RETENTION PERIOD FOR INACTIVE ACCOUNTS].
• Google refresh token: until you revoke access, ask for deletion, or the account is deleted; also removed automatically the first time a revoked grant is detected.
• Billing records: retained by Stripe and by us as required for tax and accounting for [STATUTORY RETENTION PERIOD].
• Webhook delivery records: kept for idempotency for [WEBHOOK RETENTION PERIOD].
• Infrastructure and application logs: retained by the hosting provider under its own terms, currently [LOG RETENTION PERIOD].

11. International transfers

The application is configured to run its server functions in [DEPLOYMENT REGION — reference deployment is Frankfurt (fra1)]. Several sub-processors in section 9 are established in, or route to infrastructure in, the United States and other countries outside the EEA and UK. Where personal data is transferred outside the EEA/UK, it is done under the European Commission’s Standard Contractual Clauses and the UK Addendum, together with any additional measures required after a transfer risk assessment.

[CONFIRM TRANSFER MECHANISM PER SUB-PROCESSOR AND ATTACH THE TRANSFER RISK ASSESSMENT]. A copy of the safeguards is available on request at [PRIVACY CONTACT EMAIL].

12. Your rights

Subject to the conditions in applicable law, you have the right to: obtain access to your personal data; have inaccurate data rectified; request erasure; request restriction of processing; receive your data in a portable, machine-readable form (portability); object to processing based on legitimate interests; and withdraw consent at any time without affecting processing already carried out.

• Some of this is self-service: sign out at any time, revoke Drive access from your Google account (section 6), and cancel a subscription from the billing portal in the app.
• Account deletion is by request — there is no self-service delete button, and signing out does not delete anything. Email [PRIVACY CONTACT EMAIL] and we will delete your profile, usage counters, run references and stored Google credential.
• We respond within one month, extendable by two further months for complex requests, and we may need to verify your identity first.
• There are no automated decisions producing legal or similarly significant effects about you.
• You may complain to a supervisory authority. Our lead authority is [LEAD SUPERVISORY AUTHORITY]; you may also complain to the authority where you live or work.

Requests about personal data contained in material you processed should go to whoever controls that material — usually you. If we receive such a request directly we will refer it on rather than act on it: for a synchronous run we hold no copy of the material to act on, and for a durable run the copy that exists is run state held by the workflow runtime on its own schedule (section 3), not a searchable record we can amend on your behalf.

[ADD ANY US STATE PRIVACY DISCLOSURES REQUIRED (e.g. CCPA/CPRA NOTICE AT COLLECTION)].

13. Children

The Service is a developer tool and is not directed to children. We do not knowingly collect personal data from anyone under [MINIMUM AGE], and accounts require a Google account meeting Google’s own age requirements. If you believe a child has provided us with personal data, contact [PRIVACY CONTACT EMAIL] and we will delete it.

14. Security

Measures implemented in the application itself include:

• Transport encryption for all traffic, and a nonce-based strict Content-Security-Policy.
• Owner-scoped row-level security in the database — every row belongs to exactly one account and the policy is enforced by the database, not only by the application.
• Privileged credentials (service-role database key, Google client secret, payment and model provider keys) are server-side only and are never exposed to the browser.
• Same-origin checks and body-size limits on state-changing endpoints; per-subject rate limiting; signature verification on payment webhooks with replay protection.
• URL fetching re-resolves DNS and rejects private, loopback and reserved addresses on every redirect hop.
• Records flagged as containing credentials or personal data are excluded from exports.
• Not storing your material at all in the synchronous lane, which is the strongest control on this list — and the reason the durable lane, which cannot offer it, is called out separately rather than folded in here.

No system is perfectly secure. If you find a vulnerability, report it to [SECURITY CONTACT EMAIL]. In the event of a personal data breach we will notify the competent supervisory authority within 72 hours where required, and affected individuals where the law requires it. [BREACH RESPONSE AND NOTIFICATION PROCESS].

15. Changes to this policy

We will update this policy when the software changes — that is the point of describing behaviour rather than intentions. Material changes will be notified by email to the account address or by an in-app notice at least [NOTICE PERIOD]before they take effect, and the “last updated” date above will change.

16. Contact

Numen Labs LLC, [REGISTERED ADDRESS]. Privacy: [PRIVACY CONTACT EMAIL]. Security: [SECURITY CONTACT EMAIL]. Data protection officer: [DPO NAME AND CONTACT, OR “none appointed”].

See also the Terms of Service. The behaviour described here is implemented in the source code, which you are welcome to check against this document.