Privacy Policy

Data about you. The account you hold, the organisation it belongs to, and your use of this site. We decide why and how this is processed, so it is ours to answer for.

Material you give us about other people. The corpus you upload, the cases mined from it and the answers your system produces when we run them. We process this on your instructions, for the service you have contracted for. The people in it are usually your customers rather than ours.

• Account. Your name, your email address, a hash of your password, and the sessions you open. The product sets one session cookie and no others.
• Organisation. The organisation you belong to and the systems and deployments registered under it.
• Audit. Who changed a test case, who triggered a run, who issued or revoked a key, and when. This is part of what makes the record independent, so it is not optional and it is not shortened on request.
• Correspondence. What you send us, when you send it.

This marketing site collects nothing. It is a set of static pages. There is no analytics, no tag manager, no embedded third-party script, and it sets no cookies.

The public exposure checker takes the model identifiers you paste into it and answers with their retirement dates. It has no account, no tenancy and no database beyond its cache of the providers' own published deprecation pages.

To run the service: to build and hold your test set, to execute it against your system on the cadence you have set, to produce reports and evidence packs, and to tell you when a model you depend on is retiring.

To operate and secure the service, and to bill for it. To answer you when you write to us.

We do not train models on your material, we do not sell it, and we do not use one customer's material to serve another.

It is parsed in a sandbox that holds no database access and no key material. The text that comes out is re-validated against a schema, and then de-identified in memory, in the model host, before the first durable write. Only then is it chunked, embedded and stored, and content hashes are computed after de-identification rather than before it.

The claim is precise, because the loose version of it is false. We do not claim that personal information never touches our infrastructure - your document arrives, so it does. We claim that raw source objects and parser output live nowhere but a short-retention store, and that everything downstream of de-identification has never held an original identifier. The second claim is the one made of things that can be pointed at, and it is the one we stand behind.

De-identification is measured rather than asserted: a labelled corpus, a published recall number, and an escalation path for spans the first pass is unsure about. What it detects and what it misses is part of what we will show a security review.

The service runs as one self-contained cell per jurisdiction - one network, one database, one entry point. No customer data crosses a cell boundary, and that includes backups, logs and error traces, which is where residency is usually lost rather than in the database.

Two things sit outside every cell: the tenant metadata needed to route you to yours, and this marketing site. Neither holds customer content.

• Amazon Web Services - all compute, database, object storage, key management and outbound email, in the region of your cell.
• A model provider, for our own calls. Building a test set involves model calls that we make, rather than the ones your system makes. These carry de-identified material only, because they happen downstream of clause 4. The endpoint is configurable, and which provider serves your cell is disclosed on request.

Your system's own model calls are not ours. A verification run sends a test case to an endpoint you implement, inside your infrastructure; whatever your pipeline then calls, it calls under your own arrangements and not under ours.

We will tell you before adding a sub-processor that touches customer material.

• Raw uploads and parser output: a short-retention store, deleted once the de-identified version is committed. There are two mechanisms, because one is not a guarantee: an explicit delete on commit, and a lifecycle rule as the backstop for when that delete does not run.
• Test cases, runs and results: for the term of your agreement, and deleted on the timetable it sets.
• Sealed evidence packs: retained under a write-once policy for the period your agreement records. A sealed pack cannot be deleted on request, because a record that can be withdrawn is not evidence. Content captured alongside one is bound to it by hash and stored separately, so that content can be deleted while the seal survives.
• Account and audit data: for the term, and then as long as we need it to evidence what the service did.

Deletion is the deletion of rows and objects. We do not claim crypto-shredding: a per-tenant key that could make deletion a key deletion is designed and not yet built, and describing the weaker promise as the stronger one is exactly the overstatement this business is selling against.

Tenant isolation is enforced twice - once in the application, and again inside the database with row-level security, under roles that are not permitted to bypass it. Storage and database are encrypted with managed keys. The component that parses untrusted uploads holds no database credential and no key material.

Nothing here is a claim that we cannot be breached.If customer material is affected by a security incident, we will tell you.

You can ask us for a copy of the data we hold about you, ask us to correct it, or ask us to delete it, subject to clause 7.

A request from one of your customers comes to us through you. We hold their material on your instructions and have no relationship with them, so we act on your instruction rather than going around you - and clause 4 is the reason most such requests can be answered without us at all.

The version line at the top changes when this policy does, and a material change is notified to account holders by email before it takes effect.

Privacy questions, and any request under clause 9: privacy@presoja.com.