Privacy Policy
Effective date: 6 November 2026
1. Who handles your information LH Infra Mesh Private Limited operates Lighthouse and determines the purposes and means of personal-data processing for its own platform activities. Our registered address and privacy/grievance contact are in the Contact, Grievance & Dispute Resolution Policy. For an enterprise workspace, we may process some customer-controlled data on documented instructions under a Data Processing Addendum. Our own account administration, security and billing purposes remain separately identified. A label such as processor does not override the actual role. This notice covers enabled Lighthouse features, not every possible future product. Before publication, the data inventory and provider details below must be matched to the production service.
2. Information and purposes Account information: name, phone number, email, login identifiers, role and business affiliation are used for registration, authentication, support and account administration. Professional and business profiles: business name, location, contact details, services, experience, credentials and authorised brand relationships are used to create profiles and perform the stated verification checks. Public portfolios and reviews: descriptions, images, credits and reviews you submit are used for the visibility you choose and the public services you request. An image or drawing may reveal people, addresses or site security information; remove unnecessary personal details before publishing. RFQ and order information: requested products, specifications, quantities, approximate project location, quotations, order records, delivery details and invoices are used for sourcing, coordination, fulfilment support, disputes and required accounting records. Private project or AI inputs: plans, photos, prompts, BOQs and output history are processed only for the feature requested, security, support and other specifically disclosed lawful purposes. Uploading does not make the material public. Technical information: device/browser information, IP address, session data, necessary logs and error reports are used for service delivery and security. Optional analytics, advertising identifiers and tracking are subject to the Cookie Policy and applicable choices. Payment information: the payment provider may handle financial credentials where payments are enabled. Lighthouse should receive only the transaction details needed for billing and reconciliation. [CONFIRM payment provider, data received and whether any financial credentials are stored.] Support and compliance information: correspondence, complaint evidence, moderation records and consent records are used to resolve requests, protect users and demonstrate
compliance. Do not send unnecessary identity documents or sensitive material through ordinary email.
3. Information received from others A business administrator, authorised supplier or professional may provide your details to deliver a service you requested. Registry and professional-directory information may support verification. We assess the lawful basis, notice obligations, accuracy and necessity before reusing publicly available personal data; public availability is not unrestricted permission. Partners must have authority for referrals and uploads. We do not need your entire contact list to accept a lead. We will not import it for that purpose.
4. Lawful processing and choices We provide clear, purpose-specific notices and seek consent where required. You can decline optional marketing, optional analytics and optional model-training uses without losing unrelated core services. Permission to publish a portfolio, send an RFQ, receive marketing and train a model are separate decisions. Where law permits processing without consent for a specified purpose, we document that legal ground and use only necessary data. We do not import broad foreign-law “legitimate interests” language as a substitute for an available Indian legal basis. Consent withdrawal should be as easy as giving consent. It stops future consent-based processing, subject to necessary legal retention, and may prevent the particular service that needs the information. It does not automatically invalidate processing already lawfully performed.
5. Who receives data Other users see only content and fields made public. Relevant shortlisted suppliers or professionals receive the minimum request information needed for the requested introduction, quotation or order. Before a new disclosure, the interface must explain the recipient category and purpose. Do not share complete plans or precise residential locations with every dealer when an approximate requirement will suffice. Service providers may process data for hosting, storage, authentication, communications, support, analytics, payments or AI under appropriate obligations and access limits. Confirm the actual provider legal entities, locations, purposes and retention before launch; the enterprise Subprocessor List is not a claim that an unverified vendor has been appointed. Business administrators receive authorised workspace information consistent with the controls disclosed to their users. Independent sellers and professionals are responsible for their own separate processing and privacy notices. We may disclose information when legally required, to respond to valid legal requests or to protect lawful rights with appropriate safeguards. In a corporate transaction, recipients must be bound to protect the data and provide required notices.
6. AI processing, review and training A requested AI feature may send the minimum necessary input to the identified AI provider and return an output to your workspace. The User Uploaded Content & AI Processing Notice must be shown at that point and identify relevant provider practices. Private uploads, enterprise material and personal data are excluded from general model training unless separately authorised on a lawful basis with sufficient IP rights. Service inference, safety checks, retrieval indexing, feedback and model training must not be presented as one undifferentiated purpose. Human access is limited to authorised support, safety, legal or quality tasks explained to the user; reviewers must be bound by confidentiality. Optional quality-review programmes require their own notice where appropriate. Pseudonymised data remains personal data when individuals can still be identified.
7. Storage, transfers and security [CONFIRM primary hosting, backup and provider processing countries.] Information must not be transferred to a location prohibited by applicable law or contrary to an agreed enterprise restriction. Required contractual and technical safeguards apply; we do not claim that all data stays in India unless the verified architecture supports that statement. We apply safeguards appropriate to the data and risk. No system can guarantee perfect security. The public Security Policy explains reporting and responsibilities without claiming unverified certifications, encryption specifications or round-the-clock monitoring.
8. Retention and deletion We keep data only while needed for the stated purpose or an identified legal requirement. The Data Retention Schedule distinguishes active records, deleted content, backups, security evidence, verification records and financial records. It does not impose an automatic seven-year retention of every closed account or ten-year retention of every RFQ. After a verified deletion request, ordinary account data is deleted or irreversibly anonymised under the disclosed deletion timetable. Narrow categories may remain for tax duties, valid legal holds, fraud evidence or mandatory intermediary retention, with restricted access and an expiry review. They are not reused for advertising or AI training. [CONFIRM and publish actual production deletion and backup-expiry periods before release.] We instruct processors to delete relevant data and track completion. Independent recipients may retain records for their own lawful duties; we explain this and assist with routing requests where appropriate.
9. Your requests and complaints Use [CONFIRM privacy request URL and monitored email] for access or information about processing, correction, deletion, consent withdrawal and grievances. Applicable legal rights, including nomination where available, will be honoured according to the law in force. Where portability, restriction or objection is not a statutory right, we explain any voluntary export or account controls actually offered.
We verify identity proportionately, request clarification where needed, and give reasons for any lawful refusal or partial fulfilment. A request must not require more information than necessary. The Account Deletion Policy provides a route available even after uninstalling the app. You may escalate to the grievance officer and then the competent regulator, Board, appellate body or court where that route is available under applicable law. This notice does not represent future commencement provisions as already operative.
10. Children, permissions and external services Accounts are for adults aged 18 or above. We do not knowingly offer accounts to children. If child data is uploaded incidentally or an account appears to belong to a child, contact us so we can assess and remove or lawfully handle it. An age statement alone is not an adequate safeguard for a future child-directed feature. Camera, photo-library, microphone or location permissions are requested only for relevant enabled features. Denial may affect that feature. [CONFIRM which device permissions are actually used.] External websites and independent providers have their own notices; linking does not authorise unrelated collection.
11. Marketing, changes and contact You can stop optional marketing using the unsubscribe or preference route provided. We retain the minimum suppression information needed to respect that choice. Operational messages about security or an existing transaction are handled separately. We publish material changes with appropriate notice and obtain fresh consent for new purposes when needed. This policy is supplemented by the Cookie Policy and the feature-specific AI Processing Notice, not replaced by vague consent to all future policies.
Publication checks Complete the processing inventory, device-permission list, contacts, retention periods and country/provider details. Align the App Store privacy disclosures and Google Play Data safety answers with actual behaviour. Legal must confirm the applicable SPDI/IT Act duties and the staged commencement of the DPDP framework before publication.
12. Detailed purposes and legal bases for international processing Where GDPR or UK GDPR applies, identify a legal basis for each activity rather than treating use of the service as consent to everything. Account creation, user-requested RFQs and paid service administration may rely on contractual necessity where the processing is objectively necessary. Fraud prevention, service security and limited business administration may rely on legitimate interests after the required balancing assessment. Tax, lawful orders and mandatory records may rely on legal obligation. Optional marketing, non-essential tracking and other consent-based uses require a freely given, specific and informed choice that can be withdrawn. Withdrawal does not retrospectively invalidate earlier lawful processing, but future consent-based processing
must stop unless another valid basis genuinely applies. Do not switch bases merely to defeat a withdrawal. Special-category data requires the relevant additional condition; a general upload licence is insufficient. The service should minimise such data and must not infer health, religion or other sensitive characteristics for advertising. Precise residential and security information can be highly sensitive even if not legally classified as a special category.
13. Public, imported and historical information Public profiles and completed-project stories may include professional identity, company details, project credits, approximate location and approved images. Private account, RFQ, quotation and enterprise records are not public simply because the same person has a public profile. Where information comes from a firm, authorised agent, public business source or rights-cleared portfolio, record its source and provide the notice required by the applicable law. Public availability does not remove privacy obligations. If we receive information about a non-user, we limit it to the lawful stated purpose and provide an appropriate route for correction or objection. When older projects are resurfaced, retain their historical context and review unnecessary personal details. A current professional profile should not continue to attribute an employee or client relationship known to be outdated. A correction request must propagate to relevant discovery and AI-derived records.
14. Recipients, providers and independent parties Recipients can include selected suppliers responding to an RFQ, an appointed professional, payment and logistics providers, infrastructure and support processors, AI providers used for a chosen feature, and authorities where law requires. The actual list or categories and relevant purposes must be published accurately. A supplier may independently determine how it performs a contract or retains an invoice and can be a separate controller for that activity. A cloud provider processing solely on instructions has a different role. Describing everyone as a “partner” does not resolve responsibility. Lighthouse must limit processor use by contract, supervise onward access and use approved subprocessors for enterprise processing. Buyer data must not be shared with unrelated sellers or advertising audiences merely because a user submitted one RFQ.
15. EU/EEA and UK individual rights Where applicable, you may request access, correction, erasure, restriction and portability in the legally prescribed circumstances; object to processing based on legitimate interests; and object to direct marketing. You may withdraw consent and complain to the competent supervisory authority. Portability applies to the relevant automated consent/contract processing and does not mean every internal record must be exported. We respond without undue delay and within the applicable one-month period, subject to a permitted extension of up to two further months for qualifying complexity or number of
requests and timely explanation. Apply current jurisdiction-specific rules for identity verification, clarification and clock calculation. We do not impose a blanket 30-day substitute for a calendar-month deadline. We verify proportionately, protect the rights of others and explain any lawful refusal or limitation and the complaint route. Information is ordinarily provided without charge, subject only to lawful exceptions. You do not need to purchase a service to exercise a right. Where a solely automated decision with legal or similarly significant effects falls within the relevant restrictions, we will not rely on ordinary platform acceptance as authority. Apply the permitted basis and safeguards, including appropriate human involvement, representations and contest where required. Routine product suggestions are not automatically such decisions.
16. California and other US state privacy rights Where Lighthouse is subject to the relevant state law, provide the notice at collection and required disclosures of categories, purposes, retention and sale/sharing practices. Covered California residents may exercise access/knowledge, deletion and correction rights, applicable sale/sharing opt-outs and limits on specified sensitive-information use, without unlawful discrimination. Apply the relevant 45-day response framework for covered requests, with a permitted additional 45 days and notice where appropriate. Opt-out requests have their own requirements and must not be delayed by unnecessary identity verification. Honour authorised-agent requests and legally recognised preference signals subject to the applicable rules. Before launch, complete the factual disclosures for the required lookback period: categories collected, sources, purposes, recipient categories, categories sold/shared or disclosed and sensitive information practices. This draft does not assert that Lighthouse meets every applicability threshold or that it has never shared data. Other state regimes can add appeal rights and targeted-advertising or profiling opt-outs. Publish the applicable appeal route and preserve regulator access. Do not claim a single California paragraph satisfies every state.
17. International transfers and local representatives Personal data may be accessible from the countries actually used for hosting, support and approved providers. Publish those arrangements accurately. Where required, use an applicable adequacy decision or valid contractual mechanism, assess the transfer and adopt necessary supplementary measures. A standard service acceptance is not a universal waiver of transfer restrictions. For relevant EU transfers, complete the correct standard contractual clauses and annexes. For UK transfers, use the applicable approved mechanism, such as the UK Addendum or IDTA as appropriate. Provider access from a foreign support location must be considered even if the storage region remains unchanged.
Assess whether an EU/UK representative, DPO or other local appointment is required and publish actual verified contacts before the relevant operation begins. Do not list a fictitious representative or assume an Indian grievance officer fulfils all roles.
18. Canada, Australia, Singapore and UAE preparation A Canadian release requires assessment of federal and applicable provincial privacy law, meaningful consent, accountable transfers and local notice/language requirements. Australian operations require assessment of Privacy Act applicability and exceptions, relevant Australian Privacy Principles and breach-notification duties. Singapore and UAE releases require local review of the applicable privacy regime, responsible contacts, overseas transfers and required notifications; UAE free-zone regimes may differ. These are market-specific activation requirements, not a statement that Lighthouse already operates in all these jurisdictions. Before activation, complete the local notice with actual processing facts, rights channels, contacts and transfer arrangements.
19. Retention, closure and notice changes Retention is determined by the purpose and applicable law, not by a generic desire to keep data forever. Separate transaction records, grievance evidence, security logs, active portfolios, withdrawn permissions and unnecessary marketing data. A legal hold applies only to relevant records and must be reviewed. Account deletion must propagate to necessary processors and derived active records, subject to disclosed lawful exceptions and backup cycles. Retained evidence must not return to advertising or AI training. A materially new use requires updated information and any necessary consent before it begins. Before publishing this policy, replace the provider, contact, region, retention and processing placeholders with verified facts. Legal descriptions cannot substitute for an actual data inventory or functioning rights workflow.
20. Collection context and mandatory information At the point of collection, Lighthouse should identify the relevant purpose and whether a field is necessary for the requested function or optional. Declining an optional field must not prevent an unrelated service. If a required detail is withheld, explain the specific function that cannot be provided rather than claiming that every platform feature requires it. A public professional profile and a private personal account are different records. Public business contact information should be distinguished from private login and security details. A user must not be led to believe that a phone number is private if the actual configuration publishes it.
21. Non-users, referrals and imported portfolios When a professional, employee, client or photographer is named by someone else, Lighthouse must consider the source, necessity, accuracy and applicable notice obligation. The uploader's assurance is relevant but does not excuse ignoring a credible objection from the person concerned.
A referral should contain only information needed for the proposed introduction and supported by an appropriate basis. Lighthouse must not infer that a person referred by an architect has consented to recurring promotional calls, public profile creation or use of their image. Where notice must be provided directly, the process must do so within the applicable legal framework.
22. Purpose changes and compatible use Information collected for an RFQ must not be repurposed into an advertising audience or public project story simply because it is commercially useful. A proposed new purpose requires an assessment of compatibility, applicable legal basis, necessary notice and consent where required. Aggregated operational reporting must not expose identifiable homes, negotiated rates, individual behaviour or another customer's confidential business. If re-identification remains reasonably possible, the data must be handled as personal or confidential information as applicable. Calling a dataset “anonymous” does not make it so.
23. Requests made by representatives A person may use an authorised representative where the applicable law permits. Lighthouse may verify both the requester's identity and the representative's authority proportionately, without requiring access to the person's entire account. Different verification requirements may apply to access, deletion and advertising opt-out requests. Requests should be routed according to Lighthouse's actual role. For customer-controlled enterprise data, Lighthouse will assist the customer and forward the request as appropriate, while independently handling information for which Lighthouse determines the purposes. The individual should receive a clear explanation rather than being referred in a circle between providers.
24. Access, correction and protection of others An access response must be delivered securely and should explain any lawful limitation. It may require redaction of another person's information, protection of legally privileged material or another applicable exception. Those limits must be applied to the relevant material rather than used to refuse the entire request without assessment. Correction should reach relevant active profiles, transaction records where legally correctable, recipient notifications where required and derived records. Where an original invoice or evidentiary record must remain unchanged, a linked correction or restriction may be appropriate. Lighthouse must not silently overwrite legally required historic records.
25. Retention explanations and legal holds The retention explanation should distinguish the active-service period from statutory records, dispute evidence, security logs and backup cycles. A legal hold must identify the relevant matter and categories and be reviewed when the justification changes. It must not authorise unrelated profiling or advertising. When a request cannot be fully completed because particular data must be retained, Lighthouse will explain the categories and basis to the extent lawful. Restricted retention is
different from continuing ordinary use. On expiry of the reason, the normal deletion process must resume.
26. Marketing, service messages and suppression Marketing choices should be available through the disclosed unsubscribe or preference route. A service message must concern a genuine security, account, transaction or legal purpose and must not disguise unrelated advertising as a necessary notice. A minimal suppression record may remain to prevent future marketing after opt-out. That record must not be used to reconstruct a deleted profile or enrich an advertising audience. Partners receiving a withdrawal should apply it to their own relevant communications and comply with their independent duties.
27. Complaints, remedies and material changes A privacy complaint should identify the issue and relevant record where possible; a person need not prove financial loss before Lighthouse considers a valid rights concern. Lighthouse will provide a reasoned outcome and applicable escalation information. Material changes must be communicated in a manner appropriate to their impact. An updated notice must not retrospectively legitimise an unlawful collection or silently authorise a new training purpose. Previous notice and consent versions must remain available internally to assess what applied to earlier processing.
28. App media access, AI sharing and location privacy Use the platform’s appropriate media picker or share sheet with access limited to the files needed for the chosen task. Optional AI processing and optional source connections can be declined while manual use remains available. Before personal data is transferred to an AI provider, disclose the data, recipient and purpose and obtain the required explicit permission. This is separate from permission to publish or train models; revoking device access alone does not erase copies already uploaded. Project location defaults to city-level visibility and the confidential-client setting unless the user expressly selects another authorised disclosure. Remove unnecessary location metadata from delivered files where the pipeline permits, and explain any residual exposure before publication. Users must be able to remove imported material before generation and publication. Originals, derivatives, imported text and AI-job records follow the disclosed retention, deletion and withdrawal process in P04 and I02; abandoned temporary assets must not be kept indefinitely. These draft commitments must be tested before the policy is published.
29. App disclosures and third-party software Privacy notices, store declarations and in-app disclosures must describe the actual released build, including data processed by embedded SDKs and server-side providers. A provider’s involvement does not remove Lighthouse’s responsibility for its own collection and disclosure.
Before unexpected collection or sharing of sensitive data, provide a clear explanation in the relevant app flow and obtain the required affirmative permission. A statement buried in a policy or treating dismissal as consent is insufficient. Required device permissions remain separate from contractual acceptance. Do not sell personal and sensitive app-user data contrary to Google Play policy. A customer-directed enquiry must remain within its disclosed service purpose and must not become an unrelated contact database.
30. Optional access and tracking Declining optional tracking or permissions must not disable unrelated available functionality. Collect only the files or location needed for the requested purpose. Marketing choices must remain distinct from account administration and essential order notices.