Havara Privacy Policy

Effective August 28, 2026

1. At a glance

• We collect what you give us: your account details, the content you post, and the records your board enters (memberships, dues standing, violation cases).
• Your content is visible to the audience you post it to: a channel, a group, a direct message, or the board. Database-level security enforces this, not app-level promises.
• Your board sees more than other members do: violation cases, all units' dues standing, join requests, and moderation reports. Section 5 lists exactly what.
• Poll votes are stored linked to your account even on "anonymous" polls, but the app only ever shows counts, to everyone, including the board.
• AI "Ask" answers come from two vendors: OpenAI searches your community's documents; Anthropic writes the cited answer. Neither is told who asked, and neither trains on your data by default.
• Push notifications show message previews by default. You can turn previews off in one toggle.
• We don't sell data, run ad networks, track your location, or read your contacts. We do sell paid placement to vendors, labelled as an advert wherever it appears. Section 9 is the full list of things we don't do, verified against our code.
• If you ask a vendor for a quote and your board passes it on, that business gets your phone number and email address. The form asks you for them and says so before you send. Section 4.2 explains it, including how long the vendor's link keeps working and how a board takes it back. Nothing has been sent yet.
• Board members will receive a vendor email we are paid to send. It lists the vendors who have bought placement in their community, it carries an unsubscribe link, and it goes to board members only, never to residents. Nothing has been sent to anyone yet. Section 4.1 explains it.
• Deleting your account deletes your personal records but anonymizes content you authored: your messages stay in the thread, attributed to an anonymous "Member."
• You can download all your data yourself, in the app, any time.
• Analytics is switched off in the shipping app, and stays opt-in per person if we ever enable it. 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. 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.

2. Who we are and what this covers

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

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

This policy covers three surfaces:

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

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

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

3. What we collect

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

We collect limited technical information automatically (device push token, session tokens) 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 and carry your account's user id. We do not collect precise location, contacts, biometrics, or financial-account numbers (see Section 9).

4. How we use your information

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

We use the information above to:

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

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

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

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

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

Havara sells paid placement to local businesses inside a community's vendor directory. A paid placement is labelled as an advert everywhere it appears, and it carries this disclosure word for word:

Paid placement. We confirm the business is real and insured. We do not vet their work.

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

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

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

4.2 Quote requests, and the two emails they involve

Your phone number and email go to the business your board passes your request to. Nothing has been sent yet.

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 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 neighbour'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.

Nothing has been sent. No quote request has been relayed by email and no listing invitation has gone out, because the function that sends them is not deployed. We are describing this before it happens rather than after.

5. Who can see what

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

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

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

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

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

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

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

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

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

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

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

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

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

6. The AI "Ask" feature

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

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

What happens when you ask a question:

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

Separately, at document-upload time: if a board uploads a scanned or image-only PDF (no text layer), the file is sent to 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 immediately afterwards. The text Textract returns is stored so the same file is never scanned twice; it is deleted when no document refers to 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) and your question text. 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.
• No account identifiers (name, email, user ID) are included in the request body sent to either vendor.
• Per OpenAI's published API data policy (verified 2026-07-12), API data is not used to train OpenAI models unless the customer opts in (we have not), and abuse-monitoring logs are retained up to 30 days.
• Anthropic's commercial terms prohibit training models on customer content (verified 2026-07-15).

What Ask never does:

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

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

7. Who we share data with

A small set of infrastructure vendors under contract, each receiving only what its job needs, plus 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, not a code change. If we enable one, we will update our subprocessor list first and, where the change is material, notify you per Section 17. We have broken that commitment twice and it is fair that you know from this page rather than from a changelog. 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.

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

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

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

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

8. Cookies and tracking

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

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

Staying signed in, and the four small things kept beside it. The mobile app and the web console each store the session token issued when you sign in. The mobile app holds it in the app's own on-device storage. The web console holds it in your browser's local storage for app.havara.app.

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

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

No advertising, no cross-site tracking, no third-party analytics today. We use no pixels, beacons, device fingerprinting, or advertising identifiers, and we do not follow you across other websites. There are no ad SDKs and no tracking domains in the app or on the site. Our analytics integration 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 (Section 7 lists both and their status). Section 9 is the full list of things we don't do.

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

9. What we DON'T do

Each absence claim below was verified against our codebase, not just asserted: the cookie claim on 2026-07-15, the advertising claim on 2026-08-20, the crash-telemetry claim on 2026-08-28, the rest on 2026-07-12. Two claims in this list have needed correction after the fact, the advertising claim and the crash-telemetry claim, and both corrections are dated in the changelog below.

• We don't sell your personal information, to anyone, ever.
• We don't use cookies to track you. The havara.app site sets no cookies at all, and the app and web console keep you signed in with a token stored on your device rather than a tracking cookie. Section 8 has the per-surface detail.
• We don't run 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 labelled 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 track your location. The app contains no GPS/location code and requests no location permission. The only "location" data we hold is text someone typed (an event's venue, an optional note on an alert or violation case).
• We don't read your contacts, your calendar, or your photo library. Contacts are never accessed; the calendar permission is used only to write an event when you tap "Add to calendar"; photos are accessed only when you actively pick or capture one for chat. Camera captures for chat are not saved to your camera roll.
• We don't process payments. Dues standing is a read-only record your board types in. There is no card, bank, ACH, or payment SDK anywhere in the product, and we will never ask for payment details in chat or email.
• We don't train AI models on your data, and our AI vendors don't either by default. OpenAI's API terms exclude training on API data (verified 2026-07-12), and Anthropic's commercial terms prohibit training on customer content (verified 2026-07-15).
• We don't send third-party analytics today, and we do send crash reports. The analytics integration ships disabled and additionally requires your individual opt-in even if enabled. Crash reporting to Sentry is on. Section 3 lists in full what a report contains; the short version is the error and where it happened, plus your account's user id and which build it came from. It never carries message content, your email, your phone number or your push token.
• We don't compile data about you from public records or other outside sources. Everything we hold came from you, your board, or your device.
• We don't show board members your DMs or your individual poll votes. See Section 5.
• We don't use dark patterns on deletion. Account deletion is in the app, self-serve, and immediate.

10. How long we keep data

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

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

11. Your rights and controls

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

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

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

12. Security

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

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

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

13. Where your data lives, and international transfers

All app data is stored in a single Supabase project hosted in AWS region us-east-2 (US East, Ohio, United States). Our AI, push, email, and crash-reporting vendors 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.

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

14. US state privacy rights

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

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

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

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

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

15. Children and eligibility

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

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

16. Notice to residents, household members, and invitees

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

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

• Invitations: a board member may enter your email address to invite you. It is used to send/track the invitation and is not used for marketing.
• Unit and household records: your board may record the unit you live in and your household role (primary owner, co-owner, tenant, occupant).
• Dues standing: your board may record your unit's dues status.
• Violation cases: your board may open a rule-enforcement case that names you.
• Vendor contacts: if you are a vendor, a board may add your business contact details to its community's vendor directory. A board may also email you a resident's quote request, which carries that resident's phone number and email address, and may email you a link to confirm your own listing. You can ask the board, or us, to remove your business from a directory.

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

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

17. Changes to this policy

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

18. Contact

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

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