Product Status
Current AutoCore release status, verified boundaries, external configuration requirements, and known limitations.
AutoCore is documented here as version 1.0.0-rc.1 with status Release Candidate. The release-candidate label means the technical release boundary has been exercised and reviewed, while the product still requires installation-specific configuration and final commercial decisions before a stable release claim is appropriate.
How to read status language
“Verified” means the claim is supported by current source, tests, executable behavior, or recorded evidence. “External configuration” means the product has a boundary for the setting but the operator must supply or approve it. “Known limitation” is an intentional current boundary, not a hidden promise.
Current release identity
| Field | Current value |
|---|---|
| Documentation version | 1.0.0-rc.1 |
| Product status | Release Candidate |
Stable 1.0.0 | Not claimed |
| Architecture | Web, Admin, API, Worker plus PostgreSQL, Redis, Meilisearch, and reverse proxy |
| Deployment model | Controlled commercial installer and immutable application artifacts, delivered through an authorized channel |
| Primary market model | One primary market per installation in Commercial 1.0 |
| Default edition behavior | No implicit edition; edition identity is explicit and fail-fast |
The repository also contains a shared-source release line with its own package version and historical release tags. That shared source metadata must not be read as a stable AutoCore commercial release. AutoCore documentation uses the AutoCore RC identity above until a later release decision creates a separately verified stable documentation version.
Technical verification represented by the source record
The current source and recorded release evidence cover the following areas:
- Clean installation and installation idempotency rehearsals.
- Upgrade, rollback, interrupted-operation recovery, backup verification, and installer locking scenarios.
- Edition-aware builds and isolation checks for AutoCore and EskişehirAraba.
- Health/status behavior, API contracts, database schema, and background-worker behavior.
- Security and bundle checks recorded in the release evidence.
- Anonymous behavior of the AutoCore demo surfaces where that behavior is safe to verify.
These checks do not automatically establish a customer's production readiness, legal approval, provider activation, SLA, or compliance certification.
External configuration boundaries
Before an installation is treated as operational, an authorized operator must supply and verify:
- Domains, DNS, TLS, reverse-proxy routing, and any external ingress policy.
- PostgreSQL, Redis, Meilisearch, media storage, email, SMS, and monitoring dependencies.
- Secret ownership, rotation, backup storage, restore access, and incident contacts.
- The installation's legal entity and policy content for the applicable jurisdiction.
- Payment-provider mode, credentials, webhooks, reconciliation, and business approval if payments are enabled.
Payment and legal readiness
Payment-provider integration points and legal-policy data structures do not mean live payments or pre-approved policies are enabled by default. Treat both as explicit release gates.
Known limitations
- Commercial 1.0 associates one primary market with an installation; simultaneous multi-market or multi-currency operation is not documented as available.
- Austin is a demo/default market preset, not a hardcoded product restriction. Berlin is a validation example for non-US configuration.
- Stable
1.0.0status is pending a later release decision. - Payment activation, legal content approval, and production operations require external configuration and business ownership.
- Future categories, AI capabilities, native mobile applications, and additional integrations remain future or separately gated scope unless a later page marks them verified.
Status maintenance rule
Every AutoCore page carries a version in front matter and is reviewed against the source hierarchy when the release boundary changes. The documentation navigation exposes only published pages; planned pages remain in the internal coverage matrix until they are source-verified and safe to publish.