SPARKS Privacy and Compliance Statement
Privacy as architecture, not policy
SPARKS was designed from its first line of code around a simple principle: relational intelligence belongs to the individual it describes. The platform’s core architecture is built to deliver mental-state-aware personalization without exposing mental-state data; insights are computed for the user, held by the user, and shared only through mechanisms the user explicitly controls.
This is reflected in concrete design decisions rather than policy language alone. Analysis is user-initiated: SPARKS browser integrations operate on manual trigger only, with no ambient scanning, no background collection, and no processing of content the user has not deliberately submitted. Identity is decoupled from insight: mutual recognition between SPARKS users operates through opaque, randomly generated identifiers that carry no personal information and cannot be reversed into it. Organizational analytics are structurally anonymized: aggregate workforce insights enforce k-anonymity with a minimum cohort threshold of ten, meaning no reporting view can ever isolate, or be narrowed to, an individual; below threshold, the data simply does not render. Individual profiles are never visible to employers, and no individual-level data flows from a user’s SPARKS instance to any organizational customer.
California (CCPA/CPRA)
SPARKS treats behavioral and inferred psychological data as sensitive personal information under the CPRA’s heightened standard. Users receive notice at collection, purpose limitation is enforced at the architecture level, and the platform supports the full set of California consumer rights: access, deletion, correction, portability, and the right to limit use of sensitive personal information. SPARKS does not sell personal information and does not share it for cross-context behavioral advertising; there is no advertising use of user data anywhere in the platform.
European Union (GDPR and EU AI Act)
SPARKS aligns with GDPR’s requirements for special-category data, processing psychological and behavioral information on the basis of explicit consent, with data minimization, purpose limitation, and storage limitation implemented as system constraints rather than manual procedures. Users hold the full complement of data-subject rights, including erasure and portability, and consent is granular and revocable at any time. With respect to the EU AI Act, SPARKS is architected as a user-controlled self-insight tool rather than an employer-directed monitoring system: analysis serves the individual who initiates it, outputs are delivered to that individual alone, and organizational reporting is confined to k-anonymized aggregates that support wellbeing programs without evaluating any person.
HIPAA (United States)
SPARKS is built HIPAA-ready for delivery through employee assistance programs, insurers, and other covered entities. The platform implements the administrative, physical, and technical safeguards contemplated by the Security Rule, including encryption in transit and at rest, role-based access controls, audit logging, and documented breach notification procedures, and Memores is prepared to execute business associate agreements as part of any engagement involving protected health information. The platform’s minimum-necessary posture is structural: because individual insights never leave the individual’s control, the protected health information surface is kept deliberately small by design.
Canada (PIPEDA)
Memores builds to PIPEDA’s ten fair information principles as its baseline worldwide. Meaningful consent, identified purposes, limited collection, and individual access are implemented natively, and the manual-trigger design directly operationalizes PIPEDA’s requirement that collection be limited to what a reasonable person would consider appropriate in the circumstances.
The common thread
Most platforms treat these four regimes as four compliance projects. SPARKS treats them as one design brief: collect only what the user deliberately provides, compute insight for the user rather than about them, and make individual identification mathematically unavailable in every aggregate view. Compliance obligations are easier to meet when the architecture never creates the risk in the first place.