Skip to main content

Legal

Privacy Policy

Version 1.13.0 · Last updated November 5, 2026 · Effective October 21, 2026


In plain language

This is the whole policy in ten sentences. The detail follows, and where the two differ, the detail governs.

  1. We collect what the product needs to work — your name and email, the home you tell us about, the projects you post, the messages you send, and the documents you upload.
  2. We do not sell your data, and we never will. No advertising, no data brokers, no pay-to-rank in anyone's feed.
  3. Your eznest account data is stored in Canada — Montreal, on encrypted storage. Some services process limited information in the United States: Clerk for sign-in, Amazon Bedrock when you use the AI assistant, Twilio if you turn on visit texts, Apple for iPhone push notifications, Google for homeowner website address entry, provider business listings and public business-page maps, and DigiCert for a fingerprint of a document's digital signature. If a business you hire connects its own QuickBooks Online books, Intuit in the United States will receive your household's name and the text of the project you posted when that business syncs an invoice; eznest tells you at least 30 days before it switches that connection on, and §5.2 says exactly what Intuit receives. Open-Meteo, in Switzerland with servers in the European Union and the United States, receives your home's city and its coordinates when the Home weather card shows a forecast or someone adds one of its weather alerts as a to-do. Mail you exchange with our eznest.ca addresses is held separately in Google Workspace and may be stored and processed in the United States and other countries. §5.2 says exactly what each receives.
  4. eznest AI runs on Amazon Bedrock in the United States (each request is sent to us-east-1 and AWS may serve it from us-east-1, us-east-2 or us-west-2), and it will not process your information until you switch it on. Nothing you say to eznest AI trains any AI model.
  5. We can read your messages and your documents. They are encrypted on our disks, not from us. Anyone who tells you a marketplace can't see your messages is describing a different product.
  6. We record optional usage signals by default so the product can get better at helping you; you can switch those signals off. A limited signed-in operational request record is separate and required (§3.5). We only use the optional signals to tailor what you see if you separately turn personalization on.
  7. You can export your data and close your account yourself, at any time, without asking us or paying a fee.
  8. We keep your data until you delete it. Apart from the records listed in §8.2, such as a crew’s photograph of a visit and the record of your signed-in requests, we do not have automatic expiry clocks on your account content, and we would rather say so than invent one. When a file is deleted or replaced, our storage keeps the earlier copy for 365 days before removing it (§8.2). Your conversations with eznest AI have a rule of their own, six months after your last message, but eznest does not apply it automatically yet (§3.6, §8.2).
  9. If something goes wrong with your information, we write it down — every incident, whatever its size — and we tell you and the regulators when the law requires it.
  10. You can complain to us, and then to the Privacy Commissioner of Canada if we have not put it right.

1. Who we are and what this covers

Eznest Technologies Inc. ("eznest", "we", "us") is a corporation incorporated under the Canada Business Corporations Act on 13 June 2026, corporation number 1801532-5, with its registered office at 226 Kinloch Court, Nepean, Ontario K2J 5S9, Canada.

We operate the eznest platform: a home-services marketplace connecting homeowners with service providers, together with a set of tools for keeping track of a home ("the Platform").

We are the organisation accountable for the personal information described in this policy.

This policy covers the personal information we handle through:

  • the eznest website and web application at eznest.ca;
  • the eznest mobile applications;
  • eznest AI, the assistant built into both;
  • our email and messaging to you.

It applies to homeowners and household members, service providers and their staff, and anyone who contacts us. Where we say "you", we mean whichever of those you are.

What this does not cover. It does not cover what a service provider does with information you give them directly, or what they do with your information after you hire them — they are an independent business and their own privacy practices are their responsibility, not ours. It does not cover other websites we link to.

The Platform is in an invite-only beta

Accounts today can only be created with an invitation code. That bounds who this policy currently applies to, and it means some capabilities described here as available are available to a small group. Where something is built but switched off, this policy says so plainly rather than describing it as though it were running.


2. Privacy Officer

Our Privacy Officer is accountable for the personal information under our control and for our compliance with this policy.

Niruban Kandasamy, Privacy Officer Eznest Technologies Inc. 226 Kinloch Court, Nepean, Ontario K2J 5S9, Canada privacy@eznest.ca

Write to that address for anything in this policy: a question, an access request, a correction, a deletion, a complaint, or to tell us something has gone wrong. It reaches a person, not a queue.

Our eznest.ca mailboxes, including privacy@eznest.ca and support@eznest.ca, are hosted by Google Workspace (Gmail), provided by Google LLC. Google receives the sender and recipient details, subject, message text and any attachments you send, and the replies we send back. See §5.2 and §8.1 for where this correspondence may be stored and processed.


3. What we collect

We have grouped this by where it comes from, because that is the question people actually ask.

3.1 Your account

WhatNotes
Email address, nameBoth required. In production these come from your sign-in provider (Clerk) rather than being typed into eznest.
Phone numberOptional. Only if you add it to your profile — we never ask for it at sign-up.
RoleHomeowner, provider, or staff.
Invitation code, and the IP address you redeemed it fromWhile the beta is invite-only.
Identity link to your sign-in providerThe provider's identifier for you, plus the email and verification status they report.

We do not hold your password. Clerk is our sole authenticator in production, so the credential you type lives with them, not with us. The password field on our own user records holds a random value that cannot be used to sign in.

Multi-factor authentication is not available today. We would rather tell you that than let you assume otherwise.

3.2 Your home and your household

All of this is optional, all of it is entered by you, and none of it is required to use the marketplace:

  • the address, city, province and postal code of your home, plus property type, year built and floor area;
  • purchase price and mortgage balance, if you choose to record them;
  • rooms, appliances, systems, finishes, belongings (including serial numbers and purchase value), warranties, maintenance schedules and service history;
  • vehicles and machines you record in Garage, including their make, model and year, odometer and hour-meter readings, parts and stock changes, maintenance plans, service records, reminders and private notes;
  • your own list of trusted contractors, including their names and contact details;
  • household members, and for a child or teen account, an optional date of birth, a guardian link, and the spending and access limits the guardian sets.

Address entry in the website uses Google Places. In the website's Add a home and new-project forms, when you type an address, eznest's server in Canada sends Google the address text you have typed starting with the third character, whether or not you pick a suggestion. If you pick a suggestion, the server sends Google the selected place ID and receives address details, including latitude and longitude. The new-project form saves those coordinates on the property record. Google does not receive your browser IP address on this address-entry path, and we do not send Google your eznest account identifier or other homeowner records with it.

3.3 What you create on the Platform

Projects (title and description are required; budget, timeline, urgency and location are optional), bids and proposals, quotes and cover notes, appointments including the visit address, reviews, disputes, support tickets, reports of other users' content, and your personal to-dos, notes, reminders, checklists and expenses.

Support requests. A support request keeps what you wrote, the replies, and up to three images you choose to attach to the request or to one of your replies; the support team can attach images to its replies too. The eznest apps and website may also send, with a request, the platform they are running on (iPhone, Android or the website), the version of the app and the version of the operating system, so support can see the build you were using. We keep nothing else about your device: not its model, its identifiers, its settings or its location. An image is stored privately, in the same encrypted storage in Montreal as your other uploads. Before we keep it we check that it is a picture and run a malware scan, and if it fails either check we do not keep it. It opens only through a link that is generated fresh each time the request is read and stops working after about fifteen minutes. Only you and eznest support staff can read the request, its images and those three details. We keep an image exactly as it reaches us, so if your phone wrote its location or device details into the picture, they are still in the file support opens; remove what you do not want to share before you send it. Closing your account does not delete support requests, their replies or their images today (§7.4 lists what it does erase), and we have not set a period for how long they are kept; write to the Privacy Officer (§14) if you want to ask about one.

Messages between you and a provider are stored as ordinary text on our servers. They are encrypted on the disks they sit on, and access is restricted, but they are readable by us. They are not end-to-end encrypted, and we will not pretend otherwise.

Private calendar links. If you make a private link that puts your visits in a calendar of your choice (§5.3), we keep a record of it: a one-way fingerprint of the link rather than the link itself, whether it is for a household's visits or for your own assigned visits, which household or business membership it belongs to, when you made it, and when you revoked or replaced it.

3.4 Files you upload

Documents, project photos, provider portfolio images and evidence attached to a job are stored in Amazon S3 in Montreal, on a versioned, server-side-encrypted bucket with public access blocked. We also extract the text of documents you upload and store it in our database, so the assistant and search can find things inside them. Extraction runs on our own servers; no third-party OCR service sees your files.

When you file an uploaded file in your home's Documents vault, we scan it for malware. A file with a detected threat, or one that cannot be checked at that time, is refused and is not added to your documents. This check currently applies to the home Documents vault; it does not claim that every other file-upload path has the same protection.

3.5 What we observe

WhatNotes
Sign-in sessionsThe IP address and browser user-agent for each session, plus when it was issued, when it expires, and whether it has been revoked.
Failed sign-in attemptsEmail and source IP, for abuse protection.
Usage signalsWhich parts of the product you use, recorded to make the product better at helping you. On by default; you can switch it off — see §7.3.
Signed-in account interactionsFor a signed-in homeowner account, each API request records the time, HTTP method, route template (never a record ID from the URL), response status, duration, request ID, source IP and browser or app user-agent. We use this operational metadata to run and diagnose the service and understand feature use. The code default is to keep it for 90 days; the configured period may differ. It is deleted when the account is closed. This record is required to operate the signed-in service and is separate from the optional usage signals controlled in §7.3. Request and response bodies are not recorded in it.
Firewall request logThe firewall in front of eznest’s servers (AWS WAF) writes a log of the requests it checks, whether or not you are signed in. The firewall request log stores the IP address and browser or app user-agent of every request it records, with the time, the HTTP method, the request path and what the firewall decided, for 90 days by default (the configured period may differ), in Canada (Montreal), and is then deleted automatically. Before it is stored, the request headers that carry a password or secret, your cookies, the address you came from and the whole query string (the part of a web address after a question mark) are blanked, and a request to a private link (a calendar link, a signing link, an invoice link, or a claim or invitation page) is not recorded in it at all. Request bodies are not recorded. We use it to investigate attacks, and a separate alarm on the firewall’s count of blocked requests tells us when many are blocked at once.
Reports that a business listing is not that businessAnyone can report a public business listing without signing in (This isn't my business on the claim page, or Not your business? Ask us to remove this listing on the listing's page). We keep the IP address the report came from, the browser user-agent, and the time it was made, as evidence of the request so someone at eznest can judge it, and to limit abuse. The report is not linked to an account. It is kept with the listing's record and deleted three years after the report was made. For a business we have never contacted it can go sooner: the one-year removal of never-contacted business contact records (§8.2) deletes the report with the listing once someone at eznest has dismissed the report and the year since the business's details were collected has passed.
Requests to claim a business listing when its email address cannot be usedSomeone who says they act for a listed business, and whose email address on the listing is missing or cannot be used, can ask us to let them claim it, without signing in. We keep the name and email address they give us for our reply; the address the listing had; the registry, registration number and registered name they give; their role and the document or record they say shows that they act for the business (text they write); the IP address and browser user-agent the request came from; and the times. When someone at eznest decides the request, we also keep who decided, the reason they gave and what they checked. The request is not linked to an account, and typing an email address proves nothing: someone at eznest reads it and checks the registry themselves, and nothing about the listing changes and no one is given access until they decide. Only eznest administrators see it. A request still waiting is kept until someone decides it; a decided request is deleted three years after the decision, or sooner together with a never-contacted listing when the one-year removal in §8.2 removes the listing. If the listing was declined, the copy of its old email address kept on the request is removed with the listing's own address (§8.2).
Operations presenceWe keep your internal account identifier and the time of your last recorded signed-in request in Redis so authorized eznest staff can see which accounts made a request in the last five minutes in the operations console. This shows recent requests, not whether you are online. The individual presence value expires six minutes after your last recorded request. A matching index is pruned as requests arrive and expires six minutes after the last presence write. This operational record is separate from the optional usage signals controlled in §7.3.
Mobile device tokensThe iPhone app registers a device token with Apple and sends the notification token to eznest so push notifications can be delivered. eznest sends Apple that token and the notification text, which may name a visit or project. Android push through Firebase remains off because its production project and service-account key are not configured. Closing the account deletes eznest's stored token registration; this does not claim deletion from Apple or Google.
Audit recordsAn append-only record of privileged actions taken on the Platform. Its detail field can contain email addresses.

What we do not do here matters as much. There is no third-party analytics library, advertising tag, crash-reporting SDK, tag manager or tracking pixel in the eznest website or apps. We do not keep a web-server access log of our own that records who read which page; the firewall request log above is the one record of requests outside the signed-in service, and the signed-in account-interaction record described above is an intentional first-party record with a route template rather than a raw URL. There is nothing here that follows you to another website.

3.6 Your conversations with eznest AI

If you switch eznest AI on (§6), we store the whole conversation: every message you send, every reply, and every action eznest AI took on your behalf including what it looked up and what it found. We also keep a short profile of you that eznest AI writes for itself — a summary of who you are, your home, what you have going on, and what you have told it you prefer — which it re-reads at the start of every later conversation. We record how much AI usage your account has consumed.

How long we keep it. Our rule is that a conversation is kept for six months after your last message in it, or until you delete it if that comes sooner. The profile, and the short notes eznest AI pins in it about what you prefer, are kept only as long as the conversations they were built from. The same rule applies to everyone, including members in Quebec. eznest does not apply this rule automatically yet. Until it does, we keep your conversations and your profile until you delete them with the control described in §6.6 or close your account, and §8.2 repeats this. What the removal will not reach. When it runs, it removes a conversation that is six months past your last message and, with it, the profile and pinned notes of a person who then has no conversation left. A profile that already has no conversation when it runs is not found by it, so it stays until you delete it with the control in §6.6 or close your account (§7.4). A separate cleanup of profiles in that position has not been built or run.

3.7 If you use the personal-finances tools

These are optional and separate from the marketplace. If you use them, we store the bank statements you import — the account name and institution, a masked account number, balances, and every transaction with its description, date and amount. The raw text of an imported statement is encrypted with a key held in AWS Secrets Manager.

The statement file is kept, not discarded. The statement file you upload is encrypted by eznest, with the same key that protects the extracted text, before it is stored in the Amazon S3 storage in Montreal that holds your other uploads (§3.4). It stays there until you delete the imported statement or close your account (§7.4). Like other files in that storage, an earlier copy of a statement file that was deleted or replaced stays for 365 days before it is removed (§8.2).

3.8 If you are a service provider

Your business profile: display name, legal business name, headline, biography, logo, service area (city, province, radius and coordinates), categories and rate cards. Your verification documents and the licence numbers your business gives us. We record and show those numbers; we do not currently check them with a regulator.

The eznest profile itself asks for business records — business registration, insurance certificates, trade certifications and the licence numbers your business gives us — and does not ask you to upload an individual's government identification to eznest. When Stripe Connect is enabled for a provider business, Stripe may require individual identity, beneficial-owner, bank and verification-document information to open or maintain the connected account. Stripe collects that information directly inside its hosted pages or Stripe-controlled embedded frames; eznest receives the account's verification status and requirements, not the identity documents or bank credentials.

Voice memos in the provider mobile app. During a site visit, the provider app can record a short audio note against the visit. Two things must be true first: you have granted the app microphone access, and the visit carries recording consent — the app refuses to record audio or video until consent has been recorded on the visit's Overview tab, because the person being recorded may not be you. The recording is written to the app's protected storage on your device and kept there with the visit. It is not uploaded to eznest. The app's visit-sync path that could carry visit media to our servers was retired on 2026-09-02; the production service ran a build that still exposed that path between 2026-08-26 and 2026-09-04, but the app had no App Store or TestFlight distribution in that window and a read-only census of production on 2026-09-01 found no projects at all, so there was nothing a visit could have been finalized against and no voice memo reached us. No other path in the app sends audio anywhere; we therefore do not receive, store, transcribe or otherwise process a voice memo, and deleting the app deletes them. If that changes, this policy and the App Store privacy label will say so before it does.

If you use the provider CRM, we store the contact details you enter for your own clients, including people who have never used eznest. You are responsible for having a basis to hold that information; we hold it for you as your service provider.

3.9 People who are not eznest users

We hold some personal information about people who never signed up:

  • contacts a provider enters into their own CRM;
  • contractors a homeowner adds to their trusted-contractor list;
  • people who email our business mailboxes, including their contact details, message and attachments;
  • business contact information for Ontario service businesses collected from public sources for outreach, under Canada's anti-spam legislation, with an opt-out list we honour permanently (see Businesses we list from public sources below);
  • customers who book a business without an account; and
  • people a household or a business invites by email.

Customers who book a business without an account. A business can take bookings through its profile page and its public booking page on eznest, or through the booking widget on its own website, and it can also log a booking itself, for example after a phone call. You do not need an account to ask for a booking. We keep, for the business you booked and for as long as the booking record exists:

  • your name, which is required;
  • your email address and phone number, if you give them;
  • the service you asked for, the time you prefer and any notes you write;
  • the booking's status, and where it came from (the business's booking page, its eznest profile page, its widget, or entered by the business) and any tracking tags on the link you followed;
  • for a booking you make yourself, a record that you agreed to submit it: the time, where it was made from, and the internet address (IP address) it was sent from.

We use these details to pass your request to the business, to let the business answer and manage the booking, and to show the business where its requests come from. If you, or the business that took your booking, gave us your email address, we also send you one email naming the business and the service, inviting you to sign up and claim the booking, with a link to stop us writing to that address. We do not create an account for you from your email address; an account exists only if you sign up. The business is an independent business and keeps its own copy of what it sees; §1 explains that its practices are its own responsibility.

People a household or a business invites by email. A household can invite someone to join it, or invite a friend to eznest through Refer a friend, and a business can invite a customer, a team member or a contact to eznest, to a seasonal plan or to claim a record the business holds for them. We keep the email address the invitation was sent to, who sent it, the role or record it offers, when it was sent and when it expires, and whether and when it was used. An invitation sent through Refer a friend also records the household that sent it. If the person who invites you types your name, we use it in the invitation email and do not keep it. We use these details to send the invitation, to make sure only the person it was written for can accept it, and, for Refer a friend, to give the household that invited you its referral credits once you set up your own home on eznest. We do not use them to send you anything else. If you decline, ignore it or it expires, we do not make an account for you.

Businesses we list from public sources. For an Ontario service business that has not joined eznest, we keep a business record. It holds the business's name, address and category; the phone number, website and email address the business published, with where and when we collected each; and the evidence for any email we sent it. If the business is a sole proprietor, some of this is personal information about one person. The record can appear as a public business listing on eznest, and it is how we write to the business, under Canada's anti-spam legislation, to invite it to claim that listing. Every such email names eznest and carries a link that stops them.

A business, or the person behind it, can get out in three ways. The first two take effect at once; the third when a person at eznest acts on your message, which we aim to do within the 30 days in §7.7:

  • The link in the email. From that moment we write nothing more to that address, by any route, and the address stays on our opt-out list permanently.
  • The listing's own controls (This isn't my business on the claim page, Not your business? Ask us to remove this listing on the listing's page; §3.5). We record the report and stop writing to the business at once. The listing stays visible until someone at eznest decides; if they agree, the listing is hidden.
  • Writing to the Privacy Officer at privacy@eznest.ca. A person at eznest can suppress the listing: it leaves the public listings, we write no more, and the business's email address and phone number go on the opt-out list.

What is removed, when, and what is kept. Removal is not a single delete. Our systems run a removal each night, and it works to these periods (the table in §8.2 repeats them):

  • A record we have never written to, never had claimed, never decided on and never checked, is deleted whole, with the images we host for it, one year after we collected it. A record that we have written to, or that our automatic checks against business registers and the business's own website have already run on, is not on this one-year clock.
  • When a record is marked as declined, we blank its email address, phone number and contact name 90 days after its last update. The business name and city stay, so that we can count what happened.
  • Our records of the emails we sent and the evidence behind them are deleted three years after they were made, and a withdrawn consent three years after it was withdrawn.
  • The opt-out entry (email address or phone number) is kept permanently. That is the point of it.
  • A suppressed or hidden listing is kept, with the details it held, and has no removal date yet. We keep it so that a later import does not collect the same business again. We have not built an automatic full deletion of it. If you want it deleted in full, ask the Privacy Officer, who will tell you what was removed and what was kept, and why (§7.7).

Asking us to remove your details. Write to the Privacy Officer at privacy@eznest.ca, from the email address on the booking or invitation if you can, and tell us the business or the person who booked or invited you. A person at eznest, not a queue, reads it, tells you what we hold and aims to answer within the 30 days in §7.7. Where we remove something, we say what; where we keep something, we say what and why. A business that holds its own copy must be asked separately.

If you are one of the other people listed here and want to know what we hold or want it removed, write to the same address. We will act on it whether or not you have an account.

3.10 What we deliberately do not collect

  • Payment card numbers or bank account details. We do not take payments today — the payments integration exists but is switched off, so no card, no bank account and no payment-processor customer record is created for you.
  • Government identification, of anyone.
  • Voice or audio, on our servers. eznest AI's voice features are built but switched off in production, so no audio reaches us through eznest AI. The provider mobile app can record a voice memo during a visit; it stays on the device and is never sent to us — §3.8 says exactly what happens to it.
  • Precise or continuous location. The mobile app can record a single coarse check-in location as proof a provider attended a visit, and that is the only location capture in the product.
  • Race, religion, political opinion, health information, sexual orientation, or biometric data. We have no field for any of them.

4. Why we use it

We use your personal information to run the Platform for you: to create and secure your account, to match you with providers and providers with work, to carry projects from a first description through to a completed job, to let you and a provider talk, to keep the records of what was agreed, to send you what you asked to be sent, to answer your support requests, and to keep the Platform safe from abuse.

We use it to meet our own legal obligations — tax and financial records, anti-spam compliance, and responding to lawful requests.

We use it, with your consent, to personalize what you see and to power eznest AI. Those two are treated separately and are described in §6 and §7.3.

We do not use it to build an advertising profile, and we do not sell it. No third party pays us to reach you, and no provider can pay for placement in your results.


5. Who we share it with

5.1 Other people on the Platform

This is the part you control by using the product:

  • When you post a project, the providers eligible to bid see its description and location. Your name, email and phone are not published with it.
  • When you engage a provider, they see what they need to do the work — your name, the service address, the scope, and your messages.
  • A person at that business who is assigned to your visit can add the visits assigned to them to a calendar of their own choosing. That calendar then holds your visit's time, service name, status and service address, kept by the calendar service that person chose (§5.3).
  • Reviews you write are shown publicly with your display name.
  • Household members you invite see the home you share with them.
  • If a crew arrives and cannot do the work, you can see the photograph they took of what stopped them. It is a photograph of your own property, taken during a service you booked, and the household members who can open your project records can open it. The crew's own written note about the visit is not shown to you. The link that displays the photograph is generated fresh each time you ask and stops working after about fifteen minutes. Within those minutes a forwarded link does still open, so it is short-lived rather than private to you; after they pass it opens nothing. We delete the photograph 90 days after it reached eznest unless you ask us to keep it or a dispute or claim is open; the row for crew photographs in §8.2 says exactly how.

About the location and device details a camera writes into an image file. When a photograph is taken through the eznest app or the eznest website, the picture is re-saved before it is sent to us, which does not carry that information forward. We do this to protect the crew member who took it, not to alter the record. Two limits, stated because they are true: photographs taken and stored before 27 September 2026 were not re-saved, and may still carry it; and re-saving happens on the device, so we cannot promise it for a file that reached our storage by some other route. We do not read, index or act on camera metadata in any case.

If you are named as your business's billing or signing contact. Providers can invoice each other and prepare business agreements on eznest. If you hold an owner, admin or finance role, an existing business counterparty can see your name, work email address and billing role; signing contacts are limited to owners and admins. This happens only after your business and theirs already have a commercial relationship on eznest, recorded by an invoice, agreement or active commercial relationship between the two. There is no directory of contacts, and a provider you have never dealt with cannot list your business's people.

To send a business its first invoice or prepare its first agreement, a provider must already know and enter an authorized contact's email address. We confirm whether that exact address belongs to someone with the required billing or signing authority and return their role — we do not return their name or echo the address, and we will not tell a provider who works somewhere or reveal an address they did not already have. These confirmations share one rate limit and are recorded in our audit log.

Corrected 2026-09-06. Until that date any invited provider could list the name, work email and role of every owner, admin and finance member of every validated business on the Platform, without any relationship to it. That was a defect, not a design; this section describes what the code does now.

Corrected 2026-09-07. The agreement signer picker had retained the same directory defect for owner/admin signing contacts after the billing picker was repaired. It now uses the same relationship gate and known-address bootstrap described above.

5.2 Companies that process data for us

We use these services in the Platform and in our business operations:

WhoWhat forWhere
Amazon Web ServicesEverything we run: the database, file storage, cache, secrets, transactional email, and the AI assistant's processing.Storage: Canada (ca-central-1, Montreal). SES email: ca-central-1. Bedrock inference: sent to us-east-1 and may be served from us-east-1, us-east-2 or us-west-2.
Clerk, Inc.Sign-in and account authentication.United States.
Google Workspace (Gmail), Google LLCHosting eznest.ca mailboxes, including privacy@eznest.ca and support@eznest.ca, for access requests, complaints, support and other correspondence. Receives sender and recipient details, subject, message text, attachments and our replies.May be stored and processed in the United States and other countries where Google or its subprocessors maintain facilities. We have not verified an account-specific region restriction; we do not promise Canadian-only mailbox hosting.
Twilio Inc.Sending the text messages you asked for, and receiving your replies.United States (Twilio's US1 region).
Apple Push Notification serviceDelivering iPhone push notifications; Apple receives a device token and notification text, which may name a visit or project.United States.
Google Places / Maps PlatformIn the website's Add a home and new-project forms, when a homeowner types an address, eznest's server in Canada sends Google the address text typed so far starting with the third character, whether or not the homeowner picks a suggestion. If the homeowner picks a suggestion, the server sends Google the selected place ID and receives address details, including latitude and longitude; the new-project form saves those coordinates on the property record. Google does not receive the homeowner's browser IP address on this address-entry path. A provider can also look up and connect their own business listing to show its Google rating; Google receives the provider-entered business search (such as name and city) or a place ID, followed by a place ID for rating details. If you press Show map on a public business page, your browser loads Google's map of that business's listed address. Google then receives your IP address, eznest's website origin as the referrer, and the listed business address in the map request. Simply opening the business page does not load the map. These Google paths do not send eznest account identifiers and do not send other homeowner records with the lookup.United States.
DigiCert, Inc.Independent timestamp when a document is signed; receives a SHA-256 fingerprint of the document's digital-signature value and a random nonce, not the document content, names or email addresses.United States.
Open-MeteoThe Home weather card: eznest's server sends Open-Meteo's geocoding service the home's city (the city name only), then its forecast service the latitude and longitude the geocoder returned for that city — the city's point, not the home's own location. eznest keeps a city it has looked up for the life of the server, and a forecast for 30 minutes, so Open-Meteo receives the city name only when it was not already looked up, and the city's coordinates unless a recent forecast is cached. When someone in the household adds one of the card's weather alerts as a to-do, eznest's server reads the forecast again the same way to confirm the alert, so that path also sends the city name (only when not already looked up) and the city's coordinates, unless a recent forecast is cached. A provider's storm watch for one of its business service areas sends the geocoding service that service area's city, and nothing else goes to Open-Meteo on that path; the snow reading itself comes from the federal weather service. No account identifier, name, street address or browser address is sent, and the province is used only on eznest's server to pick the Canadian match.Switzerland, with servers in the European Union and the United States.
Intuit Inc. (QuickBooks Online)Accounting sync, only for a business whose owner or admin connects its own QuickBooks Online company, and only from the day eznest switches that connection on (§13). When a connected business starts a sync, eznest's server in Canada sends Intuit, for each milestone of that business's projects whose card charge succeeded in the year chosen: your household's name, as a customer in the business's QuickBooks; and an invoice for that customer with the request text of the project, the milestone's title, the amount before tax, the charge date and an eznest reference number. No street address, email address or phone number is sent, and nothing is sent for a milestone that was not charged. Intuit sends back sign-in tokens for the business, the company's identifier and the identifiers of the records it holds.United States (the register's processing and storage region for Intuit). The records sit in the business's own QuickBooks company, under its agreement with Intuit.

Clerk receives your email address, name, IP address and sign-in events directly from your browser. Amazon Bedrock receives the AI-assistant content described in §6 when you enable and use it. Twilio receives your mobile number and each visit-message body only if you turn texts on. Apple receives an iPhone device token and notification text, which may name a visit or project. Google receives homeowner address text from the third typed character and selected place IDs from eznest's server-side website address-entry path, a provider's own business lookup when that provider connects its listing, or your IP address, eznest's website origin and the listed business address when you press Show map on a public business page. Open-Meteo receives the home's city and the coordinates eznest looked up when the Home weather card shows a forecast or someone adds one of its weather alerts as a to-do, and no account identifier. When a document is signed, a fingerprint of its digital signature goes to DigiCert's timestamp service in the United States to prove when it was signed; it receives no names, email addresses or document content. Intuit receives, only for a business that connects its own QuickBooks Online books and only from the day eznest switches that connection on, the name of the household that hired the business and an invoice for each charged milestone, as the QuickBooks Online section below sets out.

About the text messages, in full. They are off until you turn them on in Settings → Notifications, where you give the number and agree to a sentence that says what the messages are for. We never text you before that. What we send is about visits to your home — a business confirming one, being on the way, arriving, or finishing — so how many you get depends on how much work you have booked; expect a few per visit and none at all in a week with no visits. Message and data rates may apply. Reply STOP to any message to stop them, or turn them off in the same settings screen. Reply HELP for what they are and how to stop them.

Your mobile number and the record of your agreement are not shared with anyone for their own purposes, and never with anyone for marketing. Twilio processes them to carry the message and for nothing else. Twilio has no Canadian region — its regions are the United States, Ireland and Australia — so this is a United States flow and we name it as one rather than implying otherwise.

About QuickBooks Online, in full. A business can connect its own QuickBooks Online company to eznest so that the invoices for its charged milestones appear in its own books. The business decides: an owner or admin of the business signs in on Intuit's own page and grants eznest access, and eznest never sees the business's Intuit password. The connection is built and switched off, and nothing is sent to Intuit while it is off. eznest switches it on only on a day it announces at least 30 days ahead (§13).

What Intuit receives, and from whom. Once the connection is on, and only when a connected business starts a sync, eznest's server in Canada sends Intuit, on that business's behalf, for each milestone of that business's projects whose card charge succeeded in the year chosen: the name of the household that hired the business, as a customer in the business's QuickBooks company (eznest first looks for a customer with that name so it does not make a second one); and an invoice for that customer carrying the project's request text, which is the words the homeowner wrote when posting the work, the milestone's title, the amount before tax, the charge date and a reference number of eznest's own. We send no street address, email address or phone number, and nothing for a milestone that was not charged. The request text is written by the homeowner, so it holds whatever the homeowner chose to write. To save the invoice, eznest also reads the company's tax codes and income accounts, and creates an item called "Eznest Services" if the company has none. Intuit sends back its sign-in tokens for the business, the company's identifier and the identifiers of the records it holds. A separate setting, which is off, would also have a sync read back each invoice eznest sent (its total, its tax and its unpaid balance) so that differences from eznest's records can be listed; it never changes an eznest record.

Where Intuit processes it. Our processor register gives the United States for both processing and storage. The invoices and customer names then sit in the business's own QuickBooks company, which Intuit holds under the business's agreement with Intuit and Intuit's terms, not under this policy. We have not verified a restriction of that company to Canada, and we do not say there is one.

How a business disconnects. An owner or admin chooses Disconnect on the Accounting page of the website (Financials, then Accounting); the apps send the business there. eznest asks Intuit to cancel its access, and deletes its saved sign-in and its record of what it sent, in the same step. If Intuit cannot be reached at that moment the disconnect still completes here, and the business can end the connection from inside QuickBooks. eznest keeps the invoices, payments and tax records it already holds, the note that the business disconnected and the company identifier it recorded. What Intuit already holds stays in the business's own QuickBooks company, and eznest cannot remove it. If the business connects again, eznest sends its invoices again.

We do not currently check licence numbers with regulators. We record and show the number a business gives us. Our production HCRA adapter is configured as a no-op, and the ESA/ECRA adapter returns no external result. Neither authority currently receives a provider's licence number from these paths.

We also read public reference data — product recalls, map data, open government data. We send those sources nothing about you, with one exception worth naming: when we geocode a business address in our provider-outreach work, that address text goes to OpenStreetMap's geocoder in Europe. This never involves a homeowner's address. The weather forecast is not a public-data read in this sense: when the Home weather card shows a forecast, eznest's server sends Open-Meteo the home's city and the coordinates the geocoder returned for it, and no account identifier, name, street address or province — as described in the table above. Adding one of the card's weather alerts as a to-do reads the forecast again the same way, so it also sends the city name (only when not already looked up) and the city's coordinates, unless a recent forecast is cached.

Built, but switched off, and receiving nothing today: Stripe (payments and provider connected accounts), Google/Firebase Android push, Intuit QuickBooks (described above, because a business that connects it will be sending Intuit your household's name), two alternative AI providers, and the import of busy times from a business's own Google Calendar or from an Outlook calendar link it pastes into eznest, which would let eznest avoid offering a time the business is already booked. While that import is off, nothing is read from either calendar service. If it is switched on, a business owner or admin connects it, and eznest keeps only the busy start and end times for the next 90 days, plus the encrypted connection details until the business disconnects it or its account is erased. For a provider in a controlled Stripe Connect rollout, Stripe may receive the identity, beneficial-owner, bank and verification information described in §3.8 directly through a Stripe-hosted page or Stripe-controlled frame. The rollout controls remain off today. We will tell affected users before enabling a material new processing flow.

Signing an agreement does not send the document to an e-signature vendor. We sign contracts ourselves: the document stays in our storage, and no e-signature vendor receives your name, email, contract or signature. To record when it was signed, we send DigiCert a SHA-256 fingerprint of the PDF's digital-signature value and a random nonce; it returns a signed timestamp token. DigiCert receives no document content, name, email or address.

We do this because we operate the platform where these agreements are signed and are not a party to the agreements themselves, but any fee we take is set out in the agreement's own terms, so a "signed at" that we record is a claim by an interested operator. The authority has nothing at stake, which is what makes its token worth something. The audit certificate we produce names which authority was used, and it separates the facts anyone can check for themselves — the document's digest and that token — from the facts that rest on our own record-keeping.

We maintain a machine-verified register of every one of these at subprocessors.yaml; an automated check in our build confirms each entry corresponds to something actually present in our code.

On contractual protections: we are a young company and we are candid about this. Formal data processing agreements with our processors are being put in place; we have not yet completed that work, and we are not going to claim protections we have not signed. Our Privacy Officer can tell you the current state for any named processor.

5.3 Private calendar links, and the calendar service you choose

You can make a private link that puts visits in a calendar you already use, such as the calendar app on your phone or an online calendar. A member of a household can make one for the household's visits. Someone who works for a business on eznest, a technician or a business owner, can make one for the visits assigned to them. Nothing is sent anywhere until you make a link and add it to a calendar.

What a link sends. Each visit from the start of today, Toronto time, to 60 days ahead: its time window, its service name (or the job's title where a visit has no service name), its status, when it last changed, and an identifier that lets your calendar update the visit rather than add it twice. Cancelled visits, replaced visits, no-shows and visits where the crew could not get in stay in that window, marked cancelled.

  • A household calendar carries the household's visits that you can see in eznest, including visits another member of the household arranged, and names the business doing each one. It contains no home address, prices or crew names.
  • A calendar of your own assigned visits carries only the visits assigned to you, with the service address of each. If you own the business, it still carries only the visits assigned to you, not the whole business's schedule.
  • No calendar includes a customer's phone number or email address, private notes or money details.

Who can read it. The calendar service you add the link to fetches your visits from eznest with it, and checks again for changes on its own schedule, so a change may not appear there at once. Anyone who has the link can read the calendar without signing in, so keep it as private as a password. We show the link only when it is made or replaced, and we keep a one-way fingerprint of it rather than the link itself, so we cannot show it again, to you or to anyone else.

Your calendar service keeps its own copy, under its own rules. You choose the calendar service; we do not. It is not one of the companies in §5.2, and we have no agreement with it. Once it has fetched your visits, it keeps its own copy under its own privacy and storage rules, which may place that copy outside Canada, including in the United States. We do not know where it keeps your calendar, and we cannot delete what it has copied.

How to stop it. Revoke the link on the screen where you made it: for a household calendar, Household & privacy on the website, Your household on iPhone or Household & settings on Android; for your own assigned visits, Schedule. Revoking stops every later request made with the link, and making a replacement link stops the old one. Neither erases what your calendar service has already copied: remove the subscription in that calendar to clear it there. We allow a calendar to reuse a copy it fetched for up to 15 minutes without asking us again, and a calendar service may keep its own copies for as long as its own rules allow. A link also stops working when you leave the household or the business it belongs to, and closing your account (§7.4) deletes every link you made.

5.4 Other situations

  • Professional advisors — lawyers, accountants and auditors, bound by confidentiality.
  • Legal requirements — where we are required by law, or where disclosure is necessary to investigate a breach, prevent fraud, or protect someone's safety. We will tell you unless we are legally prohibited from doing so.
  • When police or another public body ask us for information about a member — a call, a letter, a court order or a warrant — nobody at eznest hands over a member’s information, messages or records on a call or an email, and our support team does not answer the request. It goes to our Privacy Officer, who writes down who asked, which body, when, and what it asks for; checks the request is genuine by calling the body back on a number found independently, not one in the request; asks our lawyers what we must provide and what we may tell the member; and then provides only what is asked for and what our lawyers confirm, by the means the body names, and writes down what was provided and when. Separately, where we believe a crime has been committed or we are legally required to report, our founder, who is also our Privacy Officer, decides whether and to which body we make a report, and makes it in person; we report content that sexualises a minor. Our Acceptable Use Policy says so too.
  • A change in our business — if eznest is acquired or merges, your information may transfer as part of that. You would be told, and this policy would continue to apply until you were given notice of a replacement.
  • Anything else — only with your consent.

5.5 What we never do

We do not sell personal information. We do not rent or trade mailing lists. We do not share your information with advertisers or data brokers. We do not let a provider pay to appear higher in your results. We do not combine your data with data bought from third parties to profile you. These are commitments in our privacy and ethics charter, not aspirations.


6. eznest AI and artificial intelligence

6.1 Where it runs

eznest AI runs on Amazon Bedrock, a third-party AI service operated by AWS, and requests are processed in the United States: each request is sent to us-east-1, and the Bedrock inference profiles we use may serve it from us-east-1, us-east-2 or us-west-2 (measured with AWS's GetInferenceProfile on 2026-09-11 and re-checked quarterly). Eznest account data remains stored in Canada; the prompt and context needed for each eznest AI response are transmitted to and processed in the United States for that request.

Production is configured to use Amazon Nova 2 Lite for the small tier, Anthropic Claude Haiku 4.5 for the middle tier, and Anthropic Claude Sonnet 4.5 for the large tier. If a tier's primary model is unavailable, its configured fallback is Amazon Nova Lite, Claude Sonnet 4.5, or Claude Haiku 4.5, respectively. Search embeddings use Amazon Titan Text Embeddings V2. A request uses the tier selected for it, not every model in this list.

6.2 What reaches the model

When you talk to eznest AI: your message, your recent conversation history, a summary of your own account — your name, your home's basic details, counts of what you have on the go, your next appointment — the profile eznest AI keeps of you, and the results of whatever it looks up on your behalf. Every one of those lookups is made for your account. Their results can include words other people wrote that you can see in eznest, such as a business's quote or the messages in a conversation you are part of; §6.3 says when those are sent to our AI provider without checking that person's consent.

6.3 Your consent, and its exact limits

For a signed-in account, the eznest AI switch in Settings → Privacy controls whether the features below may send information to our AI provider. This consent is express and separate from accepting this policy. We check for an active grant with the language of the consent wording recorded; if the grant is missing, withdrawn, or cannot be confirmed, the AI step is refused or skipped. An older grant without that recorded language must be confirmed once before these features can use AI again.

The same AI consent check covers:

  • Conversations, analysis and drafting: messages to eznest AI, matching them to help pages, reasons you give for declining a proposed action, conversation summaries, quote comparisons, lead scoring, proposal drafts, business analysis, the cost estimates and project-description drafts eznest AI prepares for you in a conversation, and questions you ask the assistant.
  • Personal-finance help: the Money coach, AI reading of a statement, and AI categorisation of transactions, including the search representations made from transaction descriptions when you choose a category. AI reading of a statement is tried when the bank-specific and credit-card statement readers cannot read it; the general fallback reader, which needs no AI, is used when AI reading is off or does not succeed. Without AI consent, local rules and the statement readers that need no AI still work; a transaction those rules cannot categorise stays uncategorised.
  • Search and indexing: AI summaries of signed-in searches, searching saved activity by meaning, indexing documents you may read in your home's vault, and indexing your usage signals. Document indexing checks the requesting member's consent; the background signal-indexing job checks consent for each person whose signals it processes. Without consent, ordinary search remains available without an AI summary, and these AI indexing and search steps do not run.
  • AI memory: writing the summary eznest AI keeps of you after a conversation. This needs both AI consent and separate personalization consent. Both are checked again when that background summary is about to be written; consent to a conversation alone is not enough.

Another person's words have additional checks when a summary, comparison or score is asked for directly. A conversation summary asked for directly includes only messages whose recorded author has allowed AI processing. A quote comparison asked for directly includes only quotes whose recorded sender has allowed it. Words with no recorded author or sender are left out; no model is called when no messages, or fewer than two quotes, remain. Lead scoring requires consent from everyone recorded as creating or changing the household's request and refuses if that authorship or consent cannot be established. These checks are in addition to the requesting person's own AI consent.

Inside a conversation with eznest AI, those additional checks are not made. When you ask eznest AI in a conversation to compare quotes or summarise a conversation, the quotes or messages you can see are sent to our AI provider with your own AI consent only, without checking the other person's. For quotes that is each business's name, total, terms and lines; for a conversation it is each message with its sender's name.

You can withdraw AI consent at any time in Settings → Privacy. Later consent checks refuse or skip the AI step, including the memory refresh after a conversation ends. Some background and import work checks once for a batch, so withdrawal does not recall information already sent or cancel work already admitted by that check. Turning AI off is separate from deleting stored conversations or memory (§6.6).

These AI steps use the Bedrock service in the United States described in §6.1. Public assistant and search requests made without signing in do not use this account consent check, because there is no account grant to read. Do not put personal or sensitive information into those public requests. A business's estimate calculator, which prices an estimate from the business's own rates and margin settings, and preparing quote lines from an approved estimate do not call an AI model and do not require AI consent. Writing proposal wording from an approved estimate does, and is covered above.

6.4 What we do not do with it

Nothing you say to eznest AI, and nothing in your account, is used to train, fine-tune or improve any AI model. There is no training pipeline in our system. There is no cross-user aggregation feeding any model. AWS does not train its models on Bedrock inputs.

We should be precise about one related point: there is an account-level AWS setting for AI data retention that we have not yet applied. Until we have, we are not going to claim a zero-retention guarantee we cannot evidence.

We use Amazon Bedrock Guardrails to check AI prompts and answers. The guardrail is enabled in production and attached to both conversations (including streamed replies) and individual text-generation requests. It is configured to block detected payment-card numbers and security codes, Canadian social insurance and health-card numbers, United States social security numbers, passwords and AWS access credentials. It also filters harmful content and attempts to override the assistant's instructions. The guardrail's working draft also defines three denied topics (personalised legal advice, personalised financial advice and medical diagnosis), but they are not part of the version that production attaches today, so the guardrail does not restrict eznest AI on those topics.

This is a check by AWS, not a removal of sensitive information before it reaches AWS. Names, addresses, email addresses and phone numbers are not configured for blocking. The guardrail does not cover the separate requests that make search representations of text (embeddings), and it is not a guarantee that every unsafe request or answer will be detected.

When the guardrail intervenes, we attempt to record operational details such as the model, guardrail version, request reference and whether it acted on the prompt or answer, without copying the prompt, answer or matched text into that audit record. If it blocks an answer for personal or sensitive information, we also attempt to enter a near miss in our confidentiality-incident register. A blocked prompt alone does not create that incident entry. These intervention records are separate from the conversation history described in §3.6.

eznest also limits what the assistant can do. Actions that change something require your explicit confirmation, unless you switch on automatic actions (§6.5), which covers only the small, reversible actions named there. Some actions are prohibited outright, and there are caps on how much any single conversation can do.

6.5 Automated decisions

No AI decides anything about you that has a legal or similarly significant effect. No AI decides whether you get an account, what you pay, whether a provider is verified, or whether a dispute succeeds. By default eznest AI suggests and drafts, and you decide: every action that changes something shows you an approval card first.

One automatic action is yours to switch on. You can let eznest AI go ahead with its own actions without asking. It is off until you turn it on. When it is on, eznest AI adds small, reversible things for you without showing an approval card first: a to-do, a reminder, a note, a saved business, or a home system such as a furnace or roof recorded in My Home. Everything else still asks first, including messages, quotes and new projects, and some actions are not permitted at all. Your permissions still apply, each action is logged, and each one can be undone. The switch is Let eznest AI act without asking in the eznest AI card on the iPhone, and Automatic actions on the What eznest AI knows page on the website. Turning it off restores the approval card for every action from then on. Turning eznest AI off altogether also stops it.

Decisions eznest makes by rule. Separately from eznest AI, eznest applies a few fixed rules to accounts without a person looking at each case: lowering a provider's trust level when a verified credential passes its expiry date, refusing a provider's bid when the project needs a higher trust level, and refusing sign-in attempts for a short time after repeated failures. These are rules, not an AI model. They are listed, with the information each uses and the principal factors, in the automated-decision inventory. eznest does not approve a milestone for anyone: approval is the client's alone.

6.6 Making eznest AI forget you

Signed in, go to Privacy → Erase eznest AI history (on the website, the section Erase saved eznest AI history). It clears both your conversation history and the profile eznest AI wrote about you from it — the two together, because clearing the transcripts while keeping the summary distilled from them is not forgetting. eznest AI starts over without that history or profile. It can still look up the account and home information you allow it to access when you next use it (§6.2).

It is immediate and self-serve. Closing your account clears both as well.


7. Your choices and your rights

7.1 Get a copy of your data

Signed in, go to Privacy → Download my data. It is immediate, self-serve, machine-readable, and free — no waiting period, no email, no fee.

It is a copy of the main categories of your data, not of everything we hold. Each part of it holds only records that are yours or that your account may read: your homes and the records attached to them appear for the homes you own, a household's homes, requests, projects and schedules appear while you are an active member of that household, and its Garage records appear only where your role in the household lets you read Garage. If a part could not be read, the file is marked incomplete and names that part. A few parts can still come back empty without that warning, so if something you expect is missing, download it again or ask the Privacy Officer.

It currently includes:

  • the date and time the file was made, your account's identifier, the version of the file's layout, and whether the file is marked complete;
  • your account record: your name, your email address and whether it is verified, your phone number, your role, your account's status, and when it was created;
  • how your account was admitted during the invite-only beta: the role it was given, when the invitation was redeemed, and the IP address it was redeemed from;
  • the household and business memberships you hold or have held, with your role in each;
  • the sign-in sessions eznest still holds for your account: when each was issued, when it expires or was revoked, and the IP address and the browser or app user-agent it came from;
  • the sign-in methods linked to your account, with the email address and verification status each one reported;
  • the devices registered to receive notifications from eznest: the platform and app, when each was registered, and when it was last seen;
  • your signed-in account-interaction records (§3.5), including the source IP address and user-agent stored with them;
  • the homes you own, and the homes held by a household you are an active member of: the address and the map location eznest recorded for each, property type, year built, floor area, purchase price and mortgage balance;
  • how each of your homes was matched to eznest's newer home records, including any home that could not be matched and the reason recorded;
  • what you have recorded about your home: rooms, belongings, home details, systems, appliances, valuations and warranty coverage;
  • the cover photos on your rooms and belongings, and the cover photos you uploaded, listed by their details;
  • maintenance tasks and service history;
  • the document listings for your home, and where each filed document came from;
  • your trusted contractors;
  • the product recalls you acknowledged;
  • the Project Twin records you created or that belong to a home you own, with their spaces, condition records and captures;
  • your projects: the projects you posted, and your household's requests and its projects with businesses, with the files attached to a request listed by their details;
  • the milestones on the projects you posted and on your household's projects with businesses, with their amounts and status and, where recorded, when each was submitted, approved or charged, and whether and how much of it was refunded;
  • a project schedule a business has shared with your household: the phases you can see, the links between them, and their recorded date changes;
  • the jobs and visits a business has assigned to you as a member of its team;
  • appointments you organised or were invited to;
  • the earlier reviews you wrote, from before verified reviews;
  • the messages you sent in eznest conversations, including a posted job's conversation with the business you hired: what you wrote, when you sent each message, the conversation it belongs to and when you last read it, with a count of the messages you have sent and when you sent the last one; the other people in a conversation appear only as account identifiers;
  • the support tickets you raised, with the replies you could read, their status and their dates; a reply is marked as yours or as from support, and the staff member who wrote it is not named;
  • the disputes you opened or are named in: what was disputed, the reason and the description, the decision and its remedy, and the dates; the other party appears only as an account identifier;
  • the quotes a business wrote to you or to your household, and the quotes you wrote or sent yourself for a business: their amounts, terms, line items, status and dates; the business or provider appears only as an identifier;
  • your provider profile: your business name, headline and bio, your verification status, your rating and counts, and your lead, invoicing and listing settings;
  • any request to hand your household's billing to another member that you started or were asked to accept, with your actions on it, its receipts, the notices sent about it, and any record that evidence in it was removed;
  • your household's Garage records: vehicles and equipment, their documents listed by their details, readings, maintenance plans, service records, the decisions taken on imported service records, parts and their stock events, notes, the maintenance notices sent to you, the Garage activity log, and the receipts for Garage changes you made;
  • to-dos, reminders, notes, expenses, supplies, and checklists with their items;
  • notifications, your notification preferences, your quiet hours, and the notifications quiet hours held back, with whether each was later sent or dropped;
  • your agreement to receive visit texts, with the mobile number you gave for them and any withdrawal;
  • the people you have blocked, by their account identifier, and when you blocked each of them;
  • the notices eznest has sent you that a legal document has a new version, with the document, the version, the channel, the language and the time of each;
  • your preferences, such as language, time zone and reduced motion, and the prompts you dismissed or snoozed;
  • your consent history: every consent eznest has recorded for you, including the ones you later withdrew, with the wording you agreed to;
  • usage signals, and how many search-index entries have been built from them;
  • your eznest AI conversations: what you and eznest AI said in each, when, and the name of any tool it used;
  • the profile eznest AI keeps of you;
  • your eznest AI settings and your daily eznest AI usage totals;
  • receipts for actions you took, with their outcome where one is recorded: changes to your trusted contractors, checklists and to-dos, messages you sent, changes to a business's team, support requests, warranty cases, daily-log entries and checklist templates;
  • everything in the personal-finance tools: your accounts and credit lines, transactions with their tags and links, imported statements (each listed by name, with the text eznest extracted from it) and the transactions staged from them, your categories, rules, merchants and tags, finance documents, payment schedules, bills and reminders, and payoff plans with their month-by-month schedules.

Garage records are included where you have permission to read that household’s Garage. The download includes vehicle and machine records (including archived records), readings, maintenance plans, parts and stock changes, service records and completed-work reviews, private notes and their revision history, document listings, and Garage activity history. Garage reminders and action receipts are limited to your own. It does not copy uploaded Garage files into the download. For those files, on the website go to My home → Garage, open an asset and choose Documents & warranties, then Export Garage ZIP. This separate archive covers the household’s Garage files, including those attached to archived assets, with a manifest that identifies unavailable files; it is not an export of all the household’s other documents.

It does not include:

  • failed sign-in attempts recorded against your email address;
  • the privileged audit log (the Garage activity log is included where you can read Garage);
  • credentials that anyone holding the file could use: the push-notification token itself, live session identifiers, the sign-in provider's internal identifier for you, and password-reset and email-verification links;
  • your private calendar link records;
  • the files themselves: where the download lists a document, photo or statement file, it gives the file's details rather than a copy, and the text eznest extracted from your home and Garage documents is left out (the text extracted from your imported statements is included);
  • the messages other people sent you (what you wrote is included, as above), and the messages you sent in the conversation on a project a business runs on eznest or in a business's Crew chat, which are not included or counted;
  • the names, email addresses and phone numbers of the other people in your conversations, support tickets, disputes and quotes, who appear only as identifiers, and the notes that only eznest staff can read on a support ticket;
  • the milestones of a project that reached your household only because you claimed the customer record a business kept for you;
  • the requests you sent asking a business listed on eznest to contact you, and the message you wrote in each;
  • the raw inputs and results of the tools eznest AI used in a conversation;
  • the verified reviews you left after a closed job;
  • bids, agreements, invoices, warranty cases, the card-network chargeback cases on a business's payments, and reports you made about other users' content;
  • household member profiles, including a child or teen account's date of birth, guardian link and limits;
  • the verification documents and portfolio of your provider account, eznest staff's notes on its verification, and the client records you keep in the provider CRM.

If you want any of those, ask the Privacy Officer and we will assemble them for you. We are working to close the gap.

7.2 Correct it

Change your name and phone in Settings → Account. Home details, projects and everything you have entered are editable where you entered them. For an email change, or anything you cannot reach, write to privacy@eznest.ca.

7.3 Control what we observe and how it is used

There are two separate switches, and they do different things:

SwitchDefaultWhat it controls
Personalization master switch (Settings → Privacy)On — we record optional usage signalsTurning it off stops us recording the optional usage signals used for personalization, and turns off every form of personalization regardless of anything else. It does not stop the limited operational signed-in account-interaction record described in §3.5.
Personalization consent (Settings → Privacy)Off — you must grant itWe only use your own history to shape what you see if you grant this. Without it, matching still works, on neutral factors only.

You can also erase every usage signal we have recorded about you, immediately and yourself, from Privacy → Erase my signals. That page also lists what we have observed, so you can look before you erase.

Marketing email and SMS are separate consents, each independently withdrawable, and every marketing message carries an unsubscribe. Transactional messages — about a project, a booking, a security event — are part of operating your account and are not a marketing preference.

7.4 Close your account

Settings → Account → Delete my account. You will be asked to re-confirm it is you, then to type DELETE.

What that erases: your home contents and belongings, your notes, to-dos, reminders, checklists and expenses, your personal-finance accounts, transactions, imported statements and their stored files, bills and payoff plans, your preferences, your eznest AI conversations and the profile eznest AI keeps of you, your notifications, eznest's stored device-token registrations, your private calendar links, your optional usage signals, your signed-in account-interaction records and search index, your identity links, your AI usage records, your beta invitation record, and every outstanding sign-in session. Your account record itself is anonymized: your email is replaced, your name becomes "Deleted user", your phone is removed, and every access token is invalidated.

Your sign-in record at Clerk. Your sign-in itself lives with Clerk (§5.2), so closing your account also has a half that happens outside our systems: we ask Clerk, server to server, to delete your sign-in record. We make that request when our connection to Clerk is able to carry it. If it cannot be made yet, or Clerk does not confirm it, the request is recorded against your anonymized account as still owed and is completed later; it is not closed until Clerk confirms the record is gone. Whichever state that is in, signing in with that identity is refused — it never re-creates an account, and none of your erased data comes back. Clerk's identifier for you stays on the anonymized record so that identity can never be attached to a new account; Clerk never reuses it, and once your record there is deleted it points to nothing.

Your customer record at Stripe. Payments are processed by Stripe (§5.2), so closing your account has a further half that happens outside our systems: where eznest has created a customer record for you at Stripe, your name, email address, phone number, address and saved cards are removed from each Stripe customer record eznest created for you. The customer record itself stays, because every charge, invoice, payout and tax record attached to it stays (see below). If Stripe cannot take the removal when your erasure runs, the removal is recorded against your anonymized account as still owed and is retried until Stripe has done it — the same way the Clerk request above works.

What we keep, and why:

  • Financial records — the ledger and any invoices. Required for tax and accounting.
  • The payment records at Stripe — every charge, invoice, payout and tax record, which stay at Stripe as they were made, including the card and billing details recorded with each charge and the copy of a card made for a payment on a business's own Stripe account. The personal details named above are removed from the customer records eznest created for you, not from these payment records. Required for tax and accounting, like the ledger records above.
  • The audit log — including the record of your deletion, and of whether Clerk has confirmed deleting your sign-in record.
  • Your consent history — the record of what you consented to and when survives withdrawal, because it is the evidence of what we were permitted to do.
  • Clerk's identifier for you — on the anonymized account record, as explained above, so an erased sign-in can never be attached to a new account.
  • Your household's name in a business's QuickBooks books — if a business you hired connected QuickBooks Online (§5.2), your household's name and the text of your project may already sit in an invoice in its own QuickBooks company at Intuit. Closing your account does not remove them: they are that business's record, and eznest cannot reach into its books. Ask the business.

What we do not yet erase, honestly stated: your home record and the documents, maintenance history and service records attached to it; the household’s Garage vehicles and machines, readings, maintenance plans, parts and stock changes, service records, completed-work reviews, reminders, private notes and their history, files, action receipts and activity history; your projects, milestones, reviews, messages and appointments; and files you uploaded, other than personal-finance statements, remain in storage.

Garage records stay with the household when one member closes an account. Closing your account does not erase those shared records or their private notes and history. This is not a promise to keep them forever: the rules for household transfer and deletion, including when the last member leaves, are not yet complete. For a request to remove them, contact the Privacy Officer.

These are not oversights. A home can be shared with household members, so deleting yours could destroy someone else's records. Projects, messages and reviews are shared with a provider who is a party to them. We have not yet finished the rules for those cases and we would rather leave them than get them wrong. If you want them removed, ask the Privacy Officer and we will handle it individually. We will update this section as we resolve it.

If you cannot reach the button — for any reason — email privacy@eznest.ca and we will close the account for you.

7.5 Withdraw consent

Any consent can be withdrawn in Settings → Privacy: AI processing, personalization, marketing email, marketing SMS, data sharing. Withdrawal is recorded rather than erased, so there is a record of when it changed.

Some consents are structural: if you withdraw consent to what is necessary to operate your account, the way to give effect to that is to close the account.

7.6 Complain

Tell us first — privacy@eznest.ca. We will acknowledge you and tell you what we are doing.

If we do not resolve it, you can complain to the Office of the Privacy Commissioner of Canada (priv.gc.ca, 1-800-282-1376). Quebec residents may also complain to the Commission d'accès à l'information du Québec (cai.gouv.qc.ca).

7.7 Our service standard

We aim to answer an access or correction request within 30 days, at no charge. This is a commitment by our Privacy Officer rather than something automated — the export in §7.1 is instant, and everything else is handled by a person.

How a request is handled. Write to the Privacy Officer at privacy@eznest.ca. The 30 days run from the day your request reached us, not from the day a person opened it. Our administration tools let staff record each request when it arrives: what kind it is (a copy of your information, erasure of your account, a correction, withdrawal of consent, or something else), the day it arrived and the day an answer is due, when you were told it had arrived, and how it was closed. Before we send you a copy of your information or erase your account, we match the request to your account and check that it is you. An erasure is carried out only after a second member of staff, not the one who asked for it, agrees. A correction or a withdrawal of consent is closed by a person, with a note of what was done.

If we need more time. If the Privacy Officer decides that an answer will take longer than 30 days, and the law allows it, we extend once. We write to you before the 30 days end, say why, give the new date, and tell you how to complain (§7.6). Our administration tools record each extension: who extended the request, when, why, and the new date, which cannot be later than a limit set in eznest's settings. They do not remind us of a date.

If we refuse. If we refuse your request, we tell you in writing and give the reason, as far as the law lets us, and we tell you that you can complain to us and then to the Office of the Privacy Commissioner of Canada (§7.6). The request is recorded as refused, with the reason, and never as done.


8. Where your data lives, and for how long

8.1 Where

The Platform's database, file storage, cache and secrets are stored in AWS Canada (Central), Montreal. This is enforced by a permission policy that denies requests to any other region, by a start-up check that refuses to run the service if it is misconfigured, and by a validation in our infrastructure definition. These controls do not govern the separate services in §5.2, including Google Workspace mailboxes.

Correspondence with our eznest.ca addresses is held in Google Workspace. Google's data-processing terms and Workspace location terms permit storage and processing where Google or its subprocessors maintain facilities, subject to any applicable region commitment. We have not verified a region restriction for our mailboxes. This mail may be held and processed outside Canada, including in the United States, and may be accessible to authorities under the laws of those countries. The application's automated transactional email uses AWS SES in Canada (Central); that is a separate service from the mailboxes our staff use to receive your mail and reply.

We should be precise about the strength of that: eznest runs in an AWS Organizations management account, but Service Control Policies do not apply to that account. The regional guardrails here are enforced by our own IAM configuration and application code, not by an organisation-level boundary over this workload.

8.1.1 Foreign lawful access — the part most policies leave out

You should know two things about what "stored in Canada" does and does not protect you from.

Your sign-in data is held by Clerk in the United States. While it is there, it is subject to the laws of the United States, and may be accessible to United States courts, law enforcement and national security authorities under those laws, without notice to you or to us. We chose Clerk for the security of the sign-in itself, and we are telling you the trade-off rather than burying it.

Content sent to eznest AI is processed by Amazon Bedrock in the United States. The prompt, recent conversation context, relevant account context and retrieval results described in §6 are subject to the laws of the United States while processed there. Your database records and uploaded files remain stored in Canada.

Your text messages go through Twilio in the United States, if you turned them on. Your mobile number and the text of each message are subject to the laws of the United States while Twilio holds them, on the same terms as the two flows above. Twilio has no Canadian region, so there is no version of this feature that keeps those messages in Canada — which is why it is off until you ask for it, and why replying STOP ends it.

iPhone push notifications go through Apple in the United States. Apple receives a device token and the notification text, which may name your visit or project. Android push through Google/Firebase is not enabled.

Homeowner website address entry and a provider's own business lookup go through Google Places in the United States. In the website's Add a home and new-project forms, once you have typed the third character of an address, eznest's server in Canada sends Google the address text typed so far, whether or not you pick a suggestion. If you pick a suggestion, the server sends Google the selected place ID and receives address details, including latitude and longitude. Google does not receive your browser IP address on this address-entry path. When a provider connects a Google listing, Google receives the provider-entered business name and city, or place ID. These calls do not send an eznest account identifier or other homeowner records.

A public business page's map comes from Google only when you press Show map. That sends Google your IP address, eznest's website origin as the referrer, and the business's listed address to place the pin. Opening the business page without pressing the button does not load the map. Google processes the request in the United States.

QuickBooks Online, if a business you hired connects it, goes through Intuit in the United States. The household's name and the invoice for each charged milestone described in §5.2 are subject to the laws of the United States while Intuit holds them in the business's QuickBooks company, on the same terms as the flows above. The connection is switched off, and eznest announces at least 30 days ahead before it switches it on.

A calendar you subscribe to is held wherever your calendar service keeps it. If you add a private visit calendar link to a calendar service (§5.3), that service holds its copy of those visits in its own locations, under its own rules and the laws that apply there, which may include the United States. You choose that service; eznest does not, and does not know where it keeps your calendar.

Canadian storage is not immunity, and we will not imply that it is. Our Canadian infrastructure is operated by Amazon Web Services, a United States company. Under the United States CLOUD Act, a US-headquartered provider can be compelled to produce data it controls regardless of the country the servers sit in. Keeping your data in Montreal meaningfully reduces exposure — it is why we did it, and why we enforce it in code — but it does not place your data beyond the reach of a US legal order served on our provider.

We tell you this here, and we will tell you again at the point we ask for anything sensitive. If we ever receive a legal demand for your information, we will tell you unless we are legally prohibited from doing so, and we will not hand over more than we are required to.

8.2 For how long

We keep your account data until you delete it. Apart from the records in the table below, we do not run automatic expiry clocks on it, and we are not going to publish a retention schedule our systems do not enforce.

eznest AI conversations are not in the table below, because nothing deletes them by age yet. We have decided the rule: conversation text is kept for six months after your last message, or until you delete it if that comes sooner, and the profile eznest AI writes about you, with the notes it pins in it, is kept only as long as the conversations it was built from. The same period applies to members in Quebec. We have not decided whether Quebec law requires a different period, and we do not state a legal basis for this rule here. Until the automatic removal is built and running, your conversations and profile stay until you delete them (§6.6) or close your account (§7.4). When the removal runs, this paragraph moves into the table. The removal looks for conversations to remove: a profile with no conversation at all is not found by it and stays until you delete it (§6.6) or close your account (§7.4), and a separate cleanup of such profiles has not been built or run.

Six other kinds of record have no automatic expiry yet, and they are not in the table below either. They are: the messages between you and a business on a project, with the photographs sent in them; the notifications in the app; the record of the emails and push notices we sent, or chose not to send; the record of the text messages we sent, or chose not to send; the history of events that other records point to; and your support requests, with their replies and images. We have not set a period for any of them, we do not state a legal basis for one here, and nothing in our systems removes them by age today. Our nightly cleanup has a removal for each of the six, and it is switched off for all six until someone with the authority gives us a period for that kind of record. When a period is set for one of them and its removal is running, that kind of record will be added to the table below, and not before. What closing your account does to each of them is in §7.4 and is unchanged.

Records that back an invoice, a refund or a billing hand-over are never taken by that cleanup. The record of when an invoice link was sent, delivered and opened, the record of an email sent about an overdue refund, the copy of a plan's billing terms that we emailed, and the notice that a billing hand-over was completed are kept out of the removal on purpose, and nothing else removes them by age. They are in the table below. Whether, and after how long, they may ever be removed has not been decided, and we do not state an answer.

Business-mailbox correspondence is separate from your Platform account. We have not verified an automatic expiry schedule for Google Workspace mail. Closing your Platform account does not itself delete mail you exchanged with our staff. Ask the Privacy Officer about access, correction or deletion of that correspondence.

What stays with the outside services we use (§5.2). Closing your account erases what eznest holds. It cannot reach what a service has already received. The table in processor-retention-register.md lists, for each of those services, what it receives, how long it keeps that by default, how eznest deletes or redacts it, and who decides. Where nobody has given us a period, it says "No period supplied" rather than guessing. We do the same here: we have not been given a period for how long Clerk, Twilio, Amazon SES, Amazon Bedrock, Apple, Google (address entry and maps, and Android push when it is on), DigiCert or the Google Workspace mailboxes keep what they received, and we will not state one we cannot back. What eznest can do is this. For Clerk, it asks Clerk to delete your sign-in record and keeps trying until Clerk confirms (§7.4). For Stripe, which is switched off today, it removes your details from the customer records it created and leaves the payment records (§7.4). For Apple, and for Google's Android push when it is on, it deletes the device registration it holds, and it cannot delete anything at Apple or Google. For Twilio, it asks Twilio, when you close your account, to delete each text it sent for you, by the message id it recorded when it sent it. It tries once, at that time, and records any deletion that did not succeed so that it can be tried again. That does not reach a text sent before eznest recorded whose text it was (other than the confirmation sent when you turned texts on), or your own replies to us, such as STOP, and we have not established what Twilio keeps for its own legal reasons after a deletion. It has no way to delete the fingerprint DigiCert received. At Amazon, files and backups follow the table below, and eznest keeps no copy at Amazon SES or Amazon Bedrock to delete.

A QuickBooks connection has no clock of ours. If a business connects QuickBooks Online (§5.2), eznest keeps its record of what it sent, and the business's saved sign-in, until the business disconnects, and then deletes both. We do not delete them by age. How long Intuit keeps what it holds is governed by the business's agreement with Intuit, not by this policy.

What we do enforce automatically, today:

DataKept
Business-outreach records and the consent evidence behind them3 years from when each record was made. Consent evidence is the exception: it is removed 3 years after the business withdrew its consent, and stays while the consent stands.
Business contact records never contacted1 year, then removed
Personal details of a business that declined outreachRemoved after 90 days (the copy of the listing's address kept on a claim request goes with it)
Requests to claim a business listing (§3.5)A decided request is deleted 3 years after the decision; one still waiting is kept until someone decides it
Operational job logs30 days
Earlier version of a file that was deleted or replaced365 days, then removed (see below)
Marketing opt-outsPermanently — an opt-out is honoured forever, by design
Signed-in account-interaction records (§3.5)90 days by default, removed nightly; the configured period may differ
Firewall request log (§3.5)90 days by default, then deleted automatically; the configured period may differ
Crew photographs of a visit90 days after the photograph reached eznest, then the photograph is deleted, both the entry in the visit record and the stored file. The clock stops for a photograph that a household member has asked us to keep, or that support has put on hold because a dispute or a claim is open; it starts again if that hold is released. A crew's written note about the visit is not a photograph and is not covered by this row.
Security and privacy incident recordsAt least 5 years (see §9). Each record is marked to be kept for five years from the day it is made; no automatic removal runs after that.
Records of when an invoice link was sent, delivered and opened; of an email about an overdue refund; of a plan's billing terms we emailed; and of a completed billing hand-overNo automatic removal. Nothing removes them by age, and the cleanup that may one day remove other delivery records is built never to take these. No period is stated because none has been set

Business records and the one-year row. The row for business contact records never contacted covers a record that eznest has never written to, never had claimed and never decided on, and that our automatic checks against business registers and the business's website have never run on. The registry check runs every day on a limited number of records, oldest check first, and each run marks the records it checks. A record that has been contacted, claimed or checked is not removed by the one-year clock; a contacted record's outreach evidence follows the three-year row, a declined record follows the 90-day row, and a suppressed or hidden listing is kept, as §3.9 explains.

Two more numbers worth knowing: database backups are retained 7 days, so deleted data persists in point-in-time recovery for up to a week; and the logs our servers write (the website, the application and the virus scanner) are retained 30 days. Other logs are kept longer. The firewall request log is in the table above. The record of network connections to and from our servers, which holds the addresses, ports and sizes of the connections and no message or file content, is retained 90 days. The record of administrative actions taken in our cloud account is retained 365 days where it can be searched, with a copy in our file storage that is removed after 400 days.

Files that are deleted or replaced. Our file storage keeps versions. When a file in it is deleted or replaced — by you, by someone else who may change it, or by eznest itself, as when an upload fails its safety check — the earlier copy stays in the same encrypted storage in Montreal as a previous version, and is removed automatically once 365 days have passed. Nothing in eznest shows or opens that copy; it is kept so that a file lost by mistake is not lost for good. Until it is removed, it is still information we hold, which is why we tell you about it.

What closing your account removes from file storage. When closing your account erases a file (§7.4), every stored version of it is removed, not only the current copy. Closing your account also removes the earlier versions of files of yours that were deleted before the account closed, by you or by anyone else, where our records still show the file was yours. An earlier version stays on the 365-day schedule when our records show the file was someone else's — another household member's or a business's — or belonged to the home rather than to one person, as a file in the home's Documents vault does, or when the record that showed whose it was went with the file. The removal starts as the account closes and is retried until our storage confirms that no version is left. If you want an earlier version removed sooner, ask the Privacy Officer.

Financial records and consent history are kept as described in §7.4. The audit log is kept for 2,557 days unless a legal hold keeps a row longer.


9. Security, and what happens when something goes wrong

9.1 What protects your data

  • Encrypted at rest — the database (AWS-managed keys), file storage, and the cache.
  • Additional field-level encryption with AES-256-GCM for e-signature and financial personal information, with keys held in AWS Secrets Manager. The service refuses to start in production without them.
  • Encrypted in transit — TLS 1.2 minimum, TLS 1.3 supported; all HTTP traffic is redirected to HTTPS. Inside our private network, traffic between the load balancer and the application runs unencrypted; the network itself is isolated and not reachable from the internet.
  • A web application firewall in blocking mode in front of the site.
  • Server-side session revocation — we can invalidate every outstanding session for an account instantly, and we do so on password change, sign-out-everywhere, and account deletion.
  • Role-based access through a single authorization layer, so a homeowner surface cannot reach provider data.
  • An append-only audit log of privileged actions.

9.2 What we are not going to overstate

  • The privileged audit log records actions, not every read of personal data. Separately, the signed-in account-interaction record described in §3.5 keeps endpoint templates and operational metadata, not record IDs, request bodies or response bodies. It is not a record-level data-access log.
  • Audit writes are best-effort: a failure is logged rather than failing your request.
  • eznest has not had an external security audit or penetration test. When it does, we will say so here.
  • The production database runs in a single availability zone. That is a resilience limitation, not an encryption one, and we mention it because we would rather you knew.
  • Two-factor authentication is not available (§3.1).
  • Signing out of your identity provider does not currently propagate to your eznest session; signing out of eznest does.

No system is perfectly secure, and anyone who tells you otherwise is selling something.

9.3 Breach and incident handling

We keep a register of every privacy incident, whatever its size and whether or not anyone was harmed. Recording an incident is unconditional; whether it must be reported is assessed afterwards, and we record both the conclusion and our reasoning. Records are kept for at least five years.

Incidents are classified by what actually happened, including four categories specific to the assistant: a model output containing another user's information, injected content causing an unintended action, a bypassed safety control, and audio captured without its disclosure.

When we will tell you. If we conclude a breach creates a real risk of significant harm to you, we will notify you as soon as feasible, directly. We will tell you what happened, what information was involved, what we have done about it, what you can do, and how to reach the Privacy Officer. We will report the same breach to the Office of the Privacy Commissioner of Canada, and to the Commission d'accès à l'information du Québec where a Quebec resident is affected.

Our internal procedure is published at incident-response-runbook.md.


10. Cookies

We set seven cookies of our own. None of them tracks you, and none is used for advertising:

CookieWhat it doesLifetime
eznest_qtokenKeeps you signed in. Not readable by scripts.24 hours
eznest_inviteCarries your invitation code through sign-up. Set when you open an invitation link, a business-claim link or a contact-claim link. Not readable by scripts.2 hours, deleted once used
eznest_prospectCarries the business listing you are claiming through sign-up, when you open a business-claim link. Not readable by scripts.2 hours, deleted once used
eznest_contact_claimCarries the code from a one-click contact-claim link through sign-up, so the claim can be completed once you are signed in. Not readable by scripts.2 hours, deleted once used
eznest_nextRemembers the page inside eznest you were heading to, such as an invoice to pay, so you land there after you sign in. Not readable by scripts.10 minutes, deleted once used
eznest_kioskKeeps the Home OS kiosk unlocked for a child after their PIN is entered, on that device only. Sent only with pages under the household section of the app. Not readable by scripts.15 minutes
ez_rmRemembers that you prefer reduced motion.1 year

Your browser also keeps four preferences on your device. They live in your browser's local storage, not in a cookie: the theme you chose (light, dark or follow your device), under ez_theme; the width you set for the eznest AI panel, under ez_nestor_panel_width; whether the Dispatch page shows the board or the list, under eznest-dispatch-view; and the menu shortcuts you pinned, under ez_pinned_<role>_<name>, a key that carries your role and your name, or your email address if your account has no name. If you pinned shortcuts before pins were kept for each person, the website still reads them from ez_favs_<role> in your browser until you change your pins. None of them is sent to eznest, and clearing your browser's site data resets them.

Drafts stay in the tab you wrote them in. A message or a support request you have not sent yet, and a request still on its way to eznest, such as a visit you are scheduling, a rebooking request to a provider you saved, or a provider's contact details you are adding to your home, are kept in that tab's session storage, so that a refresh neither loses them nor sends them twice. Each stays there until it is sent or you close the tab, and only what you send reaches eznest.

Clerk sets its own cookies to maintain your sign-in. Those are theirs and are governed by their privacy policy. The Stripe payout controls on Business → Payouts and the Google map that appears after you press Show map on a public business page load in Stripe's and Google's own frames, which set their own cookies under their own privacy policies.

There is no advertising cookie, no analytics cookie and no third-party tracker anywhere in the product. That is also why you will not see a cookie consent banner: every cookie we set is strictly necessary to sign you in, carry you through sign-up or a claim, return you to the page you were going to after you sign in, or keep a child's restricted session on a household's kiosk, or it remembers a preference you chose.


11. Children

eznest is for adults. You must be the age of majority in your province to create an eznest account and to accept this policy and the Homeowner Marketplace Agreement.

A child may use eznest inside an adult account holder's household without being a party to this policy or to that Agreement. A child accepts neither document and has no account of their own to sign in with. The adult account holder who sets up the child's profile accepts both for themselves, consents on the child's behalf, and is responsible for the child's use, as §2 of the Agreement says. We record that consent.

Household child and teen accounts are different, and deliberately so. A guardian, meaning the owner, an administrator or a manager of the household, can create a profile for a young person in their household. The profile has a name, an optional date of birth, an avatar and a PIN the guardian chooses, which we keep only as a one-way hash, not as the PIN itself. Its email address is an internal placeholder, not a real mailbox, and it has no password and no phone number of its own. A young person uses the profile on a shared device after the guardian enters the PIN from the guardian's own signed-in account; on the website that session locks again after 15 minutes. The guardian sets what that profile may do: whether it can take part in the allowance with real money and up to what weekly amount, whether its reward requests need approval, whether it can claim bonus chores, and how far it can open the household's home document vault, which starts closed and never lets a young person delete, share or export a document. eznest AI is off for a young person until the guardian switches it on, and even then it keeps only a short list of read-only help about their own screens. A young person's profile cannot be given access to the household's projects, quotes or visit photos, which are for adult members only. The eznest apps give a young person's profile the household chore board, the coin balance and the reward store, and no screen for messages with a business, and the eznest server refuses a young person's profile any request to open a conversation with a business, to write in one or to hold its live connection. We collect nothing else about a young person beyond what these household tools need. We do not use a young person's information for advertising, and we do not sell it.

A guardian can see, export and delete a young person's account data at any time. Until the guardian deletes it, we keep a young person's profile as we keep any member's data (§8.2).

What a guardian's download of a young person's data contains. It holds the young person's own records, in the same machine-readable form as the download in §7.1, including their profile and parental controls, notes, to-dos, notifications, personal-finance records, eznest AI conversations and the profile eznest AI keeps of them, preferences and usage, the chores assigned to them, their reward balances and history, their allowance records, and the parental consents we recorded. It leaves out other members' records, and the household's shared homes, projects, requests and Garage records, which the young person can reach only by belonging to the household. Apart from the profile and parental controls, it leaves out everything §7.1 says the download leaves out, including the files themselves and the raw inputs and results of the tools eznest AI used.

What deleting a young person's profile does. It closes that young person's account the way §7.4 closes an adult's, limited to what belongs to them. Their name, email and phone on the account record are replaced, the account is marked deleted, and every sign-in session and access token of theirs stops working. Their date of birth, avatar and PIN are removed. Everything that is theirs alone is erased: their home notes and other personal content, any personal-finance records, their eznest AI conversations and profile, their notifications, and their allowance account (coin balance, its history, reward requests and cash payouts), along with the chores assigned to them. The household's own chore and reward lists, and its shared home records, are not theirs alone and stay; §7.4 explains the household records we do not yet erase.

What we keep, and why. The consent history for the profile survives the deletion, because it is the evidence of what the guardian agreed to and when: the record that the profile was created, any consent to real allowance payouts, any export, and the record of the deletion itself, each recording which guardian acted and when. The young person's name is removed from the wording of those records. The audit log keeps the entry that the profile was deleted, and the household's roster keeps a removed entry with no date of birth, so the guardian's own history stays intact.

Closing your own account does not delete a young person's profile. It erases what is yours (§7.4). To remove a young person's profile and what is theirs alone, delete the profile first.

If you believe we have information about a child outside that structure, write to privacy@eznest.ca and we will delete it.


12. Quebec residents

Quebec's Act respecting the protection of personal information in the private sector, as amended by Law 25, gives you rights in addition to those above:

  • A named person in charge. Our Privacy Officer (§2) is that person.
  • An incident register. We maintain one, covering all confidentiality incidents regardless of severity, kept at least five years (§9.3), and we notify the Commission d'accès à l'information where there is a risk of serious injury.
  • Portability. You can obtain the personal information you gave us in a structured, commonly used technical format (§7.1).
  • De-indexing. You may ask us to stop disseminating your personal information, or to de-index a link, where dissemination causes serious injury to your reputation or privacy.
  • Automated decisions. Where a decision is based exclusively on automated processing, you are entitled to be told and to have it reviewed by a person. §6.5 describes the automatic action you can switch on for eznest AI, which you can turn off at any time, and the decisions eznest makes by rule, which the automated-decision inventory lists with the information each uses and its principal factors. To ask for a person to review one of those decisions, write to the Privacy Officer (§14). If we add another, we will tell you before it takes effect.
  • Transfers outside Quebec. The Clerk, Amazon Bedrock, Twilio and Apple processing described in §5.2, §6 and §8.1 takes personal information outside Canada. The Twilio flow happens only if you turn text messages on, and stops when you turn them off or reply STOP. Homeowner website address entry and provider business lookup reach Google Places in the United States. Pressing Show map on a public business page sends Google your IP address, eznest's website origin and the business's listed address. The Home weather card's forecast, and adding one of its weather alerts as a to-do, send the home's city and the coordinates eznest looked up to Open-Meteo, which processes in Switzerland and on servers in the European Union and the United States. A digital-signature fingerprint reaches DigiCert in the United States when a document is signed. A private visit calendar link you add to a calendar service (§5.3) lets that service, which you choose, fetch your visits from eznest and keep them wherever it holds your calendar, which may be outside Quebec.

Correspondence with our eznest.ca mailboxes is also held separately in Google Workspace and may be stored and processed outside Canada, including in the United States, as described in §8.1.

A Canadian French version of this policy is published at eznest.ca/fr/privacy, and this English version is published at eznest.ca/privacy. The two carry the same version number, the same effective date and the same last-updated date, and we change them together: a change to one is made to the other in the same publication.


13. Changes to this policy

If we make a minor change — clarifying wording, correcting a link, adding detail that does not change what we do with your information — we update this page and the "last updated" date.

If we make a material change — a new purpose, a new processor receiving your personal information, a change to how long we keep something, or a reduction in your rights — we will:

  1. tell you at least 30 days before it takes effect, by email and in the app;
  2. explain what changed and why, in plain language;
  3. where consent is required, ask for it again rather than assuming it.

Continuing to use eznest after a material change takes effect means you accept the updated policy. If you do not, you can close your account under §7.4.

We record what you accepted. When you create an account, we record which version of this policy and of the Marketplace Agreement was in force, when, and from what address — so that if it is ever in question, the answer is a record rather than an assumption. That record is kept even after you close your account, because it is the evidence of what we were permitted to do. It appears in your consent history.


14. Contact

Niruban Kandasamy, Privacy Officer Eznest Technologies Inc. (CBCA no. 1801532-5) 226 Kinloch Court, Nepean, Ontario K2J 5S9, Canada privacy@eznest.ca

Office of the Privacy Commissioner of Canada — priv.gc.ca · 1-800-282-1376 Commission d'accès à l'information du Québec — cai.gouv.qc.ca


Appendix A — Related documents

DocumentWhat it is
Homeowner Marketplace AgreementThe terms between you and eznest for using the marketplace.
Acceptable Use PolicyWhat you may and may not do on the Platform.
Privacy and Ethics CharterThe commitments this policy is built on, including no data mining and no pay-to-rank.
Subprocessor registerThe services that process information for us, supported by application integration checks or operating records.
What each outside service holds, and for how longFor each of those services: what it receives, how long it keeps it by default, how eznest deletes or redacts it, and who decides. Where no period has been supplied it says so.
Incident response runbookHow we record, assess and report privacy incidents.

Appendix B — Change log

v1.13.0, clarified 2026-11-05 (the server refuses a child's profile any message request; minor change under §13). §11 now states that the eznest server refuses a young person's profile any request to open a conversation with a business, to write in one or to hold its live connection. The earlier entry of the same date, below, recorded that the server did not yet refuse a message request made through the profile; it did not, and it now does, so the sentence that said so is gone from §11. The server gives that profile one refusal, the same for every one of these requests, whether or not the profile is already a member of the conversation, and it gives the same answer for the messages and photos on a household project, which a young person's profile cannot be given access to. This describes what the server now does and corrects a limit §11 had stated; it adds no purpose, no party that receives personal information, no collection and no retention period, and it reduces no right. Under §13 we classify this as a minor change, as the entries below it are. The earlier entry is left as it was written. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-11-05 (a child in a household; minor change under §13). §11 now says, from what the Platform does today, that a child may use eznest inside an adult account holder's household without being a party to this policy or to the Homeowner Marketplace Agreement; that the adult who sets up the profile accepts both, consents on the child's behalf and is responsible for the child's use; what the profile holds (a name, an optional date of birth, an avatar and a PIN kept only as a one-way hash, with a placeholder email address and no password or phone number); how a young person uses it on a shared device; what the guardian controls; that eznest AI is off until the guardian switches it on; that the apps give the profile the chore board, coin balance and reward store and no screen for messages with a business, and that the server does not yet refuse a message request made through the profile; and that closing the guardian's own account does not delete the young person's profile. It also removes two statements the Platform did not back: that a guardian sets quiet hours for the profile and whether it can use the marketplace at all. The Platform stores those two settings but nothing acts on them, and the website no longer offers them. Under §13 we classify this as a minor change: it adds no purpose, no party that receives personal information, no collection and no retention period, reduces no right, and corrects the description of what already happens. Whether the law lets a child be bound by, or be a data subject without the guardian's consent, is for counsel; that question is counsel's and is filed on the tracker as a counsel item linked to BUG-761.

v1.13.0, clarified 2026-10-30 (extensions are recorded; minor change under §13). §7.7 said the Privacy Officer keeps a decision to extend the time to answer a request in the officer's own request log, and that our administration tools did not record an extension. They now do: for each extension they record who extended the request, when, why, and the new date, which cannot be later than a limit set in eznest's settings. A request that is past its answer date is closed only with a recorded reason it was late. §7.7 still states no length for an extension. This describes what the request record now does, and adds no purpose, no party that receives personal information and no retention period, and reduces no right. We classify this as a minor change under §13 for that reason; whether the law allows a given extension is the Privacy Officer's case-by-case question with counsel, and this entry states no legal conclusion. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-28 (what Download my data contains: phone number, message text, support tickets, disputes, quotes and provider profile; minor change under §13). §7.1 said the download left out the phone number on your profile, the text of your messages, your support tickets, your disputes, your quotes and your provider profile, and said we were working to close that gap. Download my data now includes them, and the file's layout version rose with them. §7.1 lists each part and lists what stays out. The other people in a message, support ticket, dispute or quote appear only as account or business identifiers, never by name, email address or phone number; the messages other people sent you, the notes only eznest staff can read on a support ticket, the verification documents and portfolio of your provider account, and the card-network chargeback cases on a business's payments are not included. An automated check in our build holds §7.1 to the download, as it has since v1.9.1. We classify this as a minor change under §13: it gives you a fuller copy of information we already hold and changes no collection, purpose, recipient or retention rule. The effective date and acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-28 (the French version is published; minor change under §13, proposed). §12 no longer says a French version will be published later. It now says that the policy is published in Canadian French at eznest.ca/fr/privacy, that the English and French versions carry the same version number, effective date and last-updated date, and that we change them together. The French page is public, and the website's other pages stay in English. This describes how the policy is published and changes nothing we do with personal information: no purpose, recipient or period is added and no right is reduced. We propose to classify it as a minor change under §13 for that reason. Whether the French text carries the same legal weight in its terms of art, and whether a certified translation is needed, are questions for Quebec counsel, each recorded as its own work item owned by counsel; this entry states no legal conclusion. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-28 (the Privacy Officer is named with the full street address; minor change under §13). §2 and §14 now read “Niruban Kandasamy, Privacy Officer” above Eznest Technologies Inc., and spell the street as 226 Kinloch Court. The person, the address and privacy@eznest.ca are the same as before. It changes nothing eznest does, and adds no purpose, recipient, retention rule or processor. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-26 (six kinds of record with no automatic expiry; the invoice and refund records kept out of the cleanup; minor change under §13, proposed). §8.2 now names six kinds of record that have no automatic expiry: the messages between you and a business on a project and the photographs sent in them, the notifications in the app, the record of the emails and push notices we sent or chose not to send, the record of the text messages we sent or chose not to send, the history of events that other records point to, and support requests with their replies and images. It says we have set no period for any of them and state no legal basis, that our nightly cleanup has a removal for each that is switched off, and that a kind of record is added to the table only when a period is set and its removal is running. It adds one row to the table and one paragraph saying that the record of when an invoice link was sent, delivered and opened, the record of an email about an overdue refund, the copy of a plan's billing terms we emailed and the notice of a completed billing hand-over are never taken by that cleanup and are removed by no automatic clock; it states no period for them because none has been set. This adds detail about records we already keep and changes nothing we do: no removal runs, no purpose, no recipient and no period is added. We propose to classify it as a minor change under §13 for that reason. Whether a notice is owed is a question for counsel, recorded on the work item messages-notifications-delivery-records-event-history-sms-re (T-5410); this entry states no legal conclusion. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-25 (requests to claim a business listing; minor change under §13). §3.5 now lists what we keep when someone who says they act for a listed business, and whose email address on the listing is missing or cannot be used, asks us to let them claim it: the name and email address they give for our reply, the address the listing had, the registry details and the evidence of authority they write, the IP address and browser user-agent of the request, the times and, once decided, who decided and why. The request is not linked to an account and gives no one access by itself. §8.2 says how long it is kept: a request still waiting until someone decides it, and a decided request for three years after the decision, or sooner together with a never-contacted listing when the one-year removal removes the listing; the copy of a declined listing's old address goes with the listing's own address after 90 days. Three years is the period of the nearest comparable record, the public report that a listing is not that business (§3.5), and whether it is the right period is counsel's question, filed as T-7322. This describes what the server does with this change and adds no purpose and no party that receives personal information; it concerns people who are not account holders and reduces no right. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-25 (eznest AI: what the removal will not reach; minor change under §13). §3.6 and §8.2 now say that the removal of conversations, once it runs, takes a person's profile and pinned notes only together with the last conversation it removes: a profile that has no conversation when it runs is not found by it, and stays until the member deletes it with the control in §6.6 or closes the account (§7.4). They also say that a separate cleanup of such profiles has not been built or run. The rule in §3.6 is unchanged; this says what the coming removal does not yet reach. It changes nothing eznest does, because no automatic removal runs yet, and whether to clean such profiles up is not decided; this entry states no legal conclusion. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-25 (how a request is handled; extension; refusal). §7.7 now says what happens after you write to the Privacy Officer, in addition to the 30-day standard it already gave. The 30 days run from the day the request reached us. Our administration tools can record each request with its kind, the day it arrived, the day an answer is due, when you were told it arrived and how it closed; a copy of your information or an erasure waits for a match to your account and a check that it is you, and an erasure also waits for a second member of staff to agree. §7.7 also says that the Privacy Officer may extend the time once where the law allows it, by writing to you before the 30 days end with the reason, the new date and the complaint route (§7.6), and that an extension is kept in the Privacy Officer's own request log because the administration tools do not record one yet; and that a refusal is given in writing with its reason and the complaint route, and is recorded as refused. §7.7 states no length for an extension. This describes how requests are already handled and what the request record already does, adds no purpose, no party that receives personal information and no retention period, and reduces no right. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again. Under § 13 we classify this as a minor change, like the clarifications beside it: it describes handling that already happens.

v1.13.0, clarified 2026-10-24 (what the guardrail restricts). §6.4 said the guardrail restricts personalised legal or financial advice and medical diagnosis. That was wrong for production: the three denied topics exist in the guardrail's working draft but not in the version that production attaches, so the guardrail does not restrict those topics today. §6.4 now says so. Nothing else about the guardrail changes: what it blocks, what it filters and what it does not cover are as before. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-24 (support requests: images and the build; minor change under §13). §3.3 now describes what a support request keeps. Besides what you write and the replies, it can hold up to three images you attach to the request or to a reply, which are stored privately, checked and scanned before they are kept, and opened only by you and eznest support staff through a short-lived link. The apps and website may also send the platform, the app version and the operating system version they are running, and nothing else about the device is kept. Support requests were already listed in §3.3 and §8.1, and this adds no processor and no new purpose. The section also says plainly that closing your account does not delete support requests today and that no keeping period has been set. The effective date and the acceptance version are unchanged.

v1.13.0, clarified 2026-10-24 (text messages at Twilio; minor change under §13). §8.2 no longer says eznest has no way to delete a text message at Twilio. It now says what closing your account does about the texts eznest sent through Twilio: eznest asks Twilio, server to server, to delete each text it sent for you, by the message id it recorded when it sent it; it tries once, at that time, and records any deletion that did not succeed so that it can be tried again. It also says what that does not reach (a text sent before eznest recorded whose text it was, other than the confirmation sent when you turned texts on, and your own replies to us, such as STOP) and that we have not established what Twilio keeps for its own legal reasons after a deletion. The register behind it, processor-retention-register.md, says the same. The deletion ships in the same release as this wording. Under §13 we classify this as a minor change: it describes the keeping and deleting of texts that eznest already sends, adds no purpose, no party that receives personal information and no retention period, and reduces no right. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-24 (what stays with the outside services; minor change under §13). §8.2 now says what stays with the outside services listed in §5.2 once your account is closed, and Appendix A lists the table behind it, processor-retention-register.md. For each service the table states what it receives, how long it keeps that by default, how eznest deletes or redacts it, and who decides. We have not been given a period for most of those services, and §8.2 and the table say that in so many words instead of publishing one we cannot back; the periods eznest itself sets, for the earlier versions of files, database backups and imported busy times, are unchanged and are the ones already in this policy. The table also records two points for counsel that this policy does not decide: how long the tax and invoice records at Stripe may be kept, and the delivery ledger. Under §13 we classify this as a minor change: it describes processing and keeping that already exist, adds no purpose, no party that receives personal information and no retention period, and reduces no right. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-24 (what Intuit QuickBooks receives; minor change under §13). §5.2 now describes the QuickBooks Online connection in full, where before it was only a name in the list of what is built and switched off. It says who connects it (an owner or admin of a business, signing in on Intuit's own page), what eznest's server sends Intuit when the business starts a sync (the household's name as a customer, and for each charged milestone an invoice with the project's request text, the milestone's title, the amount before tax, the charge date and an eznest reference, and no street address, email address or phone number), what Intuit sends back, that our processor register gives the United States for processing and storage, how a business disconnects and what that deletes and keeps, and that eznest cannot remove what Intuit already holds in the business's own QuickBooks company. The plain-language summary (item 3), §7.4, §8.1.1 and §8.2 carry the matching sentences. We checked each statement against the adapter, the sync service and the disconnect code. Under §13 we classify this as a minor change: the connection is switched off, so Intuit receives nothing today, and the change adds detail about something that does not yet run; it adds no purpose, no party receiving personal information today, no change in how long anything is kept, and no reduction of any right. Switching the connection on is a different event, and it is a material change under §13: Intuit then becomes a processor receiving personal information (a household's name and project text). eznest will therefore tell people at least 30 days before it switches the connection on, by email and in the app, and will move the acceptance version when the processor register shows Intuit as live; the notice to businesses is provider-notice-quickbooks.md. The effective date and the acceptance version are unchanged by this entry, and no one is asked to accept this policy again today.

v1.13.0, clarified 2026-10-24 (when police ask for a member’s information). §5.4 now says what eznest does when police or another public body ask for information about a member, and when eznest itself reports a matter to the police. It describes how eznest already handles such a request under its internal referral-to-authorities procedure: it goes to the Privacy Officer, who checks it is genuine, asks counsel, and provides only what is asked for and confirmed. It states no legal conclusion about what a law requires. Under §13 we classify this as a minor change: it adds detail about existing practice and changes no purpose, recipient, retention rule or right. The effective date and the acceptance version are unchanged.

v1.13.0, clarified 2026-10-24 (the retention table checked against what the systems enforce). We compared each period in §8.2 with the retention rules in the database, the nightly removal jobs and the cloud settings that apply them; the comparison is written out in section 4.1 of the records of processing. Every period in the table matched a rule that runs, and three statements were corrected. The table row for business-outreach records and the consent evidence behind them said 3 years for all of it; the nightly job removes consent evidence only 3 years after the business withdrew its consent, so consent evidence that was never withdrawn stays, and the row now says so. The row for security and privacy incident records said 5 years, but the register only marks each record to be kept until five years after it was made and nothing removes it afterwards, so §8.2, §9.3 and the list of safeguards now say at least five years. The sentence that said system logs are retained 30 days was true of the website, application and virus-scanner logs only; the production network now also keeps a record of network connections for 90 days, and the cloud account keeps a record of administrative actions for 365 days with a copy in file storage removed after 400 days, and §8.2 now says so. Each correction describes keeping that already happens, and none adds a purpose, a recipient or a right. The two longer-kept logs are described in this policy for the first time, and the connection record is not yet listed in §3.5. Whether §13 treats this as a minor or a material change is not decided here. The effective date and the acceptance version are unchanged.

v1.13.0, clarified 2026-10-24 (businesses listed from public sources). §3.9 now has a passage, Businesses we list from public sources, on the business record we keep for an Ontario service business that has not joined eznest: what it holds, the three ways a business can get out (the link in the email, the listing's own controls, and a message to the Privacy Officer), what is removed and when, and what is kept. §8.2 gains a paragraph under its table saying what the one-year row for never-contacted records does not cover. We checked each statement against the code and the retention policies that drive it (RetentionPurgeJob, migration V23, UnsubscribeResource, AdminProspectResource, ProspectLifecycleService, ProspectImportService). That check found two things the policy had not said. The one-year removal applies only to a record that has also never been checked against business registers or the business's website, and the daily registry check marks every record it runs on, so a checked record leaves that clock. And a suppressed or hidden listing is kept in full with no removal date, because no automatic full deletion of it exists yet. Both describe processing that already ran, and neither adds a purpose or a party receiving personal information. They state a longer period of keeping than a reader of the table alone would have taken, so they are flagged for counsel, who is asked whether a suppressed listing may be kept without a removal date and whether the one-year row should run from collection whatever the checks have done. This entry answers neither question, and it does not decide whether §13 treats the change as minor or material. The effective date and the acceptance version are unchanged. The prospecting document (docs/product/provider-prospecting-engine.md, §8 and §9) was corrected in the same change.

v1.13.0, clarified 2026-10-23 (annual review of this policy; minor change under §13). We prepared the annual review of this policy, for the Privacy Officer and counsel to read, by checking its factual statements against our code, configuration and registers; the record, privacy-policy-annual-review-2026-10-23.md, lists each statement checked, each correction made and what counsel is asked to see. The check found three statements to correct. §3.7 said the bank statement file you upload is written to the container's own disk and should be treated as temporary. That no longer matches how production is configured: since the 2026-10-01 change that stopped statement files being lost at every deploy, the file is kept in the Amazon S3 storage in Montreal that holds your other uploads, encrypted by eznest before it is stored; §3.7 now says so, and that the file stays until you delete the imported statement or close your account, with an earlier copy of a deleted or replaced file kept for the 365 days §8.2 gives. §6.6 named the control that clears your eznest AI history Make eznest AI forget me, but the website and the iPhone app call it Erase eznest AI history, and it said eznest AI then starts over knowing nothing about you, although eznest AI can still look up the account and home information you allow it to access; §6.6 now uses the real name and says that. §5.2's list of what is built but switched off did not mention the import of busy times from a business's own Google Calendar or an Outlook calendar link, which exists in our code, is off in production and receives nothing; §5.2 now names it and says what eznest would keep if it were switched on. Under §13 we classify this as a minor change: each correction describes processing that already existed, or something that is switched off, and none adds a purpose, a party receiving personal information today, a change in how long anything is kept, or a reduction of any right. The §3.7 correction states a longer period of keeping than the sentence it replaces did, so the record flags it for counsel. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.13.0, clarified 2026-10-23 (the firewall request log). §3.5 now lists the firewall request log: the firewall in front of eznest’s servers writes a log of the requests it checks, and that log stores the IP address and browser or app user-agent of every request it records for 90 days by default, in Canada, with credential headers, cookies, the referring address and the whole query string blanked and with requests to private links left out. §8.2 lists its retention. The sentence at the end of §3.5 that said we keep no generic web-server access log is reworded, because the firewall log is a record of requests outside the signed-in service. This describes a log that the infrastructure change waf-traffic-is-logged-to-canada-with-calendar-feed-urls-reda (T-4548) turns on; the policy and that change release together. The effective date and the acceptance version are unchanged. Under § 13 we classify this as a minor change: the log records requests the firewall already checks, adds no purpose and no party that receives personal information, and its contents and keeping period are stated here.

v1.13.0, clarified 2026-10-22 (how long eznest AI keeps conversations). §3.6 and §8.2 now state the rule the founder decided on 2026-10-22: conversation text is kept for six months after the member's last message, or until the member deletes it if that comes sooner; the profile and its pinned notes are kept only as long as the conversations they were built from; the same period applies in Quebec. Both sections say that no automatic removal runs yet, so what eznest does with conversations today is unchanged: they stay until the member deletes them or closes the account. The Quebec question and the legal basis are open points for counsel, and this entry states neither. The effective date and the acceptance version are unchanged. Under § 13 we classify this as a minor change: it states a retention limit that is shorter, not longer, than keeping conversations indefinitely.

v1.13.0, clarified 2026-10-21 (Garage records; minor change under §13). §3.2 names the vehicles and machines, readings, parts, service records, reminders and notes already stored in Garage. §7.1 describes the Garage records already included in the account download, its access limits, and the separate household Garage file archive. §7.4 makes explicit that Garage records stay with the household when one member closes an account and that household transfer and deletion rules remain unfinished. This adds detail about existing collection, export and retention; it changes no processing purpose, recipient, retention rule or right. The effective date and acceptance version are unchanged.

v1.13.0 — 2026-10-21 (a public report that a listing is not that business). §3.5 now lists what we keep when someone reports, without signing in, that a public business listing is not that business (This isn't my business on the claim page, or Not your business? Ask us to remove this listing on the listing's page): the IP address the report came from, the browser user-agent, and the time it was made. We keep them as evidence of the request so someone at eznest can judge it, and to limit abuse; the report is not linked to an account. It is kept with the listing's record and deleted three years after the report was made, or sooner for a business we have never contacted: the one-year removal in §8.2 deletes it with the listing once someone at eznest has dismissed the report and the year since the business's details were collected has passed. Until this change §3 listed each record that carries an IP address one by one and said we keep no generic web-server access log, but did not mention this report. Under §13 we classify this as a minor change: the report is not linked to an account and changes nothing about what we do with an account holder's information, no new party begins receiving personal information, no retention period of an existing record changes, and no right is reduced. The effective date moves to 2026-10-21; the acceptance version is unchanged, and no one is asked to accept this policy again.

v1.12.0 — 2026-10-20 (erasure at Stripe, and the payment records kept there). §7.4 now describes the Stripe half of closing an account. Payments are processed by Stripe, and where eznest has created a customer record for a person there, account erasure removes the person's name, email address, phone number, address and saved cards from each Stripe customer record eznest created for them, while the customer record itself and every charge, invoice, payout and tax record attached to it stay, required for tax and accounting like the ledger records already listed. If Stripe cannot take the removal when the erasure runs, it is recorded against the anonymized account as owed and retried until it is done — the way the Clerk sign-in release already works. Under §13 this is a minor change: Stripe is already named as a processor in §5.2, no new purpose is added, no new party begins receiving personal information, no retention period changes, and no right is reduced — the section adds detail about an erasure step and names the payment records that stay. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.11.1 — 2026-10-20 (correction: who hosts our email). Earlier versions of this policy did not name the service that hosts our eznest.ca mailboxes, including privacy@eznest.ca and support@eznest.ca, which this policy tells you to write to. That service is Google Workspace (Gmail), provided by Google LLC, and our operating records show we have used it since August 2026. This version names it in the plain-language summary, §2, §5.2, §8.1, §8.2 and §12, and §3.9 now covers people who write to these mailboxes without an account. It says what Google receives, that this mail may be stored and processed outside Canada, including in the United States, and that we have not verified a region restriction or an automatic expiry schedule for it. It also separates this mail from the Platform's Canadian storage and from the AWS SES service that sends the Platform's automated email. Under §13 we classify this as a minor change: it names a service that was already in use and does not change what we do with your information, so no notice was sent before it was published. The acceptance version is unchanged, and no one is asked to accept this policy again.

v1.11.0 — 2026-10-19 (the Home weather card's forecast). §5.2 now lists Open-Meteo among the companies that process data for us. When the Home weather card shows a forecast, eznest's server sends Open-Meteo's geocoding service the home's city (the city name only, and only when eznest has not already looked that city up), then sends its forecast service the latitude and longitude the geocoder returned for that city — the city's point, not the home's own location — unless a forecast from the last 30 minutes is already held. When someone adds one of the card's weather alerts as a to-do, eznest's server reads the forecast again the same way, so that path also sends the city name (only when not already looked up) and the city's coordinates, unless a recent forecast is cached. A provider's storm watch for one of its business service areas sends Open-Meteo's geocoding service that service area's city. Open-Meteo receives no account identifier, name, street address or browser address, and the province is not sent: eznest's server uses it only to pick the Canadian match from the geocoder's answers. Open-Meteo processes in Switzerland and on servers in the European Union and the United States, and §12's list of transfers outside Quebec now includes the weather lookup. Until this change §5.2 counted weather among the public reference data we send nothing about you, and our subprocessor register said Open-Meteo received no personal information, while the forecast lookup already sent the home's city and its coordinates. Under §13 this is a material change: it names a new processor receiving your personal information. The effective date and the acceptance version move to 2026-10-19, so a returning user on the website, iPhone or Android is asked to accept this version before continuing protected work; their earlier acceptance remains in the record. This version took effect on 2026-10-19, the day it was published, and not 30 days after an advance notice as §13 describes for a material change. No email or in-app announcement of it was sent before it took effect; a returning user is asked to accept it, as described above. The reason is that the version corrects a description of a lookup that was already running: holding the correction back for 30 days would have left the wrong description published for that time, and eznest has no live clients yet. §13 still describes how we make a material change.

v1.10.0 — 2026-10-18 (a young person's download). §11 now says what a guardian's download of a young person's data contains and what it leaves out. Until this change that download held only the young person's profile and parental controls, although §11 already said a guardian could export the young person's account data. It now holds the young person's own records in the same form as the download in §7.1, together with the chores assigned to them, their reward and allowance records and the parental consents we recorded. It leaves out other members' records and the household records the young person can reach only by belonging to the household. Under §13 this is a minor change: it gives a guardian a fuller copy of the young person's own data without a new purpose, processor, retention period or reduction in rights. The effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (what Download my data contains). §7.1 said the download left out your sign-in sessions, your registered devices, the sign-in methods linked to your account, your eznest AI conversations, the profile eznest AI keeps of you and your AI usage records. The download already contained all six; the list was wrong. §7.1 now lists what the download contains, part by part, as the download builds it, including parts the old list did not name, such as your household's requests, projects with businesses and shared schedules, Garage records, consent history, your agreement to receive visit texts, quiet hours, Project Twin records and receipts for actions you took. It also lists what the download leaves out, and names four kinds of record the old list implied were included and are not: the verified reviews you left after a closed job, the milestones of a project that reached your household only because you claimed the customer record a business kept for you, the messages you sent in the conversation on a project a business runs on eznest or in a business's Crew chat, and the requests you sent asking a business listed on eznest to contact you, with the message you wrote in each. The old list said message bodies appear as a count; that count covers the messages you sent in eznest conversations, including a posted job's conversation with the business you hired, and not the conversation on a project a business runs on eznest or a business's Crew chat. The old list named milestones without saying what each holds; §7.1 now says that each has its amount and status, and that when it was submitted, approved or charged, and whether and how much of it was refunded, appear only where they were recorded. An automated check in our build now fails when the download gains or loses a part that §7.1 does not list, or comes to include something §7.1 says it leaves out. We classify this as a minor change under §13: it corrects the description of a copy we give you on request, and changes nothing about what eznest collects, why, who receives it or how long it is kept. Naming four kinds of record the download does not contain corrects a description; it does not reduce a right, because the download never contained them and the Privacy Officer still assembles anything it leaves out. The effective date and acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (deleting a young person's profile). §11 now says what deleting a household child or teen profile erases and what it keeps. Before this change the deletion marked the profile removed and the account deleted but left the young person's name on the account record, their date of birth, their allowance account and their other records in place, which §11's "delete a young person's account data" did not describe. The deletion now runs the account erasure of §7.4 for the young person's own records. We classify this as a clarification of v1.9.1: it removes data on a request the policy already describes and adds no purpose, recipient or retention, so no new acceptance version is introduced.

v1.9.1, clarified 2026-10-18 (automatic actions). §6.5 described one automated action, a threshold a member sets for approving small milestones automatically. No such setting exists: eznest does not approve a milestone for a client, and the setting refuses a change. §6.5 no longer describes it. It now describes the automatic action that does exist, the opt-in switch that lets eznest AI go ahead with its own small, reversible actions without asking (off by default; the five things it covers: a to-do, a reminder, a note, a saved business and a home system recorded in My Home; where the switch is on the iPhone and the website; turning it off restores an approval card for every action), says that eznest AI otherwise suggests and drafts and the member decides, and points to the automated-decision inventory for the decisions eznest makes by rule. The last paragraph of §6.4 said that every action that changes something requires your explicit confirmation; it now says so unless you switch on automatic actions, which covers only the small, reversible actions named in §6.5. The automated-decisions line in §12 now repeats this instead of saying no such decision is made. Under §13 this is a minor change: it corrects the description of existing behaviour, without introducing a new purpose, processor, retention period or reduction in rights. The last updated date is unchanged because it already reads 2026-10-18; version 1.9.1, the effective date and the acceptance version remain unchanged. No new acceptance is required and no material-change notice is sent.

v1.9.1, clarified 2026-10-18 (AI consent and filtering). §6.3 incorrectly listed AI-assisted features as operating without a consent check, and §6.4 incorrectly said we did not use the AI service's content filtering. §6.2 said eznest AI could not read another user's information; it now says that what eznest AI looks up for you can include words other people wrote that you can see, such as a business's quote or a conversation's messages. §6.3 and §6.4 now describe the existing consent checks, the separate personalization consent for AI memory, the additional checks on other people's words when a summary, comparison or score is asked for directly, that only the asking person's consent is checked when eznest AI compares quotes or summarises a conversation inside a conversation, the order in which statement readers are tried, the features that call no AI model, and the Bedrock guardrail enabled in production, including its limits and intervention records. Under §13 this is a minor change: it corrects the description of existing processing and safeguards, without introducing a new purpose, processor, retention period or reduction in rights. The last updated date changes; version 1.9.1, the effective date and the acceptance version remain unchanged. This clarification does not require a new acceptance or trigger the material-change notice process.

v1.9.1, clarified 2026-10-18 (earlier versions of files). §8.2 now says how long our file storage keeps the earlier copy of a file that was deleted or replaced: 365 days, after which the storage removes it automatically. It also says that closing your account removes every stored version of the files it erases, and the earlier versions of your files that were deleted before the account closed where our records still show the file was yours, and it names the earlier versions that stay on the 365-day schedule. The plain-language summary repeats the 365 days. The storage has kept earlier versions on this schedule since before this policy was first published, and §8.2 previously gave only the seven-day backup window for deleted data, which understated how long the earlier copy of a deleted file remained. Nothing about what we collect, why we use it, who receives it or how long we keep it changes; the policy now describes what was already happening. Under §13 we classify this as a minor change that adds detail: the effective date and the acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (crew photographs are deleted after 90 days). §8.2 now lists the retention rule for a crew’s photographs of a visit, which eznest’s systems already enforce each day: a photograph is deleted, with its stored file, 90 days after it reached eznest, unless a household member has asked to keep it or support has put it on hold for an open dispute or claim. §5.1’s paragraph about the photograph a crew takes when it cannot do the work now says so and points to that row. §8.2’s table also now lists the signed-in account-interaction records that §3.5 describes, which are removed each night once they are older than the configured period, 90 days by default; §3.5 already gave that period, and the table had left it out. The plain-language summary and the opening sentence of §8.2 now point to the records in §8.2’s table instead of saying there are no automatic expiry clocks at all. Both rules were missing from this list while they ran; this update describes them. We classify this update as a minor change under §13, because none of the material changes §13 lists applies: it adds no purpose and no processor, it does not change how long eznest keeps anything compared with what eznest already does, and it reduces no right, since a household can keep a photograph. It corrects a retention description to match what the systems do, as the 2026-10-06 audit-log clarification did. The effective date and acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (cookie table). §10 now lists every cookie the website sets, with how long the website keeps each. It named three cookies and now names seven: eznest_prospect, eznest_contact_claim, eznest_next and eznest_kiosk are added. It also corrects the invitation cookie's lifetime from 30 minutes to 2 hours, which is what the website has set since 2026-09-20. It now says that the browser keeps four preferences in local storage on the device (the theme, the eznest AI panel's width, the Dispatch page's board or list view, and the pinned menu shortcuts, whose key carries your name) and that none of them is sent to eznest; that drafts and requests still on their way stay in the tab's session storage until they are sent or the tab closes, and that only what you send reaches eznest; and that the Stripe payout controls and the Google map shown after Show map load in their companies' own frames, which set their own cookies. The cookies, the stored preferences and drafts, and the frames were already in use, and the earlier section should have described them. We classify this update as a minor change under §13, because none of the material changes §13 lists applies: each cookie serves a purpose eznest already had, namely signing you in, carrying you through sign-up or a claim, returning you to the page you were going to after you sign in, keeping a child's restricted session on a household's kiosk, or remembering a preference you chose, so there is no new purpose; no new processor receives anything, since the Stripe frames are the ones §3.8 describes and the Google map is the one §5.2 describes; nothing eznest keeps is kept for a different period; and no right is reduced. The effective date and acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (customers who book without an account, and invitees). §3.9 now names two groups of people who have no account: customers who book a business through its profile page or public booking page on eznest, its booking widget or a booking the business logs itself, and people a household or a business invites by email. For each it lists the details held and the purpose, it says that the one email inviting a customer to claim a booking goes to the address the customer or the business gave us and carries a link to stop us writing to it, and it says how such a person asks for their details to be removed, that the Privacy Officer at privacy@eznest.ca aims to answer within the 30 days in §7.7, and that a business's own copy must be asked of the business. eznest already held these details and already sent that email; the policy did not describe them until this update. We classify this update as a minor change under §13, because none of the material changes §13 lists applies: there is no new purpose, no new party receiving personal information, no change to how long anything is kept, and no reduction of anyone's rights. The version, the effective date and the accepted policy version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (private visit calendars). A new §5.3 describes the private calendar links eznest added on 2026-10-07: what a link sends, that anyone who has a link can read it without signing in, that the calendar service a person adds it to keeps its own copy under its own rules, and how to revoke a link. §3.3 now says what eznest keeps about a link; §5.1 tells a household that a person assigned to its visit can put that visit, with its service address, in a calendar of that person's own choosing; §7.1 and §7.4 add link records to what the download leaves out and what closing an account erases; and §8.1.1 and §12 say that a subscribed calendar is held wherever the person's calendar service keeps it. The former §5.3 and §5.4 are now §5.4 and §5.5. The links were a new thing eznest does, and this policy should have described them when they were added; it did not until this update. We classify this update as a minor change under §13, because none of the material changes §13 lists applies: a link sends visits only after a person makes it and adds it to a calendar, and only to the calendar service that person chooses, which is not a processor eznest engages; the link carries visits that person can already see in eznest, so it adds no purpose of eznest's own; nothing eznest holds is kept for a different period; and no right is reduced, since the person gains a way to stop the sharing at any time. The effective date and acceptance version are unchanged, and no one is asked to accept this policy again.

v1.9.1, clarified 2026-10-18 (operations presence). §3.5 now discloses the existing operations-presence record: an internal account identifier and last recorded signed-in request time in Redis, readable by authorized eznest staff for the five-minute request-activity view. The individual value expires after six minutes; the matching index is pruned on writes and expires six minutes after the last presence write. The earlier policy omitted this record. Under §13 this is a minor change: it adds detail about existing operational processing without changing collection, purpose, recipients, retention or your rights. The effective date and acceptance version remain unchanged. The records of processing now describe the same record.

v1.9.1 — 2026-10-08 (name only). The assistant built into eznest is now called eznest AI; earlier versions of this policy call it Nestor. Only the name changed. The assistant, what it collects, how it is processed and where, how long it is kept, and your choices are exactly as described in v1.9, so the effective date and the acceptance version are unchanged and no one is asked to accept this policy again. Entries below keep the name used at the time.

v1.9, clarified 2026-10-06 (records-of-processing alignment). §8.2 now states the audit-log retention period that has existed in code since V234: 2,557 days unless a legal hold keeps a row longer. The earlier sentence said the audit log was kept indefinitely, which no longer matched the retention policy table. This is a correction to a retention description, not a new collection, use or disclosure.

v1.9 — 2026-10-06. Disclosed the already-live Google Places address entry in the website's Add a home and new-project forms: from the third typed character, eznest's server sends Google the address text typed so far, and if a suggestion is selected, the selected place ID. Google returns address details, including latitude and longitude, and the new-project form saves those coordinates on the property record. This version asks returning users on the website, iPhone and Android to review and accept the current policy before continuing protected work; their earlier acceptance remains in the record.

v1.8 — 2026-10-04. Disclosed the Google map on a public business page and the data Google receives when a visitor presses Show map. The map now loads only after that action and sends eznest's website origin, not the page URL, as the referrer. The provider's own Google Places lookup remains separate. This version asks signed-in users on the website, iPhone and Android to review and accept the current policy before continuing protected work; their earlier acceptance remains in the record.

v1.7 — 2026-10-02. Corrected the public processor list to match reachable production paths: Apple push has been live since 2026-09-21, Twilio texts are live for people who opt in, a provider can connect their own business through Google Places, and native signing uses DigiCert's timestamp service. SES email is sent through AWS Canada (Central), not us-east-1. The prior policy and register incorrectly listed live paths as switched off. Every existing acceptance is against the older version, so this publication changes the active acceptance version and asks returning web users to re-accept.

v1.6, clarified 2026-10-02 (personal-finance export). §7.1 now says that Download my data includes everything in the personal-finance tools: accounts, transactions, imported statements with the text eznest extracted from them, bills and reminders, categories and rules, and payoff plans. It previously listed the personal-finance tools among what the download does not include, which was true until this change. The statement files themselves are listed rather than copied. We classify this as a clarification of v1.6: it adds data to a copy given on your request and adds no purpose, recipient or retention, so no new acceptance version is introduced.

v1.6, clarified 2026-10-01 (personal finance). §7.4 now lists your personal-finance accounts, transactions, imported statements and their stored files, bills and payoff plans among what closing your account erases, and no longer counts personal-finance statement files among the uploads that remain in storage. Before this change, closing an account did not erase those records; §7.4 neither listed them as erased nor as kept, and the code now does what the section says. We classify this as a clarification of v1.6: it removes data on a request the policy already describes and adds no purpose, recipient or retention, so no new acceptance version is introduced.

v1.6, clarified 2026-10-01. §3.4 now says that a file filed into the home's Documents vault is checked for malware on eznest's own servers, and that a file with a detected threat or one that cannot be checked is refused rather than added to the vault. The scope is the home Documents vault, not every upload path. We classify this as detail about a security safeguard on files the policy already said our own servers process for text extraction; no new recipient or acceptance version is introduced.

v1.5 — 2026-09-24. §3.5, §7.1, §7.3, §7.4 and §9.2 now disclose the first-party signed-in account-interaction record added on 2026-09-20: route-template, status, duration, request ID, source IP and user-agent metadata, with a 90-day code default and deletion on account closure. The earlier wording incorrectly implied that the optional personalization switch stopped every operational signal and that no such first-party access metadata existed. Because this adds a purpose and retention statement rather than merely clarifying unchanged processing, the active policy acceptance version is bumped and returning users must accept v1.5. This immediate republication follows the already-active log and therefore did not receive the 30-day advance notice promised in §13; that process failure is not hidden by calling the change a correction. The update also replaces the absolute mobile-token claim with the release-gated Apple/Firebase behaviour in code and limits deletion language to eznest's own stored registration. No advertising or cross-app tracking is added.

v1.6, published 2026-09-27. Text messages. eznest can now send you a text about a visit to your home if you turn them on, which adds Twilio Inc. as a third United States processor and sends it two things it did not have before: your mobile number and the text of each message. That is a material change by any reading, so it is a new version rather than a correction, and every existing acceptance is against a document that no longer describes where your data goes. §5.2 names Twilio and says what the messages are, how many to expect, that rates may apply, and that STOP and HELP work; §8.1.1 says what United States processing means for them; §12 adds the transfer. Twilio has no Canadian region, so there is no version of this that keeps the messages in Canada, and the policy says so instead of implying otherwise. Texts are off until you ask for them: a number on your account has never been permission to text it, and as of this version that is enforced in code rather than left to a setting.

v1.4, corrected 2026-09-14. The inactive third-party e-signature transport, webhook, remote archive downloader, credentials and deployment wiring were removed from the product source. New agreements use Eznest's native signing ceremony; no new contract or signer information can be sent through the retired integration. Local historical archive reads and immutable database vocabulary remain until a separately authorized read-only production and former-vendor account census establishes the disposition of every historical record. This version removes the retired integration from the current subprocessor register without claiming that historical retention obligations have disappeared.

v1.4, corrected 2026-09-11. §1 (sentence 4), §6 (the AWS row), §9.2 and §9.4 said Nestor's requests are processed in us-east-1. Each request is sent to us-east-1, but the Bedrock inference profiles eznest uses (us.meta.llama3-3-70b-instruct-v1:0, us.amazon.nova-2-lite-v1:0, us.anthropic.claude-haiku-4-5-20251001-v1:0) are cross-region profiles that AWS may serve from us-east-1, us-east-2 or us-west-2 — measured with GetInferenceProfile on 2026-09-11. The policy now says the United States and names the three regions; the consent text in the product already said the United States and is unchanged. The destinations are re-checked quarterly and recorded in the subprocessor register.

v1.4, updated 2026-09-11. §7.4 now says what closing your account does with your sign-in record at Clerk. Before this change it did nothing: eznest erased its own records and left the Clerk sign-in record in place, so the same identity could open a new, empty account. Closing your account now also asks Clerk to delete that record, once our connection to Clerk can carry the request, and keeps the request on record as owed until Clerk confirms; in every state, signing in with an erased identity is refused rather than re-creating an account. To make that refusal hold, Clerk's identifier for you now stays on the anonymized account record, where erasure used to clear it. Under §13 this is a minor change: it adds detail about what deletion does, deletion removes more rather than less, nothing new is sent to any processor, and the one thing newly kept is a suppression key of the same kind as the deletion record §7.4 already said we keep. The effective date is unchanged, and it is recorded here for the same reason as the correction below.

v1.4, corrected 2026-09-12. §3.8 and the entry below said the visit-sync path was retired before the first production release. The repository's release record says otherwise: the first production image (2026-08-26) served a build that still exposed the path until the 2026-09-04 release carried the retirement. The sentences now say that, and rest the "no memo reached us" claim on what is backed — no App Store or TestFlight distribution of the app in that window and a 2026-09-01 production census with no projects — rather than on a date that was wrong.

v1.4, corrected 2026-09-11. §3.10 said "no audio of yours is processed". That was wrong about the provider mobile app, which can record a consented voice memo during a site visit and has been able to since before this policy was first published. The memo stays on the device and no memo has been sent to eznest — the one sync path that could have carried it was retired on 2026-09-02; a production build exposing that path did run from 2026-08-26 to 2026-09-04, but the app had no App Store or TestFlight distribution then and a 2026-09-01 census of production found no projects for a visit to be finalized against — so nothing about what eznest does with your information changed, and under §13 this is a correction to the page rather than a new version requiring re-acceptance. §3.8 now describes the voice memo on its own, and §3.10 says what "not collected" means for audio: not on our servers. We are recording it here for the same reason as the v1.1 corrections below.

v1.4 — 2026-09-07. The Stripe Connect disclosure now names the individual identity, beneficial-owner, bank and verification information Stripe may collect directly when a provider connected account is enabled. It also records that Model A account management can use Stripe-controlled frames embedded on the Payouts page. Stripe's production rollout remains switched off; this publication precedes activation rather than describing it as live.

v1.3 — 2026-09-07. The business-contact disclosure now covers both invoice billing contacts and agreement signing contacts. Both paths require an existing relationship before listing contacts and use the same audited, rate-limited known-address bootstrap for a first commercial document.

v1.2 — 2026-09-04. Signing became native: the third-party e-signature processor was removed from the contract path, and one narrow outbound flow was added — a cryptographic digest of a signature sent to an independent timestamp authority, which receives no document, name, email or address. See §5.2.

v1.1 — 2026-08-30. Published version aligned to the live United States Bedrock processing region and the final public legal set.

Corrections carried into the published policy:

  • The original policy named OneSignal as a push-notification processor. OneSignal has never been part of eznest. At that correction's publication, push was switched off; Apple push was subsequently enabled and is disclosed in v1.7.
  • Earlier internal text stated that AI ran on eznest-operated infrastructure, not a third-party cloud. It runs on AWS Bedrock in us-east-1.
  • It claimed we learn from de-identified, combined patterns across users to improve AI suggestions. No such mechanism exists, has ever existed, or is planned. Nothing is trained on your data.
  • Earlier internal text omitted Clerk, our live identity provider, and did not disclose Bedrock processing in the United States.
  • It published retention periods — 7 years for audit records, 24 months for behavioural data, 2 years for marketing — that nothing in our systems enforced. §8.2 now states what is actually enforced, and says plainly that account data is kept until you delete it.
  • It described personalization as on by default with a one-tap opt-out. The reality is two separate switches with different defaults; §7.3 sets them out.
  • It described the export as a complete copy of everything we hold, and account deletion as removing your data. §7.1 and §7.4 now list exactly what each covers and what it does not.
  • It offered controls that were not reachable, including account deletion, which was impossible for every production user until 2026-08-28. That is fixed.
  • It claimed TLS 1.3 minimum, analytics cookies we do not set, and a breach log that did not exist. The breach log now does (§9.3).

We are recording these here rather than quietly deleting them, because a privacy policy that has been wrong before should say so.