COR

Privacy statement

This statement describes the personal data COR processes, limited to what the product code and configuration actually do. Anything unconfirmed is marked as a visible decision point.

Version of 13 October 2026. This page is not meant to be indexed.

1. Who is responsible

COR is the brand name of the service on cor.today (marketing) and app.cor.today (app). COR is offered by a private individual, not by a legal entity.

The controller is cor.today. There is no postal address and no Chamber of Commerce registration. Contact goes through the existing route on cor.today.

2. What this statement covers

This statement covers the marketing site cor.today (including www.cor.today), the start flow on /start, creating an account, and using the COR app. Demo routes are a local sandbox and do not write production data.

3. Marketing, website analysis and onboarding

If you enter a company website on cor.today or /start, COR creates an onboarding run. COR stores the requested domain, the run status, and a summary of what was found on the public website. That summary may include company name, description, products or services, location details, phone, email and source pages when those appear on the site.

For the analysis COR fetches the public website. Services that only read that public page are not recipients of your personal data.

To limit abuse, COR counts new requests per IP address (at most 5 per hour) and per domain (at most 3 per day). The IP address comes from the x-forwarded-for or x-real-ip request headers. Those counters are stored in the database.

Each run has a secret viewer token. COR stores it in the HttpOnly cookie cor_onboarding_run_tokens (at most 6 runs, 24 hours). The active run id is in the HttpOnly cookie cor_onboarding_current_run (24 hours). Both cookies are host-only: they are not set on .cor.today. The page also keeps the run id in sessionStorage as cor:onboarding-run-id, for the interface only.

If you continue from the marketing host to the app, COR creates a one-time handoff. The database stores only a hash of that token, valid for at most 5 minutes. The app then exchanges the handoff for the viewer token in cookies on the app host.

If you enter an email address after onboarding to log in, COR may keep that address together with the viewer token for 2 hours as a login intent, so the run can be linked to your account.

4. Accounts, users and organisations

After registration COR stores a profile linked to your login account, with email address and name. An organisation has a name and a slug. Membership has a role: owner, admin or member.

Invites contain email address, role and who invited. They expire after 14 days if not accepted. Requesting an organisation stores email address, requested organisation name and optionally a domain. Password registration may put name, organisation name and accounts to follow in account metadata.

In the app an organisation can follow companies or accounts. COR stores those accounts, sources, signals, opportunities and who may see which account. That is the core of the service: which account deserves attention, why, and what to do next.

5. Sign-in

Sign-in goes through the sign-in service of the hosting and database provider. Sessions live in cookies that that service sets through the app. Application code does not hardcode auth.cor.today as the sign-in host.

  • Email code: COR sends a one-time code through the sign-in service, not through product mail. Local configuration uses a 6-digit code that expires after 3600 seconds. Whether those settings also apply in production is not in this repository.
  • Password: sign-in and registration with email and password, plus password reset via a recovery code.
  • Signing in with an external account, if you choose that option.

Sign-in mail goes through the sign-in service. The From address of those messages is not in this repository. The address login@cor.today does not appear here.

6. Email

Product mail (morning email, invites, welcome and profile messages) goes through an email service. The From address comes from environment configuration; the production value is not in this repository.

The morning email goes to members of an organisation. COR may send an internal copy of a customer digest to a fixed internal owner address.

7. Monitoring, logs and internal review

COR fetches public sources (including news, vacancy pages and tenders). Text from those sources may go to an AI service provider for classification. An internal audit trail may be stored.

Clicks in the morning email are recorded (organisation, digest, time). In server logs COR masks the full email address of digest recipients. Hosting logs are not configured in application code.

There is no automated privacy wipe or tombstone in production. Deleting customer data is described in the code as manual.

8. Cookies, measurement and consent

COR does not show a cookie banner and has no consent platform. On cor.today and www.cor.today the site loads an analytics service with measurement id G-16F6JJ8GFE (page URL and page title). That measurement is not loaded on app hosts.

All hosts load analytics services. Funnel steps (such as landing viewed, website submitted, registration, first dashboard visit) go to analytics services. Those events do not include email, name, website or run id. COR stores attribution (UTM and referrer class) in the cor_funnel cookie for 30 days, SameSite=Lax. Fired events sit in sessionStorage under cor:funnel-fired.

COR also uses, among others: cor_onboarding_run_tokens and cor_onboarding_current_run (24 hours, HttpOnly), cor_activation_invite (1 hour, HttpOnly), cor_platform_org (30 days, HttpOnly) and the session cookies of the sign-in service. Application code does not set its own retention for those. In local configuration the access token is valid for 3600 seconds. The production retention of session cookies is not in this repository.

9. Processors and other parties

COR shares personal data only with these categories of processors:

  • Hosting and database providers.
  • Email service.
  • Analytics services.
  • Sign-in services, if you sign in with an external account.
  • AI service providers.

Some service providers may process data outside the EEA; we choose providers that offer appropriate safeguards.

10. Retention

As a general rule we keep personal data for 14 days. Specific periods used by the service:

  • Onboarding cookies: 24 hours.
  • Handoff token: at most 5 minutes; then it cannot be exchanged. There is no cron that deletes expired rows.
  • Login intent: 2 hours.
  • Organisation invite: 14 days.
  • Signup quota per IP: 1-hour window.
  • Signup quota per domain: 24-hour window.
  • Funnel cookie: 30 days.
  • Platform-org cookie: 30 days.
  • Activation-invite cookie: 1 hour.
  • Local configuration: one-time code 3600 seconds. The production value is not in this repository.

12. Your rights

If the GDPR applies, you may among other things request access, rectification, erasure, restriction, portability and objection, and lodge a complaint with a supervisory authority.

The app has no self-service wipe. Erasure is described in the code as manual.

You exercise those rights through the existing route on cor.today.

13. Changes

If processing in the product code changes, this statement should change with it. This page stays noindex and out of the sitemap until it is released.