01What cookies and similar technologies are
A cookie is a small text file a site asks your browser to store and send back with later requests to the same site. It is how a server recognises that two requests came from the same browser — which is the only reason you stay signed in when you move between pages. A cookie is set by a name, a value, an expiry and a scope; it holds no code and can do nothing on its own.
“Similar technologies” covers everything that achieves the same effect by another route, and this policy treats them identically:
- First-party cookies — set by cortext-ai.uk itself, or by a vendor operating on a cortext-ai.uk subdomain. Every cookie in the table below except the four marked third-party is first-party.
- Third-party cookies — set by another domain whose script runs on a page you opened, such as the payment or identity-verification screens. See third parties.
- Local storage — a browser store that holds data indefinitely and is never sent to a server automatically. We use it for the 4 keys in the local-storage table.
- Session storage — the same idea, cleared when the tab closes. We do not currently use it.
- Pixels and web beacons — one-pixel images used to record that a page or an email was opened. We do not use them anywhere, including in transactional email; we cannot tell whether you opened a payout notice.
- Device fingerprinting — inferring an identifier from your browser configuration. We do not do it for tracking. Our edge provider does evaluate request characteristics to distinguish a browser from a bot, and records only the outcome, in cx_bot.
This is version 2.4 of the policy, published 6 July 2026 and effective 20 July 2026, superseding version 2.3, effective 11 november 2025. It sits alongside the Privacy Policy, which explains what we do with the data these technologies produce, and the Contributor Terms of Service.
02The four categories in use
Every cookie we set falls into exactly one of four categories. The consent banner controls three of them; the fourth is set regardless, because without it the site does not work.
Strictly necessary — 7 cookies
Sign-in state, the anti-forgery token that must accompany every form submission, the regional routing pin that serves an EEA contributor from the Ireland deployment, the automated-traffic check, and the fraud-prevention cookies set by Stripe and Veritas ID on the payment and verification screens. These are exempt from consent under Article 5(3) of the ePrivacy Directive because they are strictly necessary to provide a service you requested. They cannot be switched off in the banner, and blocking them in your browser means you cannot sign in, submit a form or set up a payout.
Functional — 3 cookies
Preferences that make the product remember you between visits: language, date format and currency display; the Explore board tab, sort order and filters you last used; and the referral code from a referral link, so the referrer is credited. Declining these costs you nothing except convenience — you will re-set filters each visit, and if you arrived via a referral link the referrer may not be credited.
Analytics — 2 cookies
First-party product analytics through Tandem Analytics, processing in Sweden. They count page views, distinguish one browser from another with a random identifier that contains no name or email, and group views into a visit so we can measure how many people who start an application finish it. There is no cross-site identifier and the data is not combined with any other company’s. Declining changes nothing about your experience; it removes you from the funnel numbers.
Performance — 2 cookies
Real-user monitoring through Sitewatch Telemetry: page-load and interaction timings, and the correlation identifier that ties a browser error report to the matching server request so a fault can be reproduced from both ends. Request bodies and form values are redacted in your browser before anything is sent, so a crash report cannot carry a half-typed application out with it.
03What we do not do
Cortext Labs, Inc. sets no advertising cookies and no cross-site tracking cookies. There is no ad network on this site, no retargeting pixel, no conversion tag, no social media tracker and no data-broker integration. We do not build advertising profiles, we do not sell or share personal information for cross-context behavioural advertising as the CCPA defines those terms, and we do not participate in real-time bidding.
The reason is structural rather than principled restraint: Cortext makes money from AI labs paying for expert work, so there is no advertising business here that would need funding by tracking you.
We also do not: read cookies set by other sites (we cannot); track you across the web after you leave cortext-ai.uk; use tracking pixels in email; fingerprint your device to build an identity; or store the contents of your CV, submissions or messages in a cookie.
Introducing any of these would require a new consent category, a change to the banner, a new version of this policy and 30 days’ notice under changes. It is not something that could happen quietly.
04Every cookie we set
This list is complete for cortext-ai.uk as at 20 July 2026. Four entries are third-party cookies set by Stripe and Veritas ID, and they load only when you open a payment or verification screen — they are absent on every other page, including the whole of the public site.
| Name | Set by | Category | What it does | Lifetime |
|---|---|---|---|---|
| cx_session | Cortext | Strictly necessary | Keeps you signed in between page loads and ties the browser to one authenticated contributor record. | 30 days, or until you sign out |
| cx_csrf | Cortext | Strictly necessary | Carries the anti-forgery token that must accompany every form submission, so a third-party site cannot post to Cortext as you. | 12 hours |
| cx_route | Beacon Grid Networks | Strictly necessary | Pins your requests to the region that holds your account data, so an EEA contributor is served from the Ireland deployment. | Session |
| cx_bot | Beacon Grid Networks | Strictly necessary | Records the outcome of an automated-traffic check so a legitimate browser is not re-challenged on every request. | 30 minutes |
| cx_locale | Cortext | Functional | Remembers the language, date format and currency display you selected, so it survives sign-out. | 12 months |
| cx_board_prefs | Cortext | Functional | Remembers the Explore board tab, sort order and any filters you had applied when you last left the page. | 6 months |
| cx_ref | Cortext | Functional | Holds the referral code from a referral link so the referrer is credited if you go on to be engaged. | 30 days |
| _tandem_id | Tandem Analytics | Analytics | Distinguishes one browser from another for aggregate product analytics. Contains a random identifier, no email or name, and is never shared across sites. | 13 months |
| _tandem_ses | Tandem Analytics | Analytics | Groups page views into a single visit so completion rates for the application flow can be measured. | 30 minutes |
| sw_rum | Sitewatch Telemetry | Performance | Samples page-load and interaction timings and links them to any JavaScript errors raised in the same visit. | 24 hours |
| sw_trace | Sitewatch Telemetry | Performance | Correlates a browser error report with the matching server request so a failure can be reproduced from both ends. | Session |
| __stripe_mid | Stripe | Strictly necessary | Set by Stripe on the payout setup and tax-form screens for fraud prevention. Only loads once you open a payment screen. | 12 months |
| __stripe_sid | Stripe | Strictly necessary | Stripe session identifier used for fraud prevention during a single payout-setup session. | 30 minutes |
| vid_session | Veritas ID | Strictly necessary | Maintains the identity-verification session while you photograph your ID and record the liveness check. Set only on the verification screen. | 24 hours |
Lifetimes are maximums. “Session” means the cookie is deleted when you close the browser. Signing out clears cx_session immediately regardless of its stated lifetime.
05Local storage — including the two keys this build actually uses
The keys below are written to your browser’s local storage, not set as cookies. The practical difference matters: local storage is not transmitted with every request, so it is invisible to the server unless the page deliberately reads it and sends it — but it has no expiry and survives closing the browser until something clears it.
| Name | Set by | Category | What it does | Lifetime |
|---|---|---|---|---|
| cortext_auth | Cortext | Strictly necessary | Marks the browser as signed in. In this build it is the whole of the sign-in state — there is no server session behind it yet. | Until you sign out or clear site data |
| cortext_pending_job | Cortext | Strictly necessary | Holds the id of the opportunity you were applying to when you were asked to sign in, so the application resumes on the right role afterwards. | Until the application is submitted or you clear site data |
| cortext_cookie | Cortext | Strictly necessary | Records your answer to the consent banner — accept all, or essential only — so the banner is not shown again. | Until you clear site data |
| cx_draft_application | Cortext | Functional | Keeps an unsent application form on your device so a refresh or a dropped connection does not lose what you typed. Cleared on submission. | 14 days from last edit |
cortext_auth and cortext_pending_job are real, and are worth understanding
In this build these two keys are not a description of something happening on a server — they are the mechanism itself, written by lib/session.ts in the application source. cortext_auth is the whole of the sign-in state: there is no server session behind it yet. cortext_pending_job holds the id of the opportunity you were applying to when you were asked to sign in, so the application resumes on the right role afterwards.
- Both are local storage, not cookies. Deleting cookies alone will not remove them; you have to clear site data.
- Anyone with access to your device can read them, and clearing them signs you out immediately.
- Because sign-in state lives on the device rather than the server, do not use a shared or public computer for Cortext until server-side sessions ship. The security section of the privacy policy says the same thing and explains what will replace it.
- cortext_cookie is written by the consent banner and records whether you chose accept-all or essential-only. Clearing it brings the banner back.
06Changing your choices
The consent banner
The banner appears on your first visit, a moment after the page loads, and offers two answers: accept all, or essential only. Choosing essential only leaves the functional, analytics and performance cookies unset. Your answer is recorded in the cortext_cookie local-storage key described in the previous section, so the banner does not ask again.
Nothing about your application, your matching, your rate or your pay depends on the answer. There is no cookie wall, no reduced functionality tier and no repeated prompting for people who declined. We do not treat “essential only” as an invitation to ask again next week.
Changing an answer you already gave
- Clear site data for cortext-ai.uk in your browser, which removes cortext_cookie along with the cookies. The banner returns on your next visit and you can answer differently.
- Clearing site data also removes cortext_auth, so you will be signed out. That is expected; sign in again.
- Or use the browser-level controls in the next section, which work whether or not the site offers a switch.
- If none of that works — an unusual browser, a locked-down device — email privacy@cortext-ai.uk and we will suppress analytics for your account server side.
Withdrawing consent stops future collection. Analytics events already collected are retained for the period in the retention schedule and then aggregated beyond re-identification; you can ask for earlier deletion under the rights section of the privacy policy.
07Browser-level controls
Your browser can block or delete cookies and clear local storage for any site, and those controls override anything a site offers. They are the reliable route.
- Google Chrome — Settings, then Privacy and security, then Third-party cookies for global behaviour. For this site only: open Site settings from the icon at the left of the address bar, then Delete data, which clears cookies and local storage together.
- Apple Safari— Settings, then Privacy. “Prevent cross-site tracking” is on by default and does not affect anything on this site, because we set nothing cross-site. Use Manage Website Data to remove cortext-ai.uk specifically. On iOS and iPadOS the same controls are under Settings, then Apps, then Safari.
- Mozilla Firefox— Settings, then Privacy & Security. Enhanced Tracking Protection sets the global policy; Manage Data under Cookies and Site Data removes cookies and local storage for one site. Firefox reports both under the same entry.
- Microsoft Edge — Settings, then Cookies and site permissions, then Manage and delete cookies and site data, then See all site data to find and remove cortext-ai.uk.
What blocking will actually break
- Blocking all cookies for cortext-ai.uk prevents sign-in and blocks form submission, because the anti-forgery token has nowhere to live. The site will appear broken rather than degraded.
- Blocking third-party cookies only is entirely safe on the public site and in the product, and breaks the payout-setup and identity-verification screens while they are open. Allow them for that one flow, then block again if you prefer.
- Private or incognito windows discard everything on close, including cortext_auth. You will be signed out each time and an in-progress application will not be preserved.
- Browser extensions that block trackers may block Tandem Analytics or Sitewatch Telemetry. That is fine — nothing on the site depends on either — but a blocked error reporter means we cannot see a fault you hit, so tell support@cortext-ai.uk if something breaks.
08Do Not Track and Global Privacy Control
Global Privacy Control
We honour Global Privacy Control. Where your browser or extension sends the GPC signal, we treat it as a valid opt-out request: analytics and performance cookies are not set, and the signal is respected before the banner is ever shown, so you will not be asked to consent to something you have already declined. If you are a California resident, GPC is also treated as a request to opt out of sale and sharing — which changes nothing in practice, because as the previous section on advertising explains, we do neither.
Do Not Track
Do Not Track is a different matter, and the honest answer is more complicated. DNT was never finalised as a standard, no consensus exists on what a recipient is supposed to do with it, and most browsers have removed the setting. We therefore do not treat DNT as a legally significant signal and we do not claim to comply with it. In practice this costs you nothing: we do not track across sites for anyone, DNT or not, and if you want analytics off, the banner and GPC both do that reliably.
California law requires sites to disclose how they respond to DNT, and this paragraph is that disclosure. We would rather say plainly that we ignore an ambiguous signal than imply a protection we do not implement.
09Third parties that set cookies on our pages
3 of the 14 cookies in the tableare set by another company’s domain, and all of them are strictly necessary fraud and session controls that load only on the screens they belong to.
| Third party | Where it loads | Cookies | What it is for |
|---|---|---|---|
| Stripe, Inc. | Payout setup and tax-form screens only | __stripe_mid, __stripe_sid | Fraud prevention during payout onboarding. Stripe is also a controller of the payment data it collects directly from you. |
| Veritas ID, Inc. | Identity verification screen only | vid_session | Keeps the verification session alive while you photograph your ID and record the liveness check. |
Two further vendors — Tandem Analytics and Sitewatch Telemetry — run on cortext-ai.uk subdomains, so the cookies they set are first-party and appear in the main table under their own names. Beacon Grid Networks operates the network edge and sets the routing and bot-check cookies as our processor.
None of these companies may use what they collect here for their own advertising purposes. Each is bound by a data processing agreement, and all 14 processors that touch contributor data are listed with their purpose and processing location in the subprocessor table. Their own privacy notices govern the data they hold as independent controllers, and we link to none of them here because those links go stale — ask privacy@cortext-ai.uk and we will send the current ones.
10Changes to this policy
This is version 2.4, published 6 July 2026 and effective 20 July 2026, superseding version 2.3, effective 11 november 2025. That earlier revision was prompted by moving product analytics onto a first-party subdomain, which is why this policy carries a different date from the Privacy Policy and the Contributor Terms of Service.
Adding a cookie in a category you have already consented to, or replacing a vendor with another doing the same job, is published here and takes effect on publication. Anything that changes what you are consenting to — a new category, a new purpose, a longer lifetime, or the introduction of any advertising or cross-site technology — requires 30days’ notice by email and in the product, and resets the banner so you are asked again rather than carried over.
Prior versions are archived and available from legal@cortext-ai.uk.
11Contact and related documents
Questions about anything on this page go to privacy@cortext-ai.uk, which reaches the data protection officer. Everything at Cortext Labs, Inc. is handled by email; there is no telephone support line and no phone verification, so nobody from Cortext will ever call you about cookies or consent.
- Privacy Policy — what we do with the data these technologies produce, who receives it, how long it is kept, and your rights over it.
- Subprocessors — the full list of processors, including the analytics and telemetry vendors named above.
- Exercising your rights — access, deletion, objection and the one-month response deadline.
- Contributor Terms of Service — the contract governing contributor work, including the acceptable-use rules that prohibit interfering with these controls.