FAQ

A catalogue of ~513 engineering patterns pre-loaded into your tenant when you sign up: solved bugs, root-cause lessons, conventions, runbooks. Your agent searches it before coding (POST /api/v1/search) and contributes new patterns back (POST /api/v1/contribute) as it learns. Over time your brain diverges from the seed — your own incidents and fixes accumulate inside your tenant, never anyone else's.

The 513 patterns are derived from the GNETICS master brain — a real production knowledge base, curated and depersonalised before export. Internal TKT-tags, repository paths, environment names and any secret-shaped strings are stripped. Entries are translated to English so the seed reads as a generic engineering corpus, not as GNETICS-internal context.

No. Isolation is enforced at the database layer: every row carries a tenant_id, and every query — agent search, contribute, owner dashboard — is scoped by req.tenant.id derived from your API key. The cross-tenant isolation suite (8 checks, including a marker test where tenant A writes a unique string and tenant B searches for it and must get zero hits) runs green on every change. If that test ever fails, the build doesn't ship.

Straight answer: yes, in principle. As the operator we hold the database, so a least-privilege audit/moderation path technically exists — used only for abuse investigation, billing disputes, or a court order. It is traced (every read leaves an audit row) and never used to satisfy curiosity or to read tenants in bulk. This is what our doctrine calls "least-privilege + traced," and we'd rather say it plainly than promise something a hosted service cannot truthfully promise. If you need stronger guarantees (self-hosted, end-to-end encrypted contributions), reach out — that path is on the roadmap, not in this product yet.

Rotate the key. Coming with account management (TKT-321): a one-click rotation in your owner dashboard invalidates the previous agent key immediately — any subsequent call with the old key returns 401. Your tenant data and contribution history are untouched; only the credential rotates. Until that ships, contact us and we rotate it for you the same day.

Account management (TKT-321) exposes DELETE /api/v1/owner/account, which removes your tenant row and every pattern attached to it — seeded entries, agent contributions, audit trail. The deletion is irreversible by design. Export is via the owner dashboard's brain view (read-only, JSON) and the agent search API. No automatic retention, no shadow copy — once you delete, it's gone from the live database within the same transaction.

The full FTS-backed search is reserved for the agent key. The owner dashboard is a human surface — read-only, designed for browsing recent activity, not for piping results back into prompts. This separation (human role vs agent role) is intentional: it prevents an owner-token leak from exposing the same search capability an attacker would need to mine the brain. A dedicated owner search route (/owner/patterns, TKT-318) is on the roadmap with explicit pagination and rate limits — different surface, different threat model.

Not automatically. Contributions stay in your tenant by default. Promotion to the shared master brain is a manual editorial step: the GNETICS owner reviews candidate patterns, the contributing tenant must opt in, and any provenance kept on the master row is an opaque source_tenant_id — never an email, project name, or any identifier readable by other tenants. If you never opt in, nothing of yours ever leaves your tenant.

Yes — treat it like a database password. The agent key (brn_…) authorises both search and contribute on your tenant, so a leak means an attacker can poison your brain with bad patterns or exfiltrate the contributions you've made. Store it in your AI tool's credential manager (Claude Code .env, Cursor secret store, etc.), never in repo files. Owner tokens (own_…) are separate — read-only on the dashboard, no write access — but you should keep both off public surfaces. If either leaks, rotate (see the key-leak question above).