Havara Privacy Policy

Effective August 28, 2026

Last updated October 6, 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. There are two exceptions, and both apply to a direct message too: your community's moderators see a message that someone reports or that the chat filter holds or flags, and someone on your board who can read your message (for a direct message, one who received it) can make it into a request, which your community's administrators can read (Section 5).
• 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 live vendors: every question goes to OpenAI's moderation service first, and OpenAI also searches your community's documents; Anthropic writes the cited answer. A third provider, TypeSafe, is declared but currently disabled; if approved, it will evaluate how well retrieved excerpts support a question without changing the answer. None is told who asked, and their models are not trained on your requests by default.
• Push notifications show message previews by default. You can turn previews off in one toggle.
• We email you about your own account and your community: a welcome, charges and payments on your home, decisions on your requests, compliance notices, meeting and poll updates, event reminders and a monthly summary, and, when Havara cannot send notifications to your phone, one email a day on days with new chat messages saying how many there are and how many mention you, never what they say. These emails carry what each one is about (a title, a date, a place or an amount, for example) and a link, never a message or a notice's text, though when member email does not send a compliance notice, the copy our push notification service emails instead carries the notice's text (Section 7). Every email other than the ones about your membership, your requests or notices addressed to you has an unsubscribe link, and you can switch each kind off in your notification settings (the daily chat email on Your account in Havara on the web). Member email is switched on as of September 30, 2026. Section 4.3 explains it.
• We don't sell data, run ad networks, or read your contacts, and the app never uses your phone's location. Our server host and our crash-reporting service do work out an approximate location from your IP address and keep it with your account id: Supabase, which runs our servers, logs the city, region, postal code and country each request to them comes from, for 7 days, and Sentry keeps the city, region and country with each crash report. We use them only to run the service and fix errors (Sections 3 and 7). We do sell paid placement to vendors, labeled as an advert wherever it appears. Section 9 is the full list of things we don't do, verified against our code.
• If you ask a vendor for a quote and your board passes it on, that business gets your phone number and email address. The form asks you for them and says so before you send. Section 4.2 explains it, including how long the vendor's link keeps working and how a board takes it back.
• Board members will receive a vendor email we are paid to send. It lists the vendors who have bought placement in their community, it carries an unsubscribe link, and it goes to board members only, never to residents. Nothing has been sent to anyone yet. Section 4.1 explains it.
• 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.
• Product analytics is switched off in the app: no analytics service receives anything, and it stays opt-in per person if we ever enable it. The app does keep a few records of how you use it, because its features need them: where you last read in each chat, when you opened a cure notice your board sent you (the board can see that), the announcements and bulletins you acknowledged, and the thumbs up or down you give an Ask answer, which we keep to make Ask better (Section 3). The havara.app marketing site counts page views with Cloudflare Web Analytics, which uses no cookies (Section 8). Crash reporting is on: when the app hits an error, whether it crashes or the app catches and handles it, it sends the error type and message, the stack trace where there is one, a label for the code that failed with any record ids attached to it (for example the id of the poll that failed to load), your account's user id, and which app version and environment it came from, to Sentry, so we can fix it. Each report reaches Sentry with your device's IP address, and Sentry works out an approximate location from it (city, region and country). The same channel carries short diagnostic notes when something the app expected does not happen. No message content, email, phone number or push token is included.
• The app checks for an update each time it starts, from version 2.2 (build 35) on. It asks Expo, the company that already delivers our push notifications, whether newer app code is available. The check sends a random identifier the app creates for your installation and, if the app hit a fatal error since the last check, a short description of that error. It carries no account id, name, email, phone number or push token. Section 7 lists exactly what it sends.

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 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 Georgia limited liability company ("Havara," "we," "us"). You can reach us at privacy@havara.app (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-gated communities. Creating an account needs no invitation, but joining a community requires an invite code (issued by the board or, for a tenant, by the unit's homeowner) 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: the device push token; session tokens; for each sign-in, the IP address and the app or browser that session uses, kept in our database until you sign out or delete your account; the app-update check described in Section 7's Expo row (from app version 2.2, build 35); and, whenever the app hits an error, the crash and error reports described in the "Analytics & crash reports" row above, which are sent without you doing anything, carry your account's user id, and reach Sentry with your IP address. Our servers also keep request logs. Supabase, which hosts our servers, logs each request the app or web console makes to them: the address requested, including any search words in it (a search inside a chat puts its words there), when, and the result; your IP address; the app or browser that made it; your internet provider's name and the connection details that Cloudflare, the network in front of Supabase, uses to spot automated traffic; and the approximate location Cloudflare works out from your IP address (city, region, postal code, country and time zone). A request made while you are signed in carries your account's user id, and the sign-in log also records your email address with account events such as signing in. These logs are kept for 7 days (Section 10). On the havara.app marketing site, Cloudflare Web Analytics records page views automatically, as that same row and Section 8 describe. We do not collect precise location, contacts, biometrics, or financial-account numbers (see Section 9).

Meeting join details are entered by the board. Published meeting details are visible to members of that community; draft meeting details are visible only to its administrators. The member email for a meeting scheduled or moved carries the full join link and the phone dial-in (a link can include an access code your board put in it), unless the meeting is held only in executive session, when it carries neither. Pushes show only the link's host, never the full join link or the phone dial-in, and previews-off pushes stay generic. Opening a join link takes you to the meeting provider chosen by your board, whose privacy practices apply there. Havara does not embed or record that meeting. These details are kept with the meeting and included in the board's community record download.

Signed minutes are permanent. When a director signs a set of minutes, the minutes are published, members are emailed as for any minutes posted, and the minutes are locked: neither your board nor the Havara app can edit, withdraw or remove them, or unpublish, re-date or remove their meeting. Signed minutes can name the directors present, how each director voted on each motion and who was recused (minutes the board generates from its record do), and they end with the signer's name and seat. A mistake is fixed by a correction the board adds underneath, which every member who can read the minutes sees; a correction is added, never an edit, and it cannot be removed either. Your board keeps every saved version of its minutes, which only its administrators can read, and a saved version cannot be removed either. All of it is deleted only with the community itself (Section 10).

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), and make Ask better using the thumbs up or down you give its answers;
• send the push notifications you have enabled, honoring your mute, quiet-hours, and preview settings, including the level you set for each chat: Off sends nothing for that chat, not even when someone mentions you, and, from the next update of the Havara phone app, leaves it out of the number on the app icon; Mentions only sends only a mention; Daily digest sends one notification a day, after 6 pm in your time zone (until we know it, US Eastern time, or UTC if you have set quiet hours) and outside your quiet hours (one per day in your current time zone, so changing it does not bring a second the same day), saying how many new messages each of those chats had, never what they say (emergency alerts bypass the mutes and quiet hours you set in Havara, by design; your phone's own silent mode and Focus settings still apply, unless on Android you let Havara's emergency alerts channel override Do Not Disturb);
• support board tooling: member management, moderation, governance records, and the audit log;
• check each chat and direct message as it is posted or edited, and the name of any file attached to it, against a list of slurs and a set of scam-link patterns, inside our own database, where no outside service sees it. There is one exception: when a board member publishes a bulletin and announces it in community chat, creates a poll or adds an upcoming event for the whole community, Havara posts a line in your community's main chat under that board member's name, carrying the bulletin's title, the poll's question or the event's title. The check does not read that line when it is posted, because its words are the board's own, written in the bulletin, poll or event itself, and the check is for messages written in chat, not for what a board publishes; if the board member later edits the line, the edit is checked like any other message. A message with a link that looks like a scam is held: only you can see it until your community's moderators allow it into the conversation (allowing it sends no notification) or hide it, and when your notifications are on and outside your quiet hours we send you a notification saying it is held, which contains none of the message (the current version of the app also marks the message itself). A message with a word from the list is posted as normal and flagged to the moderators. A few words on the list also have an everyday meaning, and one is spelled the same as a common Spanish nickname, so an innocent message, a direct message included, can be flagged. Either way the moderators see the message, the names of any files attached to it, who wrote it and where;
• diagnose crashes and errors, which happens today through Sentry (Section 7), and, if in-app analytics is ever enabled, understand feature usage (analytics is opt-in per person);
• count page views and measure page-load performance on the havara.app marketing site, through Cloudflare Web Analytics (Section 8);
• 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.

4.1 The vendor digest, which is email we are paid to send

An email to a community's board listing the local businesses that paid us for placement there. Board members only, sent by a person, unsubscribe in every message. Nobody has received one yet.

Havara sells paid placement to local businesses inside a community's vendor directory. A paid placement is labeled as an advert everywhere it appears. The app's featured strip opens with this disclosure, and the vendor digest carries it word for word:

Paid placement: these vendors pay to be shown here. Each card says what Havara checked and when. We do not vet or guarantee their work.

The vendor digest takes those same paid placements to a community's board by email. Its purpose is to promote businesses that paid us, so it is commercial email rather than a service message, and we treat it as commercial email:

• Board members only. The digest is addressed to the members of that community's board. Residents and homeowners are not sent it. Sending advertising to people who joined a private community app would need an opt-in we do not ask for and do not hold.
• A person sends it, not a scheduler. A Havara operator builds the digest for one named community, reads it, and sends it. Nothing sends itself, and there is no automatic or recurring send.
• Only paid placements are in it. A business is in the digest because it holds a paid-placement slot in that community. The digest is not a summary of the whole vendor directory.
• An unsubscribe link in every message. Unsubscribing records your address on an opt-out list, and every later digest is filtered against that list. The list is held against Havara as the sender rather than against one community, so the opt-out keeps working if your board changes, if you join another community, or if you delete your account and come back. It does not switch off service email such as invitations and password resets, and it does not change your in-app notification settings.
• No open tracking, no click tracking. We do not measure whether you opened a digest or which links you followed in one. The message we build carries no tracking pixel and no images at all, we do not rewrite its links to route your click through us first, and the record we keep of a send holds no open, click or read information about any recipient. Open and click tracking are also a setting at our email provider, held per sending domain rather than attached to an individual message by our software. They are switched off for ours. Because that switch lives in a console rather than in the product, we confirm it is still off immediately before a digest goes out, rather than let this page be the only thing standing behind it. What we record is that a send happened: which community, which placements, the subject line, how many people it reached, how many had opted out, and when. The addresses it went to are not kept in that record, because a count answers the only question the record exists for and a stored list of addresses would outlive its purpose. That record exists so a business that paid can be shown what its placement bought.
• The vendors do not get your details. Businesses are named in the message. They are not given the recipient list, they are not told who received the digest, and they get nothing about you unless you contact them yourself.

Nobody has received a vendor digest. None has been sent, to any address, and no business has yet bought a placement. We are describing this before it happens rather than after, because using your email address to carry advertising is a new use of it and you should hear about it first.

4.2 Quote requests, and the two emails they involve

Your phone number and email go to the business your board passes your request to.

When you ask a vendor for a quote, the form asks for your own phone number and email address, prefilled from your profile and editable before you send. If your board then chooses to pass the request on by email, that email carries your request, your community's name, your phone number and your email address to the business, along with a link the business uses to answer. This is the point where your own contact details leave your community, and it happens only when your board presses send.

• The link needs no account. Vendors have no Havara login. The link in the email is the credential, it is single use for answering, and it stops working after fourteen days. Anyone holding that link can open a page showing your request and your contact details until then, so treat the email as you would any email that carries your number.
• You can be asked and never told. Whether your board passes a request on is your board's decision, and so is closing it. Both are recorded and both are shown to you in the app.
• Your board can take a link back. If a board removes a business from its directory, every link that business is still holding stops working immediately, on both surfaces and in the database.
• The listing invitation is a second, separate email. When a board approves a business, we can send that business an email saying it has been listed, with a link to confirm its own details and attach an insurance certificate. That message is about Havara's directory rather than about one neighbor's request, so we treat it as commercial email and it carries the same postal address the vendor digest does. It is not sent to any resident.
• We do not sell or share your contact details with vendors for marketing. A vendor receives your details because you asked that vendor for a quote and your board passed it on, and for nothing else.

This is live. The function that sends both emails is running, so a board can relay a quote request by email today.

4.3 Email about your account and your community

A welcome, your own charges and payments, answers to your own requests and notices, community updates, and a daily count of new chat messages, each with a link into Havara. Switched on as of September 30, 2026.

Havara emails you at the email address you sign in with, once it has been confirmed. We never send member email to an address typed into a profile that nobody confirmed.

• About your membership, your requests and notices addressed to you, always: a welcome when you join a community, the answer to a request to join, a change to a tenant's access end date, a compliance notice addressed to you (the rule and the deadline, not the notice's text), a hearing notice addressed to you (the rule, the hearing's date, time and place, not the notice's text), your board's written decision after a hearing and a fine committee's vote on a fine your board decided (each naming the rule, never the outcome, the reasons or an amount) and your appeal being decided (the email names the rule, not the outcome), your board's decision on your architectural request and any hearing on it, and your request or records request being resolved.
• About money on your home, on by default: a charge posted to your home (dues, a fine, a fee, interest) and a payment recorded, with the amount, the board's short description and the date. Only a home's owners get these, not a tenant living there, and never a neighbour.
• About your community, on by default: a meeting scheduled, moved or cancelled (for a meeting scheduled or moved, with its join link and phone dial-in, and whether its agenda includes a special assessment, a change to the rules on how homes may be used, or an executive session), minutes posted, a new poll, a reminder the day before an event you said you are going to, a copy of an emergency alert (its kind and place, never the note), and a monthly summary sent only when there is something new for you. The summary lists upcoming meetings and events, new documents you can open, open polls, decisions logged, your own open requests and your own home's balance, and one line of community numbers.
• About chat in your community, a daily chat catch-up: at most one email a day for each community, around 6 PM in your time zone and only on a day with something new, saying how many new chat messages you have there and how many of them mention you, with a link to the chat. It counts the messages the unread count in the app counts, in chats you can read, leaves out a chat you set to Off (a mention in it too), and for a chat set to Mentions only counts only the messages that mention you. It is on by default only while Havara cannot send notifications to your phone: you have not installed the phone app, or its notifications are off. Switching notifications off in the phone app clears the code we use to reach your phone, so this email starts the next evening something new is said unless you switch it off. If you use the phone app with notifications on, you get it only if you turn on "Also when I use the phone app". A chat message that repeats something we also emailed you, such as a line your board posts about a new event, is counted like any other message, and a chat you set to Daily digest gets both its daily push and this email.

What a member email never carries: a chat or direct message (the daily chat catch-up carries only the two counts, never what a message says, who wrote it or which chat it is in), an announcement (your board emails those itself, Section 7's Resend row), the text of a notice or a request, an alert's note, or anything about another member other than the names of your community's current board members in the welcome email. A copy of a compliance notice that our push notification service sends when member email does not (Section 7) does carry the notice's text.

Your choices. Each kind of community and money email has a switch in your notification settings, and you can unsubscribe from each of those emails from the email itself. The daily chat catch-up has its own switches on Your account in Havara on the web: the email itself, and "Also when I use the phone app"; unsubscribing from it in the email turns it off until you turn it back on there. If your mail app shows its own unsubscribe button, that works in one step. The unsubscribe link at the foot of the email opens a page on havara.app where you confirm with one button. That link, and the header your mail app reads, carry a code that identifies your account and the kind of email, so the unsubscribe works without signing in. Emails about your membership, your requests and notices addressed to you are service messages and have no switch; emails about money on your home have one. Meeting, poll, event, summary and chat catch-up emails wait until 7 AM if they fall between 9 PM and 7 AM in your time zone. Your time zone is the one your phone or browser reports when you open Havara, and until we know it we use US Eastern time; every time an email shows names its time zone. You get at most three meeting, poll and event emails a day, counting several updates combined into one email as one; the monthly summary is not counted against that limit. The chat catch-up is not counted either, so it never takes the place of one of those emails, and it is not sent on a day you already had three. Emergency alerts and emails about your own home and requests are not held.

What we keep. A queue of the emails due to you, with the event it is about and whether it was sent, kept up to 90 days (Section 10) and removed with your account. We keep no copy of an email's text. Opens and clicks are not tracked.

Switched on as of September 30, 2026. Nothing the queue held from before that moment is ever sent; those rows are deleted on the schedule above. Each email carries Havara's postal address.

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 on our servers by database access rules 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).

Pinned messages. Someone on your community's board (a board member, an admin or a declarant) can pin up to five messages to the top of a community or board channel, never a direct message or a group chat. A pin shows the message and its author, and the name of the person who pinned it and the date, to everyone who can read that channel, including members who join later. The pin ends when the board unpins it, or when the message is edited, deleted, removed or held for review, or a file is added to it. If the person who pinned it deletes their account, the pin stays without their name. Your community's activity log, which its administrators can read and which goes into the community record they can download, records who pinned or unpinned a message in which channel and when, never the message itself.

Direct messages. Readable only by the participants of the conversation, unless a message is reported, held or flagged by the chat filter (below), or made into a request (Requests, below). 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) and the reported message itself become visible to your community's moderators, so they can act on it; the same happens when the chat filter holds or flags a message in a DM. Moderators can read a DM message only through a report on it that is still open or that they acted on, or when someone on your community's board (a board member, an admin or a declarant) who received it makes it into a request, when every administrator of your community can read its text and photo in that request; a dismissed report no longer shows them the message, and a report cannot be moved to a different message after it is filed.

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.

Requests. A request you file (a maintenance issue, complaint, question or records request, which asks the board to inspect or copy association records), its comment thread, and any response date your board sets on a records request are visible only to you and to your community's administrators (a board member, an admin or a declarant). Other residents cannot see it. Your board, not Havara, sets a response date; Havara does not calculate one or apply any period set by law or by your governing documents, and filing in the app does not replace any written request those documents or the law may require. On a records request, how you asked to get the records, the copy costs your board records and the list of records it withheld from you, with its reasons, are visible to you and your community's administrators only; your board's copy-cost schedule is visible to every member of your community. The copy costs are what your board says it charges: Havara does not calculate them and takes no payment for them. Your board picks each withholding reason from a fixed list; Havara does not decide whether one applies. When your board takes an item off the withheld list, Havara keeps it, marked with who removed it and when, as part of your association's record of the request; it is erased with the request. Nobody, your board included, can change how you asked to get the records after you file. A request made from a chat message. On the phone you can turn your own chat message into a request; someone on your community's board (a board member, an admin or a declarant) can do the same with any chat message they can read, including another member's and a direct message you sent them; every administrator of your community can then read it in the request. The message's text is placed in the request, and its photo is copied into the request, so both stay with the request if the chat message is later deleted or hidden, and are erased when the request is (with the account of the person who filed it). A request a board member makes from your message is theirs: you do not see it, and your community's administrators do. The copy is the same file that was shared in chat, so it carries whatever that file carried.

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, and every unit's dues standing is part of the community record an administrator can download (below). 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. Each time you vote, your community's audit log also records your account and the poll (not your choice), but the board cannot read those entries: a board member sees only their own, so the audit log never tells the board who voted in which poll. Havara personnel with production database access could technically read vote rows and those entries; that access is restricted to service operations (Section 12).

Member directory. Shows your name, avatar, role, bio and home (the unit label, address and lot your board recorded) to members of your communities. Your phone number and email are never shown in the member directory or on your profile. Your household role (primary owner, co-owner, tenant or occupant) is shown only to you, the members of your own household, and your board (including a member your board lets manage members). Other members do see the role on your directory entry and profile (for example Homeowner or Resident) next to your home, so they can tell an owner from someone who is not the owner of that home; what they cannot see is whether someone who is not the owner is a tenant or an occupant. Directory reads go through controlled server-side functions so sensitive columns (like your push token) are never exposed. Opening other members' profiles is rate limited, to slow anyone collecting the directory in bulk; it slows that, it does not make it impossible, because the directory list itself still shows every member's name, photo and role. The phone app's member directory and every member's profile, in both apps, are marked for use by members of the association only, and not for solicitation. On the web console, search, the list of people to start a message with and your board's member roster carry the same mark.

Your member list choice. For each community you can choose to show your name and home (where everyone starts), to show your name but hide your home, or to be left out of the member list. Hiding your home takes it off your profile for other members, in both apps. On the web console, leaving the list takes you out of your neighbours' search and out of the list of people they start a message with. Your board and a member your board lets manage members are not filtered: they still find you in both, marked as not in the member list. The phone app does not honour leaving the list yet: it still shows your name in its member list, its search, its list of people to start a message with and its suggestions when someone mentions a neighbour in a chat, but never a home you hid. Your board, a member your board lets manage members, and the people in your own home always see your name and home, and your board's member roster on the web console shows your choice, while its search and its list of people to start a message with mark you only if you left the list, so it can leave you out of any member list it shares with owners. While you hold a board or management seat you stay in the member list, so residents can find their board, though you can still hide your home. Your name still shows on what you post, in chats you are part of and on your profile. The list the apps use to put names on posts still reaches every member's device with your name, marked as left out, so someone reading that list directly can tell you chose to leave it; it never shows that you hid your home, though a Homeowner whose profile shows no home may let a neighbour guess. Your choice stays if you leave the community and applies again if you rejoin; deleting your account erases it, and it is in your Download my data.

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. Havara is also told by email of a report on a declared interest, in an email that carries one report: the declaration's words, the name of the person who made it, the community and the business, the reason you chose and any words sent with the report, and your account identifier (not your name), so we can look into it. At most one such email is sent every five minutes; a report filed within five minutes of another is not emailed, and we review it from our own list instead. Only Havara can act on it: your board cannot close it. The person who made the declaration cannot see the report or who filed it, even if they are one of your community's moderators. Board hide-actions and moderation case notes are visible to capability-holding moderators. Your block list is visible only to you.

Ask questions and answers. Your Ask questions, the answers and your conversation threads are readable only by you, not by your board. A question refused by moderation is the exception: it is recorded with your name and the reason it was refused, and your community's moderators can see it (Section 6).

Audit log. Governance actions (invite redemptions, role and membership changes) are recorded in a board-visible audit log for accountability. It also records which polls you voted in (not how you voted), and those entries are hidden from the board (see Poll votes above).

Community record download. A community administrator (a board member, an admin or a declarant) can download the community's record from the web console as one file. It holds what that administrator can already see: the member roster by name, with each member's role, home and household role, and join requests; every home's dues standing, ledger entries and payments; violation cases, requests, architectural requests and requests for vendor quotes, yours included; which notices you acknowledged and whether an emailed copy reached you; your event RSVPs and your responses to emergency alerts; your place in any group the administrator also belongs to; the audit log; and the community's other records, such as announcements, meetings, the board roster, the compliance calendar and who completed each deadline, the insurance and contracts register (entries not removed) and the operating balance the board entered, the board's motions with each director's vote, action items and every version of the minutes, the meeting agenda items (an executive item's title and details included), every version of the executive session minutes and the meeting notice rules, who agreed to get official notices electronically, when and how, every earlier version of an edited notice, documents' names and polls with their vote counts. It never includes chat or direct messages (a request someone made from a message is included like any other request, with the message's text), your Ask questions, your individual poll votes or which polls you voted in, or your email address or phone number, including any you left on a quote request for a vendor, or the mailing and copy-to addresses owners gave for paper notices. Each export is recorded in the audit log.

Board roster. Your board can list its seats (for example President or Treasurer), who holds each and the term dates. Every approved member of that community, tenants and vendor members included, can read each seat's title, the holder's name and the term dates. Only the community's administrators (board members, admins and declarants) can add, change or remove a seat, and each addition, change and removal is recorded in the audit log with the seat's title (reordering the list is not). The dates are what the board typed; they are not the result of any vote in Havara. A holder must be a current member of the community: if you leave, are removed or delete your account, your name comes off the seat and the seat shows as vacant, and while your access is paused it shows as vacant too.

Meeting agendas and executive sessions. Your board can build a meeting's agenda from items, each open to members or held in executive session, closed to members, under one of six topics (legal advice, litigation, personnel, contracts with outside parties, member discipline, or a member's personal financial matters). Every member reads the published meeting's agenda, where an executive item appears only as "Executive session, closed to members:" and its topic. An executive item's title and details, the minutes of an executive session, and the board's meeting notice rules are visible only to your community's administrators (a board member, an admin or a declarant, including a management company staffer the system has seated). Executive session minutes may name members, for example in a discipline, personnel or financial matter. Each save of them is kept as a new version for the association's record. Havara does not know which notice your state or documents require; every notice period is one your board entered.

Compliance calendar. The deadlines your board keeps for the association (budget, insurance, filings, notices and the like), who owns each one, and who marked each one done and when, are visible only to your community's administrators (board members, admins and declarants). Other members cannot see them. Havara does not know any state's deadlines; every date on it is one your board entered. A daily reminder of a deadline that is due soon or overdue goes to the deadline's owner, or to every administrator when it has none or its owner is no longer on the board, as a push, and by email to an administrator the push did not reach (Section 7, Resend).

Insurance and contracts register. Your board can record the association's insurance policies, service contracts and bids. An entry your board publishes is visible to every approved member of that community, tenants included: what it covers or is for, the insurer, contractor or bidder, the amounts and dates, the notes, and a link to a document that opens only if you can already read that document. Entries your board has not published or has removed, the reminders they put on the compliance calendar, and the operating balance the board enters for its fidelity coverage check are visible only to your community's administrators. A vendor's seat in the community sees none of the register, so a bidder cannot read another bid. Havara does not know which policies, limits or contract terms your state or documents require; every figure is one your board entered, and the coverage check does no accounting.

Official notices. Every official notice your board sends to owners stays in the notice archive for the members it was sent to. In the notice archive, a notice the board later withdrew is listed by its title and the dates it was sent and withdrawn, without its text, and a notice the board later changes to board members only leaves owners' view of the archive. When your board edits a notice, members see that it was edited and when, and your community's administrators keep the earlier wording, which also goes into the community record they can download; it cannot be removed later. If you are an owner, whether you agreed to get official notices in the app and by email, when and how, your mailing address for paper notices and the name and address of anyone you asked to get a paper copy are visible to you and to your community's administrators (board members, admins and declarants) while you are a member, including a management company staffer the system has seated, and not to other members; when you leave the community, they leave the administrators' view. Your board can record a paper form you signed: you see on your account that it did, with the date on the form, but Havara does not email or notify you when it does. Havara does not know your state's rules for electronic notice and mails nothing; your board prints and mails paper copies.

Declared interests. When someone who can approve vendors declares that they or their family have an interest in a vendor, every member of that community can read it: their name, what they wrote, when, and when they withdrew it. That holds whatever the vendor's status, including a vendor still waiting for review or one the board did not approve; the app shows declarations on the vendor's page. Both dates are set by our servers, not by the person declaring. A person who has since left the community is shown as "Former member". Only the person who made a declaration can withdraw it, and a withdrawn declaration stays visible, marked withdrawn. Members who cannot approve vendors cannot make one. One person can hold at most 10 declarations at a time in a community, one per vendor, and file at most 10 in a day, or up to 20 when the extra ones are first declarations on a vendor. Any member can report a declaration to Havara. If its words break the community guidelines (for example they describe a private person beyond what the conflict needs, or carry personal data), Havara can replace them with "Removed by Havara": the declaration, its author's name and its dates stay, and so does its effect on approving that vendor. We keep a record of who at Havara removed the words, when and why, but not the words themselves, so a removal cannot be undone; the original words remain only in database backups until those age out.

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 administrative database access, 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. Every question goes to OpenAI's moderation service first, and OpenAI also finds the relevant passages; Anthropic writes the cited answer. TypeSafe passage evaluation is currently disabled pending review. None is told who asked, and their models are not trained on your requests 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 is sent to OpenAI's moderation service before anything else happens to it. A question it flags is not answered; it is recorded with your name and the reason, where your community's moderators can see it (Section 3). If that check does not come back (it times out, or OpenAI returns an error), the question is answered anyway rather than blocked, so it is a screen that can be missed and not a guarantee.
2. Your question text is embedded by OpenAI (model text-embedding-3-small) so the system can search your community's document index.
3. A permission-filtered search retrieves up to six relevant excerpts, only from documents your membership allows you to see.
4. TypeSafe is currently disabled and receives no data. If we approve this test evaluation, the current question, at most the preceding question needed for a follow-up, and the six retrieved excerpts, with their document titles and section headings, will be sent to TypeSafe. It will return structured passage-quality probabilities for internal evaluation only; those results will not reorder or filter passages or change the answer.
5. 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.
6. 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 Amazon Web Services for optical character recognition, using Amazon Textract's plain-text detection. The PDF is copied to a private AWS storage bucket in the United States for the duration of the scan and deleted after the scan. AWS's service terms allow it to keep what Textract processes (Section 7 has the detail). The text Textract returns is stored so the same file is never scanned twice, and a cleanup that runs every day deletes it once no document uses it any more. If OCR fails, the document is simply excluded from Ask. Documents that already contain selectable text are never sent to AWS at all.

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

• OpenAI receives document text (during indexing, to build the search index) and your question text, which is sent to it twice: once to the moderation service and once to be turned into the search query. On a follow-up, the question before it goes with it so a short question still finds the right passages. OpenAI does not receive the retrieved excerpts and does not write the answer. AWS receives only scanned PDFs that have no text layer, for character recognition. Anthropic receives your question, the thread's prior turns, and the retrieved excerpts. TypeSafe currently receives nothing; if approved, it will receive the current question, at most the preceding question, and up to six retrieved excerpts with their document titles and section headings, and that text may contain the names of people mentioned in it.
• No account or community identifiers (your name, email, or user ID, or your community's ID) are sent to any AI 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).
• TypeSafe's model documentation says its model is not trained on customer requests or responses (verified 2026-09-19). TypeSafe's customer agreement lets it keep, use and share the data it receives (the questions and excerpts) in perpetuity for three purposes: to derive telemetry, to monitor for fraud and abuse of its services, and as necessary to comply with law. It may use that derived telemetry (such as technical logs, hashes, summary statistics, classifications, metrics and learnings) without restriction, including to improve its products. Its privacy policy says it will not train models on the data it receives and publishes no fixed retention period (both verified 2026-09-22). Zero data retention is offered only to enterprise customers; TypeSafe's ordinary retention terms and a data processing agreement must be settled before it is switched on.

What Ask never does:

• It never builds a new answer from documents you can't see. Each time Ask composes a new answer, your document permissions are re-applied when it retrieves excerpts, so that answer is built only from documents you may see at that moment. Answers you have already received stay in your own Ask history if your access later narrows; a follow-up in the same conversation sends those earlier turns to Anthropic with the new excerpts; and the same first question in a new conversation can show you your own earlier answer again while your community's set of Ask documents is unchanged.
• 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, and only you can read them. A question refused by moderation is not answered and is not added to your history; it is recorded with your name and the reason it was refused, and your community's moderators can see that record (Section 3). Asking is 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 one integration that is wired but switched off, which we disclose anyway.

The authoritative, versioned list is our Subprocessor documentation, available on request via privacy@havara.app. Summary:

"Conditional" means the integration is built and enabling it requires only a configuration key or a reviewed code change. If we enable one, we will update our subprocessor list first and, where the change is material, notify you per Section 17. We have broken that commitment twice, and you should know that from this page. Resend was switched on on August 5, 2026 and Sentry on August 26, 2026; in both cases the configuration key was set first and this policy and the subprocessor list were corrected afterwards, not thirty days before. Both are now disclosed in full above.

Fonts are served by us, not Google. The web console and the havara.app marketing site (including the published /privacy and /terms pages) serve their fonts (Fraunces and Inter) from our own sites, so loading a page sends nothing to Google. Earlier versions of this page said both loaded fonts from Google's servers, which sent your IP address and browser headers to Google with each font request; that stopped when the release that self-hosts the fonts was deployed. The mobile app has always bundled its fonts.

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

havara.app sets no cookies and puts nothing in your browser's storage, so there is no cookie banner to click. It measures page views with Cloudflare Web Analytics, which Cloudflare documents as using no cookies or browser storage. 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. Our pages use no browser storage either: they put nothing on your device and read nothing back, and that includes the page-view beacon described below. 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. One thing is stored by your browser itself: Cloudflare, which serves the site, asks your browser to report to it when one of our pages fails to load, and your browser keeps that instruction for up to 7 days. Those reports go to Cloudflare, not to us, and successful visits are not reported.

Staying signed in, and the four small things kept beside it. The mobile app and the web console each store 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.

Beside it, the console keeps four preferences, and this is the complete list rather than a summary of it: which of your communities you last had open, whether you left the side navigation expanded or collapsed, whether you dismissed the setup checklist for a community, and a one-shot marker used to recover from a failed page load without looping. During sign-in itself the sign-in library also writes one short-lived verification value, which it deletes as soon as you are signed in. That is everything, and none of it is a cookie, none is sent to us, and none can be read by any other website. Signing out clears the session token, and clearing site data for app.havara.app clears the rest.

(An earlier version of this section named two of these five and implied that was all of them. It was not, and the count is corrected here rather than quietly.)

Page views: Cloudflare Web Analytics is on. havara.app measures page views and page-load performance with Cloudflare Web Analytics, a small script Cloudflare calls a beacon, which we embed in the page ourselves. It loads from Cloudflare's script host and reports back to Cloudflare. Per Cloudflare's published Web Analytics documentation (read 2026-09-22), it reports the page's path and the referring page but not the query string, and timing and Core Web Vitals metrics read from your browser's Performance API, and Cloudflare records the country, browser, operating system and device type. It uses no cookies and no browser storage, does not collect or use visitors' personal data, and does not track anyone across the other sites that use it; for the Core Web Vitals measurements it reports, Cloudflare also states that its Vitals Explorer does not fingerprint individuals via their IP address, user agent string or any other data. The beacon does not load on any page whose address carries an invite code or a one-time link: the invite page, the vendor reply and listing pages, and the page shown for an address that does not exist. Those pages also tell your browser not to pass their address on to the next page you open, so a code cannot reach the beacon that way either. Section 7 lists Cloudflare Web Analytics as a subprocessor.

No advertising, no cross-site tracking. We use no advertising pixels, device fingerprinting, or advertising identifiers, and we do not follow you across other websites. There are no ad SDKs and no advertising-tracking domains in the app or on the site. Our own product-analytics integration (PostHog) ships switched off, and if we ever enable it, it stays opt-in per person; our crash-reporting integration is on, and Sections 3 and 7 describe what it sends; the page-view beacon is described above (Section 7 lists all three and their status). Section 9 is the full list of things we don't do.

Fonts. The web console and the marketing site serve their fonts from our own sites; no font request goes to Google or any other third party. The mobile app bundles its fonts and makes no font request at all.

9. What we DON'T do

Each absence claim below was verified against our codebase, not just asserted: the advertising claim on 2026-08-20, the crash-telemetry claim on 2026-08-28, the cookie, analytics and payments claims on 2026-09-22, the AI-training claim on 2026-09-23, the location claim on 2026-09-25, the face, fingerprint and passcode claim on 2026-09-28, the rest on 2026-07-12. Six claims in this list have needed correction after the fact: the advertising, crash-telemetry, analytics, payments, AI-training and location claims. Prior versions of this page are available on request via privacy@havara.app.

• 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, its page-view beacon included, 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 ad networks 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 do sell paid vendor placement, in the vendor directory and in the board digest (Section 4.1). It is labeled as an advert, which business appears is decided by us and the business that paid rather than by anything we know about you, and no third party is given your data in order to target it.
• We don't use your phone's location. The app contains no GPS/location code and requests no location permission. Location information we hold linked to your account includes text someone typed (an event's venue, an optional note on an alert or violation case), the time zone your phone or browser reports when you open Havara or set quiet hours, and approximate locations worked out from your IP address: Supabase's request logs keep the city, region, postal code and country each request to our servers comes from, for 7 days (Section 3), and Sentry keeps the city, region and country a crash report arrives from (Section 7). We use these only to run the service and fix errors. A photo or video you attach may also carry, inside the file, the place it was taken, if your phone recorded that and passed it to the app; the app does not read it. On havara.app, Cloudflare Web Analytics counts the country each page view comes from, which is not linked to anyone (Section 8).
• 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 receive your face, fingerprint or passcode. If you turn on Unlock with Face ID (or Touch ID, or fingerprint) in Profile & settings, your phone does the check and tells the app only whether it passed. No face, fingerprint or passcode data reaches the app, Havara's servers or any company we work with, and the setting itself stays on your phone. It is off unless you turn it on, and turning it on or off takes a check first.
• We don't process dues payments. Dues standing is a read-only record your board types in. The only payment in Havara is the community's own subscription, which a board administrator pays on Stripe's hosted checkout (Section 7); Havara never receives the card or bank details. There is no card, bank, ACH, or payment SDK anywhere in the app or the web console, and we will never ask for payment details in chat or email.
• We don't train AI models on your data, and our Ask 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). AWS, which reads scanned documents for us, has standard Textract terms that would let it use them to improve its own AI services unless an opt-out is in place; Havara has had that opt-out in place since September 23, 2026, covering Textract and every other AI service the policy covers (Section 7).
• We don't run third-party analytics in the app, and we do send crash reports. The havara.app site measures page views with Cloudflare Web Analytics, which uses no cookies or browser storage and does not load on pages whose address carries an invite code or a one-time link; Section 8 has the detail and Section 7 lists it as a subprocessor. Our own product-analytics integration (PostHog) ships disabled and additionally requires your individual opt-in even if enabled. Crash reporting to Sentry is on. Section 3 lists in full what a report contains; the short version is the error and where it happened, plus your account's user id and which build it came from, and Sentry works out an approximate location from the IP address the report arrives from. It never carries message content, your email, your phone number or your push token.
• 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. A direct message reaches your community's moderators only when someone reports it or the chat filter holds or flags it, and its administrators only when someone on your board who received it makes it into a request. 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, your block list, quote requests you sent to vendors (including the phone number and email on them), vendor recommendations you made, interests you declared in a vendor, board seats you hold, compliance calendar deadlines you own and the completions you recorded or undid (with any note you added when marking one done), insurance and contracts register entries you added or removed and an operating balance you set (these are in its community record download), the list of records your board withheld from a records request you filed (you can see the current list on the request in the web console), motions you moved or seconded and the votes and consents recorded for you as a director (these are your association's record of what its board did, and they are in its community record download), the entries your board wrote on your ARC requests (its replies, and the meeting and outcome it records on a request to reconsider), any of your Ask questions refused by moderation, and the member email queue (which emails were due to you, about what, and whether each was sent; Section 4.3) are not included in the JSON export (you can view your block list and your reports in the app). We track this as an open item.

For anything else, or to exercise a right without app access, email privacy@havara.app. 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 access rules on every table, server-side secrets, private storage with signed URLs. We don't claim certifications we don't have.

• Database access rules on every 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; those rules are what protect the data.
• Authentication is email + password (with email magic-link as a secondary option), with password reset by a secure emailed link that opens Havara (the app if you asked from the app, the web console if you asked from the console); 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, TypeSafe), email keys, and the push secret are held in server-side secret stores, 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, and opening other members' profiles.
• Push privacy: preview toggle, per-category mutes, each chat's level, 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). The AI, email and crash-reporting vendors we use today, and Expo, which sends our push notifications and answers the app's update checks, are US-based services (Section 7); the crash reports described there are posted to Sentry's US ingest region, which is fixed at organization creation and cannot be changed later. Three exceptions: Cloudflare, which serves our website and web console, handles each request at the location nearest you, so web traffic is not processed only in the United States, and the app's update checks to Expo also enter through Cloudflare's network at the location nearest you; Apple and Google, which relay push notifications to iPhones and Android phones, do so on their own global infrastructure; and AWS's terms allow it to keep some Textract content in another AWS region (Section 7). TypeSafe, which is switched off, has no confirmed region yet (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.
• Copy-to address: an owner may give the name and mailing address of someone who should get a paper copy of each official notice, for example a person who holds their power of attorney. The owner's community administrators see and print it; Havara does not contact that person.
• Vendor contacts: if you are a vendor, a board may add your business contact details to its community's vendor directory. A board may also email you a resident's quote request, which carries that resident's phone number and email address, and may email you a link to confirm your own listing. You can ask the board, or us, to remove your business from a 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 privacy@havara.app 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 change the "Last updated" date at the top of this policy. We keep a versioned history of every change, and prior versions remain available on request via privacy@havara.app. 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 Georgia limited liability company

Email: privacy@havara.app

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.