NetQnect Data Retention Schedule

Version date: 16 September 2026.

Effective date: 16 September 2026, applying only when this exact revision is published.

Contact: legal@netqnect.com

1. About This Schedule

A fixed period is not permission to keep data after its purpose ends. These periods are maximum limits or ending conditions for the stated purpose; earlier deletion and applicable privacy rights take precedence unless a specific lawful exception applies.

The repeated 30-day deletion target is an operational target, not a statutory retention requirement or waiting period. Erasure must proceed without undue delay where required. The normal one-calendar-month rights-response deadline is separate; an operational target cannot extend a legal deadline. Acknowledgement or an accepted background job does not prove all deletion effects have completed.

The 30-day target concerns NetQnect's erasure work. Firebase describes up to 180 days for Authentication live/backup removal after customer-initiated deletion. This provider schedule does not postpone NetQnect's deletion request or permit continued active use.

2. Retention Principles

NetQnect:

• keeps personal data only for as long as needed;
• minimises data used in logs, traces and analytics;
• deletes or anonymises data when the purpose ends;
• retains limited audit records where needed for security, legal, accounting or rights-request proof;
• avoids retaining full personal-data archives after user deletion unless there is a documented lawful basis and expiry period.

3. Retention Periods

Account data

• Active account lifetime.
• Delete or anonymise within 30 days of account deletion, except limited records needed for legal, security or accounting reasons.

Profile data

• Active profile lifetime.
• Delete or anonymise within 30 days of profile or account deletion.

Connections, QR scans and Qnect activity

• Active account lifetime.
• Delete or anonymise within 30 days of account deletion, including nested notes, tasks, memory, opportunities and related subcollections, subject to applicable rights outcomes and specific lawful exceptions. Other people's own records follow their separate purpose and rights obligations.

User-to-user messages and conversation metadata

• Active account lifetime while the conversation remains needed by at least one participant.
• A user may archive their own conversation copy where the product supports it.
• If a participant deletes their account or a connection is removed, disable new messages in the shared conversation and delete or anonymise the departing participant's personal data within 30 days of account deletion, while preserving the other participant's own messages where they still need their record.
• Do not retain all app message content solely because separate support email, business, tax or accounting records may have longer legal retention. Limited security, abuse, dispute, rights-request, legal-hold and backup exceptions must be documented.

User media and uploaded files

• Active account, profile, team, event or message lifetime, depending on the feature that uses the file.
• Delete account-owned files under the user's account Storage area within 30 days of account deletion where practical.
• Shared, team, event, imported-provider or organiser-controlled media may need deletion, anonymisation, reassignment, retention under another user's or organiser's lawful basis, or a documented exception.
• NetQnect does not retain media solely because a file existed in technical storage; retention follows the feature purpose, legal/security exception or backup expiry rule.

Assistant messages and AI outputs

• Active account lifetime unless the user deletes a thread earlier.
• Delete or anonymise within 30 days of account deletion.

AI traces, debug logs and safety review records

• Production target: 7 days unless retained for a live security, abuse, legal or support issue.
• Non-production test data: no more than 21 days; shorter configured periods apply.

Embeddings, vector records and graph records

• Active profile, event or relationship lifetime.
• Delete or rebuild without the user's data within 30 days of profile, event or account deletion.

Event attendance and check-ins

• Active account or event organiser need.
• Delete or anonymise user-linked records within 30 days of account deletion, unless an organiser has an independent lawful basis to retain records.

Connected-service tokens

• While the integration is connected.
• Delete immediately on disconnect where practical, and within 24 hours as a service target.
• Calendar OAuth tokens are stored as encrypted token envelopes while Google Calendar or Microsoft Calendar is connected. Disconnect deletes local token records and pending OAuth state immediately where practical; Google OAuth revocation is attempted when a revocable token is available. Provider-account access that remains outside NetQnect's control must be handled through the provider account settings or documented provider process.

Imported connected-service data

• While needed for the connected feature.
• Delete or refresh when the integration is disconnected, consent is withdrawn or the account is deleted.
• Calendar availability checks must not import raw calendar history. Free/busy checks are requested only for bounded windows, defaulting to a maximum of 168 hours unless a narrower environment limit is configured, and the assistant-facing result is limited to provider id plus busy start/end windows. There is no calendar-specific application cache in the current source path; any persisted assistant trace that contains availability output follows the AI trace retention target above.
• Calendar OAuth state records are short-lived, contain no token material, expire after 10 minutes, and are cleaned after callback, disconnect, account deletion or the scheduled expired-state cleanup.
• Calendar connection metadata, capability preferences, write-back preferences and selected provider calendar id/label targets are retained only for the active connected-service/account purpose, then deleted or cleared on disconnect or account deletion. Calendar consent history follows the consent-history retention row.
• NetQnect-created provider event references on assistant meetings are retained for the active meeting/account purpose. Successful write-back records the synced user id so export and erasure follow the user whose provider calendar received the event. Account deletion best-effort deletes the NetQnect-created provider event before local token deletion where token/capability access remains available, including stored-event cleanup if the write-back launch scope is later disabled; provider events that cannot be reached need controlled evidence or an approved provider-side exception.

Analytics and product usage data

• Consent-based Google/Firebase Analytics: up to two months for event data and 14 months for user data where separate provider controls exist. Provider standard aggregate reports may remain available for longer where they no longer identify a user.
• Repo-owned identifiable product analytics records in analytics_events and login/session analytics in user_sessions: up to 426 days from each event or login timestamp, with earlier applicable rights-request fulfilment.
• Protected stateful product outcomes, including team admission, event/check-in, billing, account-readiness, recommendation feedback and similar canonical service records, follow the active account, feature, event, relationship, billing or legal-retention purpose that created them. They are not reclassified as optional Google Analytics data merely because they support product measurement.
• The Firestore network_intelligence_outbox is a transient ingestion queue. Outbox facts expire after 30 days and are also included in user export and account erasure when linked through userId, ownerUserId or contactUserId.
• User-linked Network Intelligence facts, recommendation-feedback facts and daily or relationship projections in the VPS/Postgres data mart follow the active account or relationship purpose and the downstream deletion workflow. Aggregated projections remain personal data while NetQnect can link them to a user.
• Aggregate or anonymised analytics may be kept longer only where users are no longer reasonably identifiable.

Crash, performance and diagnostic data

• Target: up to 90 days for identifiable records unless needed for a live incident.

Consent history

• Minimal consent, withdrawal, policy-version and rights-handling evidence may be needed after account closure. Up to six years after account closure (or case closure for rights cases) is a case-dependent ceiling, not a statutory requirement for every consent record. Keep it only where a documented obligation or claims/rights-handling need justifies the period; review and delete when that need ends.
• Store minimal evidence, not full activity histories.

Billing, invoices and tax records

• Company accounting, invoice and tax records: keep for 6 years from the end of the last company financial year they relate to, or longer where an applicable obligation, inquiry or documented legal hold requires it. Limit this to necessary accounting records, not unrelated app activity.

Support requests and contact forms

• Up to 12 months after case resolution, with earlier deletion when the support purpose ends. Separate necessary legal, accounting or security evidence follows its own justified limit.

Security logs and abuse records

• Up to 12 months, or longer where needed for an investigation, legal claim or platform security.

Backups

• Recovery copies are kept for up to 60 days, access-restricted and excluded from ordinary use. Deletion and restriction instructions are reapplied before any restored copy is used.
• Acronis recovery points stay within that maximum. Native host copies use a 14-day retention policy; Firestore point-in-time recovery and daily backups use a seven-day retention policy.
• Provider-controlled copies, including Firebase Authentication, follow the separate provider limits described above; these do not postpone our deletion requests or permit ordinary reuse.

Marketing preferences and suppression records

• Active preferences are replaced when you change them.
• Minimal suppression records remain only while needed to prevent renewed unwanted contact, with an annual necessity review.

4. Optional Programmes

We do not use your data to train AI models. If we ever propose an optional programme, we will explain it in Privacy Settings and ask you first.

5. Deletion Requirements

Our account-erasure process covers applicable records across:

• Firebase Auth user records;
• Firestore account, profile, connection, nested relationship and event data;
• user-to-user message content and conversation metadata, using deletion, archive, read-only or anonymisation behavior appropriate to multi-party records;
• assistant messages, actions, traces and token usage;
• Firebase Storage media;
• vectors and embeddings;
• graph database records;
• worker databases, queues and caches;
• user-linked Network Intelligence outbox facts and downstream facts or projections;
• connected-service tokens and imported data;
• analytics identifiers where deletion is supported by the provider.

6. Review

We review this schedule when retention purposes, systems or provider arrangements change.