Feature Data Practices
Feature Data Practices — English working draft
This guide describes current, planned, and unresolved product behavior in plain language. It is a factual working draft for product, security, and legal review, not a legal notice, a promise that every feature is enabled for every account, or a statement about provider-side processing.
Home / Personal Feed
Personal Feed and Stories
The Personal Feed is organized around accounts a user follows. Stories can contain text, photos, or video. An unarchived story expires after 24 hours. Archived stories remain available to the user until the user deletes them. This guide does not extend permanent-deletion behavior beyond the deletion controls and backend behavior that are actually supported.
Community
Feed, history, and events
The public feed and history feed are readable by all users. Reviewers can create and write community content. Events are reviewer-created and share-only; this guide does not describe a public event-creation flow for other users.
Reviewer applications and conversations
Reviewer applications can move through eligibility, apply, pending, and view application states. Reviewers may ask optional questions about identity or context, but applicants should not be asked for payment details, passwords, Social Security numbers, authentication codes, identity documents, or other sensitive secrets.
After review, the applicant and reviewer cannot access the conversation. Administrators have restricted access for operational or safety purposes. The planned retention model keeps the application information until account deletion, with permanent deletion on account deletion; the final retention and exception rules remain source-only product and legal decisions.
Reviewer directory, profiles, and badges
Reviewer directory and profile access follows the applicable privacy settings. Badge eligibility uses account age, published posts, active days, profile completion, and good standing. An applicant can opt out; opting out removes the badge and withdraws the application. These eligibility inputs do not by themselves disclose a separate identity-verification result.
Private-account content remains private. Blocks and other access controls continue to apply to community surfaces.
Music and community content
Music can be public or private. Public music uploads are limited to reviewers under the current product decision. Users retain the need for appropriate rights and copyright safeguards when sharing music or other community content. The exact upload permissions, licensing language, takedown process, and other copyright details remain unresolved source decisions and are not promised by this guide.
Plus / Create
Every user can open the camera, switch to writing, select a photo or video, or take a photo. These controls are intended for personal-feed content. Whether created content is visible only to followers, and the complete audience-control behavior for each media type, remain unresolved product decisions.
Camera and media access can involve device permissions, uploaded media, media metadata, and deletion or cleanup behavior. This guide does not invent a permission prompt, metadata field, retention period, or deletion guarantee that has not been verified in the applicable client and backend flow.
Notifications
Notification categories include follows, follow requests, post interactions, community comments and replies, story activity, and account security. Notifications are enabled by default and can be controlled per category. Lock-screen text is intended to remain generic rather than expose sensitive content.
Read notifications are planned to expire after 7 days. Unread notifications are planned to have a maximum lifetime of about 90 days. Account-security records are separate from ordinary notification cleanup. These retention values are planned/source-only behavior until implemented and verified.
Profile
Profiles can include a profile picture, first name, last name, biography, and an external HTTPS link. Changing a profile photo does not create a feed post. Monthly username editing is planned and is not presented here as an already available control.
Settings and privacy
The current default audience decisions are:
- Comments: all signed-in users.
- One-to-one messages: people the user follows.
- Audio and video calls: people the user follows.
- Group invites: people the user follows.
- Stories and live features: all signed-in users.
Blocks and restrictions override these defaults. The behavior of a private account across every setting and surface remains unresolved and must not be inferred from these defaults.
Heritage
Heritage information is read-only, static, and curated. It is intended to share Yazidi heritage information sourced from public or community sources in good faith. The material may vary as sources and community review change; it is not an official religious ruling. Where practical, the site should identify the source, date, and meaningful uncertainty. There is no public in-app contribution workflow for this material at present.
Language Contribution and AI Training
The reviewed backend has consent-gated eligibility for selected language text and voice contribution records. Consent records include a document version, scope, status, timestamps, and supersession information. The backend supports validation, purge and retention states, account-deletion handling, and related progression or trust records for the reviewed contribution flows.
The audit found no verified training executor, dataset-export record, model version, or source-to-model lineage record. It cannot establish that a contribution entered a training dataset or model. Purging source records or media does not prove deletion from an external dataset or trained model, and this guide makes no promise of untraining.
Language audit events are append-only in the reviewed database design. Account deletion can remove the actor-user association while event subjects, metadata, and timestamps may remain. Where language data is retained during deletion, the reviewed service can return a recovery reference and one-time recovery key, while storing only an HMAC verifier. The audit found a service-level purge and verification function but no verified user-facing recovery-purge route.
These statements describe reviewed repository behavior only. Deployed client flows, provider behavior, external dataset deletion, and final retention rules require separate verification.