GRIDYSSEY

Privacy Notice

Version: 2026-10-02.beta.1 Effective date and last updated: 2 October 2026

1. Who is responsible

Gridyssey is operated by Scott Bowes, trading as Gridyssey, at 11 Woodend, Worksop, S80 3HD, United Kingdom. We are the controller of the personal information described in this notice.

For privacy questions, a rights request or a data-protection complaint, email privacy@gridyssey.app or write to that address. Service questions and challenges to moderation decisions can go to support@gridyssey.app; safety concerns to abuse@gridyssey.app; beta feedback to feedback@gridyssey.app.

This notice covers the Gridyssey controlled, non-commercial Android, iOS and Web beta, its APIs and public visit-share pages, support and moderation, and the separate early-access waitlist on gridyssey.com. Public app registration is currently closed. The beta is for people aged 18 or over; new invited registration uses an adult self-attestation and email verification. We do not collect a date of birth or perform independent identity/age verification through that flow. If we learn that someone under 18 has an account, we will review it and take appropriate action.

2. Account, profile and service information

We process your email, username, display name, password hash, account identifiers, role/status, account dates and login information. Your password is stored as a one-way hash, not readable text. You may add a biography, profile image and privacy, distance, offline-transfer and notification preferences.

New invited accounts have verification state, an 18+ confirmation and a dated record of the Terms and Community Guidelines versions accepted and the Privacy Notice version provided. The privacy acknowledgement is not optional marketing consent. We do not retrospectively create these records for existing members merely because a document is published.

We store visits, trips, titles, dates/times, GYS1 grid cells, general place labels, notes, objectives, findings, weather and distance or route-leg information you add or create through the service. Planned Places can include a cell, planned date, approximate distance and status. We create progress, territory, achievement and activity records and technical identifiers/revisions for offline synchronisation.

3. Location and Home Location

A device or browser may give the app a current latitude/longitude, accuracy and capture time after you allow location access. The app can send coordinates to Gridyssey to resolve a GYS1 cell and, where you request it, to obtain a place label or route. Current device permission can be denied or withdrawn; supported features also allow manual place/grid selection. Gridyssey is not designed to continuously track your movements in the background.

A visit may save precise coordinates privately on your account. The current visit record does not save the device accuracy or location-fix time. A visit date/time is the time you declare for the visit, not independent proof of when a location was measured. Uploaded photo metadata can also contain precise coordinates. These saved records are different from a transient current position.

Your Home Location is an approximate GYS1 square covering about 100 km², with a lock state and derived Home territory. We do not store an exact home coordinate or street address as Home Location. It remains personal location information and authorised administrators can access the account field for legitimate support or administration. A route may use a saved visit point or the centre of a Home/visit square.

Ordinary explorers do not receive your private visit coordinates or Home marker. A general place label, map cell, visible photograph, text or date can still reveal where you have been. Choose what you record and share carefully.

4. Photographs and other contributions

An uploaded photograph can provide an original filename, file type, dimensions, file hashes and available capture time, exact GPS coordinates and camera/lens/exposure metadata. We normally create re-encoded display and thumbnail files and remove the temporary original upload. Selected metadata may remain separately in the private database record; re-encoding a display file does not mean that every associated metadata field has been deleted.

Profile and featured images are also resized/re-encoded. An Atlas cover references an eligible existing photo and follows that photo's access rules; deletion, restriction or loss of access can make it unavailable. The beta does not offer an active user video-upload feature.

We store posts, comments, captions, likes and related dates/identifiers. You retain your rights in your contributions; the Terms explain the limited permissions needed to provide the service. We do not use that licence to claim ownership or a right to use your photos for unrelated advertising or model training.

5. Friends, Following and public sharing

We process Friend requests and their status, accepted relationships, Following/Followers, blocks and reports. Friendship is reciprocal; Following is one-way and does not grant Friend-only or private access. Account grid visibility and individual content visibility both affect normal in-app access. If your profile is searchable, other signed-in explorers may find basic profile identity while the grid is private. Blocking affects future access through the service, but cannot remove copies someone already made.

Creating a public visit-share link is a separate disclosure, even if your ordinary profile or visit visibility is private. Anyone with the link can see a reduced visit: your display name, visit title/date, general location, GYS1 cell and one selected re-encoded photograph. It excludes exact coordinates, private notes, email and EXIF metadata. You can open that visit's public-share controls and choose Disable link. Making ordinary visibility private does not itself revoke the link.

The service rechecks whether a link, account, visit and photo remain available. Search-engine and cache restrictions cannot prevent screenshots, downloads or forwarding. Public recipients may keep copies after you remove content or disable a link.

6. Moderation and automated processing

Reports can include the relevant account/content, your reason/details, status, outcome and staff review history. Authorised staff can see a reporter's identity; we do not intentionally display it to the reported person. For safety, repeat-abuse prevention and challenges, restricted rejected-media evidence can include a derivative, storage reference, file type and cryptographic/perceptual hashes. It is not publicly visible and may remain after deletion where necessary for those purposes or a legal obligation/claim.

Gridyssey's current Smart Media processing analyses a temporary reduced photograph locally. It can assess scene relevance, safety, duplicates and consistency between photo metadata and a declared visit's location/date. It creates labels, scores, signals, decisions, model/ruleset versions and processing metrics. It does not perform face recognition, and photos are not sent to an external AI inference service for this processing. Automated signals can reject, restrict or hold a photograph for human review; authorised moderators can review the photograph and context and override an outcome. Send a challenge to support@gridyssey.app with the relevant reference. We do not claim that every photograph is reviewed by a person before it appears.

A separate additional AI image-recognition capability is under development and is disabled and unavailable in the current beta. Members' photos are not currently sent to that proposed recognition provider. Before activating new recognition or third-party AI sharing, we will update the notice with the actual purpose, provider, data, retention and transfer arrangements and obtain any permission required by law or the platform. A general privacy acknowledgement will not substitute for required explicit permission.

7. Notifications, security and diagnostics

If you enable push, we process installation/device identifiers, platform and device labels, tokens or Web push endpoints/key material, preferences and delivery/failure/revocation state. Notification records can include recipient, actor, type, related content, read state and title/body. The chosen platform push service receives its token/endpoint and payload; text may appear on your locked device depending on its settings. In-app notices can exist without push permission.

Authentication and security records include session and refresh-token hashes, session-family identifiers, expiry/revocation state, platform/device labels, login attempts, throttling records and security events. Depending on the record, IP addresses or keyed hashes of IP/user-agent information are used. Administrator audits can include actor identity, an IP address, action/reason, correlation identifier and metadata.

The beta sends first-party error/diagnostic records to Gridyssey. These can include app/build/platform/operating-system information, component, endpoint, screen/route, time, correlation identifier, error message/category, stack trace, context and fingerprint. Submitted feedback adds your message and review/support notes. We sanitise recognised credentials, tokens, cookies, secrets, EXIF and coordinate fields, but free text or unexpected structures can still contain personal information. Please avoid unnecessary sensitive details.

We have not identified an advertising SDK or a separate product-analytics/crash-reporting SDK selected by Gridyssey in the inspected client/public-site source. Map and platform SDKs can collect their own service diagnostics and interaction information under their notices. Gridyssey's first-party diagnostics, security logs and service activity are separate from advertising tracking. We do not sell personal information.

8. Support, invitations and the waitlist

If you email us, the mail service handles addresses, subject/body, attachments and delivery information. Correspondence is currently handled through the separate mail host's Webmail. The prepared restricted Staff Inbox integration is not ingesting these messages. Staff access to account, moderation and diagnostic information is limited by role and purpose. Private information can be accessed by authorised personnel and systems where necessary for support, administration, moderation, security or legal duties.

Friend invitations process the inviter, any nominated recipient email, a one-way invitation-token hash, status/expiry and delivery details. A Friend invitation is distinct from a beta registration code. New registration campaigns have a code hash, limits/use counts, expiry, creator and audit/attribution records.

The gridyssey.com waitlist is separate from an app account. It stores your normalised email, sign-up time/source, a keyed IP hash and browser user-agent for requested launch/development/access updates and basic abuse prevention. Joining does not create an account or guarantee access. You can withdraw from updates or ask to leave the waitlist through privacy@gridyssey.app. We do not use a withdrawal to start a new retention period.

9. Why we use information

PurposeUK GDPR basis
Provide the account, visits, photos, maps, social, offline, sharing, plans, export and deletion functions you requestPerformance of our contract with you, or steps you request before it
Resolve a position/place or calculate a route you requestPerformance of contract; device permission is an additional platform control
Protect accounts, prevent abuse, investigate reports, moderate content and retain proportionate safety/security evidenceLegitimate interests in protecting people and operating a reliable service; legal obligation where applicable
First-party diagnostics, reliability work and service supportLegitimate interests in understanding faults and supporting the beta
Optional push delivery or requested waitlist updatesConsent where required; necessary in-app/service notices are supported by contract or legitimate interests
Deal with valid rights requests, legal duties or lawful authority requestsLegal obligation
Establish, exercise or defend a legal claimLegitimate interests, subject to applicable limits

Where we rely on legitimate interests, we must balance the purpose against your rights and expectations. You can object. Where we rely on consent, you can withdraw it without affecting processing already lawfully carried out. Giving device permission does not authorise unrelated uses of your location or photos. Optional updates are not a condition of having an account.

Account email and authentication details are necessary to provide and protect an account. Optional profile text, precise visit coordinates and contributions are your choice; withholding them can limit the associated feature. You can ask for human review of a disputed content/account outcome. The operational description above does not determine whether a particular decision engages additional legal protections for automated decision-making.

10. Recipients and international processing

Service providers can receive information needed for hosting/database/media storage, recovery, maps/geocoding/routing, email, push delivery and app build/distribution. Coordinates or search text may be disclosed when you request a place or route; direct map requests also reveal the requested map area and connection information to the map provider. Platform/device location services may process location according to their own settings/notices.

Gridyssey administers its cPanel-hosted website/email environment through a reseller account and also uses VPS hosting for its app/API services. The underlying infrastructure is supplied separately; cPanel is hosting-management software rather than the infrastructure provider's identity.

The current server geocoding service uses MapTiler for requested place searches and coordinate lookups. Automatic road-route calculations use Mapbox Directions, which receives the route's coordinate waypoints from the server. The Web map requests OpenStreetMap Foundation tiles directly, exposing connection information such as IP address, browser/request information and the requested map area to its service/CDN. Native maps and device geocoding use the relevant Google/Apple platform services. These services have their own notices, including MapTiler, Mapbox, the OpenStreetMap Foundation, Google Maps SDK disclosures and Apple Location Services. A server-proxied route or geocoding request does not have the same data flow as a direct browser tile request.

Android and iOS distribution/build services include Google Play, Apple and Expo/EAS; platform push adapters use Google's Firebase Cloud Messaging and Apple Push Notification service when activated. These organisations may also process information for their own platform purposes under their notices. A possible integration in source does not mean every provider is active. Removing Gridyssey's push registration does not itself prove that a platform provider has immediately erased every identifier or delivery record it holds.

We can disclose limited information to professional advisers, courts, regulators or law enforcement where required by law or necessary to protect rights and safety. We do not give ordinary users access to private support, security or account records.

Provider processing can involve countries outside the UK. Before a restricted transfer, the applicable UK adequacy decision or an appropriate safeguard, such as an approved contractual mechanism and required assessment, must be established. You can contact privacy@gridyssey.app for information about applicable recipients and safeguards. We do not claim all providers store or process data only in the UK, or that a proposed AI provider has approved transfer arrangements.

The countries and transfer arrangements applying to our underlying hosting and email services are still being checked. We will provide updated information when those details are verified.

For example, MapTiler's provider is based in Switzerland and the currently used global service endpoint is not an EU-only processing commitment. OpenStreetMap tiles use a global CDN. Provider documentation is not a substitute for checking the terms and settings applying to Gridyssey's account.

11. Cookies and storage on your device

Gridyssey Web uses session/refresh cookies to keep you signed in and protect requests. The waitlist can use session/CSRF cookies to protect its form. These are service/security uses, not advertising tracking. Public legal pages do not require advertising or analytics cookies. Blocking essential storage may stop sign-in or form submission.

Native refresh credentials and push-installation markers use operating-system secure storage. Native and Web clients can store an active-session snapshot, account-scoped offline visits and photo files/blobs. Web offline data uses IndexedDB; the legacy Web visit form can use temporary sessionStorage for a location. Offline data may include precise coordinates and private notes. Signing out clears the active session/refresh credential and the current client warns before removing that account's unsynced queue. Device copies, old clients and operating-system backups need separate attention; deleting an app does not delete a server account.

12. Retention and deletion

We keep ordinary account, Home, visit, photo, plan, relationship and preference information while it is needed to provide your active account, then handle verified item/account deletion. Temporary uploads and analysis renditions are removed through their processing flows. Public links remain until disabled or the related account/content is unavailable.

Security, audit, reports, moderation evidence, correspondence and diagnostics have different purposes. Retention must depend on the continuing investigation, follow-up, safety or legal need and be reviewed; it is not permission to keep an ordinary deleted account's full content indefinitely. Some age-based cleanup rules exist but are not automatically scheduled in this beta. Records can therefore remain until manual deletion or review rather than being automatically removed after a stated number of days. We do not promise that the proposed automatic retention schedule is already operating.

A de-identified database anchor and reduced deletion/enforcement/audit references can remain to preserve record integrity and necessary security/accountability evidence. Restricted rejected-media evidence or an active legal/safety case may also remain where justified, with access limited to that purpose. Email-host copies and attachments are separate from app records. Backup copies can remain after live deletion until the relevant backup is replaced or erased; a recovery copy is not permission to recreate a deleted account. Contact privacy@gridyssey.app if you need information about the retention applying to your request.

Use Settings → Account & password → Delete account or the public account deletion page. The process requires sign-in/current-password verification and a second confirmation. Opening a page, making an export request or starting deletion is not completed deletion. If you cannot sign in, we can consider a separately verified request via privacy@gridyssey.app. An email address alone is not proof of account ownership.

The processed deletion workflow removes or de-identifies ordinary profile/content, visits/photos, relationships, Home territory, push registrations, sessions and account-scoped app records. Your public shares stop working. Removing visible media from the server cannot recall screenshots or copies others made. Unsynced data held only on a device is not on the server and may need removing there.

The account JSON export contains selected profile, visit/location, photo metadata, trip, post/comment, Following, like, activity, plan and territory information. It excludes image binaries and does not contain every security, audit, moderation or diagnostic record. It is a convenience export, not a claim that every personal-data category has been supplied; a valid rights request may need a fuller response.

13. Your rights and complaints

Depending on the circumstances, UK data-protection law gives rights to information, access, correction, erasure, restriction, objection and portability. You can withdraw consent where it is the basis. Rights have conditions and exceptions; we may need proportionate identity checks and will explain a limitation that applies. Email privacy@gridyssey.app or write to our address above.

We will handle valid rights requests without undue delay and usually within one calendar month, subject to permitted clarification, identity-check and extension rules. For a data-protection complaint, we will acknowledge it within 30 days, investigate appropriately and communicate the outcome. These are different processes and time limits.

You can also complain to the UK Information Commissioner's Office. We would welcome the opportunity to address a concern, but contacting us first is not a condition of using your statutory rights.

14. Security and changes

We use password hashing, restricted staff capabilities, visibility checks, protected credentials, diagnostic sanitisation, media processing and audit records to help protect information. No system can guarantee complete security. Please secure your device/account and report a suspected problem to support@gridyssey.app.

We will publish the date/version of changes and give appropriate notice of material changes. We will update disclosures before introducing materially different uses, paid services or additional recognition/third-party AI processing, and obtain any required agreement or permission. Clarifying a notice does not create an historic consent or acceptance record.