DRAFT FOR REVIEW
Privacy
What Navelyra holds, why it holds it, who else sees it, how it is protected, and what you can do about it.
This is a draft for review, not an approved policy. It has no effective date and it is not legal advice.
It is written from what the product actually does, and the sections below name where each statement can be checked. 11 points in it are decisions the owner has not made yet, and each one is marked where it belongs rather than filled in with a plausible guess.
Questions about it, or about the beta, go to support@navelyra.com — see Contact.
1. Who is responsible for your data
Navelyra is operated by OcularIT Solutions, Inc., a Virginia corporation. That company is the controller of practitioner account data — your name, your email address, your practice details and your billing relationship.
The client records you enter are different. You decide what to collect and why; Navelyra stores and processes those records to produce the summaries you approve. The draft position below is that a practice is the controller of its clients’ data and Navelyra is its processor, which is what the product’s design assumes.
Awaiting the owner’s approval — this section cannot be published until these are decided:
- Whether the controller/processor position in the second paragraph is the one the owner wishes to publish, or whether a data processing agreement must be offered with it
- The registered address and company number of OcularIT Solutions, Inc.
Where this section comes from
apps/web/components/site-footer.tsx renders the disclaimer this section expands onpackages/db/src/practices.ts scopes every client record to a practice
2. What Navelyra holds
Practitioner account data: your name, email address and the sign-in identity your authentication provider issues, plus the practices you belong to and your role in each.
Practice configuration: practice name, slug, default time zone, the services you offer, your chart settings and your recorded methodology decisions.
Client records: the client’s name and contact details, the birth data you record for them, and the consent you record for an intake.
Work product: calculation runs and the evidence facts they produce, generated drafts, the exact version you approve, delivery records, and the reflections a client chooses to send back. Your private notes are stored separately and are never included in anything a client can reach.
Operational records: security audit rows that record counts and events rather than content, and job records that say what ran and whether it succeeded.
Where this section comes from
packages/db/src/privacy.ts lists every relation carrying a practice identifier, discovered from the schema rather than written downpackages/db/src/privacy.ts declares the columns encrypted at rest: birth profiles, client intakes, client reflections, practitioner notes and numerology name recordsdocs/08-trust-safety-and-privacy.md describes the audit posture
3. How it is protected
Each practice’s rows are separated at the database level by row-level security, which is forced and scoped by the practice identifier of the request. The application connects as a restricted runtime role that cannot bypass it, so a query that forgets the practice scope returns nothing rather than another practice’s rows.
Birth profiles, intake responses, reflections, private notes and numerology name records are encrypted before they are stored, under a key this application holds and the database does not.
The product does not log payload contents. Access to a client’s portal is a signed link or a revocable session, and revoking access marks both the grant and its sessions so that the record of who could see what survives the revocation.
Where this section comes from
packages/db/src/runtime-role.ts provisions the restricted role and revokes the deliberate exceptionsdocs/database-schema.sql carries the forced row-level security policiespackages/db/src/access.ts revokes a grant and its portal sessions together
4. Who else processes it
Navelyra uses a small number of providers to run the service. Each one is listed here with what it does.
Navelyra does not sell personal data, and the product contains no advertising or third-party analytics tracker: no analytics script is loaded by any page.
Awaiting the owner’s approval — this section cannot be published until these are decided:
- Confirmation that this list is complete for the hosted beta, and the region each provider stores data in
- Whether the AI writing provider’s terms permit it to train on submitted content, and how that is to be stated here
Where this section comes from
apps/web/lib/site.ts names the providers from the code and the owner’s decisionpackages/payments/src/index.ts contains the Stripe adapterapps/web/lib/legal.test.ts fails if a sub-processor is named without a stated purpose
5. How long it is kept
The product deletes rather than hides. Asking for a deletion empties every relation that belongs to the practice, in an order the foreign keys accept, and revokes its portal sessions. Asking for an export produces a copy of the practice’s data, decrypted, which expires and is then removed.
The durations below are not yet decided, so this draft states the categories and refuses to state a period for any of them.
Awaiting the owner’s approval — this section cannot be published until these are decided:
- Account and practice data after a practice is cancelled
- Client intake and birth data
- Generated and delivered summaries
- Operational logs and security audit records
- Database backups
Where this section comes from
packages/db/src/deletion.ts plans and executes the deletionpackages/db/src/privacy.ts builds the export and records its expirypackages/db/migrations/0027_revoke_portal_sessions_on_practice_deletion.sql
6. What you can do about it
Your data screen exports everything your practice holds and asks for its deletion. Both are real operations against the database, not requests queued for a human.
A client can be given access to a specific delivered summary, and that access can be revoked. A client’s reflection is only ever read by the practice the client chose to send it to.
Awaiting the owner’s approval — this section cannot be published until these are decided:
- The address a data-protection request should be sent to, if one is appointed
Where this section comes from
apps/web/app/(practitioner)/app/privacy/page.tsx is the screenpackages/db/src/access.ts enforces a reflection’s audience against the practitioner who delivered it
7. Cookies
A session cookie is set by the sign-in provider so that you can stay signed in. The practice you are working in is remembered in one additional cookie. That cookie holds a practice identifier and nothing else: no client name, no birth data and no note text is ever placed in a cookie or a URL.
Where this section comes from
apps/web/lib/context.ts records the tenant-only cookie ruleapps/web/components/auth-controls.tsx is the only sign-in surface
8. Automated decisions
The dashboard ranks one next action from the stored state of your practice, using a published ranking version. It does not derive urgency from astrological content, from your private notes or from a composite score, and it is not an automated decision that produces legal effects about a person.
The reading a draft expresses is written by a language model from the evidence facts the calculation engine produced. The model does not calculate a chart, and no summary reaches a client without a practitioner approving the exact version that is sent.
Where this section comes from
apps/web/app/(practitioner)/app/page.tsx discloses the ranking version and what is not usedpackages/db/src/portal.ts serves only an approved version
9. Changes and contact
This draft will be published with an effective date once it is approved. Until then, the version you are reading is a draft for review and the sections marked above are open questions, not decisions.
Questions about this policy can be sent to the contact address published on the contact page.
Awaiting the owner’s approval — this section cannot be published until these are decided:
- The effective date of the published policy
Where this section comes from
apps/web/lib/site.ts holds the single confirmed contact address
No effective date is stated, because there is not one yet. This page will carry a date on the day an approved version replaces it.