This draft explains how CoreComp handles personal information when people use the website, sign in with Discord, join teams or hubs, participate in ladders or events, communicate through supported features, or contact CoreComp.

The final policy must name the responsible legal entity, mailing address, privacy contact, supported regions, and any feature-specific notices. Those facts are not yet confirmed and must not be inferred from the “CoreComp” brand name.

• Discord authentication: Discord user ID, display name or username, avatar, guild-access information, and official-server member roles needed for sign-in and permissions.
• No Discord email through current sign-in: the current OAuth configuration does not request or store a verified Discord email address.
• Profile and community content: biography, social links, game identities, availability, team/hub membership, roles, logos, and other information a user chooses to provide.
• Competition records: registrations, rosters, check-ins, matches, scores, standings, ratings, disputes, administrator decisions, and evidence submitted through enabled workflows.
• Technical and security records: session, request, error, rate-limit, and security-event information generated when the service is used. The exact production log fields and periods require an engineering inventory.
• Communications: support requests, reports, appeals, and messages sent through CoreComp features or connected workflows.

CoreComp does not currently publish a claim that it collects motherboard identifiers, TPM data, CPU serials, or other hardware fingerprints. If that changes, collection must not begin until the technology, necessity, security, notice, consent, retention, and legal basis are approved.

Information comes from users, Discord, teams and event organizers, competition administrators, enabled service providers, and CoreComp systems. It is used to authenticate accounts, apply permissions, operate profiles and groups, administer competition, display results, prevent abuse, resolve disputes, communicate service information, provide support, improve reliability, and comply with lawful obligations.

The final policy must map each category to its purpose, lawful basis where applicable, system of record, recipients, retention rule, and user controls.

CoreComp may disclose information to infrastructure, authentication, communications, analytics, security, support, payment, payout, identity, tax, or other providers only when the provider is enabled and the disclosure is needed for the service. Public profile, team, hub, ladder, match, and event information is visible according to the product’s published visibility rules.

A production subprocessor list and international-transfer mechanism remain release requirements. CoreComp’s current product design does not include a data-broker sale flow, but counsel must review applicable definitions of “sale,” “sharing,” and targeted advertising before a final statement is published.

CoreComp should retain information only as long as needed for the disclosed purpose, account relationship, competition integrity, dispute window, security need, contractual requirement, or legal obligation. Different categories require different triggers and periods.

Before publication, the retention registry must document the data category, system and provider, purpose, trigger, duration, deletion or de-identification method, backup behavior, legal-hold exception, and accountable owner. Any automated deletion claim requires a deployed job, monitoring, alerts, and auditable results.

Signed-in users can request the current self-service JSON export. The export route now rejects anonymous requests, uses private no-store response headers, and no longer claims to fulfill a specific law or include records the system does not actually package.

Download the current account export

A complete privacy-request workflow still needs authenticated intake, identity verification proportionate to the request, status tracking, authorized staff access, deadlines based on applicable law, appeal handling where required, and a secure response channel.

Depending on location and applicable law, people may have rights to access, correct, delete, obtain, restrict, object to, or appeal decisions about personal information, and to withdraw consent where processing relies on consent. Rights are not universal and may have lawful exceptions.

The final policy must provide a verified request method, authorized-agent procedure where applicable, non-discrimination statement, response timing, identity-verification standard, and region-specific notices.

CoreComp should use access controls, least privilege, encryption in transit, secret management, rate limiting, logging, dependency review, backup safeguards, and incident response appropriate to the risk. No service can promise absolute security.

Tax IDs, government IDs, and guardian identity evidence must not be entered into a CoreComp-controlled form or ordinary email. If those checks become necessary, an approved provider-hosted flow must collect the sensitive values and return only the minimum status CoreComp needs.

CoreComp is not currently designed for children under 13. The final age policy and rules for users aged 13–17 must be approved for each supported region and event type. CoreComp must minimize minor data, protect guardian relationships, and offer revocation or deletion mechanisms required by the approved program.

Each published version must show an effective date and change summary. Material changes may require advance notice or renewed consent depending on the change and applicable law. Prior versions should remain available in an archive.