Havara Privacy Policy

Effective October 30, 2026

Last updated October 20, 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 reports on messages and declared interests. Reports on other content go to Havara. Section 5 lists who sees each kind.
• 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, staff join-request reminders, 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, staff join-request reminders, 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 we do not request GPS permission or read GPS coordinates. 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 those Supabase and Sentry records only to run the service and fix errors (Sections 3 and 7). Google's iPhone sign-in library also declares Coarse Location for App Functionality; Section 3 explains that declaration and what remains unverified. We do sell paid placement to vendors, labeled as an advert wherever it appears. Section 9 gives the full statements, with their code and declaration sources.
• 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." A historical identifier, including your profile identifier, can remain in a report someone else filed on your content or profile (Section 10).
• You can download a copy of your personal data yourself, in the app, any time; Section 11 lists what it includes and excludes.
• You can sign in with Apple or Google in the phone app, from version 2.3: Apple on iPhone, Google on iPhone and Android. If you do, Apple or Google confirms who you are and learns that you use Havara. Section 3 lists what each one shares with us, and Section 10 what happens to it when you delete your account. Version 2.3 was available only to testers. The first public version offering Apple and Google sign-in is 2.4, available on or after October 30, 2026.
• If your community turns on its security desk, Havara keeps the guest passes you create, the vehicles you register to your home, the parcels the desk logs for your home, the desk's record of your guests' arrivals, and the fobs, spaces and lockers assigned to your home. The people who staff the desk see them for every home. Havara does not ask for a gate code or PIN, refuses a device or space name that is only a 4 to 8 digit code, and never contacts your guests. Sections 3 and 5 explain it.
• Havara's optional product analytics, PostHog, is switched off, and it stays opt-in per person if we ever enable it. Google's iPhone sign-in library separately declares data for App Functionality and Analytics (Section 3); the PostHog switch does not control that library. 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. From the first native-crash store build, phone crash reports include native stacks, device and operating-system details, memory, battery and storage diagnostics, an installation identifier (also used as the user id while signed out), an iPhone device-and-app hash, Android permission grant state, rooted or jailbroken status, app state and update metadata, lifecycle and device-state breadcrumbs, Android activity and view class/id interaction breadcrumbs, and Android app-not-responding thread stacks; the diagnostic categories follow in Section 3.
• 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 [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-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.

What changed on October 30, 2026

Phone crash reports now include device details, an installation identifier and app and device event breadcrumbs. Section 3 describes the categories, including identifiers and Android interaction and app-not-responding reports. The updated app and the web console will ask you to accept the updated policy once.

From version 2.3 of the phone app you can sign in with Apple on iPhone, or with Google on iPhone and Android, if you choose to. Section 3 says what each one shares with us. Google's iPhone library separately declares data for App Functionality and Analytics, including identifiers, phone number and approximate location. The declaration and the limits of our verification are also in Section 3. This clarification is prospective for the first public social-sign-in version, 2.4, on or after October 30, 2026.

Your board can turn on a security desk for guests, parcels, vehicles and the devices and spaces assigned to homes. Section 5 says what it records and who sees it.

When a phone app version offers Report or block on other content pages, those reports go to Havara. Only the person who filed a report and Havara can read it. Sections 3, 5 and 10 explain what it records and what remains after account deletion.

3. What we collect

Google's iPhone sign-in library

When you choose Continue with Google, the iPhone app uses Google's sign-in library. That library is built into the app. The app also calls it to clear any Google sign-in whenever anyone signs out of Havara on that phone, even if they signed in with Apple or email. Whether that call collects or transmits any of the categories below is not verified.

The library declares the following categories and purposes. These are Google's declarations, not a record of what a particular phone transmitted. The declaration marks all eight categories as linked to you and not used for tracking.

App Functionality means providing the service; Analytics means examining how the service is used. Coarse Location means approximate location. Google's published iPhone-library guidance says it may use an IP address to estimate a device's general location for fraud prevention. That guidance does not explain every category or purpose in its declaration.

We have not verified when each declared category is collected or transmitted, including whether any collection begins before you choose Google, the exact fields within Other Data Types, or a retention period for this library's data.

These declarations are separate from Havara's optional PostHog product analytics, which is off and stays opt-in per person if enabled. Signing out of Havara, deleting your Havara account or clearing the local Google sign-in record does not guarantee deletion of records Google holds separately. Google's own Privacy Policy describes its practices and controls. Sections 10 and 11 explain the limits of Havara's retention, export and deletion controls.

Google sign-in on Android also runs under Google's terms. This iPhone declaration check did not assess the Android library's categories, purposes or transmission timing; it is not an Android-wide no-analytics claim.

The information used by Havara

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.

From the first store build carrying native crash reporting, reports also include native crash stacks; device details (manufacturer, brand, model, processor and chipset, screen size and density, orientation, and whether it is an emulator); operating-system details, including whether the device appears rooted or jailbroken; memory, storage capacity and free space; battery level, charging state and temperature, and thermal state on iPhone; the device's language setting (locale) and time zone; its network connection type and whether it is online; when the device last started up; an installation identifier; on iPhone, a device-and-app hash derived from Apple's identifier for vendor, device model and app bundle id, sent whether signed in or not; on Android, which permissions the app requests and whether each is granted; whether the app was in the foreground and when it started; app memory and build type; app version and build metadata, including the over-the-air update id, runtime version and launch duration; diagnostic correlation metadata such as trace and span identifiers; and automatic app-lifecycle and device-state breadcrumbs, Android network-change breadcrumbs (network type, signal strength, upload and download bandwidth, and whether a VPN is active), and iPhone system-event breadcrumbs (keyboard shown or hidden, screenshot taken, time zone changes with the previous offset, and significant time changes such as midnight or daylight saving). iPhone native screen-view and touch breadcrumbs are disabled. Android also retains activity-lifecycle breadcrumbs and interaction breadcrumbs containing the view class and id, not its text. Android app-not-responding reports include the stacks of each app thread: on Android 11 and later when the system flags the app as frozen, and on Android 10 and earlier when the app's main thread has been blocked for five seconds. Available fields vary by platform and report. Performance tracing, profiling, replay, session tracking, console logs and HTTP breadcrumbs are disabled. While someone is signed in, the report's user field is the account id; Android reports also carry the installation identifier and iPhone reports the device-and-app hash, signed in or not. A report sent while no one is signed in, or before the app restores sign-in, can carry the installation identifier as its user id instead. The app asks Sentry not to infer or store an IP address for JavaScript and iPhone reports; Android native crash reports carry no IP address supplied by the app. Each connection still carries an address and Sentry can retain approximate geography. That approximate location can include city, region and country.

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 on that device or browser, 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).

Requests to join without an invitation code

When this feature is available and you choose Request to join, we process the community name, city, state and, when needed to distinguish matching communities, the community ZIP code. We do not use maps or GPS for this search. A match does not verify where you live or give you access.

You can give your home address and an optional unit to ask that community's board to verify your request. Only that community's board administrators can review these submitted fields. Other residents and members delegated to manage invitations or members cannot read them. You can obtain your own still-held fields in your personal-data export. The board chooses a registered home before approving you as a resident occupant. This does not record ownership.

We remove the submitted address and unit when the board approves or declines, when you withdraw a pending request, or when your account or the community is deleted. While a request is pending, we keep those fields so the board can review it. The request identity, community, status and times remain until account or community deletion. An approved member's assigned registered home follows the membership record's existing retention rules. Audit records contain request identifiers and actions, not the address you supplied, and follow the existing audit-record retention.

To limit spam, we record your account, the requested community and successful submission times. Entries older than seven days are removed on the next new request submission, or sooner when the account or community is deleted. We do not save your search terms in this submission ledger. You can check the request's status in the app and withdraw while it is pending. Existing membership welcome handling applies if the board approves you; submitted address and unit are not added to that welcome message.

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, and, if you signed in with Apple, ask Apple to end Havara's access to your Apple ID when you delete 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;
• run your community's security desk, if its board turns it on: let the people who staff the gate or front desk check guests in and hand over parcels, tell you when a parcel or your guest arrives, and keep your board's record of the devices and spaces assigned to each home;
• read the feedback you send us from Report a problem or Send feedback, and use it to fix and improve Havara;
• 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 Havara's optional PostHog product analytics is ever enabled, understand feature usage (opt-in per person); Google's iPhone sign-in library separately declares App Functionality and Analytics purposes (Section 3), separate from Havara's optional product analytics;
• 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 Havara product telemetry, withdrawable at any time; this means PostHog, not Google's separate library declarations in Section 3); 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 our global opt-out list. This stops vendor digests and some optional community emails sent to that address. Separate announcement copies and notification-fallback emails do not check this list and may still arrive according to your notification settings. Account security emails and required service notices are not turned off, and the opt-out does not change the settings stored on your profile. 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.
• 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. It may display Havara's logo and app-store badges using the same public image URLs for everyone. These URLs do not contain your email address, account ID or a unique identifier for an email opening. Your email client or its image proxy may request these images from our website host, Cloudflare, which receives the request information that client or proxy sends. We do not use these images to measure whether you opened a message. We do not rewrite links to route your click through us first, and the record we keep of a send holds no open, click or read information about a 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.

The shared email appearance described in Section 4.3 also applies to these vendor and quote-request emails.

4.3 Email about your account and your community

A welcome, staff join-request reminders, 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.

Shared appearance across Havara emails. Account emails, invitations, legal notices, community notices and updates, announcement copies, vendor and quote-request replies, operational alerts, and emails sent when a push notification cannot reach you may display Havara's logo and app-store badges from the same public image URLs for everyone. Your email client or its image proxy may request these images from our website host, Cloudflare, which receives the request information the client or proxy sends. The image URLs contain no email address, account ID or identifier for an email opening. We do not use these images to measure whether you opened a message. Where we already know the recipient's name, these emails may greet them by the first part of that name; for a welcome a board member sends by hand, the greeting may use the name they give. Account sign-in and security emails use a neutral greeting. This shared appearance also applies to the separate accommodation and delivery notices described below.

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, including a board setup welcome when you create one, and a counts-only reminder to staff who manage members when join requests have waited over 24 hours and no usable push token reaches their phone (at most once per community per 24 hours, skipped when Board and admin is muted), 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.

Accommodation requests are not member email. When a notification about one does not reach you, our push notification service emails a copy to the email address on your profile instead (Section 7): to a community administrator, that a member filed one; to the member who filed it, that the board asked for more information, recorded a decision or replied. Each carries the community's name and a link to the Havara console, never what anyone wrote: no title, no details, no question, no decision and no file name.

Delivery notices are not member email either. When your community's security desk logs a parcel for your home, or reminds your home about one still waiting, everyone who was seated on your home when the parcel was logged gets a notification, and our push notification service emails anyone of them it did not reach (Section 7). Someone seated on your home after the parcel was logged is not told about it. The email says only that a delivery arrived or is still waiting, with your community's name and a link to Havara: never the name on the label, the carrier, the tracking digits, where it is kept or the desk's note. Like the other copies that service sends, it can arrive during your quiet hours. When a guest arrives on a pass you made, only you get a notification, never an email. Delivery and guest notices have their own switch in the web console's notification settings, and in the phone app's from the version that adds it; switching them off stops the email too.

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 meet and confer request. In the web console, or in the app from version 2.3, you can ask your board in writing to meet you about a disagreement with the association. The request, the director your board names to meet you (with their name and their seat on the board, which you see because they act for your association), the meeting time and place, and the written resolution either of you proposes and the other confirms are visible only to you and to your community's administrators, and they are part of the community record your board can download, so do not repeat medical or disability details from an accommodation request in it. Havara charges nothing for it, and no amount can be attached to it in Havara; Havara does not stop your board charging a fee elsewhere, such as on your home's balance. Once you and the director have both confirmed a resolution, neither of you can change it in Havara; whether it binds anyone depends on your governing documents and state law. It is erased with the request when you delete your account; a copy your board downloaded is your association's. 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.

Accommodation requests. A request you make for a reasonable accommodation or modification because of a disability, its thread and its documents are visible only to you and to your community's administrators (a board member, an admin or a declarant, including a management company staffer the system has seated), also after you leave the community. No other member can see them: not a co-owner or tenant of your home, not a member your board lets handle requests or compliance, and not a vendor account. An administrator can open a document only while it is attached to your request, so once you remove it they cannot; you can remove a document at any time, after a decision too, and the decision stays. Administrators are told of a new request or a reply, and you of their questions and decisions, by a notification that carries none of what anyone wrote (Section 4.3). Requests are never in the community record download. Havara does not decide what the law requires: your association decides each request, and the console asks administrators to use what a request says only to decide it.

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 of messages and declared interests. Reports on chat messages and declared interests 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.

Reports on other content. In a phone app version offering Report or block on content pages, reports on other content go to Havara. Only you and Havara can read a report you file. Your community's moderators cannot read it or see who filed it. A report is not anonymous to Havara. It records the fields listed in Section 3, without attaching another copy of the source's words, medical details, photos or files. An email alert to Havara carries only the report identifier and the total number of open reports of this kind. It carries no source kind, content, reason, community or people. At most one alert is sent in each five-minute period; Havara checks the report queue even when an alert is not sent. Filing a report does not automatically remove the source. Section 10 explains which identifiers remain if the source or its author is removed.

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).

Architectural completion inspections. After approval, a community administrator can record the inspection date, whether the project is completed or was not built as approved, a note and one to six photos. You and your community administrators can read inspections on your request. New inspections require you to remain an approved member; you retain access to earlier inspections on your own request after leaving. This checks membership, not legal ownership or the work itself. Correcting an inspection adds another record; the earlier note, result and photos stay in history. Reopening an approval makes its inspections historical. A flagged result creates no violation or legal finding automatically. The console resizes photos to PNG before upload. The server checks file metadata and does not verify that uploaded files were resized. Havara does not automatically redact people or private information. Your personal download includes inspections on your requests and inspections you recorded; the community record includes its inspections. Photo files are separate from those JSON downloads. A record names the inspector while their account exists; deleting that account clears the inspector account link but keeps records and photos on another requester's retained request. The note, image, file metadata or a previously returned copy may still identify the inspector. Deleting the requester's account removes the request and inspections; unreferenced completion photos then become eligible for daily file cleanup after 24 hours or uploader deletion. Unattached completion uploads use that same rule; ordinary older ARC draft uploads keep their existing rule. Havara cannot recall photos already loaded on your device or downloaded copies after a permission change.

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, the security desk's records (guest passes without their codes, guest arrivals, parcels and their reminders, the shift log, vehicles, and devices and spaces), 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), accommodation requests, 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 owners' private notice delivery methods, primary and secondary destinations, representative contacts or preferred languages. Each export is recorded in the audit log.

Filtered board reports. The same community administrators can prepare narrower reports for violations, architectural requests, resident requests and registers, with names or Name unavailable, relevant titles, home/rule where applicable, kind/status and dates. The register report also shows the other party and whether each entry is Published or Draft. A report can be filtered and downloaded as CSV or printed or saved as PDF through the browser. It excludes narrative bodies, attachments, contact destinations, accommodation requests and financial statements; titles and names are still free text. Filters stay on the page, with no saved search history. Each successful preparation records the administrator, community, report kind and time in the existing activity log, not the filter words or file contents and not proof of saving. Havara stores no report file. Downloaded or printed copies are controlled by the association and cannot be recalled when a role changes or an account is deleted.

Board roster. Your board can list its seats (for example President or Treasurer), who holds each, the optional category it records for each seat (owner-elected or declarant-appointed) and the term dates. Every approved member of that community, tenants and vendor members included, can read each seat's title, recorded category, the holder's name and the term dates. The category is what your board records for the seat, independently of its holder; Havara does not verify an election. 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 and building safety registers (the Registers page). Your board can record the association's insurance policies, service contracts and bids, its reserve components (each with a replacement cost and a yearly reserve contribution the board typed), its building inspections and its recurring maintenance tasks. 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, bidder, engineer or vendor, the amounts and dates, the notes, and links to documents that open only if you can already read those documents. For an inspection that includes the day the report arrived, the day your board recorded delivering the inspector's summary to owners, and the repair status. Havara does not send an inspection's report or summary to anyone: your board publishes the entry and delivers the summary itself, and the date shown is the one your board recorded. Entries your board has not published or has removed, the reminders they put on the compliance calendar (including the reminder to deliver an inspection summary), 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 registers, so a bidder cannot read another bid. Havara does not know which policies, limits, contract terms, inspections or reserve figures your state or documents require; every figure is one your board entered, and neither the coverage check nor the component totals do any 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. Your primary instruction can be paper, email or both; without electronic consent it uses paper. An absent or unusable email leaves a postal fallback for your board. A secondary destination can request paper, email or both. Optional representative details are contact information only, and preferred language is an instruction to your board, not automatic translation. These choices remain until you clear them or the account or community is deleted. Leaving ends administrator access and keeps your private record. Your own data export includes the details; the community record excludes them. Your board can view and print current delivery instructions for a notice, with the time a courtesy email was accepted by the email provider, if one was. They are current choices, not a snapshot at the notice's original posting. A recorded send means provider acceptance, not receipt; its historical destination is not retained. Havara's courtesy email continues to use your account email and notification setting. Your board sends any custom or secondary email outside Havara.

Security desk. Your community's board can turn on a security desk for a gate, guardhouse or front desk. It is off until the board turns it on, and while it is off nobody can see its records in Havara, except that your own Download my data (Section 11) still includes the guest passes you created, with their codes, and the vehicles you registered, and your community's administrators can still read the audit log entries made when a device or space was assigned or ended (below). Everyone with an approved seat on your home (owners, co-owners, tenants and occupants, including an owner who rents the home out and does not live in it) sees the guest passes, vehicles, guest arrivals, parcels and ended devices and spaces recorded for your home since their own seat on it began, and the devices and spaces assigned to it now. So someone who moves in, or joins your household, later does not see what was recorded before they did, even while others stay seated on the home. Your community's administrators (a board member, an admin or a declarant, including a management company staffer the system has seated) and members given security desk access see them for every home, and the shift log; they still see the earlier records until they are deleted (Section 10). Assigning or ending a device or space also writes its name, and who assigned or ended it, to your community's audit log, but not the home it belongs to. Only your community's administrators can read the audit log. They can read these entries whether the desk is on or off, and the entries are kept for as long as the community exists (Section 10). A vendor account sees none of it, even if it is given that permission. Leaving your home cancels the guest passes you made for it and deletes the vehicles you registered to it. A pass code is something the desk types in to find the pass; it opens nothing. Havara does not ask for a gate code or PIN, and refuses a device or space name or detail that is only a 4 to 8 digit code, the shape of one; please don't type a code into a note, because a code written among other words is not caught. Havara takes no photo of a visitor or a parcel, records no ID number, sends no text messages and has no page for your guests.

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.

Private board discussion. The console has a separate text thread for current approved community administrators, including management administrators assigned to the community and declarants with that role. Other members cannot read it. Havara keeps each message, its author account link, its community and its posting time. Posting and removal add activity records with the actor, community, message identifier and time, without the message text. The thread does not send notifications or feed community chat or search. You can remove your own message while you hold an administrator role. Removal erases its text and keeps a dated placeholder and activity record. Losing that role ends thread access and self-service removal. Deleting your account clears your author account link but retains the text, which may still identify you. Community deletion removes the thread. Your personal download includes messages you wrote, even after leaving; a current administrator's community download includes the thread. Removed text is absent from both downloads. Havara cannot recall copies someone already received. Backups follow the existing backup schedule. For a privacy request after losing access, contact [email protected]. Formal decisions belong in Meetings.

Committees. Community administrators appoint existing approved community members, other than vendors, for dated committee terms. Havara keeps the committee name, purpose and optional descriptive Board label, plus each appointment's title, dates, member account, original membership and appointing account. The label and appointment grant no board role or architectural decision authority. Current appointees read the current roster and all committee messages and PDFs, including earlier content. Administrators see appointment history and may manage appointments without reading the content. Any administrator can appoint themselves and then read all earlier committee content.

Names on earlier appointments, messages and files resolve only through the original, still-approved membership. After departure, suspension or account deletion, other people see Former member. Reapproval of the same membership can resume an unended current term and its name. Leaving and rejoining requires a new appointment and does not restore the old name. Unlike Board seats, committee appointment history retains your account identifier after leaving. Account deletion clears the relational account and membership links but retains appointment titles, unremoved message text and PDFs, which may identify you. Other retained identifiers and previously received copies can connect records, so Former member is not a promise of anonymity. Supabase Storage retains uploader ownership metadata while a PDF remains stored.

Current appointees can remove their own messages and files. Any current community administrator can remove either by its activity reference without being appointed or reading it, including in a read-only community. Removal erases the message text, or the filename, storage path and byte count, and keeps a dated placeholder. A removed file becomes unavailable for new downloads; physical cleanup is pending the existing bounded server sweep. Ending or losing an appointment ends content access and your own removal controls. New appointees can read earlier content. All administrators see metadata-only activity records containing the actor, time and record identifier, even when they cannot open that committee. Your personal download includes your appointments and authored content records after leaving, plus metadata for committees you created. Administrator community downloads include committee metadata and appointment history, but messages and file records only for committees the exporter is currently appointed to. Neither includes PDF bytes, and erased content is absent. Community deletion removes the committee records and leaves unreferenced PDFs for cleanup. Saved, downloaded, exported and emailed copies cannot be recalled; backups follow the existing schedule. Contact [email protected] for a privacy request after access ends.

Committee emails require your separate, account-wide opt-in on Committees in Havara on the web, which starts off. Each sender must also explicitly request email for that message or file share. Resend receives the confirmed account email address, community identity and a fixed update with a link containing the community and committee identifiers. No committee name, person name, message text, filename or PDF bytes is sent. Only other current opted-in appointees qualify. Mail waits at least ten minutes, expires after three days and follows existing quiet hours and suppression controls. At most three committee emails per recipient in 24 hours use a separate limit from other community emails; excess updates are skipped. Havara retains the first attempted-send time with the private send record. Failed or unconfirmed sends can hold capacity until the update expires plus 24 hours, so fewer updates may arrive. Retries stop 23 hours after the first attempt to stay within the provider's duplicate-prevention window. A failed or conflicting retry may still represent an email already delivered. Recipients must qualify when the update is posted and at the final send check. An appointment that is no longer current, an opt-out or an erased source at that check stops delivery. An update already handed to the email provider cannot be recalled. The unsubscribe link switches this preference off; unsubscribe from all engagement email does too. Restore it separately on Committees on the web. Later appointments and opt-ins do not create new emails for earlier updates. There is no committee push notification.

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 [email protected]. 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 five 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, using sb-<project ref>-auth-token.

Beside it, the console keeps five preferences, and this is the complete list rather than a summary of it: which of your communities you last had open (havara.console.communityId), whether you left the side navigation expanded or collapsed (havara.nav.open), whether you dismissed the setup checklist for a community (setup_hidden:<community id>), a one-shot marker used to recover from a failed page load without looping (havara:chunk-reload in session storage), and whether you dismissed the notice about the privacy policy update effective October 30, 2026. The notice preference uses the key havara:privacy-notice:2026-10-30, holds the string dismissed, and is per browser. During sign-in itself the sign-in library also writes one short-lived verification value (sb-<project ref>-auth-token-code-verifier), 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 the original four 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 or advertising identifiers, and do not use device diagnostics or installation identifiers for advertising or cross-app profiling, 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 these vendors and their status). Google's iPhone sign-in library separately declares data for App Functionality and Analytics, as Section 3 explains, including the limits of our verification. This is separate from the PostHog choice; Android Google-library declarations were not assessed by the iPhone check. 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.

The console also keeps an optional analytics installation record, havara.analytics.install.v1, only when product analytics is enabled and you opt in. It holds a random installation identifier and a local account marker, never transmitted with the events. It is kept per browser tab in session storage, or tab memory when storage is unavailable, and removed on account change, sign-out, withdrawal or confirmed deletion. It is separate from the five preferences above.

8.1 Optional product analytics

Havara's optional PostHog product analytics is currently switched off in the phone app and console. Nothing is sent. Activation is planned for a date at least 30 days after the customer-admin notice is sent; that date has not been set. Publication, the notice, a recorded Privacy Policy Section 17 materiality decision and any required acceptance, verified project privacy settings and retention, and the full notice period must precede key placement. The Subprocessor List remains Conditional until a separate update after the first verified event.

Once activated, it is off unless you turn it on in Profile or Your account. It sends only the event names and scalar properties in the event list described below, a random installation identifier and a timestamp. It is not linked to your account: no account, community, conversation or content identifier, names, contact details, message text, page queries or fragments are sent. There is no identification call, person profile, autocapture or replay. PostHog receives the connection IP address; before activation its project must be set to discard client IP data and disable GeoIP enrichment. It must not infer a location from these events. This does not change Sentry, Cloudflare or Google's separate processing.

The phone keeps the installation identifier with a local account marker in device storage. The console uses session storage, with a tab-memory fallback. The account marker never leaves the device. The identifier is removed on sign-out, account change, consent withdrawal and confirmed account deletion, then recreated on the next permitted send. A session restore for the same account keeps it. Demo and mock activity is never sent. Previously sent events cannot be located by account for export or deletion, because there is no account linkage or PostHog deletion integration. They expire under the project's retention setting, which is unknown until project creation and must be verified and published before activation.

Permitted events and properties (all other events and properties are dropped):

9. What we DON'T do

The statements below draw on our codebase and, for Google's iPhone-library categories and purposes, its privacy declaration checked on October 16, 2026. The earlier code checks were: the advertising claim on 2026-08-20, the crash-telemetry claim on 2026-10-09, the cookie, analytics and payments claims on 2026-09-22, the AI-training claim on 2026-09-23, the location claim on 2026-10-09, the face, fingerprint and passcode claim on 2026-09-28, the outside-sources claim on 2026-10-14, 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 [email protected].

• 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 request GPS permission or read GPS coordinates. Google's iPhone sign-in library separately declares Coarse Location for App Functionality; Section 3 explains the declaration and the unverified transmission timing. The following describes the location records Havara itself uses. 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, the time zone and language setting native crash reports carry to Sentry (Section 3), 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 and files are accessed only when you actively pick or capture one to attach it. 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).
• Havara's optional product analytics is off; Google's iPhone sign-in library separately declares analytics. Section 3 describes the library's declarations and the limits of what we have verified. The PostHog choice does not control Google's library. This is not a claim that Android Google sign-in has no analytics. 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 describes the diagnostic categories. From the first store build carrying native crash reporting, reports also include native crash stacks; device details (manufacturer, brand, model, processor and chipset, screen size and density, orientation, and whether it is an emulator); operating-system details, including whether the device appears rooted or jailbroken; memory, storage capacity and free space; battery level, charging state and temperature, and thermal state on iPhone; the device's language setting (locale) and time zone; its network connection type and whether it is online; when the device last started up; an installation identifier; on iPhone, a device-and-app hash derived from Apple's identifier for vendor, device model and app bundle id, sent whether signed in or not; on Android, which permissions the app requests and whether each is granted; whether the app was in the foreground and when it started; app memory and build type; app version and build metadata, including the over-the-air update id, runtime version and launch duration; diagnostic correlation metadata such as trace and span identifiers; and automatic app-lifecycle and device-state breadcrumbs, Android network-change breadcrumbs (network type, signal strength, upload and download bandwidth, and whether a VPN is active), and iPhone system-event breadcrumbs (keyboard shown or hidden, screenshot taken, time zone changes with the previous offset, and significant time changes such as midnight or daylight saving). iPhone native screen-view and touch breadcrumbs are disabled. Android also retains activity-lifecycle breadcrumbs and interaction breadcrumbs containing the view class and id, not its text. Android app-not-responding reports include the stacks of each app thread: on Android 11 and later when the system flags the app as frozen, and on Android 10 and earlier when the app's main thread has been blocked for five seconds. Available fields vary by platform and report. Performance tracing, profiling, replay, session tracking, console logs and HTTP breadcrumbs are disabled. While someone is signed in, the report's user field is the account id; Android reports also carry the installation identifier and iPhone reports the device-and-app hash, signed in or not. A report sent while no one is signed in, or before the app restores sign-in, can carry the installation identifier as its user id instead. The app asks Sentry not to infer or store an IP address for JavaScript and iPhone reports; Android native crash reports carry no IP address supplied by the app. Each connection still carries an address and Sentry can retain approximate geography. That approximate location can include city, region and country.
• 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, or from Apple or Google when you choose to sign in with them (Section 3), and, if your community runs a security desk, from the people who staff it, who type names for guests, walk-in visitors and parcels (Section 3).
• 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.

Google's separately held library data (Section 3). No retention period has been verified for the data Google's iPhone sign-in library declares. Google holds any such records under its own terms, outside Havara's database and local sign-in-token lifecycle. Signing out, deleting a Havara account or clearing the local sign-in record does not guarantee deletion of those records. Google's Privacy Policy describes its own controls.

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.

Also in your personal download: your bulletin acknowledgements; chat reactions, mentions of you in chats you can still read (excluding held messages), read cursors, direct-chat participation and group memberships; metadata and storage paths for files attached to your own messages; the alerts you raised; your quote requests and broadcasts, including the contact details you supplied and vendors' replies; your recommendations and declared interests; reports you filed and their status, your outgoing block list and feedback; your refused Ask questions and dates, without classifier categories; your current board seats, committee appointments, your own committee messages and file metadata, committees you created (their identifiers and creation date), and your own board discussion messages; your agenda proposals and requests to speak; the items withheld from your own records requests and their reasons; your notice delivery results and chat-digest dates; the kinds, status and dates of emails queued for you, without their internal payload or delivery diagnostics; your organization memberships and community assignments; your recorded native membership removals; your own community-creation, invitation, community lookup, profile-read, document-processing, Ask and Apple-token storage attempt history; safe sign-in account details and Apple or Google sign-in identifiers; and the status and dates of Apple access-revocation work still linked to your account, without any credential. Your commercial-email suppression status and source are included only when they match your confirmed sign-in email, never the editable email on your profile. Current board seats no longer identify you after that membership ends.

Excluded from the personal download: sign-in credentials, password hashes, Apple tokens, raw sign-in profile metadata (including Google's photo link), invitation codes and vendor action tokens; other people's reports, who blocked you, classifier categories, moderators' notes, complaint snapshots and the protected reasons for removing a declared interest, because these can reveal reporters or other people's private information; internal email payloads, provider identifiers and delivery errors; file contents (the JSON contains metadata, not the files); shared association records such as notices and their history, polls, meetings, minutes, board motions, director votes and consents, action items, packets, compliance deadlines and completions, budgets, dues and ledger records, registers, directory businesses, group definitions and shared audit history. Being the staff member who entered or approved a shared record does not make the other people's information in it yours to download. Desk entries, parcels, devices, spaces and shift notes can concern other occupants or visitors, so they are excluded; the guest passes you created and vehicles you registered remain included. Ask your board for community records through a records request. Operational security counters and request logs, provider-held sign-in-library or diagnostic records, and separately collected pre-account inquiries are outside the self-serve file. Contact us for an access request that requires identity verification or protection of another person's information. These exclusions do not remove that right.

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 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. From version 2.3 of the phone app you can also continue with Apple (on iPhone) or Google (on iPhone and Android): the provider confirms who you are and gives the app a signed token, which our server checks against that provider's published keys before signing you in. The web console offers neither yet. If the provider confirms an email address that already has a Havara account, the sign-in is added to that account; if it gives a different address, such as an Apple private relay address, you get a new, separate account with no communities, and Havara cannot yet join the two.
• 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 and run Sign in with Apple and Google sign-in, 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 work that out state by 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.

An accommodation request (Section 5) can hold information about a disability, which is sensitive personal information. We use it only so your community's administrators can handle that request, and we show it to no one else.

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.
• Notice contacts: an owner or their board may record a secondary postal or email destination and optional representative name, postal address and email, including someone who is not a member. Only the owner and community administrators can read them while the owner is a member; the board can print the instructions. A representative is a contact, not an automatic recipient unless separately named in the secondary destinations. Havara does not contact these people or verify representative status.
• Guests, visitors and people who collect a parcel: if your community runs a security desk, a resident or the people who staff the desk may type your name, and sometimes your vehicle's plate, on a guest pass, the entry log or a parcel record. Havara never contacts you about it. Once recorded, a name or plate cannot be changed by anyone in your community, and neither can a closed parcel. Someone seated on the home who can see a guest pass can cancel it, and the people who staff the desk can mark a waiting parcel collected or returned to the sender. Each record is deleted on the schedule in Section 10.
• 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 can edit most of these records. A security desk record is the exception: your board can do only what the bullet above describes, so correcting a name, a plate or a closed parcel needs our help through [email protected]. If the board 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 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 [email protected]. For material changes we will give advance notice by email where enabled, on havara.app and in the web console, and the current versions of the Havara app and the web console will ask you to accept the new version before you continue using them (your acceptance history is versioned and included in your data export). An older version of the app that cannot show that request keeps working until you update it, and then asks.

18. Contact

Havara LLC, a Georgia limited liability company

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.