Manual · FAQ · V1.7 · 2026-11-14

AirMemo FAQ

Version 1.7 · 2026-11-14. The questions teams actually ask while evaluating AirMemo, answered from the published pages and the live endpoints. This is the docs FAQ. Every answer states what runs today, anything not offered is marked as such, and what is deliberately not answered is collected under "Known gaps" at the end.

What AirMemo is

Q1. What is AirMemo, in one paragraph?

AirMemo is governed memory for AI agents at work: it delivers your organization's in-force decisions (the current answer on a project, a released policy, a corrected fact) into the session context of the agents your people run, and proves each delivery. It is the layer that decides what an agent is told next; it is not a chatbot, not a model, and not a store of source code. The moving parts: the gateway (the base URL an API-routed client points at, which adds the org's in-force memos to each request on its way to the model vendor), the cloud (api.airmemo.com: queue, governance, audit, receipts), the hook (a small binary that rides each agent's lifecycle events), the MCP server (the same six tools over MCP for any client), the browser sensor (a first-party extension that inserts a memo into a chat composer, and says so), and the console (org admin, inside the customer app at /app). The console is the customer's own administration surface; it is not the operator console a self-hosted install runs at /console, and not AirMemo's internal desk console.

Q2. Is this a memory tool, or a RAG index over our code?

No. AirMemo is push, not pull: it does not ingest or index your repository, your conversations, or your terminal output, and it stores no prompts and no model responses. It delivers author-written memos and nothing else, at session start, at prompt submit, or in the outgoing request. On the gateway rail the request passes through on its way to your model vendor and keeps no body on either side, so delivery is a queue of authored memos, not retrieval over your files.

Q3. Who is this for, and does it count non-engineers?

Everyone in the org who uses an agent, not just engineers: a seat is one governed person holding at least one active agent (a hook install) or a live gateway credential, so engineers, marketing, finance, sales, and executives all count. One person's several agents are covered by that one seat, and a tier caps agents as a total rather than per seat. It is priced per person per month, not per memo and not per agent.

Getting started

Both paths are live. Self-serve: sign up at the console (/app), create the organization, mint a bootstrap token, and run the free tier (up to 5 agents); sign-up is enabled on the hosted service, verified live 2026-10-18, re-checked 2026-10-30 (GET https://api.airmemo.com/portal/signup/status returns "enabled": true). Front desk: for a pilot workspace, SSO, procurement, or self-hosting, start at /talk.

Q5. How do I install the hook, and can we download it today?

The hook, not the product. AirMemo is live and self-serve: the console, the gateway, and the MCP server are available today, and the browser sensor is an add-on in test for the chat services it names. The hook's one-line installer and its release artifacts are served from the private repository that produces them: no one-line public install URL resolves, and customers install through the enrolled path described below. If you already have the binary (design-partner builds), an owner mints a one-time enrollment key (Org admin → Rollout → Enrollment key) and machines enroll with airmemo-hook enroll --org <slug> --org-key <key> --platform <name>; fleet tooling uses managed-install (one non-interactive command per machine, idempotent, deterministic exit codes). Platforms: claude, codex, copilot, gemini, cursor, windsurf, opencode. Until you have the binary, the gateway (Q15) or MCP (Q6) carries the same context with no install.

install --gateway is narrower than the platform list: it writes a gateway base URL for Claude Code (ANTHROPIC_BASE_URL) and Gemini CLI (GOOGLE_GEMINI_BASE_URL), and a provider block for Codex ([model_providers.airmemo] in $CODEX_HOME/config.toml, wire_api = "responses", a base URL carrying /v1). Every other platform is refused with a typed reason instead of a key the vendor ignores.

Codex is the one worth reading, because it moved twice. Codex speaks only the OpenAI Responses API, which the gateway serves now: the policy block goes into that API's top-level instructions, and the conversation in input plus any instructions the client sent go out untouched. The installer refuses in two places rather than guess: it will not retarget a model_provider you already set (re-run with --force), and it will not add [model_providers.airmemo] beside a table of that name it did not write, which is a duplicate-key error that stops codex loading any config, hooks included. What remains is the base URL: a provider pointed at a host that does not answer /v1/responses fails its first turn, and because the hook judges that client routed and stands down, the person loses the memo on both rails.

Q6. How do I connect an MCP client, and can an agent read the docs without an account?

Point any MCP client at https://api.airmemo.com/mcp with an org API token as the bearer; no install, six tools (whoami, search_context, get_decisions, get_memo, get_manual, propose_context). Per-client snippets ship for Claude Code, Codex CLI, Cursor, VS Code (Copilot), and Gemini CLI; Windsurf and OpenCode are wired by the installer. A separate anonymous docs arm at /mcp/docs serves get_manual, list_docs, search_docs, and get_doc over the public corpus, with no token, no sign-up.

Q7. What does the installer do to a machine, and can the hook block an agent?

install merges into the platform's config (pre-existing customer hooks are preserved byte-identically), pins the binary by SHA-256, so the hook never self-updates, and a changed hash makes install refuse without --force. It needs no administrator rights (user-space config), and uninstall removes exactly what it added. The hook is fail-open by design: when anything goes wrong on the poll path it exits 0 and the agent turn proceeds; a memo may be skipped, but the tool is never blocked. One deliberate exception, opt-in: force-continuation (off by default) lets urgent memos continue a turn.

Q8. What does an administrator approve?

Four things, and none is silent: (1) an organization API token, created by an owner or admin with scopes (memos:read, optionally memos:create, memos:revoke, audit:read), org-scoped and audit-logged on every call; (2) an agent enrollment for org-wide delivery: new agents land pending and consume no Agent Cap slot until an owner or admin approves them (Org admin → Agents); approving a person's first active agent, or issuing their first live gateway credential, consumes their Seat, and it frees when they hold neither; (3) agent proposals: propose_context, and any memo a bearer key writes to POST /v1/memos, both file a draft that an owner or admin must approve in the portal before any memo is enqueued, and the approvals queue names the token that wrote it; (4) a memo aimed at a team, while the org's group delivery is Parked: it is stored and signed, then released one memo at a time from the approvals queue.

Q9. Do I need a token for MCP access, and what is the credential model?

Yes: a short-lived, revocable org API token, scope-checked and audit-logged on every call; the raw token is shown once and only its SHA-256 is stored. There is no OAuth flow in v1. The bearer token is the credential, and no third-party identity provider is required for an integration to work.

Configuration and operation

Q10. How is the hook configured, and can a memo interrupt a running agent?

Resolution order is flags > environment > config file > defaults, and airmemo-hook config prints the effective configuration (secrets redacted). Defaults worth knowing: poll every 10 seconds, 5-second HTTP timeout, 7-day local cache, learn events off. Force-continuation is off by default; when on, only urgent memos can continue a turn. Leave it off unless you want a memo to spend model tokens without a human asking, and scope who can send urgent.

Q11. What are the rate limits?

Defaults: 30 pushes per minute for agent traffic and 60 events per minute for integrations, enforced by one shared policy engine across the agent API, integrations, and portal. Policies are rows (org, scope, who, action, limit) and the most specific match wins; a limit of 0 on an override row is a hard block (0 on a code default means no cap). Every violation is audit-logged (rate.limited), and a per-author concurrency cap can answer 429 max_concurrent_exceeded.

Q12. How does an org-wide ("broadcast") send get approved?

A comms-role author sending org-wide enters pending and is not enqueued until an owner or admin approves it in the portal; reject means revoked. A matching broadcast policy row is a grant that bypasses the approval step (rate limits still apply). There is no auto-escalation: if nobody approves, the memo lapses to expired and the author sends it again.

Q13. Can I send this to one team, and who actually receives it?

Yes. Pick the group in the composer: the target list is your org's own teams and projects, searched by name; a person target searches people by name or address. The scope kinds are org, team, project and person. The contract still accepts a legacy channel scope, which names a device label rather than people: no group can carry that kind and no rail reads a label, so a new send carrying one is refused 422 scope_unresolvable, and a stored one delivers to no one. It is deprecated, with a sunset of 2027-05-04. The composer does not offer it, because a room is not a set of people anything can count. One memo names one scope, so reaching two teams is two sends.

A team has to exist as a group with members. A name that matches no group is refused with 422 scope_unresolvable, the same answer that covers an archived group (group_archived), a name carried by two groups of one kind (group_ambiguous), and an id that names no group in your org (group_not_found). The console sends the group id, not the string you typed, so a rename does not change who a send goes to.

Who receives it is printed above the send button as three counts of people, and they are a funnel, not three ways of saying one thing:

addressed: the people the scope names: the chosen team's live members, one person, or the whole roster for an org send.
reachable: of those, who holds a rail today: one active install of their own, or a live gateway credential. This is also the number the invoice counts.
delivered: of those, whom this memo's platform and agent target admits. A gateway credential holder takes whatever the gateway carries, on whatever client they already run.

The no-agent case. A team whose members have not installed the hook and hold no gateway credential does not refuse the send. You read "4 people are addressed, but none has an agent or a gateway credential yet. The memo is saved and delivered as soon as one appears." And that sentence is what happens: stored, held, and delivered to each person the moment their install or credential goes live. Only a scope that names no live person at all is refused, because there is nothing to wait for. A team send does not wait for approval on account of its author's role: that gate is org-wide only. It does wait when the org's group delivery is set to Parked, where every new memo aimed at a team waits in the approvals queue until an owner or admin releases that one memo (Q8).

Afterwards the memo prints two readings side by side: "Addressed at send" (the people the send froze) and "Would receive it now" (who is in the scope and able today). The memos list then shows coverage as receipts over the frozen number, so a team that grows next week cannot quietly improve last week's score.

Q14. How do we roll out to a fleet (MDM / managed machines)?

One command per machine from the console's Rollout tab. The org enrollment key is embedded, rotation happens in the same tab, and re-runs are idempotent with zero prompts. Exit codes are deterministic: 0 ok, 3 bad key, 4 unreachable, 5 unsupported platform, 6 hash-change conflict, and 7 agent pending approval (park the machine and re-run after approval; not a failure). airmemo-hook installer-mdm emits managed templates for MDM tooling.

The gateway rail

Q15. How do we connect our agents, and what does the gateway do?

Three answers, in this order, and the first one is the spine.

An API-routed tool. Anything that speaks the Anthropic Messages API, OpenAI chat-completions, or the OpenAI Responses API points its base URL at the gateway, Codex CLI included, the Responses-only client (Q5): https://<gateway>/k/<token> for an Anthropic-shaped client, https://<gateway>/k/<token>/v1 for an OpenAI-shaped one, chat-completions or responses, because codex appends /responses to the base URL itself. Nothing else about the client changes. Its own provider key still travels with the request, and the gateway holds no vendor credential of its own: the key is forwarded to the vendor in the request the client wrote, AirMemo stores none and never replays one, so revoking access takes one token, not a key rotation. The gateway resolves the memos in force for the person behind the token, adds them as a marked system block before the call leaves, and mints the receipt server side.

A desktop or CLI coding agent. The hook (/mechanism#install) is the rail with per-event delivery you can watch, and it can be pointed at the gateway: when it is, it asks the gateway what to carry, and if the gateway has not answered within 1.5 seconds it uses the local poll it already runs.

A desktop chat app. A desktop app that exposes a gateway or model-address setting can be pointed at the gateway by hand: the ChatGPT desktop app reads the Codex config the installer writes, and Claude Desktop exposes a third-party inference setting. We do not certify either path yet: the ChatGPT desktop setting is written by the installer's Codex block, and the Claude Desktop setting is entered by hand. A plain chat window in either app has no such setting.

Browser chat. A browser chat window has no place to put a base URL, so the gateway cannot route it. A first-party browser extension covers it, and it is described as a sensor: it inserts the memo into the composer and reports the pages it was loaded into. It is an add-on in test, not a managed install. Where it is not installed, that traffic is unobserved, and nothing on the site counts it as covered.

Deploy: the reference compose file runs the gateway (docker compose up -d in infra/selfhost/compose; it listens on 8082 and binds loopback until TLS sits in front of it). Enroll people with POST /portal/gateway/enroll as an owner or admin: one token per active person, 30 days by default, at most 1000 people per call. An org-wide token is refused on this rail, because a receipt has to name a person.

Q16. When the gateway cannot reach policy, does it block the call?

Not unless your org says so, and the Gateway page in the console shows which mode is in force.

Alert is the default. The request is forwarded bare and the response says so in x-airmemo-policy (ok, stale, unavailable, or unknown), so a client can tell a governed call from an ungoverned one without reading logs. stale marks a call that carried a cached policy while the policy store was unreachable.

Block is set per organization by an owner or admin, through PUT /portal/gateway/mode, and audited as org.gateway_mode_configured. The gateway then refuses a request whose policy it cannot resolve with 503 and airmemo_policy_unavailable, instead of sending it bare. The org's mode is read before the memos are, on every request, so a cold cache cannot quietly turn a block org into an alert one; if the mode itself cannot be read, the request is refused too, and that refusal says unknown in x-airmemo-policy.

A second refusal is not about policy at all: if the memos resolve but the body has nowhere to put them, alert forwards the call bare with x-airmemo-injection: unsupported on the response, and block refuses it with 400 and airmemo_body_unsupported.

A third is not about policy either, and is the same answer in both modes: a body no provider can read is refused before the mode is even read. Not JSON at all is 400 airmemo_body_not_json; a numeric parameter that is not a finite number or is out of the wire's range (max_tokens: 0, temperature: 1e9, NaN written bare) is 400 airmemo_body_field_invalid, and the message names the field.

Either way what is at stake is the outgoing model call, never the memos already on the machine: the hook's delivery rail is separate from the model call, so a refused request changes nothing about what the tool already holds. In block mode the turn stops with the client's 503, and the response carries retry-after: 5 so a library that honours it backs off instead of spinning. No second path to the provider exists: the installer writes one base URL, and a fallback the gateway cannot see would be a second rail nobody governs.

Troubleshooting

Q17. "My memo didn't arrive": where do I look first?

Run airmemo-hook doctor, then walk the decision tree: identity present; memo targeted at this platform/agent (a mismatch stays queued for the right target, not lost); expires_at in the future; not already injected (duplicate guard); if org-wide, was it approved; revoked?; agent online within the expiry window. The stderr inject: line names skips, and a hook that ran but printed {} is the no-op contract, not an error.

Q18. Enrollment and auth failures: the common ones and their fixes.

not enrolled → run enroll; already enrolled; refusing to overwrite identity → delete the config file to re-enroll (identities are never silently clobbered); 401/403-class failures (unknown_device, bad_signature, clock_skew, …) are never retried, never injected: run doctor, and keep the system clock within the 5-minute HMAC window; device_pending is a wait, not a fault. After approval the hook picks it up on its own, with no re-enroll and no restart.

Q19. How do I prove a memo was delivered?

Receipts. Each injection posts a receipt to /v1/receipts: which memo reached which agent, when, and a proof hash of what was delivered. Locally, airmemo-hook receipts shows the journal (injected: true, receipt_sent: true means fully delivered; receipt_sent: false retries on the next poll's offline drain). In the console, delivery rows and the append-only audit trail are the record. Receipts are chained per organization: each stores the fingerprint of the receipt before it, so a row edited, reordered or dropped after the fact fails at that point and every point after it. GET /v1/receipts/ledger exports the chain as NDJSON with the head in x-airmemo-chain-head for you to keep, and GET /v1/receipts/ledger/verify re-walks it server-side. The honest edge: the chain proves alteration after the fact, never a delivery that did not happen (a suppressed receipt leaves no gap), and receipt verification is limited where the input is not recomputable server-side; see the security page.

Security, privacy, and compliance

Q20. What actually leaves a developer machine, and do you track usage?

A request from the AI client to https://api.airmemo.com/mcp (or the hook's poll to the configured base URL) over HTTPS, carrying the org token. The hook dials exactly the configured base_url: health, enrollment, queue, receipts, deliveries; learn events are off by default. Telemetry is opt-in and off by default, and receipts, not analytics, are the record of what was delivered. Secret scanning runs at author time and again at delivery, and matched values are never stored.

Q21. What do you store, what do you never store, and how long is it kept?

Stored: the org's memos (author-signed text) with scope, priority, expiry, and approval state, plus delivery receipts with their proof hash. Never stored: source code, prompts, chat history, credentials. A memo is live until the expiry set when it is authored (7 days where the author sets none), after which the memo expires and its queued copy is deleted (memos are not archived); receipts and audit events are insert-only, and the tier's audit window (Q29) bounds how far back the console can read, not how long a row is kept. Rows leave storage through erasure: export-before-delete manifests, and offboarding hard-deletes them within 30 days.

Q22. Where is our data processed, and is there an EU option?

Default is a single region: US. A region setting exists and an "EU" claim can be recorded, but it is not a storage guarantee yet: cloud processing is split across US East (Postgres) and US West (compute), and EU data-residency processing is not offered today. The machine-readable posture is https://api.airmemo.com/status.json; the human trust page at https://api.airmemo.com/trust renders the same posture as HTML and does not serve JSON. Both were checked against the live service on 2026-10-18.

Q23. Do you have a SOC 2 report?

Not yet, and it is not claimed. There is no report yet, and we will publish it when it exists.

Q24. SSO, SCIM, and MFA: what ships today, and what is not offered (SAML)?

SSO (OIDC), SCIM 2.0 inbound provisioning, and MFA ship today, at every tier. SSO never grants privilege by itself (JIT members are members; the roles are owner, admin, member, comms), and SCIM deprovisions to member. SAML is not offered yet, and fine-grained RBAC beyond the four-role enum does not exist.

Q25. Can we self-host it (including air-gapped), and what does it cost?

Yes. The self-host kit ships (compose, Helm, Terraform; one image, run twice: an api process and a worker process), licensed by an offline signed license file with no phone home; without a license it runs in community mode with ceilings. Restricted-egress deployments are documented and everything outbound is off by default: no telemetry, no license server, no update check. Self-hosting is priced at the same $12 a person per month as the cloud edition, with no multiplier; you run the infrastructure.

A self-hosted install serves two surfaces: the customer app at /app, and your own operator console at /console (org roster, incidents, audit, events, box health), signed in with that install's operator. AirMemo's internal desk console at /ops is not part of it: the path and its intake and prospect routes are not registered on a self-hosted box, so they answer 404.

Q26. Is the hook safe to deploy fleet-wide, and can we read the source?

Deployment: a single static binary, no shell execution, user-space, hash-pinned, merge-safe install and exact uninstall; fail-open, so it can never block an agent session (Q7). Source review: the hook client is proprietary, and AirMemo will make its source available for a customer's security review under a confidentiality agreement on request. There is no public repository; see Q5 for the install path that works now.

A public DPA covers controller/processor terms, the sub-processor list, retention, deletion, and breach notification; the Privacy Policy states what is collected, why, and for how long (front-desk intake data: 90 days). Requests are handled through the same org-scoped channel as the rest of the service: there is no separate compliance portal. The requester kit (/requester-kit.md §7) lists the same path for a buyer's legal reviewer.

Billing, plans, and limits

Q28. How is a seat counted, and what happens when people leave?

A seat is one governed person with at least one active agent (an approved hook installation on at least one machine) or a live gateway credential (issued to them so a chat tool can deliver on their behalf). A person running three agents is one seat; the seat attaches at their first active agent or first live gateway credential, and it frees when they hold neither. The subscription quantity is that count of people, so the bill follows people while the agent ceiling follows the tier (5 on Free, 100 on either paid tier) or the number a contract records. Seats cannot be moved below the count in use (the console refuses with 422 seats_below_enrolled). Enterprise has no minimum size and no rate floor; an org still sitting on an older price row that carries its own minimum is held to that row's minimum (422 enterprise_floor) until the row is re-pointed to the flat rate. Console identities are not the meter: a person who only signs in to the console holds a user slot, not a seat, and unused logins do not bill. A licensed self-host install takes its people from the licence's seat count and its agents from its agent cap.

Q29. What are the hard limits per plan?

Free: 5 people · 5 agents · 7-day audit visibility. Cloud: 100 · 100 · 90 days. Self-hosted: 100 · 100 · 90 days. Enterprise: people by contract · agents by contract · 365 days. On the self-serve rows the same number caps people and console users, and the agent column is the tier's total, not an allowance per person. Enforcement is technical and automatic: exceeding either ceiling is refused at enrollment with 429 seat_quota_exceeded or 429 agent_quota_exceeded, and a lapsed org's capacity clamps: immediately on cancellation, on day 15 for a failed payment.

Memo body: 20,000 characters on every plan (about 3,000–3,300 words); titles cap at 140. This is one delivery guardrail, not a plan difference: a longer memo is refused with 422 memo_too_long, never silently truncated.

Q30. What happens if a payment fails, or we cancel mid-term?

Payment failure: full access for 14 days, then read-only from day 15. Reads keep working, writes answer 403 org_readonly, and nothing is deleted. Cancellation: capacity clamps immediately. A canceled enterprise org drops to the business ceiling (100 agents, 90-day audit), and write access runs 90 days, then read-only; data is kept. Refused billing webhooks leave audit rows, so refusals are visible.

Q31. Refunds and chargebacks.

Refunds are handled manually: no code path issues one, by design, and the Terms carry the refund and dispute remedies (§6, §7). Plan conversions are handled as price changes, not credits, and the pricing page describes them that way.

Q32. Can enterprise buy by invoice or ACH, and what does it cost?

Yes. Enterprise is the same $12 a person a month as the self-serve paid tiers, billed annually, with ACH set up in the console or a card for the first annual invoice. There is no ladder to climb: no minimum order size, no band, no floor, no volume or term step, and no setup fee. An order is an enterprise order because it runs past the self-serve ceilings (100 people or 100 active agents) on an annual invoice, not because of its size: 100 people come to $1,200 a month, $14,400 a year. Self-hosted is the same $12, with no multiplier. A pilot runs 90 days at $12 per person per month, billed monthly by agreement at whatever size you start at, with no minimum and no pilot discount; at day 90 it continues monthly at the same rate unless you give written notice or sign an annual order. There is no usage-based billing and no per-memo price anywhere: every active price is a licensed recurring seat price, and a seat is a person.

Support, status, and contributing

Q33. Is the status page real?

It is a live ledger, not a static page: /status renders from service probes, and the same posture is published machine-readably at https://api.airmemo.com/status.json (live 2026-10-18: ok, no incidents). If you want to cite availability, cite the ledger.

Q34. How do we reach a human, and is there an SLA?

Front desk: /talk (pilot requests, SSO, procurement, self-hosting) and the support terms in the Terms of Service (§10). What is deliberately not shipped: a human service layer, with no onboarding calls, no account managers (exception paths are automated only). There is no published uptime SLA today.

On a self-hosted or air-gapped install, support is by appointment and the install never calls us: an owner or admin exports the Support bundle from Audit in the customer app (/app) and sends it, or carries it across whatever the site allows. Nothing is transmitted automatically and the zip is the customer's to delete (docs/enterprise/onprem-runbook.md §8d).

Q35. Can we contribute, or run the stack locally?

External contributions are not open yet: the repository is private (the hook client is proprietary; see Q26). You can run the stack locally: pnpm --filter @airmemo/cloud db:dev for a fresh database and make test for the suites (the repo root exposes only validate:contracts and gen:cloud; root pnpm test and pnpm db:dev both return ERR_PNPM_NO_SCRIPT), make hook:build for the Go hook, and the hook's whole delivery path can be smoke-tested offline against the fake cloud. The MCP docs include a runnable third-party client example.

Self-serve account actions

Q36. Do I need a card to start, and what does free include?

No card. Sign-up creates the organization and there is no payment call in the signup handler. Free includes 5 agents, memos up to 20,000 characters, and 7-day audit visibility (Q29); the sixth agent is refused at enrollment with 429 agent_quota_exceeded rather than billed silently.

Q37. How do I upgrade, and when does the charge land?

In the console: Billing → choose the plan → checkout. A seat-count change mid-cycle is sent to Stripe with create_prorations, so the prorated difference lands on the next invoice instead of charging the same day. Upgrades (free → a paid plan) are allowed; a downgrade is refused with 409 downgrade_not_allowed and the message to cancel first, because a plan switch is a new subscription, not a quantity edit. An enterprise order past the self-serve ceilings is billed annually, by ACH set up in the console (Q32). A pilot runs 90 days at $12 per person per month, billed monthly, with no minimum and no pilot discount. At day 90 it continues monthly at the same rate unless the customer gives written notice or signs an annual order. No annual term starts by silence.

Q38. How do we invite teammates, and what does each role do?

An owner or admin invites by email from the console (POST /portal/invites); the invitee sets a password and joins the org. Roles are owner, admin, member, and comms. SSO JIT and SCIM both land people as member, never as an admin (Q24). Seats count people with at least one active agent, not console logins (Q28), so adding a teammate costs nothing until their first agent enrolls.

Q39. How do I export or delete the organization?

Both are owner-only and both live in the console. Export (POST /portal/org/export) returns a bundle of the org's memos, receipts, audit events, members, and settings. Deletion (POST /portal/org/erasure) requires a typed confirmation and returns the export archive before it runs the erasure, so the copy exists before the rows go. Offboarding hard-deletes within 30 days (Q21).

Known gaps

Two things this FAQ deliberately does not answer, with where to ask:

Mid-term seat reductions. What removing seats mid-term does to the next invoice is not stated on any public surface yet; ask the front desk (Q34).
Uptime SLA. None is published; the status ledger (Q33) is the availability record.