GPS is useful because it is detailed
A recorded track can connect route, date, movement, and continuity better than a screenshot. The same detail makes it sensitive. A track may reveal a home address, accommodation, daily timing, rest stops, medical detours, transport use, or locations involving other people. Privacy is therefore not a note added after review; it must shape upload, storage, access, public responses, and retention.
Verified Hikes treats route files as private evidence. The reviewer uses them to assess the requested completion and level. The public certificate does not include the track, a route replay, exact coordinates, or the original filename.
Review only what is needed
Before upload, inspect the activity in the source application. Trim an unrelated approach from home or another clearly private section using a trusted tool, but do not alter the trail to create a misleading record. Explain relevant trimming or gaps. Avoid full account exports when one activity or a small group of daily files is enough.
Sensor fields such as heart rate, cadence, or temperature may exist in FIT or TCX even though they are not needed for ordinary completion review. The service should minimise use of those fields and focus on route and timing context. More data should never be collected merely because a format can contain it.
What authenticated reviewers can access
Authorised reviewers may see uploaded files, external activity links, completion dates, narrative, scan status, clarification thread, and risk or quality indicators needed for their assigned work. Partner reviewers are limited to authorised organisation or campaign scope. Every access should follow role controls and audit expectations.
Private access does not mean unlimited reuse. Evidence should not be downloaded into personal storage, forwarded by email, used for marketing, placed in broad reports, or shared with an unrelated partner. Support should direct hikers back to secure upload rather than request raw files by ordinary email.
What public verification shows
The QR page is deliberately narrower. It may show certificate status, trail, privacy-controlled recipient display, completion dates, verification level, issue date, PDF fingerprint, registry signature state, and safe event history. These fields help a viewer distinguish a valid record from a copied, revoked, or superseded PDF.
It does not show GPS points, photos, permits, guide messages, filenames, storage keys, EXIF, email addresses, payment identifiers, private support records, or reviewer notes. Public API schemas should explicitly select allowed fields rather than remove private ones after the fact.
Choose a display mode
Applicants can choose supported recipient display modes such as full name, first name with last initial, initials, private recipient, or a private certificate page. This choice controls public presentation, not the identity used internally for the application. Public PDF download is a separate setting and can remain owner-only.
A privacy-mode change after issue may require support to preserve the signed snapshot and public history correctly. The registry should avoid silently altering certificate-critical fields. Where a new snapshot is required, reissue provides a transparent path.
Retention is not the same as publication
Rejected application evidence is normally deleted after 90 days and approved evidence after 730 days. Active disputes, security incidents, fraud concerns, or legal duties may change the timing. Retention applies to private evidence files. The signed certificate record may remain after evidence deletion so the issued PDF can still be verified.
Keeping a hash or safe audit event is different from retaining the original GPS file. The public record can preserve integrity without publishing or indefinitely storing the route. This separation is one of the central design principles of the registry.
Deletion and correction requests
Contact support@verifiedhikes.com with the application or certificate reference and the request. Do not attach the evidence again. Support may ask enough information to locate the record and verify account authority. Depending on law and the record state, the response may delete private evidence, restrict processing, correct account data, change display mode, or explain a retention duty.
A deletion request cannot always erase a payment accounting record, security event, or public registry history immediately. Any retained portion should be limited to its lawful purpose and should not restore public access to private proof.
Partner workflows do not weaken the boundary
A partner campaign can connect a submission with a club, guide, expedition, or event, but it does not make the hiker’s proof public. Partner reviewers should be limited to the organisation and campaign records they are authorised to handle. They should never receive broad exports of waitlist data or unrelated applications.
Partner Confirmed describes the approved source of confirmation, not permission to republish the evidence. Logos, campaign pages, and aggregate reports remain separate from private files. Authority Confirmed requires a still narrower approved relationship and does not arise merely because an event uses an official-sounding name.
Security and file lifecycle states
An uploaded file may be received, quarantined, pending scan, clean, suspicious, failed, ready for review, reviewed, rejected, due for purge, or purged. Friendly dashboard labels explain the next action without exposing scanner internals. A pending file is not yet reviewer-ready, and a failed file should be replaced with a clean export or another evidence type.
Access and purge events should be auditable without putting filenames, storage keys, coordinates, or private notes into broad operational reports. Operators need counts and blocker classes; assigned reviewers need the evidence. Keeping those audiences separate is part of the privacy model.
Practical privacy checklist
Inspect track endpoints, remove unrelated activity, check photo content, redact unnecessary document numbers, avoid identity documents, use supported file types, and upload through the dashboard. Keep files until review completes but do not publish them merely to make a link accessible. Explain gaps honestly rather than exposing more data than needed.
After issue, scan your own QR page and confirm the display name, dates, level, and status are appropriate. Report any private field immediately. A premium registry is credible only when its public proof is strong and its private evidence boundary is stronger.