ZAIXOS Engineering Platform — Product Vision
Document type: Product Definition
Version: 1.0 · Phase: 12-2
Status: Permanent product authority — complements PLATFORM_CONSTITUTION.md
Authority: Platform Architect · Does not modify Runtime Contracts or adapter semantics
What is ZAIXOS Engineering Platform?
ZAIXOS Engineering Platform (ZEP) is a product-independent engineering foundation that packages how ZAIXOS (and adopting teams) build software with AI assistance: methodology, runtime abstraction, certified adapters, validation, templates, and developer knowledge.
ZEP is not an application framework, not a domain product, and not an IDE. It is the governed engineering layer that sits between company/product architecture and the native AI development environment.
Products consume ZEP. They own domain logic, modules, and product architecture. ZEP owns how engineering work is structured, validated, and executed across IDEs and repositories.
Product Vision
One stable engineering foundation powers every product — without coupling products to each other or to a single IDE.
Developers onboard to a known platform version. Architects enforce discipline through documentation authority and runtime contracts. Adapters translate platform semantics into native IDE behavior. Products pin platform versions instead of forking governance.
Mission
Make AI-assisted engineering deterministic, portable, and governable across products and IDEs.
ZEP exists to:
- Separate how we engineer from what we build
- Enforce documentation authority before runtime behavior
- Package runtime abstraction so products pin versions instead of copy-paste governance
- Enable multi-product scale without multi-product governance drift
(Aligned with PLATFORM_CONSTITUTION.md — product-level articulation, not a replacement.)
Long-Term Vision (5–10 Years)
| Horizon | Target state |
|---|---|
| Years 1–2 | ZEP v1 GA as Composer-distributed platform; Cursor Adapter v1 certified; Dental Clinic and second product on pinned platform |
| Years 2–4 | Multiple certified adapters; platform CLI and SDK as Public surfaces; extension registry in production use |
| Years 4–7 | Team-scale platform: shared validation, org extensions, adapter marketplace criteria |
| Years 7–10 | Enterprise-grade platform operations: audit trails for engineering governance, multi-tenant platform policy, optional hosted validation — without becoming a SaaS application host |
The 10-year end state is the default engineering substrate for ZAIXOS products and licensed adopters, not a replacement for Laravel, Symfony, or cloud infrastructure.
Core Philosophy
- Documentation First — Specifications and ADRs precede runtime materialization. Runtime implements authority; it does not invent it. (ADR-002)
- Platform vs Product Separation — Platform owns engineering methodology and runtime abstraction; products own domain and application architecture. (ADR-005)
- Contracts Over Conventions — Runtime behavior is obligated by versioned contracts, not tribal knowledge.
- Adapters Over Forks — IDE-specific files are adapter outputs; platform semantics stay adapter-agnostic.
- Pin, Don't Fork — Products declare platform version via lock file; they do not maintain authoritative ERP copies.
- Validate Before Release — Engineering acceptance is measurable, not subjective.
Product Identity
| Attribute | Definition |
|---|---|
| Name | ZAIXOS Engineering Platform (ZEP) |
| Category | Engineering platform / AI development governance layer |
| Primary artifact | Versioned platform package + contracts + certified adapters |
| Namespace (canonical) | .zaixos/ |
| Relationship to ERP | ERP v1.0 semantics are the historical baseline embedded in platform 1.x; ERP as a name retires in favor of Platform Runtime + Contracts |
| Relationship to EOS | EOS methodology becomes Platform Core methodology — same discipline, product-independent packaging |
| Not | Laravel package for business logic, Cursor configuration dump, or monorepo of all products |
Engineering Philosophy
- Deterministic phases — Work proceeds in documented phases with explicit acceptance criteria.
- Single ownership — Every asset has exactly one owner per PLATFORM_BOUNDARIES.md.
- Stable public surface — Only Public-classified APIs receive semver guarantees (PLATFORM_PUBLIC_API.md).
- Extension without core mutation — Customization via extension registry, never by editing platform core in product repos.
- Fail closed on validation — Architecture and runtime integrity tests block release when contracts are violated.
- Minimal product coupling — Products integrate via lock file, manifest, and validation invocation — not by importing platform internals.
AI Philosophy
- AI is a runtime, not an architect — AI agents execute within constraints, procedures, and workflows defined by platform authority; they do not redefine architecture.
- Human architect acceptance — Phase acceptance (Format A/B reports, Architect review via RESPONSE_TEMPLATE) remains human-gated for architectural decisions.
- Portable agent semantics — Runtime Components (constraints, procedures, workflows, delegation, enforcement, context, execution) are abstract obligations; adapters map them to native IDE constructs.
- No prompt sprawl as governance — Ad-hoc rules and chat instructions do not replace versioned platform documentation.
- Traceability — Engineering phases produce reports; reports link to specifications; specifications link to validation.
- IDE neutrality by design — Cursor Adapter v1 is first certified adapter; platform does not assume Cursor forever.
Summary Answer
What is ZAIXOS Engineering Platform?
ZEP is the versioned, product-independent engineering product that packages ZAIXOS's AI-assisted development methodology, runtime contracts, adapters, validation, and knowledge so that any product repository can adopt the same engineering discipline without embedding or duplicating it.
Product Vision v1.0 — Phase 12-2. See PRODUCT_INDEX.md.