Privacy & data handling.

Clerk provides Architecture Studio website identity and MCP OAuth authorization. Browser sign-in and host authorization are separate: signing in to the website does not by itself connect an assistant or grant access to project files. Review the permissions shown during authorization, and use your account and host controls to manage sessions and connected access.

When account contact synchronization is enabled, a new account’s verified primary email is added to the Arch Studio Accounts and Product updates segments in Resend. Product updates are opted in by default as disclosed at sign-up; unrelated topics are opted out. You can unsubscribe from any update or in Email preferences and opt back in there. Existing contacts keep their preferences when account membership is synchronized. The public Product updates form remains a separate confirmed opt-in for people without an account.

When connection verification is enabled, Neon stores your Arch Studio account identifier, legacy selected app and onboarding records alongside dated connection observations. Successful authenticated MCP initialization or tool discovery can verify a connection; website sign-in alone cannot. These records do not include prompts, tool inputs, project files, outputs or credentials, and do not indicate that you are continuously online. Legacy onboarding records and connection history are retained for account operation until removed; contact f@alpacalabs.co to request removal. Temporary connection event receipts prevent duplicate processing and are eligible for cleanup after 14 days.

The local plugin keeps durable Studio and project records in the workspace selected by the user. Files sent to the assistant are processed under that provider’s terms. A hosted MCP operation receives the explicit inputs supplied to it; it does not automatically mount or browse the user’s workspace. The host remains responsible for applying returned records and artifacts. MCP 0.1 is not a synchronized project database.

External reference sources and tools have their own access and data policies. Do not assume that an operation stays on your device merely because a local plugin initiated it. For professional work, use a firm-approved business, team, or enterprise account and confirm the host’s training, retention, connector, and access settings. Arch Studio does not override those provider policies.

Architecture Studio collects bounded hosted MCP usage when production collection is enabled. Coverage begins at activation; earlier activity is not backfilled. Website CTA click receipts are collected when production collection is enabled. Each receipt contains only the CTA action, page route identifier and target host. It contains no identity, email address, referrer, query string, campaign value or free text, is not linked to an account, and is eligible for scheduled cleanup after 30 days. Account-creation events are also collected from the verified Clerk user-created webhook. Each contains a pseudonymous account identifier, timestamp and Clerk source marker; after this release it can also contain the bounded acquisition source and optional allowlisted reference described below. It contains no email address. Session-event usage collection remains disabled. Operational account-signup notices to the Arch Studio operator are enabled separately when that notification service is activated; newsletter operator notices remain off.

When you follow a sign-up link, Arch Studio can carry one bounded acquisition source category—LinkedIn, GitHub, Google/search, personal outreach, partner/referral, direct or unknown—and an optional allowlisted short reference through that sign-up. This value describes what brought the account to sign-up; it is not browsing history. Raw referrer URLs, query strings, campaign names, email addresses and free text are not attached to the account. The bounded value is stored with the Clerk account until the account is deleted.

The privacy banner offers equally available Accept and Reject choices. The choice is kept in one first-party local-storage record for up to 12 months so the site can remember it. Before a choice, or after Reject, the acquisition source is not stored in the browser; it can travel only in the sign-up URL and Clerk sign-up parameters for that click. After Accept, the bounded source and allowlisted reference may be stored in a separate first-party record for no more than one day so they survive the sign-up and required-firm steps. That temporary record is cleared after sign-in or at expiry. Use the Privacy choices link in the footer to change the choice.

Cookieless page measurement and bounded CTA receipts do not depend on this choice. Vercel Web Analytics, when enabled in project settings, provides aggregate page-view and referrer reporting without cookies; query strings and fragments are removed before page-view delivery. CTA receipts remain separate from account source metadata and are not joined to an account.

Authenticated usage can include a pseudonymous account identifier and the organization identifier supplied by a verified OAuth grant. These identifiers can link observations to the same account or firm; this data is not anonymous. The usage record does not contain your raw account identifier, email address, prompt, conversation, tool inputs, project files, generated outputs or access tokens. Operational signup emails and their separate receipts are described below.

An organization identifier describes the verified grant context for that observation. Earlier events without that context remain unattributed; Arch Studio does not reconstruct their firm from browser state or later membership. Missing attribution does not change the requirement for organization membership in the B2B product.

Scheduled cleanup removes raw usage events, including the pseudonymous account-created event, and provider delivery receipts older than 30 days; account activity milestones inactive for 90 days; and aggregate report snapshots older than 397 days. The first bounded acquisition source and optional reference are also kept in a separate account-linked Cloudflare D1 record after the raw event is removed so aggregate account-source reporting remains possible. That record and the bounded source held with the Clerk account remain until the account is deleted. These are separate retention classes for usage collection, not a universal policy for other website account records, signup-notification receipts or your assistant provider.

The usage service verifies signed account-deletion notices from Clerk and removes retained account-linked usage and activity milestones across the account’s recorded firms and retained pseudonymous identity versions. Clerk account deletion also removes the account’s acquisition-source metadata. This deletion path remains available when new collection is disabled. A deletion marker remains for 30 days to suppress delayed events.

Already produced aggregate reports follow their separate retention schedule. Deleting live usage records does not immediately erase recovery history: Cloudflare D1 Time Travel can retain earlier database states for up to 30 days. Deletion also does not remove records held independently by your assistant or other services. Contact f@alpacalabs.co for an account-data review or removal request.

Collection is best effort. A missing event means coverage is unknown, not that no activity occurred. Delivery of instructions or resource pages does not prove that an architectural task was completed. Coverage starts only when collection is activated; previous activity cannot be presented as captured firm history.

This backend foundation does not provide shared firm or project records, firm-management screens, invitations or a customer usage report. Those capabilities require later product work. Browser sign-in, host authorization and access to your project files remain separate.

Product updates are included by default for new Arch Studio accounts and can be unsubscribed from in any update or in Email preferences. Ordinary product and editorial email uses the Product updates preference. Separately approved service notices may be sent to account contacts only for sign-in codes, security, a breaking MCP change, an outage, or terms, and do not change that preference. For people without an account, the public Product updates form remains optional and separate: Resend processes the submitted email address to send a confirmation link, and enrollment begins only after confirmation. Resend stores the Product updates preference and confirmation record. Each update provides an unsubscribe link. This preference does not subscribe you to other product topics.

When configured, Cloudflare Email sends operational signup notices to the Architecture Studio operator. Those notices may include your email address and signup time. When account signup notifications are enabled, Neon also stores account-linked hashes, delivery status, attempt times and a provider reference when available to prevent duplicate notices. These receipts contain no email body or credentials. They have no automatic expiry, including after provider acceptance; contact f@alpacalabs.co for review or removal requests. Removal must also address replayed signup events so duplicate notices are not reintroduced. Newsletter owner notices use a separate best-effort path without these receipts. Subscription records remain with the email provider until removed; contact f@alpacalabs.co for subscription questions or removal requests.

• Resend privacy policy

Website hosting and identity services process request and account information needed to operate their services. The website includes an optional, environment-gated event producer for bounded usage intent; its presence in the code does not establish that collection is enabled in a particular deployment. Public GitHub feedback is visible to others, so keep client information and credentials out of reports. This page does not claim a universal retention period, zero logging, or a no-training guarantee for every service involved.

• Clerk privacy policy
• Vercel privacy policy
• Contact channels