ZAIXOS Engineering Platform — Execution Architecture

Document type: Technical Specification
Version: 1.0 · Phase: 12-3
Status: Permanent technical authority
Related: EXECUTION_PIPELINE.md

---

Purpose

Define how engineering work flows through ZEP — from developer session through platform-orchestrated runtime components to acceptance and release.

This is not Runtime Contracts (obligations). This is execution topology — who invokes what, in what order, with what artifacts.

---

Execution pipeline overview

Developer
    ↓
Platform (pin + materialized runtime view)
    ↓
Workflow (phase orchestration)
    ↓
Procedure (step skill)
    ↓
Delegate (sub-agent role)
    ↓
Runtime Constraints (always-on rules)
    ↓
Hooks (enforcement — fail closed)
    ↓
Validation (Layers 0–5 + product architecture)
    ↓
Runtime Report (Format A or Format B)
    ↓
Architecture Review (RESPONSE_TEMPLATE — 9 sections)
    ↓
Acceptance (Architect decision)
    ↓
Freeze (product baseline — Developer Git only)
    ↓
Release (product tag/deploy)

---

Execution actors

Actor	Domain	Role in pipeline
Developer	D-R	Invokes workflows; produces Runtime Reports; executes Git freeze
Architect	D-R	Issues phase prompts; produces RESPONSE_TEMPLATE acceptance
Platform	D-P	Supplies methodology, templates, contracts, validation
Adapter	D-A	Maps abstract components to IDE artifacts
IDE Session	D-T	Executes agent, hooks, skills natively
Validation	D-V	Automated gates

---

Execution layers vs platform layers

Execution stage	Platform layer	Runtime component
Platform pin	L7 Consumer	—
Workflow	L1 Methodology	Runtime Workflows
Procedure	L1 Methodology	Runtime Procedures
Delegate	L1 Methodology	Runtime Delegation
Constraints	L2–L4	Runtime Constraints
Hooks	L4 Adapter	Runtime Enforcement
Validation	L6	—
Reports	L1 Templates	—

---

Phase execution model

Each engineering phase (e.g. 12-3, product feature phase) runs one execution cycle:

Architect publishes phase prompt (platform template)
    → Developer selects Workflow (e.g. phase-implementation)
    → Workflow invokes Procedures sequentially
    → Procedures may Delegate to specialized agents
    → Constraints apply globally (session-wide)
    → Hooks enforce on file/shell events
    → Developer completes scope
    → Validation runs
    → Developer emits Runtime Report (Format A or B)
    → Architect emits RESPONSE_TEMPLATE
    → If Accepted: proceed; if Rejected: remediation cycle

---

Workflow resolution

Input: Phase identifier, architect prompt, platform default workflow catalog (10 defaults).

Resolution order:

1. Architect specifies workflow ID in prompt (if any)
2. Else match phase type to default workflow mapping (documented in DEVELOPMENT_WORKFLOW)
3. Else fallback workflow-phase-implementation
4. Product extension workflow usable only if registered and ID unique

Output: Active workflow skill reference in materialized workspace.

---

Procedure resolution

Input: Active workflow, current step index.

Resolution:

1. Workflow frontmatter lists procedure sequence
2. Each procedure maps to materialized SKILL.md
3. Extension procedures append after platform steps only when registered in workflow (v1: extensions invoked by explicit architect mention)

---

Delegate resolution

Input: Procedure step requiring delegation.

Resolution:

1. Procedure specifies delegate role
2. Map role → materialized agent markdown
3. Delegate inherits Constraints + Enforcement
4. Delegate output returns to Developer session — not Architect auto-accept

---

Constraint evaluation

Timing: Continuous during IDE session (adapter-enforced).

Precedence: Platform A–G → extension C–G → session rules.

Effect: Shapes agent behavior; cannot be disabled by product extensions.

---

Hook execution

Timing: Pre/post tool events (file write, shell, MCP).

Behavior: Fail closed on policy violation (e.g. architecture path edits without phase, Git push by agent).

Owner: Platform enforcement handlers in adapter template.

---

Validation in execution

Validation is a hard stop before Runtime Report submission:

• Developer runs validation locally
• CI runs on PR
• Report cites validation status in Format A/B § ERP Runtime Validation equivalent

---

Report generation

Format	Sections	When
Format A	4	Minor runtime/doc changes
Format B	6	Phases, structural changes, platform work

Reports are Developer-owned artifacts — not contract definitions.

---

Architecture review

Owner: Architect
Template: RESPONSE_TEMPLATE (9 sections)
Input: Runtime Report + validation evidence
Output: Acceptance | Rejected | Accepted with conditions

---

Acceptance → Freeze → Release

Stage	Owner	Platform role
Acceptance	Architect	Methodology only
Freeze	Developer (Git)	GIT_FREEZE_PROCEDURE template
Release	Product team	None — product semver independent

Platform freeze (12-9) is platform v1.0 GA tag — distinct from product freeze.

---

Execution invariants

ID	Invariant
E-01	Agents never perform Git push/tag
E-02	Architects never skip RESPONSE_TEMPLATE sections
E-03	Validation green required before Accepted
E-04	Workflows cannot disable enforcement hooks
E-05	Platform pin fixed for duration of phase unless upgrade phase

---

Related documents

• Control/data flow detail: EXECUTION_PIPELINE.md
• Asset states during execution: PLATFORM_STATE_MACHINE.md
• Contract obligations: contracts/runtime-contracts.md (unchanged)

---

Execution Architecture v1.0 — Phase 12-3.