Legal

Privacy Policy

Last updated: September 7, 2026

Who we are

Adamant is an iOS habit and discipline app developed and operated as an independent app. If you have questions about this policy, contact us at getadamantapp@gmail.com.

1. Data kept by the app on your device

The current app stores its state in on-device app storage. That state can include your name, your birth date if you choose to use Life Mosaic, goals, habits, completion log, proof text, Apollo verdicts, streaks, XP, rank, reflections, journal entries, progress, locally cached AI responses, trial state, and preferences.

For an accepted image proof, the app can keep a smaller encoded recap copy in an app-private on-device SQLite database and store only its local reference in app state. Recap media is capped by item and total-storage limits, so older image copies can be removed while the written proof and verdict remain. Video proof retains attachment metadata rather than copying video bytes into this recap database. Voice Vault recordings are files in the app's device sandbox, with their local URIs recorded in app state. A selected item can also still exist in your device's media library, and device backups are controlled separately by your device or backup provider.

2. Six Apollo AI routes and their inputs

When the live backend is configured and you use one of these features, the app sends the backend request fields listed below to the Adamant backend. Each handler runs the request through its current input parser with route-specific validation, selection, and normalization; some fields have length, value, or count limits where applicable. It then builds the described prompt and optional image content for Anthropic. A backend field can be translated, selected, or aggregated rather than forwarded verbatim. If the backend is unavailable or not configured, the client code falls back to an offline response instead.

• Proof review. Backend request fields: habit category, habit name, written proof, optional expected proof, and an optional photo with its media type. Anthropic receives: a category-specific proof rule, the bounded habit name, expected proof and written proof, plus the encoded photo and allowed media type when present.
• Routine forging. Backend request fields: goals, optional goal labels, level, struggles, distractions, screen-time, and wasted-hours answers. Anthropic receives: goal labels when present, otherwise goal IDs; a readiness instruction derived from level; and the bounded optional reflection and time fields.
• The Oracle. Backend request fields: your question, bond tone, optional bond label, streak, rank, and days active. Anthropic receives: the bounded question, a tone instruction derived from bond tone, and the optional label and positive progress values.
• Boss forging. Backend request fields: habit details, a recent completion log, rank ID, optional rank name, requested duration, date, optional streak, and goal labels. Anthropic receives: habit IDs, names and categories; derived kept-rate and weakness summaries; rank, streak, maximum duration, and goals. The raw completion log and date are not inserted verbatim into the provider prompt.
• Future-self letters. Backend request fields: milestone kind, milestone label, milestone detail, plus an optional forged future-self name, rank, best streak, total acts, signature habit, days active, and goal labels. Anthropic receives: the milestone label and detail; bounded optional identity, progress, and habit fields; and up to seven selected goal values. Those goal values are trimmed, limited to 80 characters each, and then joined verbatim into the provider prompt. Milestone kind is validated by the backend but is not inserted into the provider prompt.
• Habit tutor. Backend request fields: habit name, category, and optional why, goals, struggles, level, and habit streak. Anthropic receives: the bounded habit name, a category-specific teaching instruction, and the bounded optional context and positive streak.

The server handlers do not contain application code that writes those request bodies or photo bytes to a database or object store. That code-level boundary is not a promise that hosting, network, or Anthropic systems erase data immediately. Anthropic processes submitted content under its own Privacy Policy; this policy does not make a separate promise about Anthropic's retention period.

On an error, the current handlers can write an Anthropic status and a response-body excerpt of up to 300 characters to server logs. They can also log a redacted skeleton of up to 200 characters of unparseable model output, with letters and digits replaced, or an unexpected error object. Provider error excerpts and unexpected errors are not guaranteed to exclude submitted content. These are operational error logs, not a user-facing content history.

3. Proof photos, videos, and written proof

For a photo review, the app creates an encoded image copy for the request and sends it with any written proof and habit context through the route above. That request copy is transient. If the proof is accepted, the app separately creates a smaller bounded recap image for its app-private SQLite store; it does not rely on the camera's temporary cache URI after completion. The current client does not put video bytes into either the image-review request or the recap database: it retains video attachment metadata, while written proof submitted with it can still use the written AI route.

You can complete an eligible habit without offering proof; that no-proof path does not call the AI. When you do offer written proof, the live route can send those words for evaluation even if no photo is attached.

4. IP and pseudonymous-install rate limiting

Each Apollo backend route derives a rate-limit key from the request's forwarded or real IP address, the route, and a time bucket; the code uses unknown when neither IP header is available. Authenticated routes also derive a separate key from a server-issued pseudonymous install ID, the route, and a time bucket. When both Upstash environment values are configured, the backend sends those pseudonymous keys and counters to Upstash Redis. Paid AI routes and install-token issuance fail closed rather than use per-instance counting when that distributed limit is unavailable. These counters are used to limit abuse and protect service capacity.

On first launch, the app obtains a signed token and random install ID and stores both in AsyncStorage under @adamant/apollo-install/v1. The install ID stays stable for that installation when the token refreshes, so it can support abuse controls and future aggregate D1/D7 retention measurement. It is not an Adamant account, does not prove a physical device identity, and normally remains until app data is cleared or the app is removed.

5. Website browser storage

The interactive website stores a Trial result and Sky progress in localStorage, which can remain in that browser profile until it is cleared. The Alive script also uses sessionStorage interaction flags for the current browser tab/session.

• adamant_consent_v1 records whether you allowed or declined the Beehiiv scripts, so you are not asked again. Deliberately kept out of a cookie.
• adamant_verdict_v1 stores the Trial archetype, chosen domain, optional name, and timestamp.
• adamant_charted_v1 stores the Sky system identifiers you have charted.
• adamant_sky_complete records that the Sky completion moment was reached.
• alv_temple records the whole-temple interaction for the session.
• alv_whisper prevents the idle message repeating in the session.
• alv_exit prevents the exit-intent message repeating in the session.

The homepage's Alive script reads the local Trial and Sky values to show a return-state chip. These browser values are separate from the mobile app's on-device state.

6. Website waitlist and campaign attribution

If you choose to join the website waitlist, you provide an email address through an embedded form operated by Beehiiv. Beehiiv processes subscriber information on our behalf and may also process information for security, service operation, and other purposes described in Beehiiv's Privacy Policy.

After Apollo’s Trial shows its result, the page may offer one optional line: want Apollo’s opening move by email? Nothing is sent unless you type an address and press send. If you do, this site sends that email address, the name of the archetype the Trial suggested, and the front you chose to Beehiiv — the same provider as the website waitlist — marked as coming from the Trial, so it can deliver the opening move and launch updates; you can unsubscribe from any email. Your answers, the name you may have typed, and the verdict text are not sent. Our own funnel record counts that an opening move was requested and, when you arrived from a campaign link, which public creative led to it; it does not contain your email address, your name, or your IP address.

A link to this website may contain campaign fields such as utm_source, utm_medium, utm_campaign, and utm_content. We use those fields to understand which published creative led to a waitlist visit or signup. When you arrive from a campaign link, this website records the visit through its own first-party endpoint: a timestamped row holding the step (view or click), the opaque creative token, and a coarse device class (iOS, Android, bot, or other). That record does not contain your email address, your name, or your IP address. It is stored server-side on Netlify rather than in your browser, and we have not set an automatic expiry on it — it is kept until we delete it, and we will update this page if that changes.

The local checks for this site prove that a campaign token survives the page URL. They do not prove that Beehiiv retains that token in an exported subscriber row; that requires a separately authorized sandbox signup before we treat signup attribution as measurable.

7. Purchases and subscriptions are not live

The current production billing path is disabled: purchase and restore return a not-configured result. Adamant does not currently send purchase or entitlement data to RevenueCat. The website offers a waitlist, not a checkout. If paid billing is enabled later, this policy will be updated before that processing is described as active.

What the app does not collect

• The current app does not require an app account, email address, or password. The optional website waitlist does require an email address.
• We do not use advertising SDKs or sell your data to advertisers.
• The app does not use third-party product analytics services such as Firebase Analytics, Mixpanel, or Amplitude. The website waitlist uses Beehiiv and campaign-attribution fields as described above.
• We do not use your app activity to track you across other apps or websites for advertising.
• The current app code does not request precise-location permission. Beehiiv's separate handling is described in its provider policy linked above.

Why we use your data

We use the limited data described above only to:

• Run AI features — send the listed inputs when their app flows are used or triggered so Apollo can return a response.
• Keep the app working — save your state locally and rate-limit backend requests.
• Run the optional website waitlist — deliver launch updates and measure which campaign led to an attributed signup.

We do not use your app activity to target advertising or sell it to advertisers.

What this site loads from other companies

Before you make the cookie choice below, this website makes no request to any other company at all. Typefaces are served from this site rather than from Google Fonts, which would otherwise have received your network address on every page you opened; the font files live at /fonts here. Nothing is loaded from an advertising network, an analytics service, or a content-delivery network. The only third-party code this site can load is Beehiiv’s waitlist form and its attribution script, and neither runs until you allow it.

Cookies, and the choice you are given

The home page and the Trial page can load two scripts from Beehiiv, the provider that operates our waitlist form (subscribe-forms.beehiiv.com): the form itself, and a separate campaign-attribution script. Neither one loads until you allow it. The first time you visit a page that uses them, a bar appears at the bottom asking; nothing from Beehiiv runs before you answer, and if you decline, nothing from Beehiiv runs at all.

If you allow them, the cookies they can set are attribution_data (from the attribution script) and bhv_attribution (from the form script). We tested each script in isolation on the live site on 2 September 2026 rather than inferring behaviour from our own code, because these scripts are Beehiiv’s and not ours. What we measured: both write a cookie only when you arrive on a link carrying campaign tags (utm_source and friends). On an ordinary visit with no campaign tags, we loaded both scripts and neither wrote anything. When a cookie is written it holds the campaign source and name, the address of the page you landed on, the referring address if there was one, and a timestamp. It does not hold your email address or your name. Beehiiv uses it to attribute a later signup to the campaign that brought you; their handling is governed by Beehiiv’s privacy policy.

We gate both scripts even though our measurement says an ordinary visit stores nothing, because relying on that would let a change on Beehiiv’s side quietly reintroduce storage with nothing to catch it. Your choice is remembered in your browser’s local storage — not in a cookie, since writing a cookie to record a refusal of cookies would be its own contradiction. If you decline you can still join the waitlist: email getadamantapp@gmail.com and we will add you by hand, or allow the form from the link shown where it would be. The Cookie settings button beside the signup area lets you change your choice. Declining after allowing reloads the page to stop the loaded Beehiiv code and clears the two first-party cookies listed above. This does not delete information already received by Beehiiv. If your browser prevents saving a withdrawal, the page uses a #adamant-cookie-declined address fragment to keep Beehiiv unloaded across that reload; fragments are not sent to the server. Other choices made while storage is unavailable apply to the current page. A saved Allow is reused only when the browser can also save a change to that setting; otherwise we ask again. Adamant itself — the iOS app — sets no cookies at all.

App updates

The iOS app is built with Expo. On launch it checks for an over-the-air update by contacting Expo's update service (Expo / 650 Industries, u.expo.dev). That request carries the app's runtime version, release channel and platform, together with the network (IP) address every internet request necessarily reveals. It does not carry your habits, your proof photos, your written proof, or your Apollo install identifier.

Processing boundaries

Mobile app state, website browser storage, Apollo requests, rate-limit counters, Expo update checks, and Beehiiv waitlist information are separate processing paths. A statement that one path is local does not apply to the others.

Children's privacy

Adamant is not directed at children under 13, and we do not knowingly collect personal information from children under 13. Use of the optional waitlist is also subject to Beehiiv's provider terms. If you believe a child has provided us with personal information, contact us at getadamantapp@gmail.com.

How long each thing is kept

These periods come from the code and the configuration that runs it, not from intention. Where a third party holds the data, we say so rather than promise on their behalf.

Where your data goes

Adamant is operated from British Columbia, Canada, and is available in many countries. To provide the app we transfer limited data to service providers who process it outside your country, including in the United States. Those providers are:

• Anthropic — runs the Claude model that produces Apollo's verdicts. Receives the proof photo or text and the habit context, with no install ID or other identifier attached.
• Vercel — hosts the Apollo backend. Receives the request, including the network address it arrives from.
• Upstash — holds the short-lived rate-limit counters described above.
• Netlify — hosts this website.
• Expo (650 Industries) — serves over-the-air app updates, as described above.
• Beehiiv — sends waitlist email, if you joined the waitlist.

Transferring data across borders means it may be accessible under the laws of the country where it is processed. If you are in the EEA or the UK, transfers are made on the basis of appropriate safeguards such as Standard Contractual Clauses operated by those providers.

Legal bases for processing

Where the UK or EU GDPR applies to you, we rely on: performance of a contract for the processing needed to deliver a feature you asked for, such as sending a proof photo for a verdict; legitimate interests for keeping the service secure and available, which covers rate limiting and abuse prevention; and consent for the optional waitlist, which you may withdraw at any time by unsubscribing. Where PIPEDA applies, we rely on your meaningful consent, given by choosing to submit proof or join the waitlist.

If there is a data breach

If we become aware of a breach of security that affects personal information and creates a real risk of significant harm, we will investigate promptly, take steps to contain it, notify the people affected and the relevant regulator without undue delay where the law requires it, and keep a record of what happened. Because Adamant has no accounts, our ability to reach you directly is limited: we will publish a notice on this site and in the app.

Your rights

You can control the current local and waitlist data in these ways:

• Reset app state: Use Adamant's reset control to return the saved app state to its defaults and request deletion of its private proof-recap rows. This does not promise removal of separate media-library originals, residual operating-system storage, or device backups.
• Clear website state: Clear this site's browser storage to remove the Trial, Sky, and Alive values listed above.
• Request information: Email us at getadamantapp@gmail.com and we will respond within 30 days.
• Leave the waitlist: Use the unsubscribe link in a waitlist email or contact us to request deletion.

Depending on where you live, you may also have the right to access the personal information we hold about you, to have it corrected or deleted, to object to or restrict certain processing, to withdraw consent, and to receive your information in a portable form. Adamant deliberately holds almost nothing that can identify you: there are no accounts, and app data lives on your device, so in most cases you can exercise these rights yourself using the Reset control without contacting anyone. For anything else, email getadamantapp@gmail.com and we will respond within 30 days.

One honest limitation: because we do not hold an identifier that links data to you as a person, we usually cannot look you up. If you ask us to delete something, we may need you to tell us what to delete and may be unable to verify the request. If you are in Canada and are not satisfied with our response you may complain to the Office of the Privacy Commissioner of Canada; in the EEA or UK you may complain to your local supervisory authority.

Changes to this policy

We may update this policy as the app evolves. We will update the "Last updated" date above and, for material changes, notify you within the app. Continued use of Adamant after changes constitutes acceptance of the updated policy.

Contact

Questions or concerns about privacy? Email us at getadamantapp@gmail.com. We read every message.