# QHM Privacy Policy

Status: Final DR1.1C Privacy Policy text, ready for publication preparation after required organisational details are completed. This document has not yet been published or publication-verified.

## 1. Introduction

This Privacy Policy explains how the QHM application processes information for the Queenscliff Historical Museum application experience.

QHM supports public, member, and administrator access to museum notices, events, membership-related workflows, volunteer-interest workflows, donation records, notification preferences, and administrator-managed content.

This Privacy Policy is based on the approved DR1.1A Privacy Policy Requirements Specification and the completed DR1.1B Privacy Policy Draft traceability matrix. It must not be published until DR1.1D publication, verification, and evidence activity is separately authorised and completed.

## 2. Who We Are

The application is identified as QHM / Queenscliff Historical Museum.

The application is available for Android and iOS. The verified Android package and iOS bundle identifier are:

- `com.historyofqueenscliffe.qhm.app`

Final public organisation details, public support details, and public privacy contact details remain pending organisational completion before publication.

## 3. Information We Collect

QHM processes information needed to operate the verified application workflows.

Account, authentication, and profile information:

- email address;
- Supabase user identifier;
- session and refresh token information used for authentication;
- role assignment;
- membership status;
- full name;
- phone number;
- membership dates where applicable;
- profile update information.

Membership application information:

- applicant name;
- applicant email;
- applicant phone number;
- volunteer-interest selection;
- notification preference selections;
- submission time;
- administrator notes where used for application handling.

Volunteer-interest information:

- member identifier;
- member name;
- submitted contact email and/or phone snapshot;
- submission time;
- administrator notice linkage used for administrator follow-up.

Donation information:

- donor user identifier where available;
- donor name where provided;
- donation amount;
- currency;
- provider session identifier;
- donation submission time;
- donation status;
- administrator notice linkage used for administrator reconciliation.

Notification information:

- notification preference categories;
- enabled or disabled preference status;
- device installation identifier;
- Expo push token where notification token registration is used;
- platform information;
- notification job and delivery records where applicable.

Administrator content and interaction information:

- administrator-created notice, event, and administrator-message content;
- author identifier;
- content title and body;
- audience and destination settings;
- scheduled date and expiry information;
- event details where applicable;
- notification settings for content;
- administrator comments, including author identifier, username/email, body, parent content identifier, and creation time;
- image asset metadata, including owner identifier, object key, MIME type, byte size, dimensions, alt text, content linkage, and default-image status.

Operational and security records:

- audit event type;
- entity and entity identifier;
- actor user identifier where applicable;
- request identifier;
- event data;
- retention metadata;
- provider event, scheduler, webhook, notification delivery, and timestamp records where applicable.

Device and technical information:

- application platform identifiers;
- Firebase Android client configuration;
- Expo project identity;
- technical records required for verified operational foundations.

Production monitoring or error-reporting information must be described according to the verified activation state at the time of publication.

## 4. How We Use Information

QHM uses information to operate the verified application workflows.

QHM uses account, authentication, role, and session information to:

- sign users in and out;
- restore sessions;
- resolve public, member, expired-member, and administrator access;
- enforce role-based permissions;
- protect member and administrator areas.

QHM uses membership application information to:

- submit membership applications;
- support administrator follow-up;
- avoid automatic membership activation from the application submission alone.

QHM uses member profile information to:

- support member account functionality;
- allow members to update profile fields verified by the application.

QHM uses volunteer-interest information to:

- record an active member's volunteer interest;
- create administrator follow-up records and notices.

QHM uses donation information to:

- support donation workflow status and reconciliation;
- create donation records;
- create administrator donation notices;
- support provider webhook and replay-protection records where applicable.

QHM uses notification preferences and device token information to:

- manage notification preferences;
- support approved notification foundation behavior;
- support notification delivery records where notification delivery is activated under approved governance.

QHM uses administrator content, comments, image metadata, audience settings, and destination settings to:

- publish and manage QHM notices and events;
- manage administrator-only information;
- display content according to approved role and visibility rules.

QHM uses audit, retention, idempotency, webhook, scheduler, and delivery records to:

- support security and integrity;
- reject replayed provider events;
- maintain operational traceability;
- support retained-record governance.

QHM uses protected deep-link and role-based visibility behavior to make content available only through approved access boundaries.

Operational services such as production monitoring, notification dispatch, webhooks, and payment activation must be described according to their verified activation state at publication time.

## 5. Third-Party Services

QHM uses verified third-party services and platform services to operate the application.

Supabase:

- used for authentication;
- used for database-backed application records;
- used for repository-backed runtime data access;
- used with row-level security and approved backend/repository access boundaries;
- used for storage-related foundations where applicable.

Expo and EAS:

- used for the Expo application project and production build process;
- used for Expo notification-token foundation behavior where applicable.

Firebase:

- used for Android client configuration;
- relevant to mobile notification foundations where applicable.

Apple platform services:

- used for iOS build, signing, distribution, and platform support;
- relevant to iOS push notification foundations where applicable.

Square or the approved hosted payment provider:

- used for hosted donation checkout and payment-provider processing where live donation payments are in scope;
- used for signed payment result handling where applicable.

Sentry or monitoring service:

- production monitoring or error reporting must be described only if activated under approved governance;
- if not activated, it must not be described as active production monitoring.

Google Play and Apple App Store:

- used for app distribution, store metadata, store privacy declarations, app review, and related store-governance activities.

No advertising SDK, analytics SDK, social sign-in provider, location service, camera access, contacts access, microphone access, SMS access, call-log access, or unrelated third-party service is verified as active application behavior in the approved Privacy Policy requirements.

## 6. Notifications

QHM supports notification preference and notification foundation behavior.

Notification preference categories verified by the application include:

- general announcements;
- events and activities;
- new bulletin posts;
- membership updates.

The application may process notification preference status, device installation identifiers, Expo push tokens, platform information, notification jobs, and delivery records where applicable.

Notification permission and push-token registration behavior must reflect the verified activation state at publication time.

This Privacy Policy does not claim that production notification dispatch is active unless that activation is separately verified and approved.

## 7. Donations and Payment Processing

QHM uses a hosted payment architecture for donations.

QHM may process donation records including donor user identifier where available, donor name where provided, donation amount, currency, provider session identifier, donation status, submission time, and administrator notice linkage.

Payment card details are processed through the hosted payment provider and are not stored by QHM according to the verified project requirements.

QHM may process signed provider webhook records, provider event identifiers, and replay-protection records where applicable to verified donation processing.

Live payment activation and Square production establishment remain subject to approved operational and deployment governance where applicable.

## 8. Security

QHM uses verified security and access-control foundations, including:

- authentication through Supabase;
- session restoration and refresh behavior;
- role and membership-status resolution;
- public, member, expired-member, and administrator access boundaries;
- repository and backend access boundaries;
- row-level security foundations;
- protected deep-link behavior;
- signed payment webhook verification where applicable;
- replay rejection for provider events;
- audit and retention records for operational traceability.

This Privacy Policy does not claim absolute security guarantees.

## 9. User Rights and Choices

QHM provides verified in-app controls for:

- login;
- logout;
- session restoration;
- role-based access;
- member profile update fields;
- notification preference management.

Membership activation and approval are handled through approved external administrative processes and are not automatically granted by submitting a membership application in the app.

Requests about access, correction, privacy questions, deletion, or removal must use the public contact process approved by the organisation. Final public privacy contact details remain pending organisational completion and must be inserted before publication.

Account deletion and data deletion request handling must be described after the responsible organisation and public request channel are approved. No verified in-app account deletion workflow was identified in the approved Privacy Policy requirements.

## 10. Data Retention

QHM maintains retention-related records for approved retained entities, including content, volunteer interest records, donation records, and audit logs.

Retention records include retained-until metadata and a reason for retention. Specific public retention periods and final retention wording require organisational and legal/privacy review before publication.

Operational, audit, webhook, scheduler, notification, content, donation, volunteer, membership, profile, and administrator records must be retained or removed only according to approved project governance and applicable organisational approval.

## 11. Children's Privacy

The approved evidence verifies that the QHM app includes public access and museum/community content. No approved children-directed audience decision was identified in the approved Privacy Policy requirements.

Final children's privacy wording, Google Play Families applicability, and Apple/Google age or content rating responses require business and organisational approval before publication or store submission.

## 12. Changes to This Privacy Policy

Changes to this Privacy Policy must follow the approved QHM governance process.

The policy must be updated when verified application behavior, data processing, third-party service activation, public contact details, or store privacy declarations change under approved governance.

Final responsibility for approving and publishing updates remains pending organisational completion and must be confirmed before publication.

## 13. Contact Information

Final public privacy contact details are pending organisational completion.

Before publication, this section must be updated with the approved public contact channel for:

- privacy questions;
- access or correction requests;
- deletion or removal requests where applicable;
- support or escalation related to privacy matters.

Do not publish this Privacy Policy until the contact details and organisational approval have been completed under the authorised Deployment Readiness process.