ZAIXOS Engineering Platform — Target Users
Document type: Product Definition
Version: 1.0 · Phase: 12-2
Status: Permanent product authority
Audience Overview
ZEP serves roles, not org sizes alone. A solo developer may wear all hats; an enterprise team splits them explicitly.
| Persona ID | Persona | Primary relationship to ZEP |
|---|---|---|
| P-1 | Solo developer | Installs, develops, validates |
| P-2 | Freelance / contract developer | Consumes pinned platform on client ZAIXOS products |
| P-3 | Startup product team | Fast bootstrap + discipline without building governance |
| P-4 | Product company engineering team | Multi-developer consistency via platform pin |
| P-5 | Platform team (ZAIXOS internal) | Owns platform core, adapters, releases |
| P-6 | Product architect | Phase authority, acceptance, product architecture |
| P-7 | AI-native team | Heavy agent usage; relies on contracts + adapters |
| P-8 | Enterprise engineering org | Policy alignment, audit, long-term semver (future) |
P-1 — Solo Developer
| Attribute | Definition |
|---|---|
| Goals | Ship product features fast without reinventing AI workflow; pass validation before release |
| Expected usage | Install platform → develop in IDE → run validation → upgrade platform on schedule |
| Required knowledge | Git, PHP/Laravel (for PHP products), basic IDE agent usage, read platform developer guide |
| Responsibilities | Maintain product code; invoke validation; do not edit platform core in product repo |
| Also acts as | Often P-6 (architect) and P-4 (team) in small setups |
P-2 — Freelancer / Contract Developer
| Attribute | Definition |
|---|---|
| Goals | Onboard to client repo in hours; follow client engineering discipline without ambiguity |
| Expected usage | Read lock file version → use materialized adapter workspace → submit phase reports if contracted as implementer |
| Required knowledge | ZEP developer guide, product architecture docs, Format A/B reporting if in architect loop |
| Responsibilities | Stay within product + platform boundaries; escalate platform defects to platform team |
| Should not | Fork ERP into personal template; modify .zaixos/ core files without platform release |
P-3 — Startup Product Team (2–8 engineers)
| Attribute | Definition |
|---|---|
| Goals | Avoid governance debt while scaling; one onboarding path for new hires |
| Expected usage | Pin platform in CI; architect runs phase acceptance; developers use same adapter profile |
| Required knowledge | Split between P-6 (architect) and P-1 (developers) |
| Responsibilities | Product architect owns product ADRs; platform team owns platform upgrades |
| Benefit | No internal "engineering OS" project — adopt ZEP instead |
P-4 — Product Company Engineering Team
| Attribute | Definition |
|---|---|
| Goals | Cross-team consistency; measurable architecture compliance; safe platform upgrades |
| Expected usage | CI runs architecture + platform integrity tests; scheduled platform minor upgrades |
| Required knowledge | Module boundaries (product), platform public API (integrators), semver policy |
| Responsibilities | Product owns app/, product docs, product CI wiring; platform owns contract compliance |
| Interaction | Platform team (P-5) provides release notes and migration guides |
P-5 — Platform Team (ZAIXOS Internal)
| Attribute | Definition |
|---|---|
| Goals | Evolve platform without breaking products; certify adapters; maintain Public API semver |
| Expected usage | Author platform specs, contracts, adapters; publish releases; respond to extension registry |
| Required knowledge | Full platform constitution, boundaries, ADRs, adapter architecture, validation suite |
| Responsibilities | Single owner (D-P) for platform core; adapter maintainers report to Platform Architect |
| Authority | Accept/reject adapter certification; classify API surfaces |
P-6 — Product Architect
| Attribute | Definition |
|---|---|
| Goals | Enforce product architecture; accept phases via RESPONSE_TEMPLATE; prevent boundary violations |
| Expected usage | Issue phase prompts; review Format A/B reports; gate freeze/release decisions |
| Required knowledge | Product constitution, platform phase model, ERP/platform validation checklists |
| Responsibilities | Product architecture decisions; not platform core changes |
| Uses ZEP as | Methodology authority + validation commands + report templates |
P-7 — AI-Native Team
| Attribute | Definition |
|---|---|
| Goals | Maximize agent throughput without losing architectural control |
| Expected usage | Heavy workflow/delegation via adapter; hooks for enforcement; MCP context from platform templates |
| Required knowledge | Runtime Components mapping in adapter profile; contract obligations |
| Responsibilities | Do not bypass enforcement; treat agent output as implementation until architect accepts |
| Risk if wrong fit | Teams wanting only chat prompts without phases will chafe — see PRODUCT_SCOPE.md |
P-8 — Enterprise Engineering Organization (Future Primary)
| Attribute | Definition |
|---|---|
| Goals | Policy alignment, audit evidence, controlled upgrades across many repos |
| Expected usage | Central platform version policy; optional org extensions; enterprise support channel (if offered) |
| Required knowledge | Semver policy, lock file governance, validation KPIs |
| Responsibilities | Org platform council approves major upgrades; products stay on supported versions |
| v1 readiness | Persona supported conceptually; enterprise edition features not required for v1 GA |
Who Should Not Use ZEP
| Anti-persona | Reason |
|---|---|
| Single static website, no AI workflow | Overhead exceeds benefit |
| Team rejecting phase/architect discipline | Product philosophy mismatch |
| Org wanting general DevOps portal only | Wrong category — use Backstage-class tools |
| Non-PHP product with no adapter path (v1) | v1 GA optimized for PHP/Laravel + Cursor; others wait for adapter/platform maturity |
| Maintainers who insist on forking ERP per repo | Violates pin-don't-fork model |
Role × Responsibility Matrix
| Activity | Platform (P-5) | Product Architect (P-6) | Developer (P-1–4, P-7) |
|---|---|---|---|
| Platform core changes | Owns | Consults | Consumes |
| Product module architecture | — | Owns | Implements |
| Adapter certification | Owns | Validates fit | Uses materialized workspace |
| Phase acceptance | Defines process | Decides | Produces reports |
| CI validation invocation | Provides tests | Configures in product CI | Runs locally |
| Platform upgrade | Publishes | Approves timing | Executes bump |
| Extension registration | Owns registry rules | Registers product extensions | Implements extensions |
Target Users v1.0 — Phase 12-2.