Privacy Policy

Who we are and what this covers

AiC is a local-offers app. Restaurants and other local merchants post time-limited offers; people nearby claim an offer and redeem it in person at the merchant. We are running a pilot in and around Pocatello, Idaho, in the United States.

This policy describes what the AiC application actually does today, written by reading the application’s own source code rather than from a template. Where a practice is designed but not yet built, we say so instead of implying it already protects you.

AiC is not intended for children under 13, and we do not knowingly collect information from them.

What we collect

Your email address. You sign in with a one-time link sent to your email. Sign-in is handled by Supabase Auth, and your email address is stored in the authentication database it manages. We never ask for or store a password — the application has no password sign-in at all.

A phone number, only if you add one. Adding a phone number as a backup sign-in method is optional and is currently turned off. If you do add one, it is held by Supabase Auth; the AiC application database stores only the date and time you agreed to receive texts, not the number itself. No text-message service is connected yet, so AiC cannot send you a text today.

Where you are, while you browse. To show nearby offers we ask your browser for your location, or you can type a ZIP code or city instead. Either way the coordinates are kept in a temporary session cookie that your browser discards when you close it. They are never written to our database, never put in local storage, and never sent to an outside mapping or geocoding service — a ZIP code or city name is matched against a short list built into the app. If you decline the location prompt, that choice is remembered in your browser’s session storage only, so we stop asking for the rest of the visit.

Where you are, when you redeem. This one is stored. When you tap to redeem an offer at a merchant, we save the latitude, longitude, and reported accuracy of that redemption on the redemption record, along with the time. If you decline to share device location at that moment, the app substitutes the centre point of your ZIP code or city instead, which is accurate to roughly five kilometres. Be aware of two things: the saved record does not distinguish a precise reading from a substituted centre point, and these coordinates are kept indefinitely as part of the redemption record. As of 4 September 2026 this location is no longer used to decide whether a redemption is billable; we still collect and store it.

Your claims and redemptions. Which offer you claimed, when, its redemption code, when it expires, whether you cancelled it, and which merchant and location it belongs to.

Your chat messages. The app is chat-first. Everything you type in chat is stored in full, together with the assistant’s replies and the inputs and outputs of any action the assistant takes on your behalf. If you are signed in, the conversation is linked to your account; if you are not, it is linked to an anonymous session identifier.

Technical and security records. We keep an append-only audit log of changes to offers, claims, redemptions, merchants, and accounts. Depending on the action, an audit entry can include the account that performed it, what changed, a request identifier, and — on some administrative and merchant actions — the IP address and browser user-agent string. Your redemption coordinates are deliberately blocked from ever entering the audit log; the system refuses the write if they appear.

How we use it

• To sign you in and keep you signed in.
• To show you offers near you and let you claim and redeem them.
• To answer you in chat and to carry out the actions you ask for there.
• To bill merchants. Merchants pay us per redemption, so redemption counts and amounts appear on merchant invoices.
• To investigate disputes, abuse, and bugs, and to keep an honest record of who changed what.
• To understand how the product is used, in aggregate.

We do not sell personal information, we do not share it with advertisers, and there is no advertising or cross-site tracking code in the app.

Who else sees it

OpenAI. Chat is powered by a large language model. When you send a chat message, the conversation and the list of actions the assistant is allowed to take are sent to OpenAI’s API to generate a reply. OpenAI is the only model provider the application is wired to. Please do not type anything into chat that you would not want processed by an outside provider. We do not control OpenAI’s own retention of API requests; if you need certainty about that, ask us before sending sensitive information.

Supabase hosts the authentication service and the database, and sends the sign-in emails. Vercel hosts and serves the application. Inngest runs scheduled background jobs. Cloudflare R2 stores long-term archives of the audit log. Upstash may be used to hold short-lived rate-limit counters.

PostHog receives product-analytics events and Sentry receives error reports. Both run on the server only — there is no analytics or session-recording script in your browser. Analytics events carry identifiers such as your AiC account ID, a request ID, and a conversation ID; when we identify an account to PostHog we send the account ID alone, never your email, phone number, or name. Both paths run text through a filter that removes anything shaped like an email address, phone number, US Social Security number, or payment-card number before it leaves the server; Sentry additionally drops raw vendor payloads and tokens outright. This filtering is a strong safeguard, not a guarantee that nothing personal ever reaches an error report.

Merchants. A merchant sees the claims and redemptions made against their own offers so they can honour them.

One clarification, because it is easy to assume otherwise: we do use OpenStreetMap’s Nominatim service to turn a merchant’s business address into coordinates when a merchant location is created or edited. Consumer location is never sent there.

We will also disclose information if we are legally required to, or where we believe in good faith it is necessary to protect someone’s safety or to investigate fraud or abuse of the service.

Cookies and browser storage

We use cookies that make the product work, not cookies that follow you around. They are: sign-in cookies set by Supabase Auth; two short-lived session cookies holding the coordinates you shared or the ZIP code you entered, which your browser deletes when you close it; and a session identifier used to rate-limit anonymous browsing. If no session identifier is present, we bucket anonymous requests using a truncated one-way hash of the IP address instead of the address itself. Your browser’s session storage also holds a flag recording that you declined the location prompt. There are no advertising or cross-site tracking cookies.

How long we keep things

We want to be straight with you about this, because retention is where privacy policies most often overstate what is really happening.

• Claims, redemptions and their location coordinates, invoices, invoice line items, and credit memos are kept indefinitely. Invoices and credit memos are accounting records and are kept for tax and audit reasons even after an account goes away.
• The audit log is append-only and monthly-partitioned. A retention job exists that, when enabled for an environment, drops partitions older than thirteen months for billing-relevant and claim-lifecycle records and older than ninety days for everything else. When audit data is exported to long-term archive storage, every IP address in the export is replaced by an irreversible keyed hash.
• IP addresses recorded for abuse detection are stored only as a keyed one-way hash, with an expiry, and are swept once expired.
• Chat conversations and messages are kept indefinitely today. Our architecture documents a ninety-day target for chat retention, but no automatic deletion for chat has been built yet. We would rather tell you that than imply a deletion schedule that does not run.
• Records of incoming vendor webhooks are purged on a schedule — thirteen months for payment-processor events, ninety days for everything else.

Deleting your data

Please read this section carefully, because what we can do today is narrower than what we intend to build.

There is no self-service account deletion in the app yet. The full deletion cascade is designed in our architecture documentation but has not been implemented. If you ask us to delete your account, we will do it by hand, and it may take longer than an automated flow would.

When we act on a deletion request, this is what we intend to do and what will survive it. We would remove your email address, phone number, and display name from your account record; disconnect your claims and redemptions from you by replacing your account reference with an anonymous placeholder; strip the latitude, longitude, and accuracy values from your redemption records; and redact your messages, including assistant and tool turns that mention you.

Deletion is not total. The claim and redemption rows themselves remain, without you attached to them, because merchant invoices are built from them. Invoices, invoice line items, and credit memos are kept in full for accounting and tax purposes. Audit-log entries are kept as well; they are re-redacted to remove your details rather than erased, because the log is append-only and cryptographically chained. And once information has been sent to a third party such as OpenAI, we can ask them to delete it but we cannot verify it on their systems.

Your choices

• You can decline the browser location prompt and browse by ZIP code or city instead.
• You can decline device location at redemption; the app will fall back to a ZIP-code or city centre point.
• You do not have to add a phone number, and you can ask us to remove one you added.
• You can ask us for a copy of the information we hold about you, ask us to correct it, or ask us to delete it, subject to the retention limits described above.
• You can stop using the service at any time; ask us and we will close the account.

Depending on where you live, you may have additional legal rights over your personal information. We will honour a request under those laws to the extent it applies to us. We will not treat you differently for making one.

Security

Sign-in uses one-time links rather than passwords, so there is no password of yours for us to lose. Changes to important records are written to an append-only, hash-chained audit log that is checked nightly for tampering. Coordinates and secrets are blocked by construction from entering the audit log, and IP addresses are hashed before archiving. No system is perfectly secure, and we make no promise that ours is.

Changes to this policy

If we change how we handle personal information, we will update this page and change the “last updated” date at the top. This is a pilot product under active development, so expect this page to change as the product does.

Contacting us

Email us at [email protected] for privacy, access, and deletion requests, or about anything on this page. You can also use the in-app chat.

Written notices may be sent to: 1391 Remmington Rd, Pocatello, ID 83201, United States.

AiC is operated by Infinite Ideas LLC. You can reach the operator at the email address and postal address in this section.

Related

Terms of Service