Positioning guide
[TODO i18n — see issue #76] Canonical positioning for AACSearch OS. Use this page to keep blog posts, comparison pages, marketing copy and case studies aligned with the Search Operating System framing.
AACSearch is a Search Operating System for product-grade discovery — not search-as-a-service, not a hosted search service, not a generic search API, and not "the Algolia alternative". This page is the source of truth for that positioning. Everything else in marketing, blog, comparison pages and case studies should resolve to it.
Canonical line
AACSearch OS — Search Operating System for product-grade discovery.
Use this exact phrase (or a close localization) at the top of comparison pages, case studies and Hero blocks where a tagline is needed. When in doubt, prefer this phrasing over inventing a new one per page.
What this means in copy
- Subject of every sentence is the product domain, not the delivery model. "AACSearch indexes, ranks and answers across product data" — not "AACSearch is a hosted search service that…".
- Workloads, not features. Lead with what readers ship: product discovery, AI answers, multi-tenant storefronts, knowledge bases. The feature catalog (synonyms, curations, scoped tokens) is supporting detail.
- Self-hosted reality is constrained. Cloud SaaS is the live deployment
surface. Self-hosted is
Roadmap (v1.0)per Claim status. Comparison pages that pivot on "self-hosted" should link to the roadmap row, not pretend it ships. - Avoid competitor framing. "Algolia alternative" / "ElasticSearch alternative" is reactive positioning. Comparison pages are fine, but they should be neutral fact tables, not "why X is bad" essays.
Banned phrasings in new copy
| Don't write | Write instead |
|---|---|
| "Search-as-a-service" | "Search Operating System" |
| "Hosted search service" | "AACSearch cloud" (when delivery model matters) |
| "Algolia alternative" | "AACSearch vs Algolia" with neutral fact tables |
| "Generic search API" | "Search Operating System with first-class APIs" |
| "Powered by Typesense" | "Built on a Typesense storage layer" — only when truly relevant |
Existing posts that violate these rules ship with legacy: true in their
frontmatter and surface the banner pointing here. New posts MUST NOT carry
that flag.
Canonical CTAs per surface
Every public surface should send the reader to exactly one of these follow-up paths. Pick the one closest to the reader's intent:
- Buyer / decision-maker →
/contact(talk to sales) or/pricing(review plans). - Engineer evaluating →
/docs/getting-started(Quickstart) or/docs/search-api(Search API tour). - Existing customer scaling →
/dashboard(in-app entry) or/docs/operations(production hardening). - Reader curious about a single concept → the matching
/docs/overview/*or/docs/reference/*page.
If a blog post does not end with one of these CTAs, the reader has nowhere to convert. Adding "Read the docs →" with a specific doc URL is the minimum bar.
Comparison page rules
- Lead with the buyer's job, not the competitor's name.
- Use a neutral fact table — feature × product × yes/no/partial.
- Cite the comparison source (vendor doc URL, dated). Stale citations get flagged in Docs quality gates.
- End with the canonical CTA, not a "switch from X" coupon.
When in doubt
If you are unsure whether a piece of copy aligns with this guide, do not
publish it. File an issue against marketing tagged positioning and link
the draft.
Claim status
[TODO i18n — see issue #76] Fact-check of the performance, security and enterprise claims that appear in AACSearch docs and marketing. Tracks each public claim against the current implementation.
Locale fallback policy
[TODO i18n — see issue #76] How AACSearch docs handle missing translations across en, de, es, fr and ru. Defines the EN floor, RU parity rule, and how stub pages are marked.