ZAIXOS Engineering Platform — Product Positioning
Document type: Product Definition
Version: 1.0 · Phase: 12-2
Status: Permanent product authority
Nature: Architectural positioning — not marketing copy
Positioning Statement
ZEP is an engineering governance and runtime abstraction platform for AI-assisted product development.
It occupies the layer above application frameworks and below product domain architecture, providing methodology, contracts, adapters, and validation — not business features or infrastructure provisioning.
Category Definition
| Layer | Examples | ZEP relationship |
|---|---|---|
| Application framework | Laravel, Symfony | Product chooses framework; ZEP does not replace it |
| Engineering platform | ZEP | This product |
| IDE / AI runtime | Cursor, Claude Code, Copilot Workspace | Native session; ZEP supplies adapter |
| Product domain | Dental Clinic ROS modules | Product-owned; consumes ZEP |
| Company governance | Company Constitution, compliance | Parallel authority; ZEP implements engineering slice |
Comparison Matrix (Architectural — Not Competitive Marketing)
Laravel Framework
| Dimension | Laravel | ZEP |
|---|---|---|
| Primary concern | HTTP, ORM, queues, application structure | Engineering phases, AI runtime contracts, adapter materialization |
| Artifact | Composer packages (laravel/framework) | Platform package + contracts + adapters |
| Consumer | Application developers | Product teams + platform/architect roles |
| Similarity | Composer distribution for PHP products | ZEP may distribute via Composer for PHP products |
| Difference | Runs application code | Governs how code is specified and AI-assisted before/during implementation |
| Overlap | None at runtime execution of business logic | ZEP validates product repo structure; Laravel validates app boot |
Position: Complementary. A Laravel product uses Laravel for application runtime and ZEP for engineering governance.
Symfony
| Dimension | Symfony | ZEP |
|---|---|---|
| Primary concern | Components, bundles, enterprise PHP patterns | Cross-IDE engineering methodology |
| Modularity | Reusable PHP components | Runtime Components as abstract contract obligations |
| Similarity | Strict boundaries, semver components | Strict ownership domains, semver on Public API |
| Difference | Application-level component library | Meta-engineering layer; not invoked by HTTP requests |
Position: Analogous discipline (boundaries, versioning), different domain (engineering process vs application code).
Cursor Rules (.cursor/rules, project rules)
| Dimension | Cursor Rules | ZEP |
|---|---|---|
| Scope | Single IDE, single repo, often ad hoc | Multi-product, multi-adapter, versioned authority |
| Governance | Developer-maintained text files | Platform-owned constitution, ADRs, contracts |
| Portability | Cursor-specific | .zaixos/ canonical; .cursor/ materialized |
| Similarity | Constraints and guidance for AI agents | Runtime Constraints component |
| Difference | No contract schemas, no cross-product lock file, no certification | Full validation suite + semver + extension model |
Position: Cursor Rules are adapter input class, not a platform. ZEP ** produces** certified adapter materialization, not a bag of rules.
GitHub Templates (repository templates)
| Dimension | GitHub Templates | ZEP |
|---|---|---|
| Mechanism | One-time repo scaffold | Ongoing versioned dependency |
| Updates | Manual merge or re-template | Platform upgrade path with lock file |
| Similarity | Bootstrap new projects | Future candidate: template as secondary bootstrap aid |
| Difference | Static snapshot | Living platform with contracts, validation, migration policy |
Position: Templates solve day-zero scaffold; ZEP solves day-two-through-year-ten governance. Not interchangeable.
GitHub Copilot Workspace
| Dimension | Copilot Workspace | ZEP |
|---|---|---|
| Primary concern | AI plan + edit + PR flow in GitHub ecosystem | Phase-gated engineering with architect acceptance |
| Authority | Session/plan oriented | Documentation-first permanent specs |
| Similarity | AI-assisted multi-step work | Runtime Workflows (abstract) |
| Difference | No product-independent contract layer; vendor-bound | Adapter architecture; pin platform version per product |
Position: Copilot Workspace is vendor AI workflow; ZEP is org/product engineering substrate that can outlive any single vendor feature.
Claude Code
| Dimension | Claude Code | ZEP |
|---|---|---|
| Primary concern | CLI/agent coding in Anthropic ecosystem | Platform-agnostic contract obligations |
| Similarity | Agent execution, skills-like procedures | Runtime Procedures, Delegation |
| Difference | No ZAIXOS phase model, no architecture test gate, no .zaixos/ lock semantics | Full EOS-derived phase discipline |
Position: Future Claude Code Adapter is a plausible adapter target; ZEP defines what such an adapter must implement, not the reverse.
Internal Engineering Platforms (Backstage, custom dev portals, golden paths)
| Dimension | Typical internal platform | ZEP |
|---|---|---|
| Scope | Often service catalog, CI templates, docs hub | AI-assisted phase governance + runtime contracts |
| Audience | Enterprise platform teams | ZAIXOS products + small teams needing same rigor |
| Similarity | Golden path, standardized onboarding | Adoption model with validation gates |
| Difference | Usually infra/service oriented; rarely IDE contract schemas | Explicit Runtime Contract JSON + adapter certification |
| Overlap risk | CI/CD ownership | ZEP invokes product CI for validation; does not replace CI platform |
Position: ZEP is a specialized engineering governance platform for AI-native development, not a general developer portal.
Architectural Positioning Diagram
┌─────────────────────────────────────────────────────────┐
│ Company / Product Architecture (constitution, modules) │
├─────────────────────────────────────────────────────────┤
│ ZAIXOS Engineering Platform (ZEP) ◄── THIS PRODUCT │
│ Methodology · Contracts · Adapters · Validation · Docs │
├─────────────────────────────────────────────────────────┤
│ Application Framework (Laravel, etc.) │
├─────────────────────────────────────────────────────────┤
│ Infrastructure (PostgreSQL, queues, hosting) │
└─────────────────────────────────────────────────────────┘
▲ ▲
│ │
Product owns Adapter maps to
domain + app IDE (Cursor, future…)What ZEP Is Not (Positioning Boundaries)
- Not a low-code or SaaS generator in v1 (future candidate only)
- Not a replacement for PHPUnit, Pint, or product architecture tests — it adds platform integrity tests
- Not an IDE extension marketplace in v1
- Not open-core DevOps — scope is engineering methodology + AI runtime abstraction
Target Position in ZAIXOS Portfolio
| Product type | Uses ZEP? |
|---|---|
| ZAIXOS revenue products (Dental Clinic, future verticals) | Required — pinned platform |
| Experimental spikes | Optional — may defer until productization |
| Non-ZAIXOS adopters (future) | Optional — if license/distribution opens |
Product Positioning v1.0 — Phase 12-2.