Privacy Policy

Effective Date: April 15, 2026 | Last Updated: November 3, 2026

Our Privacy Commitment

Plurilore supports source-grounded study and optional personal reflection. Normal Chat is transient, private notes stay on your device, and answer reports you explicitly submit are stored separately for review. The frontend, backoffice, RAG service, and external providers have different processing and retention responsibilities.

We do not sell your personal data. The web app uses essential authentication/security cookies. Enabled mobile advertising has separate SDK processing and privacy choices, described below. Internal access is role-restricted and legal acceptance is versioned; accepting these documents is not an age check or blanket special-category consent.

Key Points Summary

• Multi-service architecture: The Service consists of a customer-facing frontend, a separate backoffice admin application, and a self-hosted RAG service that mediates AI requests.
• Study and optional reflection: Chat and inline Practice discussion support source-grounded study and possible applications to everyday life, without acting as spiritual or professional authority.
• Notes stay local: Notes created in the Notes feature remain on your device. Mobile Notes use an encrypted, per-account local database; web Notes use local browser storage. They leave the device only when you export or transmit them.
• User-initiated reports: An answer excerpt you choose to report is stored separately for up to 30 days of review access; your question and added details are optional.
• Core AI interactions are ephemeral: Accepted Chat and inline Practice discussion requests are processed at runtime to generate responses, but we do not provide a saved server-side conversation-history feature for those sessions.
• Internal access is role-based and logged: Backoffice access to user data is limited by role and audit logging.
• Processors still matter: Depending on the feature used, we rely on providers for payments, transactional email, hosting, optional OAuth login, mobile build/update and push delivery, privacy-limited crash monitoring, enabled mobile advertising, and AI/model processing.
• Legal acceptance: Protected features require an active record of acceptance of the current Terms and Privacy Policy.

Table of Contents

1. Scope & Service Architecture
2. Information We Collect
3. Legal Bases for Processing
4. How We Use Personal Information
5. AI, RAG, and Model Processing
6. Sensitive Content Boundaries & Legal Acceptance
7. Sharing, Recipients, and Processors
8. Cookies, Telemetry, and Operational Monitoring
9. Data Retention and Deletion
10. Security and Internal Access Controls
11. International Data Transfers
12. Your Rights and Product Controls
13. Regional Privacy Disclosures
14. General Audience and Younger Users
15. Changes to this Policy
16. Contact Information

1. Scope & Service Architecture

1.1 Covered Services

This Privacy Policy applies to personal information processed in connection with Plurilore, including:

• the customer-facing web application at plurilore.com and the Plurilore iOS and Android applications,
• authenticated chat, Practice, notes, pricing, and account areas,
• our backoffice/admin environment used for support, moderation, analytics, and operational review,
• our self-hosted retrieval-augmented generation service and related AI-processing infrastructure,
• our blog and wiki content systems,
• transactional emails and support communications.

1.2 Data Controller

The data controller is ONE CREATOR SRL (Romania), trading as Plurilore.

1.3 Service Architecture Overview

Our current product architecture is composed of the following operational layers:

This architecture is important because not every product feature shares the same storage model. In particular, notes and Practice reflections remain local-only, while consent records, subscriptions, Practice activity records, and certain operational logs are server-side.

1.4 Third-Party Services

Some parts of the Service depend on external providers or infrastructure partners. Their involvement is described in Sections 7 and 11. Where a third party acts under its own privacy policy or terms, those documents also apply to your use of that specific service.

2. Information We Collect

2.1 Information You Provide Directly

2.2 Information Collected Automatically

2.3 Information from Third Parties

2.4 Information Stored Locally on Your Device

Certain Practice and notes functionality is intentionally local-only.

Local notes and Practice reflections are not part of our normal server-side account export, server-side deletion workflow, or US transfer map unless you separately send them to us or another server-side feature.

What Practice does record on our servers. So that your record of practice survives losing a device, we store structured metadata about your activity — which passage you sat with, on which day, in which tradition; explicit committed-reading progress; which concepts in the Atlas your practice has touched; the numeric commitments of your Rule of Life; the marks you have earned; and which of the practices you have used and what you have met in them. We do not store what you wrote in a private reflection or the name or intention you gave your Rule. A private reflection is never added to Chat context automatically. If you use the Practice Garden, we also store your selected garden, appearance preferences, an optional bird nickname (up to 40 characters), and the public passages, earned milestones, or connections you explicitly choose as keepsakes. These preferences and keepsake references are included in your account export and deleted with your account; garden artwork is bundled with the app and does not send your activity to an image-generation service.

2.5 Internal Access and Audit Records

When authorized staff or contractors use the backoffice to investigate an account, respond to a support issue, or review a moderation/security incident, we may create audit records that show:

• who accessed a record,
• what action was performed,
• when it occurred,
• the IP address and user agent associated with the action,
• the entity reviewed or changed.

3. Legal Bases for Processing

If you are in the EEA, UK, or Switzerland, we rely on the following legal bases depending on the purpose of processing:

Reading a religious text, selecting a tradition, asking an academic question, or choosing to reflect does not by itself establish your religious affiliation. We do not use those actions to build a religious-belief profile. A prompt or report can nevertheless disclose religious beliefs, health information, or other special-category personal data, directly or through its context. Where Article 9 GDPR applies, an applicable Article 9 condition is required in addition to an Article 6 legal basis. Contract performance, legitimate interests, ephemeral processing, and accepting these legal documents do not by themselves provide that condition.

There is no blanket religious-data consent gate for entering the Hub. We minimize collection, discourage unnecessary sensitive disclosures, and must restrict, redact, or otherwise lawfully handle affected processing where an appropriate condition cannot be established. A specific consent mechanism may be needed for a distinct activity; it must be explained separately rather than inferred from Terms acceptance. Advertising consent is separate and controls advertising only.

4. How We Use Personal Information

We use personal information to:

• create and manage your account,
• authenticate you and enforce verified-email requirements where applicable,
• provide chat, Practice, pricing, and account functionality,
• calculate message allowances, one-time credits, and plan entitlements,
• process accepted Chat and inline Practice discussion requests transiently to generate responses,
• send password reset, verification, billing, and service emails,
• protect the service against fraud, abuse, excessive automation, and security incidents,
• investigate complaints, moderation issues, and account misuse,
• comply with tax, accounting, legal, and regulatory obligations,
• improve product reliability, understand operational failures, and maintain platform health,
• support customer service, audits, and incident response.

We do not sell your personal information. Enabled mobile advertising is described below; Chat content, selected traditions, private notes, and Practice reflections are not supplied as advertising-targeting signals.

5. AI, RAG, and Model Processing

5.1 How the AI Flow Works

When you submit an accepted Chat or inline Practice discussion request, the flow typically works like this:

1. the frontend validates your session, verified-email status where relevant, legal acceptance state, and quota/rate-limit posture,
2. the request is sent to our self-hosted RAG service,
3. the RAG service orchestrates retrieval and provider routing for the request,
4. accepted requests may retrieve supporting source context,
5. the RAG service calls one or more configured AI/model providers,
6. the response is returned to the frontend and shown in the current session without creating a saved server-side conversation history for normal chat use,
7. limited technical, security, or abuse-investigation records may still be created under our standard logging and incident-handling practices.

5.2 What May Be Sent to the RAG Layer and Upstream Model Providers

Depending on the feature and current provider configuration, the following data may be processed through the RAG and model path:

• accepted prompt text,
• public Practice passage, reference, framing, reflection prompt, and the discussion question you explicitly submit,
• retrieved textual context,
• system instructions and workflow prompts,
• pseudonymized user and session identifiers,
• limited routing metadata needed to produce the response.

5.3 What We Do Not Routinely Send Upstream for AI Inference

We do not routinely send the following to model providers for normal chat inference:

• your payment card data,
• your full billing record,
• your notes stored only in local browser storage,
• your password,
• unnecessary direct contact data where pseudonymized identifiers are sufficient.

5.4 No Persistent Agent Memory

The current Chat and inline Practice discussion architecture does not maintain a separate per-user server-side agent-memory profile for future continuity. In practice:

• accepted requests are handled for the current response only,
• leaving the page does not preserve a saved server-side conversation thread,
• information you want to retain should be kept in local notes or other account features that are expressly stored server-side,
• limited technical, security, and abuse-investigation records may still exist under our normal operational controls.

5.5 Inline Practice Discussion and Cross-Reference Mode

Inline Practice discussion is an ephemeral Chat surface. Single-tradition follow-ups use recent context within the current disclosure session; cross-reference turns remain stateless. Standard agents cost 1 credit per selected tradition and Pro agents cost 3 credits per selected tradition. Private reflection text is excluded unless you deliberately copy it into the question yourself.

5.6 User-Initiated Answer Reports

The Report action on Chat and inline Practice answers lets you review and edit an answer excerpt before sending it. Your question excerpt and extra details are optional. We store the submitted reason, excerpt, any optional text you include, source references, generation context (such as selected traditions, mode and model tier), platform, account link, and timestamps. We do not automatically attach a complete conversation or private reflections. Share only what is needed to explain the issue and avoid sensitive information about other people.

Reports are separate from ordinary ephemeral chat. Authorized moderators and administrators can review them and update their status. Audit records identify the reviewer, action, report, and time without copying excerpts. Reports are not automatically sent back to an AI provider for review or used to train a model. The review-access period is 30 days after submission; access stops at expiry and expired rows are physically purged by the daily 02:00 UTC cleanup. Deleting an account through the app also deletes its submitted reports. Your account export includes your own unexpired submitted-report fields, not internal reviewer audit history.

5.7 AI Model Providers

The architecture supports model-provider substitution at the RAG layer. Our current production-facing legal baseline assumes OpenAI-connected flows for accepted study and reflection requests, but the RAG service is architected to support other providers if enabled. If we materially change the active processor list or transfer posture, we will update this Policy and, where legally required, request renewed acceptance. Generation and search-translation requests explicitly set store=False. This disables API application-state storage, but it is not Zero Data Retention: provider abuse-monitoring, prompt-cache retention, legal exceptions, and account-specific arrangements may still apply. We do not claim that an unverified provider account has zero retention or special approval for processing children’s data.

6. Sensitive Content Boundaries & Legal Acceptance

6.1 Study and Reflection

The Service supports passage analysis, historical and literary explanation, comparison, structured reading, and optional reflection on how teachings relate to everyday life. Personal context is not automatically prohibited and is not treated as proof of religious identity. Responses should distinguish evidence from interpretation, acknowledge supported differences, and preserve the reader's autonomy.

The AI is not a spiritual authority or professional adviser. It should not claim to determine divine wishes, salvation, diagnosis, treatment, or necessary life decisions. Basic supportive safety responses may be appropriate when someone expresses distress; the Service is not an emergency or crisis-monitoring service.

6.2 Safety and Data Minimization

Harmful operational requests may be refused or limited. Sensitive historical topics and ordinary personal reflection are not refused merely for being sensitive. Providers may also apply moderation. A refusal does not guarantee that no runtime or provider processing has already occurred. Avoid sharing unnecessary personal or third-party sensitive information. General-audience access and removing a blanket consent checkbox do not remove applicable safeguards.

6.3 Legal Acceptance

Access to protected features depends on an active record of acceptance of the current Terms and Privacy Policy. If those document versions change, we may require renewed acceptance before those features continue.

7. Sharing, Recipients, and Processors

7.1 We Share Data Only Where Needed to Run the Service

We may share personal information with the following categories of recipients:

• hosting and infrastructure partners,
• payment processors,
• transactional email providers,
• optional identity providers,
• configured AI/model providers used through our RAG service,
• professional advisers, auditors, and authorities where legally required.

7.2 Typical Processor Map

7.3 Internal Recipients

Authorized personnel may access relevant data where necessary for:

• support,
• moderation,
• fraud or abuse investigation,
• billing operations,
• infrastructure/security response,
• legal compliance.

Backoffice access is role-based and auditable. Not every internal role can see the same data.

7.4 We Do Not Share Local Notes as Part of Normal Server Processing

Because notes are stored locally in your browser or encrypted mobile database, they are outside normal server-side sharing and processor flows unless you separately export or transmit them.

8. Cookies, Telemetry, and Operational Monitoring

8.1 Essential Cookies Only

We use essential first-party cookies and comparable session/security mechanisms required for:

• authentication,
• account security,
• session continuity,
• core navigation,
• limited informational UI state such as dismissal of banners.

The web app uses essential cookies rather than third-party advertising cookies. In mobile builds with AdMob enabled, the advertising SDK may process device or installation identifiers, network metadata, consent signals, and ad interactions. Advertising privacy controls are separate from access to Chat, Library, Practice, account, and purchases. Google UMP concerns advertising; refusing advertising consent does not disable those core features. Ad requests use non-personalized/restricted treatment and a G maximum ad-content rating. These controls do not mean that the SDK receives no data or that all local children’s-privacy requirements have been verified.

8.2 Internal Telemetry and Monitoring

To keep the Service reliable and secure, we collect internal operational telemetry such as:

• request and error events,
• rate-limit/security events,
• reliability traces,
• infrastructure and application logs.

Web and mobile error monitoring uses GlitchTip, which receives events through open-source Sentry-compatible client SDKs, alongside OpenTelemetry-based tracing where configured. We do not use the sentry.io monitoring service. This data is used for reliability, debugging, fraud/security detection, and incident response.

The mobile app sends GlitchTip only anonymous crash/error classes, release/build/platform information, and a small allowlist of coarse performance transactions. The mobile integration deliberately drops or strips prompts, responses, notes, passage contents, selected traditions, spiritual-interest data, user identity, error messages, stack traces, request URLs, arbitrary routes, breadcrumbs, screenshots, view hierarchy, session replay, and failed-request capture. We do not attach those categories to the monitoring SDK scope.

Practice notifications use generic copy. Notification payloads do not include a tradition, passage, note, chat content, or other spiritual-interest information. Expo push tokens and delivery receipts are used only to deliver and maintain reminders that the user has enabled.

8.3 Managing Cookies

You can block or delete cookies through your browser settings, but doing so may prevent authentication and other core features from functioning properly.

8.4 Do Not Track

Some browsers offer a "Do Not Track" setting. We do not guarantee a separate response to every DNT signal, but we continue to honor the privacy controls and rights described in this Policy.

9. Data Retention and Deletion

9.1 Retention Schedule

9.2 Deletion and Recovery Windows

When you delete content or request account deletion:

• some records may be soft-deleted before final purge,
• backups may retain data for a limited restoration period,
• some legal/accounting records may be retained where required,
• anonymized or aggregated information may persist after deletion if it no longer identifies you.

9.3 Notes Retention Is Different

Local notes are controlled primarily by your device. If you clear browser data, delete the mobile app database or key, lose the device, or remove local storage without exporting, those notes may be lost. The app offers an export before account deletion.

Deleting your Plurilore account does not itself cancel a subscription managed by Apple or Google. Cancel the store subscription first through the applicable store settings to prevent renewal. Store transaction records remain subject to the store's own retention requirements.

10. Security and Internal Access Controls

We use technical and organizational measures appropriate to the nature of the data we process, including:

• TLS encryption in transit,
• hashed passwords,
• role-based access control,
• audit logs for sensitive internal actions,
• rate limiting and abuse controls,
• environment-based secret management,
• routine operational monitoring,
• separation between customer-facing and backoffice/admin interfaces.

No system can guarantee absolute security. If a security incident affects your personal information and law requires notice, we will notify regulators and affected users as required.

11. International Data Transfers

11.1 Default Hosting Posture

Our default hosting posture is EU-centric for core application and database infrastructure. However, some processors or configured model providers may operate outside the EU/EEA.

11.2 Transfers That May Occur

Depending on the active feature and processor configuration, data may be transferred outside your jurisdiction in connection with:

• payments and billing,
• transactional email delivery,
• optional OAuth sign-in,
• mobile build and update delivery,
• Practice push routing and delivery receipts,
• privacy-limited mobile crash and performance monitoring,
• AI inference or embeddings for study and reflection requests.

11.3 Transfer Safeguards

Where required by law, we rely on appropriate transfer safeguards such as:

• Standard Contractual Clauses,
• Data Privacy Framework participation where applicable,
• data-processing agreements,
• contractual and organizational restrictions on onward transfer and retention,
• periodic transfer-impact review.

We maintain a separate Transfer Impact Assessment for the current architecture and review the processor/transfer posture when the architecture changes materially.

12. Your Rights and Product Controls

Depending on your jurisdiction, you may have rights to:

• access your personal information,
• request correction of inaccurate data,
• request deletion,
• request portability,
• object to certain processing,
• request restriction,
• withdraw consent where consent is the legal basis,
• complain to a supervisory authority.

12.1 Product Controls Available Today

Current product controls may include:

• account-data export for server-side data, including your own unexpired submitted reports and excluding internal reviewer audit records,
• account deletion,
• unsubscribe controls for marketing communications,
• local note export/import outside the normal server-side export flow.

To exercise your rights, contact [email protected]. We may need to verify your identity before completing a request.

13. Regional Privacy Disclosures

13.1 EU / EEA / UK / Switzerland

If you are in the EU, EEA, UK, or Switzerland, the GDPR or analogous local law may give you the rights described above. As a Romanian controller, we are also subject to Romanian data-protection oversight.

13.2 California

If you are a California resident, you may have rights under the CCPA/CPRA, including rights to know, delete, and correct personal information, and to request information about the categories of data we collect and disclose. We do not sell personal information and do not knowingly share personal information for cross-context behavioral advertising.

14. General Audience and Younger Users

Plurilore has no blanket 18+ rule or date-of-birth access gate. General-audience positioning does not establish that every feature is suitable or legally available for every age and jurisdiction. Local contract-capacity, parental-authorization, privacy, and platform requirements still apply. There is no verified parental-authorization workflow today; affected processing must be limited where a required authorization or other lawful condition cannot be established.

If you are a parent, guardian, or user with a concern about personal-data processing, contact [email protected]. We may investigate, remove affected data, restrict specific processing, or close an account as appropriate. We do not infer religious affiliation from an educational question, and we do not claim that a legal-acceptance record verifies age.

15. Changes to this Policy

We may update this Privacy Policy when the product architecture, processor map, legal basis, or data practices change. If a change is material, we may provide notice through the website, the product UI, email, or a re-consent flow. Continued use after a non-material update may constitute acceptance where permitted by law.

16. Contact Information

If you have questions, requests, or complaints regarding this Policy or your personal information, contact:

ONE CREATOR SRL
Email: [email protected]<br> Address: Romania, Jud. Dolj, Municipiul Craiova, Strada Traian Demetrescu, Nr.23, MANSARDA