This policy explains what personal data AI Design Blueprint processes across public discovery pages, member activation, validation runs, waitlist and pilot intake, and admin operations, why that processing happens, and which controls are available to you.
Last updated: October 10, 2026
Depending on how you use the platform, we may process account identifiers, sign-in provider data, profile information, communication preferences, activation answers, recommended route summaries, learning progress, validation runs, waitlist entries, pilot applications, beta access invite records, MCP OAuth access tokens, and operational security logs.
We use this information to authenticate members, create and maintain workspaces, preserve course access, track progress, support validation and pilot workflows, generate activation recommendations, assess lead and platform health, operate waitlists and pilot intake, and improve reliability, support, and product quality.
Activation answers, selected tools, artefact state, route recommendations, learning activity, waitlist status, pilot status, and related operational signals may be combined into internal lead-intelligence summaries for admin review and weekly operational reporting. These summaries are used to prioritize support, understand product demand, and identify friction in the platform. They are not sold to third parties. To draft the weekly report, a pseudonymised extract of these signals, including feedback text you wrote, is sent to OpenAI (US): account emails are replaced by aliases, the display names we hold are removed or replaced by the same alias, internal ids are removed, other email addresses are stripped, and the request is not kept in OpenAI's response store, though its abuse-monitoring retention still applies.
Necessary cookies are used to run the service and maintain basic functionality. Optional consent controls currently cover analytics storage and research contact preferences. You can grant or withdraw those optional consents through the cookie banner and, when signed in, from the Privacy & data management section inside the app.
Authentication currently relies on Firebase Authentication, including Google sign-in when selected by the user. Analytics measurement relies on Google Analytics 4 (GA4), which is loaded only when you grant analytics consent via the cookie banner; GA4 operates under Google's data-processing terms and consent mode v2. Email delivery and preference synchronization may rely on Resend. Platform and infrastructure providers may process operational data needed to host, secure, and monitor the service. AI and model providers may process prompts and outputs needed to run localized content, activation routing, evaluation, or reporting workflows. Within your plan's included allowance, AIDB Studio conversations go to OpenAI (US), and OpenAI keeps each response in its response store under its API data-retention terms. On the Basic plan, and on any plan once its included allowance is used, AIDB Studio answers with free models reached through OpenRouter (US): each request goes to OpenRouter and to the model provider it selects, whose location varies, and we ask OpenRouter to use only providers it lists as not collecting user data. A request carries the conversation, any files or images you attach, your display name and the results of tools AIDB Studio ran for you. If you choose to run AIDB Studio on your own OpenAI or OpenRouter key, those requests go to that service under your own account and its settings. When a long AIDB Studio conversation is folded to save space, on any plan, the folded turns go to OpenAI (US) to write a summary; that request is not kept in OpenAI's response store, though OpenAI's abuse-monitoring retention applies. Web search in AIDB Studio, when you turn it on, runs inside OpenAI's model call when your chat runs directly on OpenAI (the included model within its allowance, or your own OpenAI key); on any other route, including an OpenAI model reached through another provider, the search queries AIDB Studio writes from your request go to Tavily, a web search provider. Deep research sends your topic to OpenAI (US) to plan sub-questions and to read and summarise the sources, and sends the sub-questions to Tavily.
We keep personal data only for as long as it is needed for the service, security, legal obligations, or legitimate operational continuity. If you request account erasure, the live account and linked in-product records are removed, and a time-boxed backup snapshot may be retained for the number of days you selected in the Privacy & data management section before it is purged. The operational security and cost logs described below are an exception: erasure unlinks them from your account immediately rather than deleting them outright, though every row still ages out on the tiered schedule described there regardless of erasure.
When signed in, you can use the Privacy & data management section to review optional consents, inspect a data inventory, generate a portable export of account-linked data, and request account deletion. You can also update communication preferences and stop using a sign-in method at any time, subject to any account-recovery constraints.
Static instruction files (AGENTS.md, .mdc rules, copilot-instructions.md) are local files only, they send nothing. Retrieval MCP tools (principles.list, examples.search, etc.) fetch doctrine and examples from our servers. signals.feedback is open to all callers but must only be called when the user explicitly requests it; only the fields you pass are stored (ratings, opt-in text, contact email with permission). signals.report requires a signed-in Pro, Pro Plus, Teams, Enterprise, beta, or trial plan and is linked to your authenticated user ID and plan tier, the event fields you pass are stored as written (the event type, which is required, and optionally the surface, a rating, workflow stage, whether you'd recommend it, team size, and a free-text brief_context note, which may appear, pseudonymised, in our weekly lead-intelligence extract to OpenAI), with your plan and calling client. Neither signal tool reads your prompts, code, files, or repository, so do not include sensitive content in the brief_context field. contact_email is stored only when you explicitly set permission_to_follow_up to true. In that case signals.feedback also opens a support ticket and sends its free-text fields to OpenAI (US) for triage; the email itself is never sent. The support and partnership forms send your message text to OpenAI (US) for the same triage; name and email are not sent. The pilot form sends OpenAI (US) role, workflow stage, and review description; the agency form sends company, role, workflow stage, workflow description, support type, and main challenge. Name, email, and, agency-only, the material link and notes are never sent; the request isn't kept in OpenAI's response store, though its abuse-monitoring retention still applies. When architect.validate, design.validate, spec.validate or architect.certify processes what you provide (code, a description of a UI surface, or a written specification), that content, along with the repository URL and the file paths you select for repository scans, is sent to an external LLM provider (OpenAI, on a no-training-on-API-data contract and subject to OpenAI's API data-retention terms) during processing. It is persisted in OpenAI's response store unless you set private_session=true on architect.validate, design.validate or spec.validate; architect.certify always keeps a stored run. When a standard run scores production_ready we keep the submitted code for 24 hours so architect.certify can verify it, after that it can no longer be used and an automatic clean-up deletes it; private sessions keep no code. We do NOT use your proprietary code, validation scores, or architectural diagrams to train, fine-tune, or improve foundational AI models. Apart from that 24-hour hold, only the structured result is stored: per-principle verdicts, severity scores, recommendations, certification outcome, reproducibility envelope (model, seed, doctrine fingerprint, code fingerprint), a review and badge URL, and, for repository scans, a repository identifier and commit reference (kept for baseline lineage and reproducibility, not readable by internal analytics). By default these URLs are private and return nothing publicly; a run becomes publicly viewable only when you explicitly publish it from your dashboard. Publishing a run makes its score, grade, and structured findings public; it does not publish your repository identifier, the repository URL, or the file paths. The 16-character SHA-256 code_fingerprint we persist is a binding primitive between architect.validate and architect.certify (so cert cannot be minted against different code than was reviewed) and is not reversible to the original code. Set private_session=true on architect.validate, design.validate, or spec.validate to skip the stored run for that specific call (no run_id, no result_json, no badge, and consequently no architect.certify path for that run). A private session is also not persisted in OpenAI's response store, while a standard run is; OpenAI's abuse-monitoring retention applies to both. On non-private calls, the validation run record (score, verdicts, recommendations, reproducibility envelope) is additionally stored in your private workspace history and you may delete it at any time from the dashboard. This design supports the Blueprint's commitment: agents run the workflow, humans govern it. Your code stays your own unless you explicitly choose to share it. MCP OAuth 2.1 authentication (used by clients such as Claude Code) creates a short-lived authorization code and a long-lived opaque access token record linked to your user ID; these records are used only to authenticate subsequent MCP calls and can be revoked by deleting your account. You can request deletion of all MCP token records tied to your account via the data deletion process described above. Feedback you submitted through signals.feedback is unlinked from your account rather than deleted; if you attached a contact email to it, ask us and we will remove that too.
These logs are written on every call, including private sessions. They record who ran what and when, the calling client, the client software and version it declares, which install package it came from (a fixed identifier in the plugin manifest, never anything about you), and, on MCP calls, a keyed one-way digest of the network address the request arrived from (a pseudonym, not the address itself). They also record the lookup text or target (a search query, a principle, cluster, or example name, or, for a validator run, the repository and any error text) and whether the call succeeded and how long it took, but never the raw user-agent string itself: only the calling client and the client software and version it declares, both listed above. A plugin install's connection handshake is recorded once as its own row, even if no tool is called afterwards. For validation calls they also keep a request summary: the task description or focus area you passed, the repository identifier, up to three of the file paths you selected, the code language you declared, and the run's outcome. That summary holds up to 4,000 characters on some tools and 500 on others, so a long task description may be kept in full. Your code, artefact, or spec itself is never written to these logs. We use them for abuse prevention, platform availability, and incident investigation, and in aggregate for the internal operational reporting described under Activation and lead intelligence above. We may also use the search text sent to the public MCP search tools (principles.search, examples.search, guides.search) to choose topics for the guides we publish, under our legitimate interest in improving the published doctrine. A term counts only once at least three distinct callers have searched it in the window a schedule reads; a caller is an account, or a network-address digest for anonymous calls, so one person on several networks can count more than once. A shortlisted term then goes to OpenAI (US) to be mapped to a principle. A chosen term becomes the topic of a guide: Tavily receives it as the research query under its own terms (OpenAI web search does when Tavily fails or finds nothing), and OpenAI (US) drafts the guide and its cover image. The text requests to OpenAI are not kept in its response store; OpenAI's abuse-monitoring retention applies. The schedule run's copy of a search-sourced term is blanked 90 days after the run, like the lookup text itself; the guide drafted from it and the generation record behind it are our own content and are kept. Content like the lookup text and validation request summary is blanked after 90 days, the fields that identify you (user ID, email, Firebase account ID, conversation turn ID, and the network-address digest) are removed after 12 months, and the now-anonymous row itself is deleted after 24 months, under our legitimate interest in operating and securing the service. Account erasure unlinks these log rows from your account rather than deleting them: they stay without your user ID or email address, and are then used for security, availability, and the aggregate reporting above, none of which identifies you. The Privacy & data management section shows how many exist against your account, and your data export includes the most recent 500 rows of each log, stating the true total and whether it had to stop there. We leave the address digest out of that export. The same network address always produces the same digest, so returning it would let you recognise other people's rows that share your address, not only your own.
If you are a beta tester, you can invite a colleague (a "counterpart") you have named to join the beta. We use that person’s email address only to generate a personal invite link, which you send to them yourself; we do not email them. We rely on our legitimate interest in facilitating the referral you asked for. We keep an un-actioned counterpart’s email for 28 days (the beta window) and then delete it, along with the pending invite and any pre-provisioned sign-in identity. The counterpart can opt out in one click at any time and can ask us to erase their data.
We use managed authentication, server-side session controls, admin access restrictions, internal service keys, and secret management to reduce exposure of personal data. We also retain limited operational logs to detect abuse, protect platform availability, and investigate incidents. Requests to resend an activation link or to reset a password are rate-limited through a ledger that stores the email address, a keyed one-way digest of the network address, and the time of the request. It serves only those limits: each row is deleted after 2 days, and account erasure deletes your rows at once. No system is perfect, so safeguards evolve with the platform.
