Legal

Privacy Policy

What personal data we hold as a company, why, who else sees it, and how to make us act on it.

I Am Violet Inc, a Delaware corporation, is the contracting party. Metis is the platform it operates, not a separate company or a trading name. An engagement is governed by the order form both parties sign and by this document as it stands on that day.

• Version: Draft 2
• Last updated: 2026-09-06
• Status: current text

This policy explains what personal data I Am Violet Inc, operator of the Metis platform (I Am Violet Inc, Metis, we, us), collects, why, who else sees it, and what you can ask us to do about it.

1. Scope, and the one distinction that matters

Metis handles personal data in two very different capacities, and mixing them up is the commonest way a privacy policy misleads people. So:

1.1 Data we handle as controller — this policy

Our own business data: the people who visit metisfoundry.com, the people who hold accounts on our platform, the people who email us, and the researchers and arbiters who work for us. We decide how that data is used, and this policy governs it.

1.2 Data we handle as processor — the DPA, not this policy

Content a client sends us under a Statement of Work, for arbitration or verification. We process that only on the client's instructions and for the client's purposes. It is governed by our Data Processing Addendum, not by this policy. If you are an individual whose data may sit inside a client's batch, we are not the party who decided to send it, and the client is the right first point of contact — but see section 8.4, because we will help.

2. What we collect, and where it comes from

2.1 The website

The public website is deliberately quiet. As at the date of this draft:

• No analytics. There is no Google Analytics, no product analytics, no session recording and no heatmapping on the site.
• No advertising or tracking pixels. None. We do not run advertising and we have nothing to retarget you with.
• No cookies set by the site. The application sets no cookies of its own. Sign-in state lives in your browser's local storage instead; see 2.3.
• Fonts come from Google, and this is a correction. Draft 1 said the typefaces were self-hosted. They are not. The web application's stylesheet, the briefing view, and the pages our edge worker renders all load fonts from fonts.googleapis.com and fonts.gstatic.com. Your browser therefore contacts Google LLC on every page load, which discloses your IP address, your user agent and the referring page to Google, under Google's terms and not ours. Nothing about that is behind consent, and the font files are not self-hosted. Either change would remove the disclosure, and both are open items below.
• A JavaScript CDN on the voice pages. The worker-rendered voice and pilot pages import the LiveKit browser client from esm.sh, which discloses your IP address and user agent to that CDN when the module loads.
• Maps and imagery, inside the application rather than on the home page. Draft 1 described a provenance globe on the home page loading tiles from CARTO. That is no longer how it works: the home page carries no map, and CARTO is not used anywhere. The map, globe, satellite and street-level views inside the signed-in application load tiles and imagery from Esri ArcGIS Online, OpenFreeMap, an Amazon S3 elevation-tile bucket, and Panoramax. Each request discloses your IP address, your user agent, and the coordinates and zoom level you are viewing, to that provider under its own terms. For an intelligence product the coordinates are the sensitive part: what you look at can reveal what you are working on. Two further imagery sources, Google Street View and Mapillary, are compiled in only when build-time keys are present; whether the production build carries those keys is an open item below.

Our hosts keep ordinary request logs, which include IP address, timestamp, path and user agent. Two hosts see that traffic: Cloudflare, Inc., which terminates TLS and serves the web application and the edge API, and Fly.io, Inc., which runs the backend API. Each keeps its own logs under its own terms and its own retention, and we have not yet obtained either retention period in writing — an open item below. Cloudflare additionally derives a short-lived per-IP key at the edge to rate-limit abusive traffic.

2.2 Platform accounts

To hold an account you give us, or your administrator gives us, a username, a display name, an email address and a role (client, researcher, team or administrator). We store a password verifier — never the password itself — and we create sessions when you sign in.

2.3 Sign-in state in your browser

When you sign in from the website, we store a session token and a small session record — your username, display name, role and the session expiry — in your browser's local storage, so the application can recognise you. That is not a cookie and it is not sent to third parties. Signing out, or clearing site data, removes it. If your browser blocks local storage, the application will simply ask you to sign in again.

2.4 Activity and audit records

The platform keeps an audit log: sign-ins, failed sign-in attempts, account creation and status changes, invitations, exports and downloads. Each entry records the event, the actor, a short detail string and a timestamp. This exists because a data business that cannot say who touched a record is not selling provenance. The log is capped at the most recent 5,000 entries, after which the oldest are dropped; that is a real limit on how far back the log reaches, and we would rather state it than let you assume the history is complete.

Verification and arbitration decisions record the identity of the person who made them, permanently, as part of the record. That is the product.

2.4.1 The War Room access ledger, which Draft 1 did not disclose

When you join a War Room voice session we write one row to a separate access ledger. The row records the timestamp, the event, the room, the organisation, the account, the participant identity and role, whether the session was end-to-end encrypted, your IP address, and your browser's user-agent string.

Your IP address and user agent are personal data, and this is the one place in the platform where we store them ourselves rather than leaving them in a host's logs. The ledger exists so a client can prove afterwards exactly who was in a room, which is the point of a War Room. It is stored in a Cloudflare D1 database, and the row is written server-side when the join token is minted, so a participant cannot suppress it. Administrators of an organisation can read back the most recent 500 rows for their own organisation.

There is no automated purge and no deletion path in the code. Rows written to this ledger stay there until someone removes them by hand. We would rather say that than imply a retention window we do not enforce.

2.5 Requests, messages and correspondence

If you submit a collection request, message our team through the workspace, or email us, we keep the content, your name and address, and the timestamps.

2.6 Researchers and arbiters

For people who do work for us we hold identity and contact details, role and status, engagement and payment records, and a record of the decisions they signed. Arbiter names are disclosed to the client whose batch they arbitrated, under confidentiality; see section 5.2.

2.7 What we do not collect

We do not knowingly collect special-category data (health, biometrics, race, religion, political opinion, sexual orientation, trade-union membership) about visitors or account holders, we do not run advertising profiles, we do not buy personal data from data brokers, and we do not attempt to identify anonymous visitors.

3. Why we use it, and on what legal basis

Where the GDPR or UK GDPR applies, our bases are:

• Performing a contract — running accounts and sessions, delivering engagements, invoicing, and corresponding with you about work in progress.
• Legitimate interests — securing the platform, keeping the audit log, preventing abuse, and a small amount of direct outreach to business contacts about services relevant to their role. You can object; see section 8.
• Legal obligation — tax, accounting and statutory record-keeping.
• Consent — only where we ask for it, for example if you agree to be named as a reference. Consent can be withdrawn at any time.

We do not use personal data for automated decision-making that produces legal or similarly significant effects about you.

4. Machine models and your data

Our platform sends content to hosted third-party models on three distinct paths. Draft 1 described only the first.

• Machine pre-scoring and classification. Record label and description text, and the planner, worker and verifier prompts our swarms run, go over the network to a model-inference provider (section 5.1).
• Reading-room embeddings, which run by default. Text from documents opened in the reading room is sent to our Cloudflare edge worker and embedded by Cloudflare Workers AI. This is on unless an operator turns it off, and the default endpoint is the live production worker. Someone has to act to prevent this transfer; nobody has to act to cause it.
• Voice sessions with Athena. What you say is streamed through LiveKit to Deepgram for transcription, to OpenAI for the reply, and to Cartesia for the synthesised voice.

Three limits and one correction, stated plainly:

• We do not send the audit log or staff records to any model provider.
• Correction to Draft 1, which said we send no account data to any model provider. On the voice path we do. When you are signed in, your account identifier is written into the system prompt Athena's language model receives, so that it knows who it is speaking to, and that identifier reaches OpenAI. Draft 1's blanket statement was wrong, and we are not leaving it standing.
• Client batch content is sent for pre-scoring only where the client's SOW permits it. A client who cannot permit that transfer must tell us before intake, and the batch is then run without machine pre-scoring. That is currently a contractual arrangement between us and the client, not a switch in the API — so it depends on us honouring it, not on the software refusing.
• On-premise and air-gapped deployments send nothing to any of these providers. Every outbound model, embedding and grounding route is forced empty in that configuration, and the model may only be pointed at a service running inside the customer's own enclave.

We do not use your personal data to train models of our own. Non-training is the recorded default for every tenant, held as policy state and written to the audit trail when it changes, rather than being only a sentence in this policy.

We have not obtained zero-retention terms in writing from any of these providers. Until we do, how long each keeps what it receives is that provider's answer to give, and we are not going to guess it on their behalf.

5. Who else sees it

5.1 Sub-processors and service providers

The register in Annex III of the [Data Processing Addendum](./data-processing-addendum.md) was written before the audit behind Draft 2 and is now known to be out of date in several respects. It is being rewritten. Until it is, where the two disagree, the list below is the newer one.

The following companies receive data:

• Fly.io, Inc. — application and database host, in Fly's lax region, which is Los Angeles, California, United States. It runs the backend API and our self-hosted catalogue stack, and holds the durable volume the platform's state rests on: account records including password verifiers, submissions, collection requests, billing state, call transcripts and the audit log. This is the broadest access any provider has. Correction to Draft 1, which said the platform ran on infrastructure under our own physical control and was not deployed on a third-party cloud host. It is, and on the evidence of the deployed configuration it has been for some time.
• Cloudflare, Inc. — edge compute, web hosting and storage. It serves the web application and the edge API, terminates TLS, mints voice-session join tokens, and stores two databases of ours: the War Room access ledger described in 2.4.1, which holds IP addresses and user agents, and the mailbox for our own @metisfoundry.com mail, which holds message bodies, metadata and attachments. No data-residency setting is configured on any of that storage, so we cannot tell you which country it rests in. See section 6.
• Cloudflare Workers AI — the same company, but a separate content path. It runs the models behind reading-room embeddings, text and image understanding, and the edge worker's speech synthesis and transcription. Whether Cloudflare runs those model weights itself or forwards to the vendors named in the model identifiers is a question only Cloudflare can answer, and we have not yet asked it.
• LiveKit, Inc. — real-time voice and data transport, the host of the Athena agent process itself, the gateway through which the three voice providers below are reached, and the operator of our inbound phone line. It receives live audio in both directions, room and participant metadata, join tokens, and everything the agent handles during a session.
• Deepgram, Inc. — transcribes your speech during voice sessions, reached through LiveKit.
• OpenAI, L.L.C. — generates Athena's spoken replies, reached through LiveKit. It receives your transcribed speech and, when you are signed in, your account identifier. See section 4.
• Cartesia, Inc. — synthesises Athena's voice, reached through LiveKit. It receives the text Athena is about to speak, which can quote material supplied during the session.
• A model-inference provider for pre-scoring and swarm work. The configuration checked into our source control names OpenRouter, Inc., a United States company that routes onward to third-party model hosts. The value actually deployed is held as a secret we cannot read from source control, so we describe it as the configured provider rather than assert it, and confirming it is an open item below. Which model hosts OpenRouter forwards to, in which countries, and on what retention terms, we do not know.
• Resend, Inc. — sends and receives our email, including the mail plane behind our own @metisfoundry.com addresses. It receives recipient addresses, subjects, and full message bodies.
• Stripe, Inc. — payment processing. It receives the billing email address, the plan, the amount and the currency. It does not receive client content.
• Google LLC — serves the fonts on every page load. It receives your IP address, user agent and referring page. See 2.1.
• esm.sh — serves a JavaScript module on the voice pages, and receives your IP address and user agent when it loads. See 2.1.
• Esri, OpenFreeMap, Amazon Web Services and Panoramax — map tiles, terrain elevation and street-level imagery inside the application. Each receives your IP address and the coordinates you are viewing. See 2.1.
• A telephony carrier we have not yet identified. Our inbound phone line terminates through LiveKit's SIP trunk, and some carrier terminates the public-telephone leg of that call. Nothing in our own systems names it. It handles call metadata and possibly call audio, which makes it a sub-processor, and identifying it is an open item below.
• A self-hosted collaborative workspace (APITable) holds collection requests, verification decisions and client-team messages, including the names and email addresses of the people involved. It is software we run ourselves rather than a service we buy, so it is not a separate company with access to our data; it sits on the hosting described above.
• Professional advisers, accountants, payment and banking providers, for invoicing and statutory records.

One thing worth stating positively, because it is unusual: no analytics, error-tracking, session-recording or observability vendor receives anything at all. We checked for the whole familiar set and found none of them wired in anywhere.

5.2 Clients

Where you are a researcher or arbiter, the client whose work you arbitrated sees your name and role in the delivery manifest. Clients are contractually barred from publishing it, contacting you outside agreed channels, or recruiting you on the strength of it.

5.3 Upstream data sources

Public and licensed feeds — for example USGS, NASA EONET, NOAA, Open-Meteo, OpenSky Network, Celestrak, MarineTraffic and GDACS — are sources we read from.

Correction to Draft 1, which said we send them requests and nothing else. Most of the time that is true, but not in the verification pipeline. When our verification engine corroborates a submitted record, it sends that record's latitude and longitude as query parameters to the corroborating source: Nominatim (run by the OpenStreetMap Foundation), Open-Elevation, Open-Meteo, USGS, EMSC and the OpenSky Network. Nothing else goes with it — no identifiers, no record text, no account data — but a coordinate taken from a client's record is client data, and saying otherwise would have been wrong.

Separately, when you type a place name into the workspace, a War Room or an Athena action, that search string and your browser's IP address go to Nominatim from your browser.

5.4 Nobody else

We do not sell personal data, we do not share it for cross-context behavioural advertising, and we do not disclose it to third parties for their own marketing. We would disclose it if legally compelled, and in that case we will notify the affected person or client where we are lawfully able to.

6. International transfers

Metis is established in the United States (State of Delaware).

One processing location is pinned in our configuration and we can state it: the backend API, its state volume and the catalogue stack run in Los Angeles, California, United States. That volume is where account records, password verifiers, submissions, requests, billing state and the audit log physically rest.

Every other location is not established, and we are not going to imply otherwise. Cloudflare — which holds the War Room access ledger with its IP addresses, our mailbox database and its attachments, and which runs the embedding and edge inference models — carries no data-residency or jurisdiction setting on any of that storage, so its physical region is unknown to us. The same is true of LiveKit Cloud, which carries voice sessions; of Resend, which carries our email; of Stripe; and of the model-inference provider, which is a United States company but forwards to model hosts whose locations we do not know. Each of those regions must be obtained from the vendor in writing and recorded here. None has been.

If you are in the EEA, the UK or Switzerland, assume for now that your data is processed in the United States and possibly elsewhere.

Being straightforward about the state of this: we have not yet executed Standard Contractual Clauses or the UK International Data Transfer Addendum with our sub-processors, and we are not certified under the EU-US Data Privacy Framework. Putting those in place is on the list ahead of any EEA or UK client engagement, and it is one of the open items at the end of this document. Do not read this section as a claim that a transfer mechanism is already in place.

7. How long we keep it

Read this section knowing one thing about the software: the platform has no automatic deletion. Retention is a per-tenant policy value with no clock attached by default, and deletion is a workflow — a request is recorded, then an administrator executes it deliberately and the execution is written to the audit trail. Nothing expires on its own. So the entries below describe what we do, not what the code enforces on our behalf, and we are not going to state periods the software would not meet.

• Account records — for the life of the account. Closing an account does not start a timer; removal is a deliberate administrative action someone has to take, and it is logged when they take it. Draft 1 named a number of months here. There is no such clock, so the number is gone rather than left standing as a promise.
• Sessions — until sign-out or expiry, whichever comes first. A session expires 14 days after it is created, and can be revoked centrally before then. Download tokens expire after five minutes.
• Audit records — the most recent 5,000 entries; older entries are dropped automatically as new ones arrive. This is the one retention limit the code does enforce by itself.
• War Room access ledger — indefinitely. There is no purge and no deletion path in the code, so the IP addresses and user agents described in 2.4.1 remain until they are removed by hand. Giving this ledger a retention period is an open item below.
• Correspondence and requests — kept until removed. Mail in our own mailboxes is deleted when it is deleted from the trash folder, and workspace requests and messages persist until an administrator purges them. There is no age-based expiry on either.
• Contract, invoicing and tax records — as long as the applicable statutory period requires. That period follows from the jurisdiction of establishment, which is not yet fixed, so no number is stated here: [TAX RETENTION — set by the jurisdiction in section 12].
• Verification and arbitration attributions — retained as part of the record they attest to. Removing the name would destroy the provenance claim the record exists to make, so these are retained for the life of the record; if you were the verifier and object, tell us and we will discuss what can be done without falsifying the record.
• Client batch content — governed by the client's retention window, not this policy. See the DPA.

7.1 What "deleted" means here

The same honest caveat that appears in our Terms and DPA applies to this policy. Our state store has no delete primitive: deletion is performed by overwriting the document that held the data, and afterwards it is unreachable through any code path in the platform. The store has two backends and the caveat differs slightly between them. On the Postgres backend the overwritten row leaves a dead tuple until the database reclaims it. On the file backend — which is what a single-machine deployment falls back to — deleting one record rewrites the whole JSON document, and the previous contents remain in the volume's free space, and in any volume snapshot already taken, until they are overwritten or the snapshot expires. Either way, deletion does not reach into filesystem free space or into backups already taken. This is contractual, application-level deletion, not cryptographic erasure. We will not describe it as unrecoverable.

Two stores sit outside even that. The War Room access ledger has no deletion code path at all (2.4.1), and the audit log is append-only and trimmed by age rather than by subject, so a deletion request cannot remove an entry from it without breaking the trail it exists to provide.

8. Your rights

Depending on where you live you may have the right to access your personal data, correct it, delete it, restrict or object to processing, receive it in a portable form, withdraw consent, and — under the GDPR and UK GDPR — complain to a supervisory authority. Under the CCPA/CPRA you may also have rights to know, delete, correct, and to opt out of sale or sharing; we do not sell or share personal data as those terms are defined, so there is nothing to opt out of.

We will not discriminate against you for exercising a right.

8.1 How to ask

Email privacy@metisfoundry.com with what you want.

We will respond within one month, which is the maximum the GDPR and UK GDPR allow, and within 45 days where the CCPA applies. If we need the extension those laws permit, we will tell you before the original deadline passes and say why.

8.2 Verification

We will take reasonable steps to confirm you are who you say you are before acting, because acting on an unverified deletion request is itself a breach.

8.3 Limits

We may decline where a right does not apply — for example, where we must keep a record for tax purposes, or where deleting a verification attribution would falsify a provenance record that a client relies on. We will explain which exemption we are relying on rather than simply refusing.

8.4 If your data is inside a client's batch

Then the client is the controller and we are the processor: we cannot lawfully act on your request without their instruction. Tell us anyway. We will identify the client, pass the request to them without delay, and tell you that we have done so, unless the client's contract or the law requires otherwise.

8.5 Supervisory authorities

If the GDPR or UK GDPR applies to you, you may complain to your local supervisory authority. Note, honestly, that we have not appointed an EU or UK representative under Article 27, and we have not designated a Data Protection Officer. Whether we are required to do either depends on our final establishment and processing profile, and it is an open item below.

9. Security

Our technical and organisational measures, and the measures we do not have, are set out in full in Annex II of the Data Processing Addendum. In short: passwords are stored as PBKDF2-HMAC-SHA256 verifiers with 600,000 iterations and a per-account salt; sessions are opaque random server-side tokens that expire and can be revoked centrally; reads are scoped to the requesting account; downloads use short-lived, single-dataset tokens; and everything material is written to the audit log.

We hold no security certification — not SOC 2, not ISO 27001, not FedRAMP — and we have not completed an independent penetration test. Section 7.2 of our Terms of Service states that in full.

10. Children

The platform is a business tool sold to organisations. It is not directed at children, we do not knowingly collect data from anyone under 16 — or under the higher age where local law sets one — and we have no consumer sign-up flow. If you believe a child's data has reached us, tell us and we will delete it.

11. Changes

We will update this policy as the company changes — particularly when the corporate blanks in section 12 are filled, when vendors give us the processing regions and retention terms section 6 says we do not have, when transfer mechanisms are executed, and when the certification position in section 9 changes. Material changes will be dated at the top, and existing clients and account holders will be notified by email.

12. Contact

I Am Violet Inc, operator of the Metis platform
8 The Green, Dover, Delaware 19901, United States

• Privacy questions and data-subject rights — privacy@metisfoundry.com
• Legal notices — legal@metisfoundry.com
• Security vulnerabilities — security@metisfoundry.com
• Anything else — hello@metisfoundry.com

The entity name and registered address above come from the company's own incorporation record. Metis is the name of the platform; it is not a separate legal person, and no notice served on it reaches anyone other than I Am Violet Inc.