Edition Concept
Understand AutoCore editions, shared platform behavior, explicit identity, and safe branding boundaries.
An edition is a governed configuration and branding profile materialized from the shared AutoCore platform. It lets the same product architecture produce a branded deployment without forking the business runtime into unrelated applications.
Shared and edition-specific behavior
The shared platform owns the application boundaries, API contracts, database model, authorization rules, worker patterns, and reusable marketplace behavior. An edition may provide its own brand identity, locale pack, market defaults, supported capabilities, route labels, assets, and deployment namespaces where the source explicitly supports those dimensions.
| Shared by the platform | May vary by edition |
|---|---|
| Web, Admin, API, and Worker boundaries | Brand name, logo, visual assets, and copy |
| API-first business logic | Default locale and bundled locale packs |
| Relational schema and validation contracts | Market profile and default units |
| RBAC and security controls | Feature/capability flags |
| Queue, search, and media integration patterns | Deployment namespace and public route presentation |
Explicit identity
AUTOCORE_EDITION is required. An unset, blank, or unknown value must fail rather than selecting a default edition. This prevents an installation from accidentally starting with another edition's branding, locale, market defaults, ports, or storage namespace.
The public edition key is safe to expose as identity. Server-only provider credentials, internal registry data, and secret configuration are not part of the public edition configuration.
Materialized artifacts
The release workflow can materialize edition-specific targets from canonical source before building distributable images. Materialization is a release/build concern; it does not mean the public Web or Admin clients own separate business logic.
AutoCore international identity
The current AutoCore edition resolves explicitly as autocore. Its distributable
defaults to English, uses a neutral configurable market profile, and exposes the
AutoCore brand. These defaults are not proof that the product is hardcoded to the
United States, USD, miles, or a single city. The edition can be validated against
another market when the required locale, currency, timezone, unit, and
operational settings are supplied.
Edition-owned capabilities
Edition configuration can make a capability visible or unavailable, but a database enum or a future-facing interface is not by itself an active feature. The current AutoCore edition keeps dealer tooling, financial flows, and locale switching outside its enabled feature set while retaining explicit configuration seams for later reviewed activation.
Isolation expectations
Edition isolation requires more than a logo. Operators must keep data stores, volumes, caches, search indexes, queue names, secret references, service names, ports, and public routing aligned to the selected edition. Cross-edition data or storage reuse is not an acceptable shortcut.
Do not treat editions as simultaneous markets
Editions and primary markets are different concepts. An edition can provide a branded configuration, while an installation still has one primary market in Commercial 1.0.
What an edition may not customize implicitly
An edition must not silently change API contracts, authorization semantics, database meaning, security controls, or installation identity rules. If a future edition needs a new capability, it should be modeled as an explicit, tested configuration or a separately reviewed product change.