About this policy
Version 2026-10-24 | Last updated . Afro Fashion House Inc.
This notice explains information handling across the AFH buyer and vendor apps, website, group events, order fulfilment, support and authorised use of the admin portal. Different people see different information. A private upload, a public listing and a message to a group do not have the same audience.
The Buyer Terms and Vendor Terms explain the commercial terms for each audience. Privacy requests for both audiences use the contact in this policy.
- We use account, order, measurement, delivery and payment information to run the service, make and inspect garments, arrange delivery and handle problems.
- Measurements selected for a purchase remain in the order record even if a saved measurement profile is later edited or deleted.
- Vendor verification can include identity and business documents and the full Bank Verification Number (BVN). The current manual review process retains that number with restricted reviewer access; masking it in the app is not the same as deleting it.
- Authorised staff may review order communications and inspection evidence. Order chat is screened for prohibited contact details. Group members can see messages posted to their group, and group chat does not use the same contact-screening rules.
- Optional AI features can send selected photos, document images or text to an AI provider. They do not all run on your device. Feature-specific consent and retention disclosures are separate from agreeing to the Terms.
- AFH deletes AI try-on and photo-estimation images, generated image results and associated derived copies from its own storage and database image records after 30 days. Optional non-AI measurement reference photos instead stay with their measurement set and related orders until the photo or set is removed, as explained in section 6. Alibaba's separate retention policy applies only to information sent to Alibaba through AI features; reference photos are not sent to Alibaba.
- AFH does not retain facial geometry, embeddings or reusable biometric identifiers derived from personal photos. Ordinary account identifiers and saved measurement values are different records, with the retention rules described below.
- We collect account-linked app usage checkpoints to understand how the service is used. Aggregated reporting does not make the underlying events anonymous.
- Account closure does not erase every order, financial record, shared message or lawfully retained verification record. You may make a separate privacy request without waiting for every operational issue to end.
- Afro Fashion House Inc. handles this Privacy Policy and privacy requests for all covered users, including buyers and vendors. The single privacy email is privacy@afrofashionhouse.com.
1. Who Is Responsible
1.1 Policy responsibility and contact.
Afro Fashion House Inc., incorporated in Colorado, United States, is solely responsible for issuing and administering this Privacy Policy and handling privacy requests for the covered AFH services, including buyers and vendors. Its legal and business notice address is 870 South Colorado Blvd. #1041, Denver, CO 80246, United States. The single privacy email for all covered users is privacy@afrofashionhouse.com.
1.2 Nigerian vendor operations.
Provenfield Labs Limited remains the company handling Nigerian vendor onboarding and vendor-side operations under the Vendor Terms. It may receive necessary information for verification, fulfilment and vendor payouts as described in this notice. It is not a co-issuer or separate administrator of this Privacy Policy. Vendors should direct privacy requests to Afro Fashion House Inc. using the contact in section 1.1. Personal information about a sole trader, director or business representative can be protected even when supplied for business purposes.
1.3 Responsibilities follow the processing.
Centralising this Privacy Policy and its request handling does not remove any recipient's own applicable data-protection obligations. A controller determines why and how personal information is used; a processor acts on a controller's instructions. Common ownership does not make separate companies a single legal entity or make every recipient a processor. A recipient's role depends on the particular activity and applicable law. Afro Fashion House Inc. will coordinate necessary follow-up without requiring users to start again with a different privacy contact.
1.4 Meaning of AFH.
References to AFH, we or us in this Privacy Policy mean Afro Fashion House Inc. Sharing necessary operational records with Provenfield Labs Limited or another recipient for a disclosed purpose does not grant unrestricted use of your information. Our use of a vendor, hub or processor does not remove our own legal duties. This privacy arrangement does not change the contracting company named in the Buyer or Vendor Terms.
1.5 Privacy contact.
The privacy mailbox in section 1.1 is the central request contact. Its designation does not assert that a statutory Data Protection Officer has been appointed. If an appointment or representative is legally required, its appropriate contact details will be provided. This notice does not claim a data-protection registration or certification.
2. Scope and How to Read This Notice
2.1 People covered.
This notice covers buyers, vendors and their representatives, website visitors, event participants, recipients and wearers whose details are supplied for an order, people who contact support, and authorised administrators using AFH's systems. An individual can appear in more than one role, such as a vendor who also purchases a garment.
2.2 Admin use versus employment.
Account access, assigned role, audit history, security information and operational actions of administrators and Business Executives are covered as platform-use data. Recruitment, payroll, employee performance and broader personnel records require separate workforce or applicant notices. This document does not authorise undisclosed employee monitoring.
2.3 Privacy is not a waiver.
This notice explains processing; it is not a blanket consent request or a waiver of privacy rights. The Buyer and Vendor Terms govern commercial conduct and purchases. Where a feature needs specific consent, a sensitive-data notice or an additional choice, we must provide it separately. A broad contract clause does not replace that step.
2.4 Enabled features.
Data collection depends on the functions you use and the services actually enabled. A feature described as conditional does not mean every person is subject to it. If we introduce a materially different purpose, recipient or sensitive-data use, we will provide the required information and obtain any required consent before that use.
3. Where Information Comes From
3.1 From you.
We receive information when you register, sign in, create a store or measurement profile, upload files, place an order, join a group, submit a review, use an AI feature, message another person, request support or exercise a privacy right. Information entered in a public listing or review has a different visibility setting from information submitted privately for verification.
3.2 From other people and organisations.
A purchaser may supply a recipient's address or another wearer's measurements; a group creator may invite you; a Business Executive may be associated with a vendor's referral; and a vendor or inspector may submit order evidence. Payment providers, banks, carriers and enabled authentication/address services supply relevant results and references. We do not treat another person's submission as unlimited permission to use your data for unrelated purposes.
3.3 From use of the service.
Our systems receive technical information needed to handle a request, such as network address, device/browser characteristics available to the service, timestamps and security or error information. The mobile app also records signed-in product-journey events described in section 13. A manually entered delivery address is not the same as background GPS tracking.
3.4 Required and optional information.
The relevant screen identifies information needed for the task. An email and authentication details are needed for an account; delivery information is needed to ship; a bank account is needed for vendor payout. Many measurement fields are optional at profile creation, but a selected garment may need particular dimensions. Optional AI photo use, public reviews and marketing choices are not universal account requirements. If information is necessary but withheld, we will explain which service cannot be completed.
4. Categories of Information
The table describes the categories handled by the service and enabled workflows. It is not a claim that we collect every category from every person or that every field is required.
| Category | Examples |
|---|---|
| Account and contact | Name, email, phone where supplied, account identifier, buyer/vendor intent, sign-in provider identifier, verification state, password hash or authentication/session records, preferences and account-closure history. |
| Delivery and recipient | Recipient name, address, contact number, address-validation result, delivery instructions where supported, tracking references and delivery evidence. |
| Measurements and tailoring | Profile label, selected measurement set, dimensions, units, optional height, confidence/validation indicators, profile versions, selected garment details and the order measurement snapshot. |
| Photos and other files | Listing images/video where enabled, store logos, verification files, inspection photographs, support attachments, try-on source photos and generated results, estimated-measurement photos and file metadata. |
| Vendor verification | Contact/business name, operating location, government ID type and image, CAC certificate, proof of address, BVN, masked displays, review notes, document extracts, comparison results, status and duplicate-document fingerprints. |
| Commercial and financial | Orders, piece references, prices, charges, discounts, payment-provider identifiers/status, refunds, disputes, vendor account number and bank details, resolved account name, payout recipient reference, earnings and ledger records. |
| Messages and participation | Order/group/support messages, attachments, participants, moderation flags, acknowledgements, group roster/progress, reviews, ratings and AI feedback. |
| Referral and staff access | Vendor referral code/assignment, assigned executive, onboarding progress, relevant verification/listing feedback, invite details, staff role and recorded administrative actions. |
| Usage and technical | App route/screen, journey step, session identifier, signed-in account link, backgrounding/checkout events, notification token, delivery status, browser storage, API/network records and diagnostic information. |
| Choices and derived records | Consent text/version and time, marketing preferences, privacy requests, risk or moderation indicators, AI outputs/assessments, inspection comparisons and de-identified summaries where properly prepared. |
4.1 Sensitive information.
Some information can be sensitive under applicable law, including government identifiers, financial-account information, private communications and certain biometric or inferred information. A photograph or body dimension is not automatically biometric identification data under every law. Actual face/image processing and inferences must be assessed; we do not rely on a label such as fashion data to avoid applicable protections.
4.2 Information we do not need.
Do not send passwords, one-time codes, complete card details, unrelated medical records or intimate images through chat or support. Only provide an identity document through the appropriate verification or proportionate rights-verification process. We do not need unrelated private data merely because a garment is customised.
5. Purposes and Legal Grounds
We use information for the specific purposes below. Where law requires a lawful basis, it depends on the purpose and the person's relationship to the service. Contract necessity is not a justification for every analytics, marketing or AI activity.
| Purpose | Use and applicable legal grounds |
|---|---|
| Accounts and requested services | Create and secure accounts, provide profiles and communications, process requested orders and administer vendor participation. Where necessary, we rely on performance of a contract or requested pre-contract steps for the contracting person; another wearer's data requires an appropriate separate basis or permission. |
| Making, inspection and delivery | Give the relevant maker the garment specifications, compare the item at the hub, arrange transport and resolve mistakes. Use information necessary for fulfilment and proportionate quality control, with an appropriate basis for third-party recipient data. |
| Payments and records | Take authorised payment, reconcile refunds, pay vendors, maintain financial evidence and meet identified legal duties. The relevant grounds are contractual administration, specifically applicable accounting obligations and legitimate claims handling, depending on the activity. |
| Verification and safety | Check vendor submissions, prevent impersonation, investigate misuse and protect users. Use necessity-based fraud-prevention interests or an identified legal duty where applicable, with additional conditions for sensitive information. We do not assume every check is legally mandated. |
| Support and enforcement | Investigate tickets, moderation flags, complaints, legal claims and access misuse. Where we rely on legitimate interests, the processing must be necessary and balanced against your rights. A complaint does not authorise unrelated profiling. |
| Optional personal-photo AI | Generate the requested preview or estimate and manage the feature's consent, safety and deletion records. Obtain specific consent and any additional sensitive/biometric permission required; do not infer it from general account registration. |
| Product operation and improvement | Understand service steps, reliability, abandoned flows and feature feedback. Separate necessary diagnostics from non-essential analytics; assess legitimate interests and any consent requirement. Account-linked events are not assumed to be anonymous. |
| Marketing and public promotion | Send permitted marketing or use content for an expressly authorised campaign. Apply the relevant consent/opt-out rules. Private photos are not made into advertisements merely because they were uploaded for a garment service. |
| Rights and legal compliance | Verify and answer privacy requests, document choices, respond to binding legal demands and notify reportable incidents. Keep only the evidence needed for the identified duty or justified purpose. |
5.1 Consent choices.
Where processing relies on consent, you may withdraw it through the feature control where available or by contacting privacy support. Withdrawal does not retrospectively make earlier lawful processing unlawful, but future processing and deletion must follow the applicable rules. Declining optional processing does not remove access to unrelated core services.
5.2 No unlimited secondary purpose.
A lawful basis for order fulfilment is not automatically a basis for training a general AI model, selling information or creating sensitive inferences. We must assess a new purpose, disclose it and obtain any additional permission required. Necessary retained records must not be used indefinitely for any purpose AFH later chooses.
6. Measurements, Wearers and Order History
6.1 Profile versus purchase.
A reusable measurement profile stores the fields you supply or confirm. When used for a purchase, relevant values and specifications are copied into the order. Later profile editing or deletion does not rewrite that order evidence. We keep the minimum necessary history for fulfilment, corrections, inspection and justified claims handling under the retention criteria in Schedule A.
6.2 Who can use the measurements.
The maker of the relevant piece and authorised hub/support personnel may use the dimensions necessary to produce or assess that item. A creator of a group is not entitled to everyone's full measurements simply because they organised the event. An order snapshot is not a public body profile.
6.3 Another person's details.
If you buy for someone else, tell them about the use of their information and obtain the required authority. Use a non-identifying profile label where possible. A recipient or wearer who has no AFH account may still contact us about information relating to them; we may need enough transaction context to locate it without exposing another person's records.
6.4 Correcting history.
We can distinguish a correction to current personal data from preservation of an accurate record of what was originally supplied. Where necessary, an explanatory correction or accepted amendment may be added rather than falsifying an old transaction. We will not use the need for an order record as a reason to retain every unrelated photograph or profile field.
6.5 Optional reference photos and consent.
You may provide one full-body front photo with a measurement set to help a tailor understand an adult wearer's shape and posture. It is optional: saving measurements and ordering do not require it. Use fitted clothing with the face out of frame; do not include nudity, underwear, children or unrelated identifying information. Before upload, the app asks you to confirm permission for this particular sharing and use. For another adult, explain the purpose, recipients and retention and obtain that person's informed permission. We record the upload's account association, sharing-notice version and confirmation time. We use the reference for tailoring, relevant quality checks and support, with specific consent where required; it is not a general-purpose consent.
6.6 Reference-photo access and processing.
Reference photos are stored privately, not in the public catalogue. You can view your photo; the vendor fulfilling an eligible paid order using that set can view it for that order, and authorised AFH personnel can access it for relevant order work. This includes access in Nigeria as described in section 15. Other buyers, unrelated vendors and group organisers do not receive access to it. AFH normalises the uploaded image and removes embedded EXIF/location metadata, but does not guarantee that identifying details visible in the image have been removed. We do not send these reference photos to Alibaba or another AI service, use them for advertising or general model training, or retain facial geometry, embeddings or reusable biometric identifiers from them. An upload permission is not permission for recipients to download, redistribute or reuse a body photo for unrelated purposes. Contact privacy support about suspected misuse.
6.7 Reference-photo retention and deletion.
A saved reference photo stays with its measurement set and related orders until the buyer removes the photo, deletes that measurement set or completes account closure. It is not subject to the 30-day period for AI try-on or photo-based measurement estimation. Removing the photo or successfully deleting the set revokes further AFH app access from linked profiles and order versions and starts deletion of the stored image and its database image record; necessary numeric order snapshots remain. The app may prevent deleting a whole set while it is needed for an active order or group, but the photo can be removed separately without deleting those measurements. Storage failures are retried with access already revoked. Uploads never attached to a saved set are removed after 30 days if not deleted sooner. Restricted backup/recovery copies follow section 20 and must not restore the photo to ordinary use. Information already seen or copied outside AFH cannot be technically recalled; report unauthorised copying to privacy support for action. Minimal non-image consent and deletion evidence may remain for accountability.
7. Vendor Verification and Bank Information
7.1 Verification submissions.
Vendors supply the requested identity/business evidence and, where required by the current flow, BVN. Submitted files are associated with the application and placed in restricted storage. Authorised reviewers may examine them, record decisions, request corrections and compare relevant fields. The documents are not intended for public storefront display.
7.2 Full BVN and masked views.
The current document-submission flow stores the full BVN for authorised manual review and also stores a masked display. The full value is not merely discarded after submission. A masked vendor-facing screen does not mean the underlying value is anonymous. Access must be limited to roles that genuinely need it; the number must not be included in ordinary emails, referral exports or public content.
7.3 Manual and AI-assisted review.
Standard document submission currently queues human review. An optional certificate-reading function can send a short-lived document link to Alibaba Cloud, extract information, compare it and record a result that can advance the document's verification status. This is not an automatic government-registry certification, and it is not accurate to describe every possible document decision as human-only. You may seek correction and human review of an incorrect assessment.
7.4 External verification.
We will identify an external identity-verification service and any required consent before activating such a service. This notice does not represent that a NIBSS or other government-verification connection is active. Bank account-name resolution and payout processing are separate from proof of the authenticity of every identity document.
7.5 Bank and payout details.
Relevant account number, bank code/name, resolved name and payout references are used to set up and reconcile vendor payments, including through Paystack where enabled. Payment providers may need information for their own regulated functions. AFH retains transaction evidence separately from the live bank-account profile and should remove or mask details no longer needed.
7.6 Retention.
We retain verification evidence only for a documented verification, fraud, claims or specifically applicable legal purpose, as described in Schedule A. There is no single retention period for every vendor file. Requesting erasure is different from successful file deletion; any lawful exception must be explained and periodically reviewed.
8. Payments, Refunds and Financial Records
8.1 Buyer payment collection.
Payment details entered in the enabled Stripe payment interface are handled through that provider's integration. AFH receives the identifiers, amounts, currency, status and reconciliation information needed to operate the order. We do not ask for complete card credentials in our order chat. This description is not a guarantee that a user can never accidentally put card information into an inappropriate text field.
8.2 Transaction records.
A single payment can relate to several independently tracked pieces. We retain the necessary allocation of garment charges, delivery, customs, discounts, refunds and vendor earnings to explain the transaction and investigate discrepancies. A ledger record is not permission to retain all associated personal media forever.
8.3 Disputes and recipients.
Necessary order, payment, communication and delivery evidence may be supplied to a payment provider, bank, relevant professional adviser or authority for a refund, fraud or payment dispute. We should limit that evidence to what the case requires, avoiding unrelated body photos or verification files. The provider may process some information independently under its own notice.
9. Order Chat, Groups and Support
9.1 Order records and quality control.
Buyer-vendor messages, approved tailoring changes and the order snapshot can be reviewed by authorised AFH staff for fulfilment, hub inspection, support and dispute handling. This is not a promise of immediate human review of every message. These communications are not represented as end-to-end encrypted against AFH's own authorised access.
9.2 Contact-detail screening.
The current order-message filter checks for contact details, identity/payment references and off-platform invitations. A blocked message can remain in a restricted moderation record even though it was not delivered to the other party. Repeated flags may create an administrator alert. Screening can make mistakes; use support to challenge an incorrect block or communicate essential tailoring information safely.
9.3 Group visibility.
Group members see messages posted to their group. The creator can see limited roster/progress information, including the displayed participant name, participation/payment stage, whether measurements were submitted and relevant order progress. That is not permission to see another member's complete measurements, payment credentials or private address. Group chat does not necessarily apply the order-chat contact filters.
9.4 Support evidence.
Tickets can contain an order reference, category, correspondence and private attachments. Support, Operations and other authorised roles see information appropriate to their duties; formal refunds or disputes may require additional review. Use the secure evidence route for a private fitting concern, not a public review. Do not submit intimate images or unnecessary identity documents.
9.5 Messages after closure.
Closing an account does not necessarily remove messages already shared with other participants or all lawful complaint evidence. Denormalised display names and copies in exports or recipient devices require separate handling. We cannot promise recall of a screenshot another person lawfully received, but we remain responsible for assessing deletion and redaction within systems we control.
10. Referrals and Business Executives
10.1 Attribution.
A vendor referral code connects an application to the assigned Business Executive. AFH records the assignment, changes and relevant dates so the executive can help with onboarding and management can understand progress. This does not create a buyer referral programme or an automatic public statement about a vendor.
10.2 What the executive sees.
For their assigned vendors, the current tracking view includes business/contact name, city, email, phone, join date, application and verification stage, listing counts and relevant review feedback. It may include document type/status and reasons for correction, but it does not provide the executive with raw identity documents, the full BVN or bank-account details through that tracking view.
10.3 Exports and reassignment.
Authorised tracking exports contain relevant contact and progress fields. They are not anonymous just because they are in a spreadsheet. Staff must restrict access, protect downloaded copies and stop using records for an ended assignment except where a justified business record must remain. Reassignment changes live access; it does not automatically erase an earlier export from every device.
10.4 Feedback minimisation.
Review comments intended to help onboarding must not unnecessarily repeat sensitive document numbers, private buyer information or unrelated allegations. A vendor can ask about the referral recorded against their account and request correction of an inaccurate attribution through the appropriate support/privacy route.
11. Public Content and Promotional Use
11.1 Public storefronts.
Store name, handle, description, published listing media, selected business/social details and permitted public performance information can be visible to visitors. Do not put a private identity document, home contact detail or personal account number into a public listing. A sole trader's business content can still identify an individual.
11.2 Reviews and names.
Published reviews can display the review text, rating, submitted review images and the reviewer's name; the buyer's full name can appear where provided. Do not assume a review is anonymous or that a private support attachment is automatically a public review photo. We will assess requests concerning a displayed name or unnecessary personal content.
11.3 Reuse is not automatic.
Uploading a private photo for measurements, try-on or a complaint does not authorise its use in an advertisement or testimonial. Public availability also does not automatically justify every new use. Promotional reuse and separate AI-training purposes need the appropriate disclosure, permission or other lawful basis and must respect prior promises.
11.4 Copies and external sites.
Search engines and other people may cache or copy public content. Removing it from AFH does not instantly erase all external copies. We will address requests within our control and reasonable required steps with recipients. A third-party service linked from AFH has its own practices; that fact does not excuse AFH's responsibility for information it sends there.
12. AI Photos, Outputs and Assessments
12.1 Features and provider.
AFH uses Alibaba Cloud Model Studio for enabled visual/text assessment and image generation. Different features send different inputs. An AI request is processing by an external service even when a private file is exposed only through a short-lived signed link; expiry of that link does not prove deletion of bytes the provider already retrieved.
12.2 Virtual try-on.
The requested preview uses a personal photo and selected garment imagery. AFH may assess framing and create one or more generated images or derived copies. Depending on the selected generation method, the model transfers garment appearance or works with a face/likeness reference. This is not simply local playback on your phone, and the output is a simulation rather than reliable evidence of physical fit.
12.3 Estimated measurements.
Where enabled, the photo-estimation feature uses your uploaded image and supplied height to suggest a limited set of measurements and confidence information. You must review suggestions before using them. Processing can take place through an external AI provider. A feature-specific notice and any required consent apply; a prior try-on choice does not cover every later image use.
12.4 Vendor tools.
Logo generation sends the entered brand name, selected style and generated instructions. Listing tools can process selected product photos, video frames or descriptions to assess presentation, improve resolution or assist with text. Optional certificate assessment may transmit a verification image and retain extracted fields and a comparison result. Do not include unrelated personal details in a prompt or brand field.
12.5 Consent and alternatives.
Personal-photo tools are optional. Use the manual measurement and ordinary ordering route if you do not wish to use them. Where consent is required, we must explain the specific use before processing and provide a way to withdraw it. A device photo-library permission is not itself consent to every AI use of the selected image.
12.6 Alibaba's separate retention policy.
Images and other data received by Alibaba are retained under its Alibaba Cloud Model Studio Data Retention Policy and the applicable service arrangement. Retention depends on the model, feature and settings, with security and legal exceptions; zero retention does not apply to every path. AFH's 30-day deletion rule for its own copies is not a guarantee of the same deadline for Alibaba's copies. This distinction does not remove AFH's duties to select and oversee providers, handle applicable deletion requests or honour earlier privacy commitments. Provider retention can differ for inputs, outputs, uploaded files and operational logs. Contact privacy support about the processing relevant to your request.
12.7 Training and purpose.
The AI features use inputs to provide the requested assessment or generated result. Private fitting, try-on and verification files are not authorised for general-purpose model training or advertising merely by use of a feature. Any separate use requires a justified and disclosed purpose and any consent required by law. Provider handling depends on the applicable service arrangement and settings; this notice does not make a blanket no-training representation for every provider or model. Existing non-training promises must be honoured. Contact privacy support about the processing relevant to your feature.
12.8 AFH's 30-day image deletion.
AFH deletes personal photos uploaded for virtual try-on or photo-based measurement estimation, generated image results and associated derived copies held by AFH after 30 days. This covers the stored image files and their database image records and references, not merely hiding a preview or allowing its link to expire. For try-on, the period runs from creation of the try-on request. Valid requests for earlier deletion are handled under section 21. The commitment must also be honoured for AFH-controlled temporary, migration and backup copies; the general retention criteria elsewhere in this notice do not silently extend it. Saved numerical measurement profiles, order snapshots and limited consent or feedback records are separate from the images and follow Schedule A. This image rule does not apply to public listing photographs, vendor verification documents or unrelated order evidence. Alibaba-held copies are addressed separately in section 12.6.
12.9 Feedback and staff access.
The administrative feedback view exposes rating, feedback, listing title and submission information, not private try-on image URLs or dedicated buyer-identity fields. Free-text feedback can still identify someone. Feedback and limited consent/audit evidence may be retained separately from photos. Authorised technical processing and necessary support access are different from publicly displaying a photo or routinely giving it to a referring executive.
12.10 No retained biometric identifiers at AFH.
AFH does not retain facial geometry, embeddings or reusable biometric identifiers derived from personal photos. We do not keep a reusable facial or body template for recognising or identifying you. This statement concerns AFH's retention; it does not assert that an AI model performs no temporary image or face analysis, or make the same retention representation about Alibaba. Ordinary account identifiers, saved numerical measurements and limited consent records are not reusable biometric templates under this statement. The absence of retained templates does not by itself determine whether a particular processing activity is regulated: any applicable notice, consent, deletion and other safeguards still apply.
13. Product Analytics and Automated Processing
13.1 Account-linked journey events.
The signed-in mobile app sends AFH events such as screen/route views, the journey step, checkout entry and app backgrounding, together with a session identifier and buyer/vendor audience. The server links events to the user. Routes can include record identifiers. We use these records to understand progress through the service, identify failed or confusing steps and improve operation; they are not described as anonymous merely because a dashboard displays counts.
13.2 Diagnostics.
Server, network and error records help investigate outages, security events and failed operations. Sentry diagnostics may process error and performance information when enabled. Such records can contain identifiers in a message, URL or log. We must limit unnecessary personal information and avoid recording passwords, complete payment credentials, private image links or unnecessary document content.
13.3 Automated results.
Rules and AI can generate validation warnings, moderation flags, document comparisons, listing assessments, estimates and workflow transitions. Some controls block a message or affect review progress. Standard vendor document submission queues a person, while an optional certificate-assessment action can advance a document status. We do not promise that no automated processing influences access or decisions.
13.4 Review and limits.
Contact support or privacy support to question an incorrect result and request human review where appropriate or required. We will explain the meaningful factors and consequences without disclosing another person's private information or details that would defeat security. Where law restricts solely automated significant decisions, we must meet those conditions rather than relying on general Terms acceptance.
14. Who Receives Information
14.1 Making and inspecting orders.
The relevant vendor receives the garment specification, necessary measurements and permitted order communications. Hub personnel receive the information needed to receive, inspect and prepare the relevant items. Staff access is role-based; the full residential address or every private attachment is not automatically necessary for a tailor who sends only to the hub.
14.2 Delivery, payment and support.
Carriers and fulfilment/customs partners may receive recipient name, address, contact details and shipment information. Payment providers receive relevant payment or payout data. Authorised support, finance and operational personnel receive information needed for the assigned task. We aim to limit disclosure rather than send the entire account record to each participant.
14.3 Service providers.
Hosting, storage, email, push delivery, authentication, address validation, AI and enabled diagnostics providers process information relevant to their function. Schedule B describes providers and recipients according to the features and services used. Some providers have independent compliance or account purposes, so they are not all described as acting exclusively on AFH's instructions.
14.4 Law and protection.
We may disclose necessary information to comply with a binding lawful request, protect people or systems, investigate wrongdoing or establish and defend a legal claim. We assess the scope and restrict disclosure where appropriate; a general possibility of legal process is not a reason to give unrestricted access to every requester.
14.5 Business changes.
A genuine financing, reorganisation or business-transfer process may require limited disclosure under appropriate confidentiality and privacy safeguards. Relevant continuing responsibilities and any legally required notice or choice must be addressed. A change of owner does not automatically permit incompatible use of information collected under earlier promises.
15. Hosting, Storage and International Transfers
15.1 Hosting and storage copies.
AFH uses AWS infrastructure, including Amazon S3 for media storage and CloudFront for public media delivery. Legacy media, migration originals or recovery copies may also remain in Cloudflare R2. A change of active storage provider does not by itself delete earlier copies. These copies remain subject to the retention and deletion commitments in this notice.
15.2 Public and private storage.
Published catalogue media can be delivered through a public content-delivery URL. Private verification, fitting and support files use restricted access and, where appropriate, expiring links. A signed link is an access credential for its lifetime; do not share it publicly. Restricted storage does not mean that authorised staff, technical providers or a recipient you choose can never see the file.
15.3 Countries.
AFH's service involves the United States and Nigeria. AI services, hosting, delivery networks and supplier support may involve processing or access in other countries, depending on the provider and service used. This notice does not represent that all information stays in a single country or region. Contact privacy@afrofashionhouse.com for information about the locations and recipients relevant to your use. Applicable transfer safeguards are described in section 15.4.
15.4 Safeguards.
Where cross-border transfer law applies, we must use an available lawful transfer basis and appropriate safeguards, such as suitable contractual protections and a documented assessment where required. We do not claim that merely using AWS, accepting these Terms or selecting a regional API endpoint satisfies every transfer requirement. Ask privacy support about relevant recipients and safeguards, subject to legitimate confidentiality limits.
15.5 Deletion across copies.
Migration originals, rollback copies, object versions, temporary files, exports and backups must be included in retention and deletion planning. A database remap or removal of an active link is not necessarily physical deletion. Copies retained for recovery must not be used to defeat a privacy request or silently restore data previously deleted.
16. Browser Storage, SDKs and Device Permissions
16.1 Essential storage.
The mobile app stores authentication tokens in device secure storage and uses local storage for supported functions such as cart and onboarding state. The admin portal uses a refresh-session cookie, an in-memory access token and a local sign-out marker. The hub interface can keep a local offline inspection queue until synchronisation. Clearing browser data or uninstalling an app is not the same as deleting server-side records.
16.2 Camera and media access.
Camera or selected-photo/video access is used when you choose to create or upload relevant media. You may manage operating-system permissions, although refusal can prevent that upload feature from working. Selecting a file can transmit the file and accompanying metadata; do not assume all location or other embedded metadata has been removed unless confirmed.
16.3 Notifications.
With the applicable device permission, the app registers a push token for notifications. Expo and the relevant Apple/Google delivery infrastructure handle the necessary token and message payload. A notification can appear on a lock screen or shared device. Device settings can disable pushes; the underlying order and required service messages may still exist.
16.4 Google and other SDKs.
Optional Google sign-in supplies the verified identity claims needed to link an account, not general access to your Gmail or contacts. Address autocomplete can send text as you type and validation sends the supplied address to Google services. Loading media or following a provider link also exposes ordinary network-request information to the receiving service.
16.5 Analytics and trackers.
Account-linked app usage events and diagnostics are described in section 13. Browser storage, SDK and email-related processing depend on the feature, provider and settings in use. This notice does not make a blanket statement that all services are free of tracking. Non-essential analytics or advertising-related processing requires the notice and choices applicable to that use. Contact privacy support about the processing relevant to your use.
16.6 Browser signals.
Older Do Not Track signals are not the same as Global Privacy Control or another legally recognised opt-out mechanism. Where applicable law requires recognition of an opt-out signal, AFH must honour it for the covered processing. Contacting us by email does not replace an automated opt-out mechanism required by law.
17. Service Messages and Marketing
17.1 Operational communications.
AFH sends verification, security, payment, order, inspection, delivery, group, support and refund messages through enabled email, app and push channels. Resend is integrated for email delivery. The provider receives the destination and message content needed to send the communication, as well as delivery-related information. We should not place unnecessary sensitive data in subject lines, notifications or routine receipts.
17.2 Preferences.
Account notification controls apply to the categories they describe, and device controls affect push delivery. Optional marketing choices must remain separate from essential order and security notices. Use an available unsubscribe route or contact privacy/support to stop promotional messages; we may retain a minimal suppression record to respect that choice.
17.3 Contact forms and email.
Where the website form opens an email draft, entering information in the form does not itself send it to AFH. Sending the email uses your email provider and AFH's receiving service. Where direct form submission is enabled, the form explains that the details are sent to AFH to handle your enquiry. Do not use a general enquiry to submit identity files unnecessarily.
17.4 Marketing permission.
Participation in a group, a referral or an AI feature does not by itself authorise unrelated advertising. Email open/click tracking and marketing automation, where used, are subject to the applicable disclosure, consent and opt-out requirements. Marketing permission must be separate from necessary service communications.
18. Sale, Advertising and Sensitive Uses
18.1 Sale and advertising-related disclosures.
The service purposes and recipients described in this notice do not by themselves authorise selling personal information, sharing it for cross-context behavioural advertising or using it for third-party targeted advertising. If processing falls within one of those categories under applicable law, AFH must provide the specific disclosures and required opt-out choices. Contact privacy@afrofashionhouse.com about applicable disclosures and choices for your information.
18.2 More than payment for data.
Some privacy laws define sale or sharing more broadly than receiving money. Sending information to a processor for a permitted service and disclosing it for a provider's independent advertising purpose are not automatically the same. The legal classification depends on the purpose and terms of the disclosure.
18.3 Sensitive information.
We use sensitive information only for the stated, justified purpose and applicable legal conditions. We do not treat a fashion photograph as permission to build an unrelated health, ethnicity or identity profile. Where a law gives a right to limit a particular sensitive-data use, we must provide the relevant disclosure and mechanism. A lawful verification purpose is not a general exception for every later use.
18.4 Choices and fairness.
Contact privacy support to ask about or exercise applicable opt-out/limitation rights. Any additionally required browser signal or dedicated website link must also work. We do not penalise you for exercising a protected privacy right, although a feature may genuinely need specific information to perform the service you request.
19. Security and Incidents
19.1 Safeguards.
AFH uses controls intended to limit access by account, role and purpose, protect authenticated sessions and restrict private-file delivery. Appropriate transport, storage, logging and access safeguards must be maintained for each environment. We do not claim that every database field is individually encrypted merely because a storage service supports encryption.
19.2 Your part.
Protect your credentials, keep devices updated and avoid sharing private links or exported spreadsheets. Never give staff an authentication code in ordinary chat. If you suspect unauthorised access, contact support or privacy support promptly. Your cooperation does not remove AFH's own security obligations.
19.3 Investigation and notice.
We will assess a suspected incident, limit further exposure, preserve necessary evidence and make notices required by applicable law. We will not promise that no breach can occur or that every suspected event has the same legal notification deadline. Notice should accurately describe the known circumstances and protective steps without exposing more personal information.
20. How Long Information Is Kept
20.1 Category-specific criteria.
Schedule A explains retention by category. We consider the requested service, active obligations, justified complaint/payment periods, identified legal requirements, security needs and the person's choices. We should delete or properly de-identify information when the applicable purpose ends. A vague possibility of future usefulness is not a retention schedule.
20.2 Separate records.
A private photo, its generated result, a consent record, an order snapshot and a financial entry may have different justified periods. Deleting an image does not require destroying every record that consent was given, but the consent record should not contain an unnecessary copy of the image. Pseudonymous identifiers that remain linkable are still personal information.
20.3 Holds and backups.
An identified legal or dispute hold may require limited evidence to remain, subject to the applicable law and existing commitments. Holds should be documented and reviewed, not applied to an entire account by default. Backup and rollback copies must have limited retention and restricted restoration. These criteria do not extend AFH's 30-day personal-image deletion commitment or permit retention of the biometric identifiers described in section 12.10.
20.4 Prior promises.
This notice does not retrospectively authorise longer retention, new AI training or new advertising use of information collected under a narrower promise. If an existing promise is not being met, AFH must investigate and remediate the mismatch; simply changing wording is not the fix.
21. Deletion, Closure and Consent Withdrawal
21.1 Different actions.
Signing out, deleting a reusable measurement profile, requesting account closure and requesting erasure of a particular file are different actions. Account closure can be delayed by unresolved orders, tickets, disputes or balances. A separate privacy request must still be assessed within the applicable rules; an unrelated open ticket is not an automatic justification to retain everything.
21.2 Closure effects.
The current closure process removes selected reusable profiles/addresses, deactivates access, changes selected identifiers and retains reconstructable order/payment history. Some owned media are deleted through a separate storage process; failure can keep closure pending for retry. Vendor verification records may be marked for erasure review rather than immediately deleted. Do not assume every flag represents completed physical deletion.
21.3 Historical and shared information.
Messages, recorded display names, public reviews, consent/audit evidence, provider records and authorised exports need separate assessment. We may preserve the minimum evidence necessary for a lawful purpose, with explanation, while deleting unrelated data. Someone else's lawful copy is not automatically erased when your account closes.
21.4 Withdrawing AI consent.
Contact privacy support to stop future consent-based personal-photo processing and request deletion of relevant inputs/results. Where a request is already being processed by a provider, we will assess what can be stopped and what deletion steps are required; we do not guarantee instant recall from every processor. You may continue to use unrelated manual features. A revoked device permission alone does not delete a previously uploaded file.
21.5 Recovery and restoration.
Deletion handling must cover active storage, derived objects, rollback copies and necessary processor instructions. If an older backup is restored, applicable deletion and restriction records must be reapplied before restored data is returned to ordinary use. Account de-identification must not be advertised as irreversible anonymisation where remaining identifiers still link to the person.
22. Making a Privacy Request
22.1 Available rights.
Depending on the law and circumstances, you may ask to access or obtain a copy of your information, correct it, delete it, restrict or object to certain processing, withdraw consent, obtain portable information, opt out of particular advertising/sale/profiling uses or request review of a relevant automated decision. Rights can have lawful exceptions; we will explain an applicable refusal rather than assume no rights exist because you are a vendor or have no account.
22.2 Contact routes.
All covered users, including buyers and vendors, should email privacy@afrofashionhouse.com. You can also raise a privacy request through in-app support, or send a written request to Afro Fashion House Inc. at the address in section 1.1. Support requests are routed to Afro Fashion House Inc.'s privacy handling process; they do not create a separate privacy administrator. Do not send passwords or full card numbers to establish identity.
22.3 Verification and agents.
We may request information proportionate to the risk so we do not disclose one person's records to another. Existing account verification or relevant transaction context may be sufficient; we do not require a fresh identity document for every request. An authorised agent may act where law permits, subject to appropriate authority checks. Some opt-outs must be handled without the identity verification required for access to private records.
22.4 Responses.
We will respond without undue delay and within the applicable legal period. If an extension is permitted and needed, we will explain it within the required time. We will identify the scope of any exception, the available review route and any permitted fee before imposing it. Internal routing or coordination with Provenfield Labs Limited or another recipient does not automatically restart a request or its response period.
22.5 Review and complaints.
If you disagree, reply with the request reference and say that you seek a privacy review or appeal. A reviewer should consider the reasons and any new evidence. This internal route does not prevent you from contacting a competent regulator or exercising a legal remedy. Applicable regional details appear in section 23.
23. Regional Rights and Regulators
23.1 Nigeria.
Where the Nigeria Data Protection Act 2023 applies, individuals have rights concerning their data, consent and relevant automated decisions, subject to lawful conditions. Contact privacy@afrofashionhouse.com for requests or objections, including Nigerian vendor matters; you may also complain to the Nigeria Data Protection Commission. The relevant US/Nigerian operating arrangements and international transfers must comply with the applicable Nigerian requirements. Applicable rights and safeguards are assessed under the law governing the processing.
23.2 Colorado.
If the Colorado Privacy Act applies to the processing, eligible consumers may access, correct, delete and obtain portable data and opt out of covered sale, targeted advertising or significant-decision profiling. We respond to covered requests within forty-five days, with a permitted extension and notice where appropriate; appeals follow the statutory process. You may contact the Colorado Attorney General. Special biometric obligations need separate assessment and may not depend on the same thresholds as ordinary consumer processing.
23.3 California.
Where AFH is subject to the CCPA, eligible residents have applicable rights to know, correct, delete, opt out of sale/sharing, limit certain sensitive uses and receive non-discriminatory treatment. Covered access/correction/deletion requests receive acknowledgement within ten business days and a substantive response within forty-five calendar days, subject to a permitted extension. Other requests can have shorter deadlines. Schedule C describes information categories. Any required historical collection, disclosure and sale/sharing information must address the applicable period; contact privacy support for information relevant to your request. Complaints may be directed to the California Privacy Protection Agency.
23.4 Other US jurisdictions.
Other state laws can give rights and impose conditions even where a Colorado or California threshold does not apply. We will assess the applicable law rather than assume a small business is exempt from every privacy, biometric, security or children's rule. Colorado contract-law wording in the Buyer Terms does not remove another mandatory privacy protection.
23.5 Other countries.
AFH's initial buyer launch is US-focused, with Nigerian vendor operations. This notice does not claim that all users are covered by UK/EU GDPR. If the actual activity brings those or other laws into scope, the appropriate rights, legal bases, representatives and transfer safeguards must be addressed. You may contact privacy support about a relevant non-US/Nigerian request; this clause does not exclude a law that already applies.
24. Children and Information About Others
24.1 Adult service.
AFH accounts are for people aged eighteen or older. We do not intend children to create accounts or operate the service independently. An age statement is not proof that no child's information can reach us, and we will assess reports or actual knowledge appropriately.
24.2 Adult purchases for a child.
Where a child garment is supported, an adult with appropriate authority should provide only the necessary measurements and recipient details through an approved workflow. That does not authorise uploading a child's image to an adult personal-photo AI tool. Do not provide information about another adult without the appropriate permission or other authority either.
24.3 Photos and reports.
Until a specifically reviewed child-photo feature is offered with the required safeguards, do not upload children's images for AI processing. If you believe a child has used an account or that an image was submitted without authority, contact privacy support for investigation, protection and any required deletion. A guardian's general acceptance of the Terms does not automatically satisfy every children's privacy requirement.
25. Updates, Questions and Unlisted Situations
25.1 Updates.
We will identify the effective version and explain material changes through appropriate notice. New consent will be obtained where required before a new use. An archived version and consent record should remain available for accountability. Changes must be aligned across the app, website, upload notices and app-store disclosures, rather than silently changing one copy.
25.2 Unlisted processing.
If a situation is not expressly covered, applicable privacy law and the purpose originally disclosed still apply. AFH must assess necessity, recipients, safeguards and any notice/consent requirement before proceeding. An unforeseen-situation clause is not permission for unlimited data use, retention or sharing.
25.3 Getting help.
Privacy for all covered users: privacy@afrofashionhouse.com, handled by Afro Fashion House Inc. Written privacy requests may be sent to its address in section 1.1. General order support: support@afrofashionhouse.com. Ask for an accessible copy or assistance explaining a request where needed.
Schedule A. Retention by Category
This schedule gives the stated retention periods and the purpose-based criteria that apply to other records. It is not an authorisation for indefinite retention. Operational deletion must cover associated files and recipients, not only a database row.
| Category | Period or retention criterion |
|---|---|
| Account and preferences | While the account is active and needed for the service; on closure remove/de-identify unnecessary profile fields. Keep only justified residual fraud, request or transaction identifiers for a documented period. Review dormant accounts rather than keeping them indefinitely by default. |
| Reusable measurements and addresses | Until removed/replaced or the relevant closure process completes, subject to needed current fulfilment information. Separate historical order evidence can remain under its own criterion; deleting a saved profile is not deletion of the purchased snapshot. |
| Orders, payments and payouts | For fulfilment, settlement, corrections and the identified accounting, tax, dispute or legal-claim periods that actually apply. Keep enough to reconstruct amounts and obligations, not every unrelated image or obsolete contact field. |
| Verification documents and BVN | For the justified verification relationship and a documented post-relationship fraud/claims or specific legal need. The period depends on the purpose and applicable legal requirement. Raw files, extracted fields and duplicate fingerprints must be assessed separately and deleted when no longer justified. |
| AI try-on and photo-estimation images held by AFH | Delete personal photos, generated image results and associated derived copies after 30 days, including the stored files and database image records/references. For try-on, count from request creation. Honour valid earlier deletion requests. Include AFH-controlled temporary and recovery copies in the commitment. A retry must not silently restart an old image's retention period. |
| Optional non-AI measurement reference photos | Keep with the measurement set and related orders until the photo or set is removed, or account closure completes. Removal revokes app access from linked orders and initiates storage/database-image deletion; failed storage deletions are retried. Abandoned uploads not attached to a saved set are deleted after 30 days. See section 6.7 for separate photo removal, active-set restrictions and restricted recovery copies. This is not permission to extend retention of older AI images collected under a 30-day promise. |
| Alibaba-held AI copies | Alibaba's separate Model Studio Data Retention Policy and applicable service arrangement govern its retention. See section 12.6; AFH's duties and earlier commitments remain applicable. |
| Facial geometry, embeddings and reusable biometric identifiers | AFH does not retain these identifiers derived from personal photos. This is separate from retaining an ordinary account identifier or a saved measurement value. See section 12.10. |
| AI feedback and consent records | Keep minimum feedback and acceptance/version evidence for the documented service-improvement and accountability period, without retaining private photo bytes simply to prove consent. Remove unnecessary identifying free text when appropriate. |
| Chats, tickets and inspection evidence | For the active interaction and a justified support, warranty, fraud or claims period. Review private attachments and identifiers separately from necessary transaction history. Shared messages may need redaction or restricted retention rather than erasing another person's valid evidence. |
| Public listings and reviews | While published and needed for their stated function, followed by limited justified archive/evidence retention. Remove withdrawn content from ordinary display appropriately. External recipient/search copies may persist outside AFH's direct control. |
| Journey events and diagnostics | Only for as long as needed for the specific product-analysis or security purpose, then delete or properly aggregate/de-identify. The period depends on the event and purpose; there is no single numeric period stated here. |
| Referrals and exports | For the assigned onboarding support and necessary attribution/audit period. Revoke ended assignment access and control exported copies. Contact details must not become an indefinite personal prospect list for a former executive. |
| Marketing suppression and requests | Keep minimal evidence needed to respect an unsubscribe/objection and to demonstrate request handling; do not use the suppression record for renewed advertising. Apply a justified review period. |
| Backups and migration originals | Restricted recovery use for a limited recovery period, with deletion applied to retained versions and restored copies. The period depends on the record and applicable purpose. This criterion does not extend the 30-day personal-image commitment in section 12.8 or permit retaining the biometric identifiers described in section 12.10. No promise of immediate deletion from every backup is made. |
Schedule B. Providers and Data Flows
The following providers and recipients may process information for the listed functions, depending on the features and services used. Their data handling can differ by service and settings. For locations and transfer safeguards, see section 15; contact privacy support about a recipient relevant to your use.
| Provider or recipient | Function and relevant information |
|---|---|
| Provenfield Labs Limited | Nigerian vendor operations, including necessary onboarding, verification, fulfilment and Paystack payout records. This operational role does not make it a co-issuer or separate administrator of this Privacy Policy. Processing roles depend on the activity and applicable law; Afro Fashion House Inc. remains the central privacy contact. |
| Amazon Web Services | Application/database infrastructure, S3 media storage, public CloudFront delivery and related operational records. Necessary account/transaction data and stored files are handled according to the configured service. Storage, delivery and support may involve different locations as described in section 15. |
| Cloudflare R2 | Legacy media, retained migration originals and rollback copies where they remain. Retention and deletion apply to these copies as described in sections 15 and 20. |
| Alibaba Cloud Model Studio | Enabled AI generation/assessment using feature-specific text, image links/bytes and outputs. Processing, retention and permitted uses depend on the model, feature and applicable service arrangement; see section 12. Private document review is not the same data flow as generating a public store logo. |
| Stripe | Buyer payment collection and related authorisation, fraud, refund and dispute handling. Receives payment-interface information; AFH uses transaction identifiers, amounts and statuses. Some provider purposes may be independent. |
| Paystack and relevant banks | Vendor bank-account resolution, transfer recipient setup, payouts and reconciliation. Relevant bank/account details and transaction evidence are processed. Payout processing is separate from government identity verification. |
| Resend | Email delivery using recipient addresses and message content, with delivery/error records. Open/click information may be processed where tracking is enabled, subject to applicable notice and choices. |
| Expo, Apple and Google push delivery | Notification registration and routing using device push tokens and the message payload. Device lock-screen settings can expose notification content locally. |
| Google sign-in | Optional account authentication using verified subject, email and name claims. This does not grant AFH general access to Google email or contacts through this sign-in function. |
| Google address services | US address autocomplete and validation using typed address text, session token and submitted address/unit details. This is a disclosure even though the server, rather than the app, calls Google. |
| Sentry, if configured | Backend error/performance diagnostics. When enabled, diagnostic events can contain identifiers or request details; see section 13.2. |
| Makers, hub, carriers and advisers | The minimum specifications, inspection, recipient, transaction or claim information needed for their task. The relevant recipients depend on the shipment or case; contact support or privacy support for information about yours. |
Schedule C. US Category Transparency
This schedule is a practical mapping of AFH data to common US privacy-notice categories. It does not assert that AFH meets every state-law threshold. This category description is not a statement that every category was collected or disclosed about every person during the preceding twelve months. Where a historical-period disclosure is required, it must reflect the applicable collection and disclosures; contact privacy support for information relevant to your request. Sources and purposes are detailed in sections 3-5; retention is in Schedule A.
| Category grouping | AFH examples and disclosure context |
|---|---|
| Identifiers and customer records | Account/contact details, sign-in subject, recipient address, government identifiers and relevant bank records. Service providers, necessary fulfilment/payment recipients and authorised reviewers receive information appropriate to the task, not automatically the whole category. |
| Commercial information | Purchases, saved/cart selections where recorded, order stages, payments, refunds and vendor performance. Used for the requested commerce service, support and justified analysis. |
| Internet, app and technical activity | Routes, journey/session events, network and diagnostic records, authentication/browser storage and notification events. Account-linked records remain personal data even where reports are aggregated. |
| Visual and other uploaded content | Photos, generated images, product video where supported, verification scans, review/support content and any audio contained in an uploaded file. Public content and restricted fitting/verification evidence have different recipients. |
| Professional and business information | Vendor business/representative details, verification progress, referred-vendor records and administrator roles/actions. Broader employment and applicant data needs its separate notice. |
| Derived information | Suggested measurements, confidence indicators, document comparisons, moderation flags and service-progress analysis. These can be inaccurate and require appropriate review routes. |
| Sensitive or specially regulated information | Certain identifiers, account access information, private communications and any regulated biometric or other sensitive processing identified by the technical/legal assessment. Do not infer that every photograph has the same legal classification. |
Sale/sharing and sensitive-use disclosure: Section 18 describes the applicable disclosures and choices for sale, advertising-related and sensitive uses. Any required historical-period information, opt-out or limitation mechanism must address the relevant processing. The browser-signal obligations in section 16.6 also apply.
Location information: AFH receives entered delivery/business addresses and ordinary network-related information. Entering an address is distinct from background precise-GPS collection. Any new precise-location use requires the appropriate disclosure and permission before it is enabled.