Havara Privacy Policy

Effective July 14, 2026

1. At a glance

• We collect what you give us: your account details, the content you post, and the records your board enters (memberships, dues standing, violation cases).
• Your content is visible to the audience you post it to: a channel, a group, a direct message, or the board. Database-level security enforces this, not app-level promises.
• Your board sees more than other members do: violation cases, all units' dues standing, join requests, and moderation reports. Section 5 lists exactly what.
• Poll votes are stored linked to your account even on "anonymous" polls, but the app only ever shows counts, to everyone, including the board.
• AI "Ask" answers come from two vendors: OpenAI searches your community's documents; Anthropic writes the cited answer. Neither is told who asked, and neither trains on your data by default.
• Push notifications show message previews by default. You can turn previews off in one toggle.
• We don't sell data, run ads, track your location, or read your contacts. Section 9 is the full list of things we don't do, verified against our code.
• Deleting your account deletes your personal records but anonymizes content you authored: your messages stay in the thread, attributed to an anonymous "Member."
• You can download all your data yourself, in the app, any time.
• Analytics and crash reporting are switched off in the shipping app; if we ever enable them, analytics stays opt-in per person.

2. Who we are and what this covers

Havara LLC runs the app; your HOA board runs your community. This policy covers the mobile app, the web console, and the havara.app marketing site.

Havara is a private, invitation-only community platform for homeowner associations (HOAs) and residents' communities. It provides community and group chat, direct messages, board announcements, a document library with an AI "Ask" feature, events with RSVPs, bookable amenities, polls, meetings and governance records, violation (rule-enforcement) case management, architectural-review requests, resident requests, budget and dues transparency, a vendor directory, a member directory, and emergency alerts.

This policy covers three surfaces:

Provider. Havara is provided by Havara LLC, a limited liability company organized under the laws of a U.S. state ("Havara," "we," "us"). You can reach us at [email protected] (Section 18).

Who is responsible for what (controller vs. processor). Your community, typically its HOA board, decides who may join, what is posted in its official spaces, and what records (violation cases, dues standing, units) it keeps about residents. For that community-controlled content, the community acts as the data controller and Havara acts as its processor/service provider. Havara is the controller for account-level data (your profile, credentials, device tokens) and for the marketing-site waitlist. Practical rule: for a request about a specific community's records (for example, a violation case your board opened), start with your board. For everything else, or if your board doesn't resolve it, contact us (Section 18) and we will help.

Invitation-only. Anyone can create an account, but joining a community requires a board-issued invite code or an approved join request. The invite gates community access, not account creation.

3. What we collect

Almost everything we hold is either something you typed or something your board entered. The table below is built from our actual database schema, not from a template.

We collect limited technical information automatically (device push token, session tokens). We do not collect precise location, contacts, biometrics, or financial-account numbers (see Section 9).

4. How we use your information

We use your information to run the app and keep communities safe, and for nothing else.

We use the information above to:

• create, authenticate, and secure your account;
• operate the community features listed in Section 2, scoped per community and per role;
• answer your "Ask" questions from your community's own documents (Section 6);
• send the push notifications you have enabled, honoring your mute, quiet-hours, and preview settings (emergency alerts override mutes and quiet hours by design; they are sent at critical priority);
• support board tooling: member management, moderation, governance records, and the audit log;
• if ever enabled, understand feature usage (analytics, which is opt-in) and diagnose crashes;
• comply with law and enforce our Terms of Service.

Legal bases for users in the EEA/UK (readiness statement). Havara operates in the United States today. If and when we serve users in the EEA or UK, we will rely on: performance of our contract with you (operating the app); your consent (device permissions, notifications, optional telemetry, withdrawable at any time); and our legitimate interests in running, securing, and improving the service. This paragraph is forward-compatible language, not a representation that we currently maintain EU/UK operations.

We do not sell your personal information and do not "share" it for cross-context behavioral advertising, as those terms are defined under California law.

5. Who can see what

Your community sees what you post; your board sees the records it keeps; and we tell you plainly where the board's view ends. This is enforced in the database, not just the interface.

Access is enforced server-side by row-level security (RLS) keyed to your membership and role. The rules below are database rules, not UI conventions.

Content you post. Visible to the audience you choose: a community channel (all approved members), a sub-group (its members), a direct message (its participants), or a board-facing form (the board).

Direct messages. Readable only by the participants of the conversation. Board members and community admins have no DM-reading surface in the app. If you report a message from a DM, the report you file (reason and any detail you add) becomes visible to your community's moderators.

Violation cases. A case your board opens against you (the rule cited, summary, optional location note, photos, and its append-only event timeline) is visible only to you (the cited resident) and to board members holding the compliance capability. Other residents cannot see your case. The timeline is append-only: events (notice sent, cured, appealed, closed, reopened) are never silently rewritten, and you can file (and withdraw) an appeal on your own case.

Dues standing. You can read only your own unit's dues row (status, balance, last recorded payment as entered by the board). The board/treasurer reads and edits all units. Published budgets and reserve snapshots are visible to all members.

Poll votes: read this one carefully. Your vote is stored linked to your account, even when a poll is marked "anonymous." That is how the system prevents double voting and lets you change or withdraw your vote while a poll is open. What the anonymity flag (and, in fact, the database rules for every poll) guarantee is about display: your individual vote row is readable only by you; everyone else, including the board, sees only per-option counts produced by a counting function that never returns voter identities. Havara personnel with production database access could technically read vote rows; that access is restricted to service operations (Section 12).

Member directory. Shows your name, avatar, role, and the profile fields you fill in, to members of your communities. Directory reads go through controlled server-side functions so sensitive columns (like your push token) are never exposed.

Join requests and invitations. Visible to you and to the board that processes them.

Moderation. Reports you file are visible to you (status only) and to your community's moderators. Reports are not anonymous to moderators: they see who filed the report, when, and why, and reports survive deletion of the reported message or account. Board hide-actions and moderation case notes are visible to capability-holding moderators. Your block list is visible only to you.

Audit log. Governance actions (invite redemptions, role and membership changes) are recorded in a board-visible audit log for accountability.

Builder/developer (declarant) communities. Some communities are set up by their builder or developer before residents move in. A declarant membership carries board-equivalent access during that buildout: the declarant can see and do what a board member can in that community (including the board-visible records above), enforced by the same database rules. If your community was provisioned by a declarant, that builder/developer seat has board-level visibility until the community's roles change hands to resident governance; role changes are recorded in the audit log.

Havara personnel. Our operators can access production data only through service-role credentials, for operating, securing, and supporting the service. We do not browse community content for any other purpose.

6. The AI "Ask" feature

Ask answers questions from your community's governing documents only. OpenAI finds the relevant passages; Anthropic writes the cited answer; neither is told who asked; neither trains on your data by default.

The "Ask" tab is a permission-filtered retrieval assistant over a single community's governing documents. It does not browse the web and does not answer from general knowledge.

What happens when you ask a question:

1. Your question text is embedded by OpenAI (model text-embedding-3-small) so the system can search your community's document index.
2. A permission-filtered search retrieves up to six relevant excerpts, only from documents your membership allows you to see.
3. Your question, the prior turns of that conversation thread, and the retrieved excerpts are sent to Anthropic, whose model (claude-haiku-4-5) composes a concise answer that cites every factual claim to a numbered excerpt and is instructed never to give legal advice.
4. If nothing relevant is found, Ask says it does not see the answer in the documents and points you to your board.

Separately, at document-upload time: if a board uploads a scanned or image-only PDF (no text layer), the file is sent to OpenAI (model gpt-4o, up to 20 MB per file) for optical character recognition. If OCR fails or is refused, the document is simply excluded from Ask.

What the AI vendors receive, and what they don't:

• OpenAI receives document text (during indexing/OCR) and your question text. Anthropic receives your question, the thread's prior turns, and the retrieved excerpts.
• No account identifiers (name, email, user ID) are included in the request body sent to either vendor.
• Per OpenAI's published API data policy (verified 2026-07-12), API data is not used to train OpenAI models unless the customer opts in (we have not), and abuse-monitoring logs are retained up to 30 days.
• Anthropic's commercial terms prohibit training models on customer content (verified 2026-07-15).

What Ask never does:

• It never answers from documents you can't see. Your document permissions are re-applied at retrieval time.
• It never gives legal advice; every answer carries citations you can check.
• No AI generates conversation titles. Thread titles are derived on your device from your first question, and no model call is made for them.
• Your questions and answers are stored for your history only and are rate-limited (6 asks per minute).

Board control. Boards can toggle any document out of Ask, which deletes its text chunks and embeddings from retrieval. Your control: Ask runs only when you ask a question. Nothing is sent to any AI vendor unless you use the feature.

7. Who we share data with

A small set of infrastructure vendors under contract, each receiving only what its job needs, plus three integrations that are wired but switched off, which we disclose anyway.

The authoritative, versioned list is our Subprocessor documentation, available on request via [email protected]. Summary:

"Conditional" means the integration is built and enabling it requires only a configuration key, not a code change. If we enable one, we will update our subprocessor list first and, where the change is material, notify you per Section 17.

Web surfaces only: Google Fonts. The web console and the havara.app marketing site (including the published /privacy and /terms pages) load fonts from Google's servers. Per Google's published Fonts privacy FAQ (verified 2026-07-12), each font request transmits your IP address, the requested URL, and HTTP headers (browser/OS, referring page); Google states the Fonts API sets no cookies and that font-request data is not used for profiling or targeted advertising. The mobile app does not fetch fonts remotely; its fonts are bundled.

Legal and safety. We may disclose information where required by law, or to protect the rights, safety, or integrity of the service, our users, or the public.

Business transfers. If we are involved in a merger, acquisition, or asset sale, your information may be transferred as part of that transaction; we will continue to protect it under this policy or notify you of any material change.

We never share your data with data brokers, ad networks, or "marketing partners."

8. Cookies and tracking

The havara.app site sets no cookies at all, so there is no cookie banner to click. The app and the web console keep you signed in with a token stored on your own device, not with a tracking cookie.

The marketing site (havara.app) sets no cookies. Not for advertising, not for analytics, not for "essential" purposes. It uses no browser storage either: it puts nothing on your device and reads nothing back. There is no cookie banner because there is nothing to consent to. That covers the published /privacy and /terms pages you may be reading right now.

Staying signed in. The mobile app and the web console each store one thing to keep you logged in: the session token issued when you sign in. The mobile app holds it in the app's own on-device storage. The web console holds it in your browser's local storage for app.havara.app, along with a note of which of your communities you last had open. Neither is a cookie. Neither is attached to requests to other websites, and neither can be read by any other site. Signing out clears the session token, and clearing site data for app.havara.app in your browser clears the rest.

No advertising, no cross-site tracking, no third-party analytics today. We use no pixels, beacons, device fingerprinting, or advertising identifiers, and we do not follow you across other websites. There are no ad SDKs and no tracking domains in the app or on the site. Our analytics and crash-reporting integrations ship switched off (Section 7 lists them and their status); if we ever enable analytics, it stays opt-in per person. Section 9 is the full list of things we don't do.

Google Fonts. The web console and the marketing site load fonts from Google's servers, which transmits your IP address and browser headers to Google with each font request. Google states the Fonts API sets no cookies. Section 7 has the detail and Google's own published commitment. The mobile app bundles its fonts and makes no such request.

9. What we DON'T do

Each absence claim below was verified against our codebase, not just asserted: the cookie claim on 2026-07-15, the rest on 2026-07-12.

• We don't sell your personal information, to anyone, ever.
• We don't use cookies to track you. The havara.app site sets no cookies at all, and the app and web console keep you signed in with a token stored on your device rather than a tracking cookie. Section 8 has the per-surface detail.
• We don't run ads and don't share data for advertising. There are no ad SDKs and no tracking domains in the app, and our Apple privacy manifest declares tracking = false.
• We don't track your location. The app contains no GPS/location code and requests no location permission. The only "location" data we hold is text someone typed (an event's venue, an optional note on an alert or violation case).
• We don't read your contacts, your calendar, or your photo library. Contacts are never accessed; the calendar permission is used only to write an event when you tap "Add to calendar"; photos are accessed only when you actively pick or capture one for chat. Camera captures for chat are not saved to your camera roll.
• We don't process payments. Dues standing is a read-only record your board types in. There is no card, bank, ACH, or payment SDK anywhere in the product, and we will never ask for payment details in chat or email.
• We don't train AI models on your data, and our AI vendors don't either by default. OpenAI's API terms exclude training on API data (verified 2026-07-12), and Anthropic's commercial terms prohibit training on customer content (verified 2026-07-15).
• We don't send third-party analytics or crash telemetry today. Both integrations ship disabled; analytics additionally requires your individual opt-in even if enabled.
• We don't compile data about you from public records or other outside sources. Everything we hold came from you, your board, or your device.
• We don't show board members your DMs or your individual poll votes. See Section 5.
• We don't use dark patterns on deletion. Account deletion is in the app, self-serve, and immediate.

10. How long we keep data

Most data lives until you delete your account; content you authored is then anonymized rather than erased; a few operational logs are kept longer, and we say which.

Where a row above says a window "is not yet defined," that is the honest current state: the data is kept indefinitely by default, and we are tracking the definition of concrete windows as an open item rather than inventing numbers here.

11. Your rights and controls

Export, deletion, correction, notification control, and blocking are all built into the app today. Here is the exact path for each.

Not in the export yet: the content reports you filed and your block list are not included in the JSON export (you can view your block list in the app). We track this as an open item.

For anything else, or to exercise a right without app access, email [email protected]. We may verify your identity before acting, you may use an authorized agent where law permits, and for community-controlled records we may route the request to your board (Section 2).

12. Security

Security here is structural: database row-level security on every table, server-side secrets, private storage with signed URLs. We don't claim certifications we don't have.

• Row-level security on every database table. Access is enforced in the database based on your membership and role. The API key shipped in the app is a public key by design; RLS is what protects the data.
• Authentication is email + password (with email magic-link as a secondary option), with password reset over a PKCE deep-link flow; sessions are stored on your device and refreshed automatically.
• All storage buckets are private; files (documents, attachments, avatars, photos) are served through expiring signed URLs, not public links.
• Secrets stay server-side. AI-vendor keys (OpenAI, Anthropic), email keys, and the push secret exist only in server-side functions, never in the app bundle.
• Encryption in transit and at rest. All backend and vendor calls use TLS/HTTPS; data at rest is encrypted by our hosting platform.
• Permission-filtered AI (Section 6) re-applies your document permissions at retrieval time.
• Rate limiting on abuse-prone paths: Ask queries, invite-code redemption, chat message posting.
• Push privacy: preview toggle, per-category mutes, and quiet hours are honored server-side during notification fan-out (emergency alerts excepted, by design).
• Protected directory reads via controlled server functions, so sensitive profile columns (push tokens) are never exposed.
• Server-side guards prevent removing a community's last administrator and pin every privileged write to the calling user's own identity.
• Moderation and audit: content reports, board moderation with an immutable audit trail, user blocking.

No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security. We do not currently hold any third-party security certification or audit (no SOC 2, ISO 27001, PCI DSS, or HIPAA). We would rather tell you that than imply otherwise.

13. Where your data lives, and international transfers

All app data is stored in a single Supabase project hosted in AWS region us-east-2 (US East, Ohio, United States). Our AI, push, and email vendors are US-based services (Section 7).

Readiness statement for EEA/UK users: Havara serves US communities today. If you use Havara from the EEA, UK, or another region with data-transfer rules, your information will be transferred to and processed in the United States. If and when we establish EEA/UK operations or actively serve those markets, we will put appropriate transfer safeguards in place (such as the European Commission's Standard Contractual Clauses) and update this policy. This is forward-compatible language, not a representation of current EU/UK operations.

14. US state privacy rights

Whatever state you're in, we honor the full set of rights: access, correction, deletion, portability, and opt-outs. Since we don't sell data or run targeted ads, the opt-outs are already satisfied.

Twenty US states have comprehensive consumer privacy laws in effect as of 2026 (California, Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Florida, Montana, Iowa, Delaware, New Hampshire, Nebraska, New Jersey, Tennessee, Minnesota, Maryland, Indiana, Kentucky, and Rhode Island). Whether a given law applies to a company depends on thresholds that vary by state; rather than lawyer that per state, we extend the common core of these rights to all users, wherever you live:

• Right to know / access: confirm whether we process your data and get a copy (built: the in-app export, Section 11).
• Right to correct: fix inaccurate personal information (built: profile self-edit; board-routed for community records).
• Right to delete: delete your personal information (built: in-app account deletion, with the anonymization caveat stated plainly in Section 11).
• Right to portability: a machine-readable copy (built: JSON export).
• Right to opt out of sale, targeted advertising, and consequential profiling: we do none of these, so there is nothing to opt out of. We treat any Global Privacy Control or similar signal as consistent with our existing practice.
• Right to non-discrimination: exercising rights never degrades your service.
• Right to appeal: if we refuse a request, reply to our decision email and a different reviewer will reconsider; we will respond with the outcome and, where your state provides one, the contact for your state Attorney General.

We aim to respond to rights requests within 45 days, extendable once where the law allows (we will tell you if so).

California notes: we do not sell or share personal information as the CCPA/CPRA defines those terms, we do not use or disclose sensitive personal information for purposes requiring a right to limit, and we honor requests through the channels in Section 11 without requiring account login for the email route.

15. Children and eligibility

Havara is intended for adults 18 and older: homeowners, residents, tenants, and board members. It is not directed to children, and we do not knowingly collect personal information from anyone under 18.

Honesty about enforcement: we do not run identity or age verification at signup; eligibility is set by our Terms and, practically, by the board-controlled invitation flow. Household records a board keeps (units, occupants) may reference household members who are minors as part of ordinary community administration; that is board-entered administrative data, not a child using the app. If you believe someone under 18 has created an account, contact us (Section 18) and we will delete it.

16. Notice to residents, household members, and invitees

Some data about you may reach Havara from your board rather than from you. Here is what, and what to do about it.

If you live in a community that uses Havara, some information about you can exist in the system before you sign up, or without you ever signing up:

• Invitations: a board member may enter your email address to invite you. It is used to send/track the invitation and is not used for marketing.
• Unit and household records: your board may record the unit you live in and your household role (primary owner, co-owner, tenant, occupant).
• Dues standing: your board may record your unit's dues status.
• Violation cases: your board may open a rule-enforcement case that names you.
• Vendor contacts: if you are a vendor, a board may add your business contact details to its community's vendor directory.

For these records, your community (board) is the controller and decides the content; Havara stores and displays it under the access rules in Section 5. To access, correct, or contest such a record: start with your board, which has full edit capability. If that route fails or is unavailable, contact us at [email protected] and we will assist, including verifying with the board and correcting or deleting where appropriate.

If you received an invitation and don't want to join: you can simply ignore it. You may also ask the board (or us) to delete the pending invitation record.

17. Changes to this policy

When we update this policy, we will update the effective date at the top of this policy. We keep a versioned history of every change, and prior versions remain available on request via [email protected]. For material changes we will provide advance notice in the app and, where enabled, by email, and the app's consent gate will ask you to re-accept the new version before you continue using Havara (your acceptance history is versioned and included in your data export).

18. Contact

Havara LLC, a limited liability company organized under the laws of a U.S. state Email: [email protected]

For questions about a specific community's records, your community's board is usually the fastest route (Sections 2 and 16), but you can always start with us.