Space to connect.
Clarity about privacy.

01 · RESPONSIBILITY

About this notice

This review notice covers the Seniorman community mobile app operated by Seniorman Network CIC. It describes the app, rather than every activity on the organisation’s website.

For app privacy questions, use info@seniorman.co.uk. Start with a brief description of your request. Do not send a password, sign-in code, identity document or sensitive wellbeing history in your first email.

02 · INFORMATION

What the app uses

Account and age eligibility

Your sign-in email, account identifiers, authentication and verification records, 18+ confirmation, and an optional private age bracket. An available social sign-in provider supplies the information needed to authenticate your account.

Community profile

Your community name, abstract avatar, profile status and preferences. The app’s avatar selector does not require a profile photograph.

Posts, replies and messages

The content you submit, conversation participation and related timestamps. This can include personal or wellbeing information that you choose to write. Share only what you are comfortable sharing, and avoid identifying another person.

Optional Bench photos

You can select up to four images for a new Bench post using your device's photo picker. We process only the images you choose, resize them and remove embedded metadata such as GPS information. Photos are stored privately and visible to members who can view the post through short-lived links. Photos are not sent to the AI provider. Check the visible image for faces, names and identifying documents before sharing. Deleting a post queues its photos for removal; specifically reported photos may be retained as restricted, audited case evidence pending an authorised retention or erasure review.

Safety and requests

Reports, blocks, moderation decisions, safeguarding records where needed, and requests for access, export or deletion. Restricted staff actions are audited.

Invitations and recognition

Invitation codes, referral attribution, recognition points and moderator applications where used. Recognition is non-cash and non-transferable; members see aggregate referral counts rather than an identifiable referral tree.

Notifications and service operation

Notification choices, device push tokens when enabled, delivery records, and technical/security records needed to operate the service. Optional activity-email choices are separate from device notification choices.

03 · ACCESS

How information is used and seen

App information supports sign-in, community participation, messaging, service-directory navigation, notifications, privacy requests and safety. Posts and replies are visible within the community under your community name.

Staff access depends on role and purpose. Report review and exceptional safeguarding access are controlled and audited. Administrator access is not presented as routine permission to browse private conversations.

Providers that help run the app

The app uses Supabase for authentication and database services, Hostinger for website/email infrastructure, and Expo with Google or Apple services for supported device notifications. A social provider is involved when you choose its available sign-in option. Provider processing locations, applicable terms and international-transfer safeguards still need to be confirmed in the final notice.

These two information pages contain no analytics, tracking scripts or third-party fonts. Hosting may still produce ordinary server access logs.

04 · AI ASSISTANCE

Kels is an AI assistant

Where Kels is enabled, it is identified as an AI assistant. It is not a human moderator, therapist or emergency service. Its replies can be inaccurate.

The implementation supports processing selected Kels-directed interactions through Anthropic’s Claude service. Relevant interaction text may be sent to the model provider for a response when that feature is active. Staff can control Kels features and review safety flags. Final provider, retention and wellbeing-data disclosures must be confirmed before public launch.

Do not use Kels to send identity documents, passwords or information requiring urgent professional help.

05 · YOUR CONTROLS

Choose how you take part

• Use a community name and an abstract avatar.
• Manage device notifications in the app and your device settings.
• Manage optional activity emails separately where available.
• Block or report a member or content through the app.
• Open My account → Your information rights to request access, an export or deletion.

You can contact Seniorman about correcting information, restricting its use, objecting to processing or other information-rights questions. You may also raise a concern with the UK Information Commissioner’s Office.

Proposed retention and deletion terms

Proposed terms for Seniorman Network CIC — 24 September 2026. These are purpose-based starting points for the adult community app, not statutory retention periods or a claim that automated deletion is already operating. They require controller adoption, safeguarding review and verified implementation before becoming effective.

Requests can be made using My account → Your information rights → Request deletion, or by emailing info@seniorman.co.uk. Proposed internal target: acknowledge within 5 working days and complete ordinary verified deletion within 30 days after verification, without delaying any shorter applicable legal deadline. Assess the response deadline from receipt under the applicable rules; verification is not permission to ignore a request. If lawful refusal, a permitted extension or limited retention applies, explain the reason and available complaint route. Do not describe the request button as immediate erasure.

Unverified registrations

Proposed period: 30 days after registration if verification is not completed.

Delete the incomplete account and associated registration data.

Active account and profile

Proposed period: While the account is active and needed. Review after 24 months without a sign-in; give 30 days’ notice before closing an inactive account.

On approved deletion, remove sign-in identifiers, private age information, profile and preferences from live systems within 30 days after identity verification, subject to any shorter applicable deadline.

Posts and replies

Proposed period: While published and useful to the community, with an annual necessity review.

On account deletion, remove the member’s contributions within the same deletion window. Keep only non-identifying thread placeholders; changing a name alone is not anonymisation.

Direct messages

Proposed period: 12 months from sending, or earlier under an approved deletion request.

Remove the departing member’s sent messages from live conversations within the account-deletion window. Retain only separately justified report evidence. Tell members about expiry before activating it.

Device tokens and notification delivery

Proposed period: Revoke on logout, invalidation or account closure; remove inactive tokens after 90 days. Delivery metadata: 30 days.

Delete tokens and unnecessary delivery records; retain no message bodies in push payloads.

Invitations, recognition and applications

Proposed period: While membership continues. Closed moderator applications: 12 months from the decision.

Remove personal referral links and recognition records with the account; retain only genuinely anonymous totals. A necessary staff-grant audit follows the audit schedule.

Blocks and routine moderation reports

Proposed period: Blocks while both accounts remain active. Closed routine reports and necessary evidence: up to 12 months from closure.

Delete expired records, unless a documented case-specific hold applies. Assess restrictions needed for an active safety case separately.

Safeguarding case records

Proposed period: Review every 6 months while open. Proposed default maximum: 24 months from case closure, subject to safeguarding-lead approval and any specific legal requirement.

Erase earlier when no longer necessary. Any longer retention needs a recorded lawful reason, limited scope, owner and next review date.

Staff access and security audit

Proposed period: 12 months from the event. General operational logs: 30 days.

Delete expired personal audit/log data through an authorised process; preserve only records covered by a documented incident or legal hold.

Privacy requests

Proposed period: Minimal request, verification outcome and decision record: 24 months from closure. Any identity-document copy: delete within 30 days after verification unless separately required.

Keep the decision trail, not a duplicate of exported/deleted content. Do not routinely request identity documents.

Backups

Proposed period: Proposed maximum rolling retention: 30 days, only once confirmed and configured for every relevant provider and copy.

Put deleted data beyond ordinary use until backup expiry. Replay deletions before a restored backup is returned to service.

Kels AI processing

Proposed period: No additional application-level archive of raw prompts or outputs. Published replies follow posts/messages; safety flags follow the relevant case schedule.

Model-provider logs and retention must be verified separately against the actual account settings and contract before these terms become effective.

Limited exceptions and legal holds

A hold must identify the specific records, lawful purpose, approving person, start date and next review date (no later than 90 days). Delete unrelated data on schedule. Release the hold when its justification ends and delete the affected data promptly, normally within 30 days. Safeguarding is not a blanket reason to keep all account data. Pseudonyms, hashed identifiers and detached account links can still be personal data; only genuinely anonymous aggregates are outside this schedule.

Required before activation: assign the privacy-request owner, confirm each provider’s backup/log settings, implement and test expiry and deletion across dependent records, and approve the safeguarding schedule. No production record is deleted by publishing this proposal.