Tag-based plugins can only relate posts that share an explicit tag or category — meaning if your taxonomy is messy or thin, related-post quality is awful. Atlas embeds the full text of every post into a 1,536-dimensional vector and ranks neighbours by cosine similarity. Two posts can be deeply related semantically without sharing a single tag, and Atlas finds them.

On the central Orthoplex server, in a `pgvector` table partitioned by `license_id`. Every query is automatically scoped to your license — there is no path in the API to read another tenant's embeddings. The vectors themselves are derived from public post content, so they're not a sensitive secret, but the tenancy boundary is enforced at the database query level, not just the application layer.

Atlas runs an hourly cron that bulk-embeds 50 posts at a time, so a 1,000-post archive completes overnight and a 10,000-post archive takes about a week. You can run `wp orthoplex atlas backfill` to manually drain a batch immediately, or click "Run backfill now" on the Overview tab. Re-embedding only happens when the post text changes — the server hashes content and skips identical ones.

No. Atlas runs on the managed embedding pool — your credit pool covers it (1 credit per 1k tokens for `text-embedding-3-small`, 3 for `-large`). Provider credentials never live on WordPress.

A `before_delete_post` hook fires a `DELETE /atlas/embed` request to the server, which removes the row. If for any reason that fails (network blip), the next hourly backfill will leave dangling embeddings in place — they don't cause incorrect results because the post-id lookup just won't find them, but you can run `wp orthoplex atlas backfill --reset` to do a clean rescan.

Cosine similarity above 0.85 between two posts is a reliable signal that they're competing for the same intent. Below that, you start picking up "same broad topic" pairs. The threshold is tunable — start at 0.85, drop to 0.80 if you want a wider net, raise to 0.90 if you only want the worst offenders. Pillar / hub-and-spoke architectures intentionally have many high-similarity pairs; the audit lets you ignore those and focus on accidental duplication.

Atlas writes nothing to your existing SEO plugin — it operates one layer above SEO meta. The pillar-brief generator outputs slugs and meta descriptions you can paste into Yoast/Rank Math; the gap analysis is purely informational. We deliberately don't touch your existing meta because every SEO plugin has its own dialect and we won't risk corrupting it.

Yes. Each subsite has its own license activation and its own `license_id`-scoped index, so the index for `marketing.example.com` never bleeds into `support.example.com`. The plan's seat count covers the whole network — Pro gives you 5 sites, Business 10, Agency 30.

The migration tries `CREATE EXTENSION vector` and falls back to a JSONB-stored embedding column with in-application cosine similarity if pgvector isn't available. This is slower (the entire tenant's rows get loaded for every query), but correct — it lets dev and small-archive sites run without managed Postgres extensions. For sites with 5,000+ indexed posts, pgvector is required.

Yes. The `/api/v1/me/export` endpoint returns a JSON dump of every embedding's metadata (doc_kind, doc_ref, title, created_at, updated_at). The raw vectors aren't included by default because they're only useful when paired with the same model — if you need them, contact support.