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 teams that run an application: it counts what the application sends, opens issues from those counts, keeps the team’s decisions, specs, releases and outcomes, reads the repository a workspace connects, and reads the market around what is being built. It never writes to a 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 it:

• Workspace details: the workspace (organization) name, its URL slug, an optional logo, and its settings — including who paused or resumed the automatic weekly Signal cycle, 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 checks only for the pull-request check. Forge never asks for permission to write repository contents or pull requests. 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 that record which pull requests Forge has analyzed. Nothing here decides an invoice: the plans are flat and unmetered. When the pull-request check is switched on, Forge also writes a check result on your pull requests. When a pull request merges into the repository’s default branch, Forge reads its branch name, title and description for a `Forge-Issue:` line and moves the issue it names to awaiting release; the description is not stored, only the pull request’s number as the move’s reason.
• Readings: code-read snapshots of connected repositories — per-signal and per-detector counts, up to 5 example file paths per finding, the HEAD commit the reading was taken at, the repository’s description on GitHub and its recent commit subjects, 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 3 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 only to signed-in members of the workspace the repository belongs to.
• 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.
• Products: what the workspace asks Forge to read the market for — the name, the product’s website address, Forge’s reading of what the product is (the sentences composed from that website and the linked README, each with its source and the date it was read), your description and any correction in your own words (every surface that shows them says they are yours), an optional logo, who you say it is for, the goals you choose for it (works, converts, grows), the companies, products and arguments you confirm for the watch list with your notes, the weekly briefs, the labels you put on their items, the answers about what your product does (each marked as coming from the text Forge holds about the product or from your own hand), the versioned market-fit readings, the brainstorm transcript, and — for workspaces that used them before 10 October 2026 — the credit ledger of every grant, charge and refund.
• The oversight of a product: the context you give it — the address of the application, its environments, the thresholds its issues open at, and its journeys (a start event, an end event, the page the journey lives on); the issues Forge opens from counts, with their state, every move between states with who made it (a member, or no person when a merged pull request names the issue, a release starts measuring it or its outcome is read) and the reason given; on issues opened before 5 November 2026, a member’s reading and hypotheses and an effort estimate with its assumptions; a snooze date; the work specs, every version, with who or what wrote each (Forge from the counts, a member, or the model as a labelled draft) and the model’s usage for a draft; the releases Forge reads from what your application sends (the release each row names, first seen per environment) or a deploy pipeline records (environment, commit or version, when), and which issues each ships; and the outcomes read after a release — counts over the windows the plan named, never a verdict. Feedback imported from a CSV is covered under "Your users’ data" below.
• 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. A key minted for a product with the release or feedback scope can only record a release or import feedback for that product, and nothing else.
• A repository read on your own machine: the Forge CLI (`npx @ambera/forge map`) reads the manifests and the imports of a repository on your computer and prints the result there; nothing leaves the machine and the CLI carries no telemetry. If you sign in and hand a reading to one of your products (`--submit`), what we store is that reading and nothing else: the capabilities the manifests evidence, the dependency names behind them, the paths of the files importing them (never their contents), counts, and the commit id — one reading per product, replaced by the next, and deleted with the workspace.
• 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, the report of a sector you follow (weekly on a paid plan, monthly otherwise), notices about your account or these terms — is not marketing and is not affected.

Your users’ data (Ambera Forge tracking)

A product’s application sends what it does to Forge with a tracking key the workspace creates: events (a name, for example a sign-up completed), error logs (the error’s name, message and stack, and the page it happened on) and logs (a level and a message), each optionally with a person id and a session id your application chose, a timestamp, the environment, the release, and up to twenty short plain properties. Those rows describe the people who use your application, so they are the one place Forge holds data about people who are not its customers. Forge treats them as follows:

• Before a row is stored, every message, name, stack and property value is scrubbed: e-mail addresses, IP addresses, long digit runs and anything shaped like a secret or a token are replaced with a placeholder, and a web address keeps its path and loses its query string and fragment, where sessions, tokens and e-mail addresses travel. The IP address of the request is never read. A timestamp more than 7 days old, or more than 5 minutes ahead, is replaced with the time the row arrived.
• The person id and the session id are hashed together with the product’s id before they are stored, so the id as your application sent it is never stored and the same person is a different value in every product. Someone who already knows an id and the product’s id could check it against the stored value, so your application should send an opaque id rather than an e-mail address. Forge never shows a hashed id, never lists the people behind a count, and never ranks them.
• An admin of your workspace may list, under the product’s Settings, the ids your application identifies your own team with (at most 50). Each is hashed the same way before it is stored, in the product’s store, and the id as typed is never kept, so the page can say how many are listed but never which. Forge also keeps, as hashes in the same store, the sessions of theirs it found and the anonymous ids seen in them, so a visit that starts before sign-in is recognised too; those go when the last row that named them is deleted after the plan’s days. Their rows are stored and kept like any other and left out of every figure Forge uses to judge the product; Issues and Settings say, to every member, how many are theirs. Your application may also ask, by sending an event named `$team_request` while one of you is signed in, that this person be counted as your team: the request is not stored as a row, it keeps that person’s hashed id until an admin confirms or dismisses it, or for at most 30 days, and at most 20 wait at once. On the product Forge’s own dashboard sends to, an admin can add their own account the same way. Clearing the list deletes the listed hashes and puts the rows back in the counts; deleting the product deletes all of it.
• When your website hands a visitor over to your product, the link carries the visitor’s anonymous id (`forge_h`) — never an id your application identified them with — and your product’s tracker keeps using that id, so the arrival counts as the same visitor. Your application may hand the same id to its own server in a request header (`x-forge-id`). A row the tracker sends names which part of the product sent it: the site, the app or the server.
• Each product’s rows live in a store of their own — a Cloudflare Durable Object with its own SQLite database, one per product — separate from the shared database. Every count Forge shows over them is an exact count, never a sample. A store refuses rows past the number a day your plan states (20,000 to 100,000) and counts the refusal, and a comparison over such a day is withheld.
• Rows are kept for the number of days the workspace’s plan includes — 30 days on Free, 90 on Solo, 180 on Team and 365 on Premium — from the day they arrived, and then deleted by the store itself; when a plan falls to fewer days, the older rows are kept 14 days more and then deleted. What Forge derives from them — a count per day per kind, an error’s fingerprint with its day counts, the observations an issue rests on, and a handful of an error’s latest occurrences shown to members with the issue — is kept with the product, because an outcome is a comparison with a past that must still be there. Revoking a tracking key refuses new rows within 60 seconds; what the key sent stays until the plan’s days forget it. Deleting the product wipes its store.
• Members of your workspace — viewers included — can list those rows on the product’s Activity page and filter them by name, level, environment, release, the part of the product that sent them (site, app or server), a phrase or a property, for as long as they are kept. The table shows each row as stored, scrubbed as above, and never a person id or a session id: those stay hashed in the store and are never listed or shown. The one filter that reads them is the team’s own: with ids listed under Settings, the page can leave their rows out. It never shows their rows alone.
• Feedback: text a member imports from a CSV or a service of yours sends with an API key that has the feedback scope (what a user said, on which day), with an optional reporter key the member chose. The reporter key is stored as given and never shown — a surface says only whether an item carries one — and it is deleted with the product. Forge counts feedback by theme; it never writes to anyone behind an item.

For these rows your organization is the controller and Ambera the processor (see "Controller and processor roles" below). Your organization decides what its application sends and is responsible for telling the people who use it, under the law that applies to it; In a browser the SDK records page views and uncaught errors on its own unless your application switches that off, and otherwise it sends only what your application calls it with; the key is a public, append-only one that can add rows to this product’s store and read nothing.

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 market map and the sector, company, category and market-size pages on forge.ambera.app render — and what each sector’s dated monthly report and its downloadable dataset are counted from. 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. When a repository reading finds a dependency it cannot place, Forge counts it under a salted hash of its name and of the workspace; the name itself is kept, and handed to a model to say what it does, only once 2 workspaces have it. Nothing else of a reading is pooled.

Forge has doors that need no account. The market map, the sector, company, category and market-size pages and the deadlines page need no account either and store nothing about the visitor; the services you pick on the deadlines page live in the page’s address and nowhere else, and what you type into “What are you building?” on a sector page is matched in your browser, stays in that browser tab until you sign in, and is sent nowhere until you do. If a search on the market map finds no sector, the only thing kept is that it happened: a count of such searches, with nothing that links it to you.

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.

Three promises hold here, and all three 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. 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.

The third is about the people who use your application. What your application sends about them reaches Forge scrubbed and with its ids hashed per product, as "Your users’ data" says, and every number Forge makes of it is a count: how many sessions (one person’s rows less than 30 minutes apart), how many people, how many completed a journey, how many times an error was thrown. No surface shows a person, lists the people behind a count, or ranks them, and Forge never contacts anyone whose row it holds. If someone who uses your application asks you what Forge holds about them, write to hello@ambera.app with the hashed id your application can compute and we answer as your processor.

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, products with their descriptions, briefs and labels, the issues, specs, releases and outcomes of their oversight — and for the rows a product's application sends about the people who use it, 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 and the rows a product’s application sends is available on request — write to hello@ambera.app. The sub-processors that touch those rows are Cloudflare (the per-product stores and the API that receives the rows), Neon and Hetzner (the shared database and its backups, which hold the counts, issues and outcomes derived from them, never the rows), and — only when a paid member asks for a spec draft — OpenRouter with Anthropic or a US host of DeepSeek’s open-weight model, which receive the program’s evidence lines and one scrubbed error occurrence, as "The model in Ambera Forge" says.

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 — receive and count what a product’s application sends, run the detectors over those counts every morning and keep the issues, specs, releases and outcomes a workspace records, read the repositories a workspace connects (on request, and again every night so the readings have a memory), run Signal’s weekly market cycle for the subjects a workspace confirmed, send the email the product calls for (the magic-link sign-in, workspace invitations, the weekly Signal brief, movement notifications for gated work, and the weekly digest for the market sectors you follow), and bill through Stripe — a flat price per plan, with no usage meter.
• 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 counts over what an application sends and every detector that opens an issue from them, the outcome arithmetic, the repository read, the check of a service’s own pages, and the market-fit arithmetic are deterministic code, so the same rows always count 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:

• Drafting a work spec, on a paid plan only: by itself when an issue opens (at most three a product each time Forge reads it, for issues opened in the last 14 days), and when a member asks, at most once an hour per issue. On every plan an issue first gets a spec Forge writes from its counts with no model. The model is handed the issue’s title, the evidence lines the program wrote from its stored counts, a member’s reading and hypotheses where an older issue holds any, one scrubbed occurrence of the error for an error issue (its message and first stack lines, with e-mail addresses, IP addresses and token-like strings already removed) or, for an issue about visitors arriving from your website, the scrubbed titles of the errors that followed their clicks, and the file paths the repository reading found — never a file’s contents, and never your application’s rows as a list. The draft is labelled the model’s, every number in it that the evidence does not hold is marked for a person, and the model cannot name a file the reading did not see.
• Reading what your product is: the public text of the product website you gave us (its home page and at most two same-site pages it links, such as pricing or features, read over plain HTTP, the first 10,000 characters) and the README of the repository linked to the product (the first 12,000 characters, read through your GitHub connection where the repository is private). The model writes a few sentences from those texts, each naming the source it came from, labelled as Forge’s reading and shown to you. It is read again when your website or README changes (checked at each market scan, when you save the website, or when you ask), and nothing is composed when neither changed. No source file is read. Where neither can be read, the description you wrote is used instead.
• Seeding a product: the text Forge holds about what the product is (the reading above together with any correction you wrote, or your own description where there is no reading), and who you say it is for, so the model can propose the companies, products and arguments to watch — and the same again when that text changes, to propose a new watch list. 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 the text Forge holds about what it is (as above) together with this week’s catalog entries for its watch list.
• Answering what your product does, per capability the market declares: the text Forge holds about what it is (as above), and the capability names read from the market. Where that text 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.
• Finding pages that mention your product: its name and web addresses. The model searches the web for them the way the weekly watch does.
• The brainstorm, only when a member writes in it: the conversation so far, the text Forge holds about the product (as above) and the market entries it may cite.
• Placing a dependency the repository read does not know: its name and ecosystem, only once enough workspaces have it (see the shared catalog paragraph above), never which workspace or repository it came from.
• The sector sweep and sector discovery, run on Forge’s own budget for the sector pages: the sector’s name and its companies’ names and web addresses. No customer data of any kind.

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, an issue opens only when a count crosses its threshold, and a drafted spec is checked against the counts it was handed.

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 that is held in memory for the visit and stored nowhere on your device — no cookie and no local storage until you sign in; 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, connecting a repository, a purchase, and a workspace reaching a usage threshold. The app itself records which steps of first use were taken — starting a sign-in, which first-run door was chosen, describing a product, running a cycle, and on the public market map how many sectors a search found and which sector an opened gap, a report or a download concerned — as named events with no content attached; the words you type into the map’s search are never among them. No finding, no file path, no line of source, nothing you wrote into Signal or an issue, and nothing your application sent to Forge 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.

The marketing site also sends page views and a handful of named events — which call to action on the page was pressed — to the same PostHog instance, without cookies and without storing anything on your device. For each visit PostHog derives a pseudonymous identifier from your IP address, browser and the current day; it changes every day, so it can count visits and which campaign brought them, but cannot follow you from one day to the next or from the site into the product. Because nothing is stored on your device, this does not wait for the banner.

Forge and the marketing site also send to Forge's own tracking — the same service Forge offers its customers, run on our own infrastructure. On the marketing site it records page views, uncaught errors, which call to action was pressed and a click on a link into Forge, under an anonymous id held in memory for the page and stored nowhere on your device; on that click the id travels in the link, so Forge can count how many of the visitors who clicked reached it. In Forge it records page views, the named steps of first use listed above and uncaught errors, and once you sign in your account id; our servers add the named events listed above — signing up, a workspace being ready, connecting a repository, a subscription starting or ending — with your account id where the step is yours, and with no person where it is a workspace's. Every id is hashed before it is stored, the IP address is never read, e-mail addresses and anything shaped like a secret are removed from what is kept, and the rows are kept for at most a year. Because nothing is stored on your device, this does not wait for the banner either.

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, transactional email through Cloudflare Email Service (for example, your magic-link sign-in message, sent from noreply@ambera.app), and the per-product stores (Durable Objects with SQLite) that hold what a customer’s application sends to Forge for the days its plan includes.
• 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 the credit top-ups sold until 10 October 2026. Every plan is billed per workspace at a flat price, with no usage meter. 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. With the pull-request check on, it writes a check result; it writes nothing else.
• 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 — no job carries source code or a row your application sent; the spec draft carries file paths and one scrubbed error occurrence. 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.

Requests go to third parties that are not our service providers on your instruction: Signal reads the public websites of the companies you ask it to watch, and the pages of the services your app rests on. Those sites see ordinary requests — from the search provider, or from us when a page is checked directly, with its robots.txt obeyed.

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 instrument's value is its memory — 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. Briefs and market-fit readings are kept for the same reason: a number with no history is a number nobody can check. What a product's application sends is kept the days its workspace's plan includes from the day it arrived and then deleted by its store; the counts, issues, specs, releases and outcomes derived from it are kept with the product, because an outcome is a comparison with a past that must still be there. Revoking a tracking key refuses new rows within 60 seconds; deleting a product wipes its store the same day. 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 grace window of 25 days, within the 30 days above. Deleting a workspace wipes every product’s tracking store first, then purges every table keyed to the workspace: members and invitations, connections and installation records, readings and their snapshots, gates, waivers, products with their entities, briefs, labels, capability answers, fit readings and credit ledger, tracking keys, evidence, feedback, issues with their history, specs, releases and outcomes, 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 pooled dependency counts hold only salted hashes of the workspaces behind them. 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; the code read never stores a credential value it finds — a finding is a location and a count; and a tracking key can only append rows to its own product’s store and read nothing, while the rows it appends are scrubbed of anything shaped like a secret before they are kept.

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 Cloudflare, Anthropic, OpenRouter, Stripe, GitHub and Google (analytics on ambera.app), alongside Apple, Google, Expo and Sentry for the mobile app. A product's tracking store is a Cloudflare Durable Object, which Cloudflare places close to where its first rows came from and keeps there; it is not pinned to the EU, and we say so rather than imply otherwise. 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.