Privacy Policy

Ambera is operated by an independent developer based in the European Union. References to "we," "us," or "Ambera" in this policy mean the operator of the Ambera mobile application, ambera.app, and Ambera Forge at forge.ambera.app.

You can reach us at hello@ambera.app for any privacy-related question, including requests under the GDPR or other applicable laws.

We collect only the information needed to run the product. We separate it into three categories:

Information you provide

• Account information: your email address (either entered directly when you sign in with a magic link, or returned by Google or Apple when you sign in with one of them — with Apple you can choose to hide your real address behind a private relay) and your first name, which we ask for during onboarding so the app can address you by name. We do not store passwords — sign-in is magic link, Google, or Apple only.
• Ledger entries: the activities you log, including direction (depleting or recovering), intensity, optional title, optional note, and the time you booked them.
• Arcs and planned activities: an arc is a stretch you set up — a week or a sprint — with a descriptive shape (how you expect it to lean, from heavy depletion to heavy recovery), an optional named lens, an optional short description, and a length. Within an arc you can add planned activities (drafts) — title, expected direction, expected intensity, planned time, and an optional per-activity reminder toggle that, when on, queues a push notification at the planned time. Drafts only count toward the ledger after you confirm them.
• Daily energy check-in: a felt rating of how the previous day left you (from drained to restored) and an optional short note. From the rating, Ambera derives a single ledger entry that fills the gap between how the day felt and what you actually logged — attributed as a check-in and editable like any other entry. We store the rating, the optional note, and the derived entry.
• Daily reflections: the free-form end-of-day note you can write on the reflection screen, one per calendar day. Writing reflections is free; the Premium weekly synthesis is what reads them back as a paragraph.
• "About you" pages: the structured notes you fill in on the edit-profile screen to give the AI assists context about you (e.g. work shape, life context, energy patterns, plus any custom pages you add). Writing these is free; only the Premium AI assists consume them.
• "Describe your day" chat sessions: when you use the Premium chat to turn a free-form description of a stretch of time into ledger entries, we store the conversation transcript and the current proposed-entry list as your active session. The session is replaced on every turn and automatically cleared the moment you save the proposed entries to your ledger or tap "Start over." Until then it persists across app restarts so a chat you began on the bus is still there when you reopen the app at home.
• Preferences: settings such as your week start day, notification preferences, quiet hours, and time zone.
• Waitlist signups: if you join the waitlist on ambera.app, your email address and the timestamp of the signup.
• Support correspondence: anything you send us by email.

Information we generate

• Derived ledger metrics: rolling balances, cumulative series, and state labels computed from your entries. These are produced from data you provided; we do not infer them from outside sources.
• Activity suggestions: the activities you tend to repeat on a given weekday, detected on our own servers from your past entries and offered back so you can add them in a tap. This is computed from your own ledger — no AI model and no outside data are involved.
• Device tokens: an opaque identifier from Apple or Google issued to your device so we can deliver push notifications you have opted into.
• Session metadata: when you sign in, we record the IP address and browser/device user-agent associated with the session, retained for security and abuse prevention (for example, spotting a sign-in from an unexpected place).
• Diagnostic logs: minimal request and error logs needed to keep the service running, including error and performance traces sent to Sentry, our error-tracking provider. Sentry is configured to collect no personal information by default — it receives the stack trace and technical context of an error, not the content of your ledger.
• Product analytics: a pseudonymous identifier tied to your account, plus events recording which screens you viewed and a small set of named interactions (signing up, logging an activity, viewing the paywall, subscribing). We use this to understand which parts of the product work and which need fixing. The analytics stream never includes the title, note, intensity, or any other content of a ledger entry.

Information from third parties (only with your permission)

• Google Calendar events, if you connect a calendar — synced into your activity log to save you from re-entering things you already scheduled. For each event we capture the title, start time, duration, attendee count, and event type. We also capture the event description, truncated, only if you opt in under Profile → Integrations → AI capture (off by default, Premium). We never capture attendee email addresses, meeting locations, or conference links. Imported items are flagged so you can tell them apart from entries you logged yourself.
• Linear activity, if you connect a Linear workspace — when you open the Linear picker for a day, we read issues you are assigned to that were updated or commented on that day, plus issues assigned to you that have been updated within the last fourteen days regardless of state, so you can pick which tickets shaped each day. Each ticket you confirm becomes its own ledger entry. For each confirmed ticket we capture the identifier, title, team, priority, and workflow state. We also capture each confirmed ticket's description, truncated, only if you opt in under Profile → Integrations → AI capture (off by default, Premium). We never capture the body of Linear comments. We only read; we never write back to Linear. Imported items are flagged like the calendar ones.
• Apple Health metrics, if you connect Apple Health on a future release — sleep duration, heart rate, step count, and active energy burned, used to adjust the energy balance calculations in the app so the ledger reflects what your body actually did, not only what you logged.
• Subscription status from RevenueCat and the App Store or Google Play, if you purchase a Premium subscription.

Team workspace data (Ambera Forge)

Ambera Forge is our product for people who build software with AI coding agents: it reads the repository a workspace connects and the application it deployed, reports what it found as counts, reads the market around what is being built, and can open a fix as a pull request in that repository. If you use Forge — either as a member of a workspace or as the person who set one up — we collect the data needed to run those reads:

• Workspace details: the workspace (organization) name, its URL slug, an optional logo, and its settings — including who paused or resumed each of the automatic functions (the weekly Signal cycle, Autopilot fixes, the nightly deployed-app read) and when.
• Members and roles: the email address and role (such as owner, admin or member) of each person in the workspace, and each member’s own preferences — currently which market sectors they follow.
• Invitations: the email address of anyone invited to join the workspace, kept until the invitation is accepted, declined, or revoked.
• Repository connections: when an admin connects a repository, Forge is installed as a GitHub App on that repository and we store the installation id — no long-lived token at all. Short-lived access tokens (they expire within an hour) are minted per request and narrowed to the job: read-only for every reading; permission to write repository contents and pull requests only when a fix pull request is being opened; permission to write checks and issue comments only for the pull-request check and its comment. Connections made before the GitHub App existed hold a classic OAuth token and a webhook secret; those are stored encrypted at rest, and the moment such a connection is upgraded to the App the old token is revoked at GitHub and deleted from our database.
• Pull-request metadata from connected repositories: titles, authors, reviewers, whether the author is a bot (recorded from GitHub’s own account type), review counts, and timestamps of merged pull requests — the rows the review-tax measurement is computed from. When the pull-request check is switched on, Forge also writes a check result and one comment on your pull requests.
• Readings: ownership-audit and code-read snapshots of connected repositories — per-signal and per-detector counts, up to five example file paths per finding, the HEAD commit the reading was taken at, which agent-instruction files (CLAUDE.md, AGENTS.md, skills and the like) the tree holds and how large they are, which capabilities the manifests evidence (payments, sign-in, a model call…), and, for most kinds of code finding, up to three located occurrences: a file path, a line number, and the single line of source at that line, trimmed and cut off at 200 characters. So a snapshot holds counts, paths, line numbers and a small number of individual lines — never a file in full, and never the code around the line. Some kinds of finding record the location and never the line: credentials, where the line is the credential itself, and findings that live in comment prose — TODO markers and commented-out code — because comments carry people's names, ticket ids and internal URLs by convention. The lines a snapshot does hold are shown to signed-in members of the workspace the repository belongs to. What leaves the workspace carries locations only: an exported tracker issue, a shared reading link, a fix pull request’s description and the closing-report email give the path and the line number, never the line of source at it.
• Team conclusions about findings: a waiver (“we accept this”) or a gate (“we refuse more of this”) recorded per finding, with the reason written and who recorded it.
• Filed-action records: which proposed action was exported into which tracker, when, and a link to the created issue — kept so a second export links to the first instead of filing a duplicate.
• Fix pull requests: a record of every fix attempt — the repository, the finding, the branch, the pull request’s address, whether it opened or why it did not — kept so the workspace can see what was proposed and so the same finding is not fixed twice.
• Autopilot: if a workspace switches on the nightly read of its deployed application, the address of that application, the finding counts of its last reading, and when the last alert was sent — kept so a new urgent finding is distinguishable from one already reported.
• Share links: unguessable tokens for readings the workspace chooses to share. While a link is live, it discloses the repository name and that reading’s example file paths and line numbers to whoever holds it — locations only, never the lines of source at them; links are revocable.
• Signal subjects: an idea or a repository the workspace asks Forge to read the market for — the title and your description in your own words (the one input Forge does not measure; every surface that shows it says it is yours), the companies, products and arguments you confirm for the watch list with your notes, the weekly briefs, the bets and the entries that moved them, the decisions you record, the answers about what your product does (each marked as coming from your description, from your own hand, or from the repository read), the versioned market-fit readings, and the credit ledger — every grant, charge and refund.
• Connected AI clients and API keys: when a member connects an AI client (for example Claude) to Forge over the Model Context Protocol, the client is authorized through OAuth and the resulting tokens and consent are stored; an API key is stored as a hash and a short prefix — the secret itself is shown once and never kept.
• An audit trail: who did what in the workspace — a repository connected, a role changed, an automation paused — as an action, the acting member, a one-line summary and a timestamp. In-app notifications work the same way.
• Billing status: the workspace’s Stripe customer id, subscription id, subscription status, current billing-period end, and the purchase events Stripe sends us.
• Advertising attribution, only if you arrived from a Reddit ad: Reddit appends a click identifier to the link you followed; the dashboard keeps it in your browser for up to 28 days and, if you create an account in that time, we tell Reddit’s conversions endpoint once that the click became a sign-up — the click identifier, the time, and an opaque account token. No email address, name, IP address or device details are sent, no Reddit script runs on our pages, and a returning user’s click is never reported. The marker that the report was made is stored on your account and deleted with it.
• Marketing email, only with your consent: at your first sign-in Forge asks — with an unticked box — whether we may write to you about the product, about once a month. Your answer is recorded with its date and the exact words shown to you; you can change it any time under Settings → Account, and every such mail carries an unsubscribe link. Without that consent we send no marketing mail at all. Mail the service sends because you use it — sign-in links, the weekly brief of a Signal subject you started, Autopilot alerts, notices about your account or these terms — is not marketing and is not affected.

Beside the workspace data sits the shared market catalog, which is not anybody’s workspace data: when Signal watches a company, product or argument, what it records — dated entries, each a claim with the public web address it was read from and a tag saying whether it is a fact, a company’s own claim, a user opinion or an inference — is a fact about the market, not about a customer, so the catalog carries no workspace id, is read by every workspace that names the same company, and is what the public sector pages and company pages at forge.ambera.app render. Nothing a customer typed reaches the catalog: the watch sees the company, its sources and its own earlier entries, never your description or your answers. A user opinion in the catalog is a claim and a web address, never a person’s handle. Forge also keeps an anonymous benchmark row per repository it has read deeply — file counts, per-detector counts and the main language under a salted hash that cannot be turned back into a repository name — so a reading can say whether a count is a lot.

Forge has three doors that need no account. A public scan at forge.ambera.app/scan of a public repository nobody connected stores the resulting review-tax report for that repository, a history of its earlier readings, and a salted hash of the requester’s IP address used only for rate limiting; a private repository cannot be read that way at all — the public scanner refuses it rather than storing anything. If you ask to be told when a public report moves, we store your email address and an unguessable token, confirm the address by email, mail you only when the headline number actually moved, and stop the moment you use the unsubscribe link. The launch check at forge.ambera.app/launch fetches the address you type exactly as a visitor’s browser would — the page, its same-origin scripts and the source maps they name — requests nothing the page did not hand out, refuses private and local addresses before the request, is rate-limited, and stores nothing: not the address, not the page, and never a credential it finds (a finding names the script and a count). Trying Signal without an account at forge.ambera.app/signal/try stores the idea you typed and the proposal the model made under an unguessable link that expires after seven days unless you sign in and claim it. The public sector and company pages store nothing about the visitor.

Forge sign-in is by magic link, Google, or GitHub — we do not store passwords for it. Forge is a separate service from the personal Ambera app, with its own sign-in and its own database. A Forge workspace holds no personal energy data, and the personal app’s ledger has no path into Forge — that separation is the subject of the "Counts, never people" section below.

We do not collect precise location, contacts, photos, advertising identifiers, or browsing activity outside the app.

Voice dictation

Long-form text fields (reflection notes, activity notes, intention descriptions, "about you" pages, the "Describe your day" chat composer) carry a tap-to-dictate microphone button. When you use it, speech recognition runs entirely on your device — your operating system converts audio to text locally, and Ambera only ever sees the resulting transcript as if you had typed it. No audio is recorded, transmitted to our servers, or sent to any third party. The microphone button auto-hides on platforms or devices that do not support on-device recognition.

Two promises hold here, and both are structural rather than editorial. The first: your personal energy data never enters Forge. Ambera Forge is a separate service from the personal Ambera app, with its own sign-in and its own database; it reads nothing from the personal app and holds no energy data of any kind. Your Forge workspace cannot see your ledger, query it, or export it — not in any view, not in any report, not on request — because there is no path by which it could reach Forge in the first place.

The second promise is about what Forge does hold. Forge reads repositories and reports what it found — and it will not turn that into a ranking of engineers. Team-facing surfaces report counts and distributions, never a per-person review load: review concentration is shown as a distribution, and it is withheld entirely when fewer than three people review. The billing count works the same way — the module that counts covered contributors returns a number, never the logins behind it. Signal keeps a matching wall on the market side: what it records about a company is a claim and the public address it was read from, never the handle of the person who said it.

This posture is published, in more detail and with the reasoning, at forge.ambera.app/privacy-for-engineers. The wall is in the architecture; the policy only describes it.

For the workspace data inside an Ambera Forge workspace — members, connected repositories, the readings produced from them, fix pull requests, Signal subjects with their descriptions, briefs, bets and decisions, and filed-action records — the customer organization is the data controller and Ambera acts as a data processor on its behalf, handling that data under the organization's instructions. For the shared market catalog and the public sector and company pages, which describe companies and products read from the public web and hold nothing a customer entered, Ambera is the controller. (For your personal Ambera account, by contrast, we are the controller.)

A Data Processing Agreement covering Forge workspace data is available on request — write to hello@ambera.app.

We use your information for the following purposes:

• To operate the ledger — store, sync, and display the activities, balances, arcs, planned activities, daily check-ins, and "about you" pages that are the product.
• To deliver notifications you have asked for, including the free imbalance nudge that surfaces when your week is drifting depletive, the daily reflection prompt, the daily energy check-in reminder, and per-activity reminders you toggle on for individual planned activities.
• To provide Premium features you have subscribed to, including AI-tailored draft suggestions, AI-assisted activity prefill from notes, personalized intensity calibration, and weekly reflections.
• To process and personalize the content you see in the app — using AI to tailor suggestions, intensity estimates, reflections, and recommendations to your own history rather than to a generic average. AI assists are always user-initiated by tapping a button; nothing is silently inferred onto your ledger.
• To process Premium subscription payments for the mobile app through RevenueCat and the platform store.
• To run Ambera Forge — read the repositories a workspace connects (on request, and again every night so the readings have a memory), read the deployed application a workspace points the launch check at, run Signal’s weekly market cycle for the subjects a workspace confirmed, open the fix pull requests a member asks for or Autopilot is switched on for, file the actions a workspace exports into its own tracker, send the email the product calls for (the magic-link sign-in, workspace invitations, the weekly Signal brief, the Launch Audit closing report, movement notifications for filed and gated work, an Autopilot alert when the deployed application shows a new urgent finding, and the weekly digest for a public report you asked to watch), and bill through Stripe — on a covered-contributor count that is never a list of people for the Team and Premium plans, and in credits for the work that consumes a model.
• To respond to support requests and to communicate service updates that materially affect you.
• To protect the service from abuse and to comply with legal obligations.

We do not use your ledger to build advertising profiles, sell to data brokers, or train general-purpose foundation models on your behalf.

Some Premium features use a third-party language model to suggest activity titles, directions, and intensities from notes you write, and to propose a starter set of planned activities tailored to your arc. These features are deliberately gated: the model proposes, you confirm or override, and nothing is silently inferred onto your ledger. AI assists are always user-initiated — you tap a button (for example, "Tailor for me" on the arc, or "Suggest from note" on an imported activity) to ask for them. The one exception is the per-arc summary, which generates on its own when you open an arc; it only reads your data back to you and never writes to the ledger.

We also use AI to process and personalize the content you see in the app — for example, calibrating intensity suggestions to your own logging history, summarizing your week in language that reflects your specific patterns, and identifying which recovery activities have most reliably restored balance for you. The goal is to make what you see feel like it was written for you rather than for an average user.

When you use an AI assist, the request to our model provider includes what is needed for that specific assist and nothing else. The full list, by assist type:

• Tailored draft suggestions (arc): the arc's shape, optional lens, and optional description, the content of your "about you" pages, a small slice of your recent confirmed activities so the model anchors intensity to your own logging style rather than a generic average, the current weekday and rough time of day so the suggestions fit the remaining hours, and — if you typed anything into the tailor sheet — the free-text refinement you wrote there ("working until 5pm," "give me 6 things, lean toward recovery"). The refinement text is sent verbatim with that single request and is not retained beyond the in-memory cache that keeps your suggestions visible while you're on the arc.
• Per-arc summary (arc): the arc's set shape and optional lens and description, the shape that is emerging from your ledger over the arc so far, and the deterministic patterns Ambera computes on our own servers (your strongest and heaviest logged day, how many days you logged) — combined into a one-to-two-sentence observational read. The result is cached on our side, keyed to the arc, and regenerated only when the arc's underlying data changes.
• "Describe your day" chat (activity form → Describe your day): the message you just typed, the prior turns of your active chat session and the current proposed-entry list (so the model can refine in place rather than start over each time you reply), the content of your "about you" pages, your time zone and the current local datetime so phrases like "this morning" or "yesterday evening" resolve to concrete times, and a small slice of your recent confirmed activities used solely to anchor the intensity number. Each refinement is sent independently. The session is persisted on our side as described under "Information you provide" so you can close the app and come back to the same chat; it is automatically cleared when you save the proposed entries to your ledger or tap "Start over."
• Suggest from note (activity form): the note you wrote, plus a small slice of your recent confirmed activities used solely to anchor the intensity number.
• Reflection gap-fill (evening reflection screen): the reflection note you just saved, the activities you have already logged for that day so the model does not propose duplicates, the content of your "about you" pages, the current weekday and rough time of day, and a small slice of your prior confirmed activities used solely to anchor the intensity number. The model proposes activities the reflection mentions that are not yet on the ledger; you confirm or remove each one before anything is recorded.
• Weekly reflections and personalized activity audits (daily background job): your confirmed ledger for the relevant window, and the daily reflection notes you wrote during that window, used together to produce a short summary or recommendation that is then cached on our side and displayed to you.
• Patterns synthesis (daily background job): the multi-week trends Ambera computes on our own servers from your ledger — for example, which weekday tends to run hardest, or what typically follows a stretch of demanding days — together with the arc shapes and lenses you set. Only these computed aggregates and your arc settings are sent to the model, never the individual entries; the resulting sentence is cached on our side and displayed to you.

Our model provider for the mobile app is Anthropic (Claude). Under Anthropic's commercial terms, inputs and outputs from our API requests are not used to train its models. We do not use AI to surveil patterns in your data without you having actively requested an AI feature, and we do not use your content to train general-purpose foundation models.

The model in Ambera Forge

Every measurement Forge reports is produced without a model: the repository read, the launch check, the market-fit arithmetic and the credit ledger are deterministic code, so the same repository always counts the same. A model is used for a stated list of jobs, and Forge’s model calls are routed through OpenRouter to two models — Anthropic’s Claude, served by Anthropic, and DeepSeek’s open-weight model, which we run only on hosts in the United States (OpenRouter is instructed to use those hosts and no other, so a request never falls back to a server elsewhere; DeepSeek the company receives nothing) — with a direct Anthropic connection as the fallback. Which job uses which model is a configuration we may change; what each job sends is fixed and listed here:

• Wording a reading’s synthesis, and checking an action a person proposed on the plan board against the latest reading: the repository’s name and the reading’s measured text — counts, signal states and example file paths Forge already computed. No source file contents.
• Seeding a Signal subject: the title and description you wrote (or, for a repository, its README and the deterministic overview of its reading), so the model can propose the companies, products and arguments to watch and the bets to test. You confirm or edit the proposal; nothing is watched until you do.
• The weekly watch of each company on a watch list: the company’s name, its known web addresses and its own earlier entries in the shared catalog — never your description, your answers or anything about your subject. The watch searches the web through OpenRouter’s web plugin, so the search queries about that company reach the search provider behind it. The results are the dated, sourced entries in the catalog.
• Writing the weekly brief and reading the market horizon: your subject’s title and description together with this week’s catalog entries for its watch list.
• Answering what your product does, per capability the market declares: your description, and the capability names read from the market. Where the description does not say, the answer is “not stated” and stays out of the number; a model never guesses from what products of this kind usually have. For a linked repository, the model only matches a market-declared name to a capability the deterministic repository read already evidenced.
• Checking your bets against this week’s evidence: the bets with their tests and this cycle’s catalog entries; a bet moves only on entries that are real, cited and tagged as fact, company claim or user opinion.
• The sector sweep and sector discovery, run on Forge’s own budget for the public sector pages: the sector’s name and its companies’ names and web addresses. No customer data of any kind.
• An agent-assisted fix, which only a member can start and which costs credits: the complete contents of up to five files the finding points at, together with the finding. This is the ONE place Forge sends source code to a model. The model returns proposed replacements; the same deterministic detector then runs over the files before and after, and a pull request opens only if the count fell and nothing urgent rose — otherwise nothing opens and the credits are refunded. Deterministic fixes (a committed .env file, a table without row-level security) send nothing to any model.

Under the terms we use these providers on, the inputs and outputs of our API requests are not used to train their models, and OpenRouter's own prompt logging is switched off for our account. The model never authors a measurement: it proposes, and deterministic code decides — the fit number is arithmetic over counts, a bet moves only on cited evidence, and a fix pull request opens only when the detector says the finding fell.

If you connect Google Calendar or Linear, Ambera always captures a small structured summary of each imported item (duration and attendee count for events; identifier, priority, and workflow state for Linear tickets) so the AI assist has useful context — this summary contains no free text, names, or email addresses. Separately, Premium subscribers can opt in to also include truncated event and issue descriptions in the notes attached to imported activities; the toggle lives in Profile → Integrations and is off by default. We never capture or send the bodies of Linear comments, attendee email addresses, or meeting locations. When the opt-in is on, the truncated descriptions follow the same handling as anything else you write into a note — sent to our model provider only when you request an AI suggestion, never retained for training, never used to build advertising profiles.

Ambera's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In plain terms, this means that for any data Ambera receives from Google Workspace APIs — currently Google Calendar event metadata when you choose to connect a calendar, as described in the "Information from third parties" section above:

• We only use the data to provide and improve user-facing features of Ambera that are prominent in the app — specifically, syncing calendar events into your activity ledger so you can confirm them as depleting or recovering entries, and (only if you opt in to AI capture under Profile → Integrations) including truncated event descriptions as context when you request an AI suggestion.
• We do not transfer this data to any third party except as necessary to provide or improve those user-facing features, to comply with applicable law, or as part of a merger, acquisition, or sale of assets with notice to you.
• We do not use this data for serving advertisements, including personalized, retargeted, or interest-based advertising.
• We do not allow humans to read this data, except (a) with your explicit consent for specific data, (b) where necessary for security purposes such as investigating abuse, (c) to comply with applicable law, or (d) where the data has been aggregated and anonymized for internal operations.

You can disconnect Google Calendar at any time from Profile → Integrations in the app, or by revoking Ambera's access from your Google Account permissions page. When you disconnect, we stop syncing new events immediately and delete the synced event metadata associated with your account within 30 days, on the same schedule described under "Retention and deletion".

We use PostHog, a product analytics service hosted in the European Union, to understand how Ambera is used so we can improve it. PostHog is configured as a data processor under our control — it acts on our instructions and does not use your information for its own purposes.

What we send to PostHog from the mobile app:

• A pseudonymous identifier for your account once you sign in (the same internal account id we use elsewhere). Before sign-in, the SDK uses an anonymous device id only.
• Screen views inside the mobile app and a small set of named events — currently signing up, logging an activity, viewing the paywall, and completing a subscription.
• Standard technical metadata that comes with any analytics event: device model, operating system version, app version, language, and the time of the event.

What we never send to PostHog from the mobile app: the title, note, intensity, direction, or any other content of a ledger entry; your email address or name; the content of any Google Calendar event, Linear issue, or Apple Health metric; and any precise location. The analytics stream tells us "an activity was logged," never what that activity was.

Analytics on Ambera Forge and ambera.app

Forge (forge.ambera.app) uses the same PostHog instance, with session recording switched off. Before you sign in it records page views under an anonymous id; once you sign in, that id is joined to your account id, email address and name, so we can see which parts of the product an account uses. Beside the page views, our servers record a small set of named events: signing up, completing a public scan (with the name of the public repository scanned), connecting a repository, a purchase, and a workspace reaching a usage threshold. No finding, no file path, no line of source and nothing you wrote into Signal is ever sent to PostHog. Error events sent to Sentry from Forge carry your account id and email address so a failure can be traced to the account that hit it; they never carry repository contents.

The marketing site at ambera.app uses Google Analytics to count visits and the pages they land on — only if you allow it. Google sets its own cookies to do so, so the tag is not loaded until you answer the banner on your first visit; declining is remembered exactly like allowing, and you can change your answer at any time from the "Analytics cookies" link in the footer. Google acts as a processor for that data. Neither Forge nor the mobile app loads Google Analytics.

You can opt out of analytics by deleting your account or by writing to hello@ambera.app to request that analytics events for your account be excluded going forward.

We share information only with the service providers needed to run Ambera, and only the minimum each one needs to do its job. The current list is:

• Cloudflare — application hosting, edge compute, content delivery, and transactional email through Cloudflare Email Service (for example, your magic-link sign-in message, sent from noreply@ambera.app).
• Neon — managed Postgres database storage.
• Hetzner — encrypted off-site database backups, stored in Germany (EU) for disaster recovery.
• Expo — push notification delivery and over-the-air mobile updates.
• RevenueCat — subscription entitlement management for the mobile app.
• Apple and Google — payment processing for in-app subscriptions on their respective platforms.
• Stripe — payment processing for Ambera Forge's subscriptions (Solo, Team, Premium), the one-time Launch Audit and credit top-ups. Team and Premium are billed per workspace on a covered-contributor count (a number, never logins). Stripe acts as a processor; we store the workspace's Stripe customer id, subscription id, subscription status, and current billing-period end so we can keep entitlements and credit grants in sync.
• Fakturoid — the invoicing service that issues the invoice for each Forge payment. It receives what a compliant invoice has to carry: the customer’s name, billing email, billing address and VAT number as given to Stripe, and the line items. Fakturoid is operated in the Czech Republic (EU).
• GitHub — Ambera Forge reads connected repositories through the GitHub App installed on them, with short-lived tokens minted per request, so those requests carry the token and the repository coordinates to GitHub. When a member asks for a fix, or Autopilot is switched on, Forge writes a branch and a pull request to that repository through the same App; with the pull-request check on, it writes a check result and a comment. The public scanner reads public repositories on our own credentials.
• The issue tracker an Ambera Forge workspace connects for exports — Linear, Jira, GitHub Issues, or ClickUp — receives the audit actions the workspace chooses to file there, including the brief's measurement text and example file paths with their line numbers. A filed issue carries locations only; the lines of source at them are not written into it. Forge writes issues into the tracker; it does not read work out of it.
• OpenRouter and Anthropic (Claude) — our model providers. For the mobile app, Anthropic alone, and only when you use a Premium AI feature, as described above. For Ambera Forge, requests are routed through OpenRouter either to Anthropic or to a US host running DeepSeek’s open-weight model (with a direct Anthropic connection as the fallback) for the jobs listed under "The model in Ambera Forge", each carrying exactly what that list says — the only job that ever carries source code is an agent-assisted fix a member started. The web searches Signal’s watch performs go through OpenRouter’s web plugin to the search provider behind it, carrying the watched company’s name and the queries about it, never customer data.
• PostHog (EU) — product analytics, as described in the "Product analytics" section above.
• Sentry — error and performance diagnostics, configured to collect no personal information by default; Forge attaches the signed-in account id and email to an error, as described above.
• Google Analytics — visit counting on the marketing site ambera.app only, as described above.

Two kinds of request go to third parties that are not our service providers, on your instruction. The launch check and Autopilot fetch the deployed application you name, exactly as a visitor’s browser would — that application’s operator sees an ordinary request from us. Signal reads the public websites of the companies you ask it to watch; those sites see ordinary requests from the search provider.

We do not sell or rent your personal data. We do not share your ledger with employers, insurers, advertisers, or analytics brokers. If we are ever legally compelled to disclose information, we will narrow the scope as much as the law allows and, where permitted, inform you.

If Ambera is ever acquired or merged, your data would transfer to the acquirer only under terms at least as protective as this policy, and you would be notified before any material change.

We keep your ledger for as long as your account is active, because the value of the product compounds with history. You can delete individual entries at any time from the app.

You can delete your entire account from within the app. When you do, we remove your data from primary storage within 30 days. We keep encrypted off-site backups (held in Germany, in the EU) on a rolling 10-day retention, alongside the point-in-time recovery window our database provider maintains; deleted data ages out of those layers as the backups roll forward.

Two things may survive account deletion. The first is a record of the deletion itself, retained because the law requires us to be able to demonstrate we honored the request. The second is billing audit records — the purchase and subscription events tied to your account, including their raw payloads from the payment platforms — which we keep for financial reconciliation, accounting, and tax obligations. These billing records do not include your ledger.

For Ambera Forge: readings of connected repositories are kept because the audit's value is its memory — the self-grade of a filed action needs the reading that proposed it, and the movement since last time needs the last time. They survive a disconnect by default so a reconnect does not lose the history, and the disconnect dialog offers deleting them instead. Signal’s briefs, bets, decisions and market-fit readings are kept for the same reason: a number with no history is a number nobody can check. Share links can be revoked at any time from the workspace — a revoked link stops disclosing anything, we keep the record that the share existed, and disconnecting a repository withdraws its live links. A fix pull request lives in your repository, under your control — closing or merging it is yours to do, and Forge only keeps its record of the attempt. Off-boarding a member is a remove-member control on the workspace page.

Deleting a Forge account deactivates it at once — every session ends with the request — and the purge runs after a short grace window, within the 30 days above. Deleting a workspace purges every table keyed to it: members and invitations, connections and installation records, readings and their snapshots, gates, waivers, exports, fix records, Autopilot settings, Signal subjects with their entities, briefs, bets, decisions, capability answers, fit readings and credit ledger, API keys, connected-client tokens, notifications, the audit trail and settings. Three things stay: the billing records above, the record of a Launch Audit purchase (a paid entitlement is a financial record), and the deletion record. The shared market catalog is not touched, because nothing in it came from you — what a competitor charges does not become untrue when a workspace closes — and the anonymous benchmark rows hold no key that could tie them back. A public report someone requested to watch is kept as long as one confirmed watcher remains; the unsubscribe link removes yours. An unclaimed Signal draft expires seven days after it was made. Anything not covered by an in-app control is handled on request — write to hello@ambera.app — and we act on the organization’s instructions as its data processor.

Data is transmitted over TLS, stored encrypted at rest in our database provider, and access to production systems is restricted to the operator. We follow common-sense practices around credentials, dependency updates, and least-privilege access.

For Ambera Forge specifically: repository access runs through a GitHub App whose tokens are minted per request, narrowed to the job and expire within an hour, so there is no long-lived repository credential to steal; the classic tokens of pre-App connections are sealed with authenticated encryption and revoked when the connection upgrades; API keys are stored as hashes; and the launch check and the code read never store a credential value they find — a finding is a location and a count.

No system is perfectly secure, and we will not claim otherwise. If we ever discover a breach affecting your data, we will notify you and the relevant authorities within the timeframes the law requires.

Depending on where you live, you may have the right to:

• Access the personal data we hold about you and receive a copy in a portable format.
• Correct information that is inaccurate or incomplete.
• Delete your account and the data associated with it.
• Object to or restrict certain processing.
• Withdraw consent at any time where processing is based on consent.
• Lodge a complaint with your local data protection authority.

Most of these you can exercise directly inside the app. For anything you cannot, write to hello@ambera.app and we will respond within 30 days.

Ambera is operated from the European Union. Some of our service providers operate globally; where data is transferred outside the EEA or UK, we rely on Standard Contractual Clauses or equivalent safeguards required by applicable law.

Our US-based sub-processors currently include Anthropic, OpenRouter, Stripe, GitHub and Google (analytics on ambera.app), alongside Apple, Google, Expo and Sentry for the mobile app. The hosts that run DeepSeek's open-weight model for Ambera Forge — DigitalOcean, Fireworks, DeepInfra, Baseten and Microsoft Azure — are likewise in the United States; OpenRouter is instructed to route to those and to no other, so no request reaches a server in China. Transfers of personal data to them are made under Standard Contractual Clauses. PostHog, Fakturoid, our database and its backups are kept within the EU.

Ambera is not directed at children under 16, and we do not knowingly collect personal data from them. If you are a parent or guardian and believe your child has provided us with personal data, contact us and we will delete it.

When we change this policy in a way that materially affects you, we will notify you in the app or by email before the change takes effect. The date at the top of this page always reflects the current version. Older versions are available on request.

Questions, requests, complaints, or things we got wrong — hello@ambera.app. A real person reads it.