Status: Private beta. Public launch Q3 2026. Owners: Rabih Naja (Founder & Chief Builder), Wassim Moumneh (Co-Founder & Chief Orchestrator) Last updated: 2026-04-23
The Build Engine is the mechanical heart of Aleph. It turns a signed-off brief into a running, multi-tenant application and keeps it running. This doc specifies the engine's responsibilities, its stages, its 17 internal gates, and the commit and deploy model.
Build Engine behavior is the same across tiers. What differs is isolation mode, support SLOs, and compliance posture.
Scope: this doc covers the code track (application build, test, deploy, operate). The sibling Aleph Assembly Line produces the 30+ business-setup deliverables in parallel and is specified in the Section 9 docs (Generated-Business-Standard for the floor, each generator-spec for per-deliverable mechanics). The two tracks share the audit log, the decision record model, the commit style, and the eject path. They do not share gates or pipeline stages.
The engine accepts four inputs per project.
Per project, the engine produces and maintains:
Seven stages. Same seven as the product spec. Repeated here with engine-level detail.
The engine stores the brief as a first-class artifact. Every downstream change links back to a brief version. Brief updates produce a diff that Shakeeb surfaces before plan changes ripple.
The engine drafts architecture and data model proposals from the brief. Proposals are typed objects, not freeform text. Shakeeb renders them into a human conversation.
The engine generates the base repo from the opinionated stack of record.
The engine writes feature code in small, atomic commits. Each commit has:
No feature is batched into a single giant commit. Rollback is always possible at commit granularity.
The engine auto-generates tests from the brief. Three kinds, all bundled into the single test CI gate:
Plus the 17 Aleph gates and 6 CI gates (lint, typecheck, build, test, RLS audit, registry).
The engine deploys to staging on every commit that passes all gates. Production deploys require:
Once a project is live, the engine runs:
Gates run before CI. They check the generated code for shape, not for functional correctness (that is CI's job). Targets are measured per project.
| Gate | What it checks |
|---|---|
| G1 Schema integrity | Drizzle migrations compile, no orphan FKs, no column drops without data plan |
| G2 Tenant scoping | Every new table has tenant_id or is explicitly shared; every query scopes by tenant |
| G3 RLS policy | Every tenant-scoped table has an active RLS policy |
| G4 Secret hygiene | No literal secrets; env reads go through typed config; vault references exist |
| G5 i18n completeness | Every new user-facing string has EN, AR, ES keys |
| G6 a11y floor | New UI passes WCAG 2.2 AA axe-core checks |
| G7 Auth coverage | Every new route declares auth requirement or is marked public |
| G8 Capability class | Every new tool call declares read, write, or destructive |
| G9 Rollback path | Every write has a documented rollback |
| G10 Observability hooks | Sentry, PostHog, OpenTelemetry wired on new flows |
| G11 Billing hook | Every metered surface emits a meter event with the correct unit |
| G12 Test coverage floor | Critical flows have at least one E2E, new routers have an integration test |
| G13 Migration class | Every migration is labeled destructive, reversible, or zero-downtime |
| G14 Design token use | New UI uses the locked palette and typography tokens, not hardcoded values |
| G15 Error boundary | Every route or component group has an error boundary |
| G16 Empty state | Every data surface has an empty state |
| G17 Voice fallback | Every voice flow has a text fallback path |
Violations block the commit at the engine level, not at CI. A gate violation is a Shakeeb decision item the user can override with policy.
Applied after Aleph gates pass. Standard CI on the generated repo.
Target: first-try pass rate above 70 percent by Q3 2026.
Every file mutation is a commit. No in-place edits that don't land in git.
Shakeeb <[email protected]> on behalf of the project owner.Shakeeb-Decision: <decision-id> and Brief-Ref: <section-id>.A human can push to the same repo; Aleph treats human commits as trusted and does not re-run the 17 gates unless CI fails. (Humans are expected to have read the same spec; trust is mutual.)
Two environments per project: staging and production. Optional: preview per branch.
Deploys go through GHCR plus Coolify on the default stack. Aleph builds a container image, pushes it to GHCR, and Coolify pulls and rolls out against the per-tenant Postgres fleet. Enterprise VPC-Vault deploys go through the customer-managed pipeline: Aleph produces the deploy plan and the GHCR-published image; Coolify (or the customer-managed equivalent) executes the rollout inside the customer cloud.
Three rollback paths, all first-class.
git revert <sha> followed by redeploy. Most common.A rollback is itself a commit. It carries its own Shakeeb decision record and is visible in the audit log.
Three classes.
Every migration carries a risk note authored by Shakeeb. Humans approve destructive migrations before apply.
| Metric | Target |
|---|---|
| Gate-pass rate first try (code) | Above 70 percent by Q3 2026 |
| Gate-pass rate first try (bundle / Assembly Line) | Above 80 percent by Q3 2026 |
| TTFD (signup to first prod deploy) | Under 60 minutes at launch |
| TTFB (signup to full bundle delivered) | 10 days median at launch, 7 days by end of 2026 |
| Commit-to-staging median | Under 10 minutes |
| Commit-to-production median | Under 45 minutes (assuming approval) |
| Rollback MTTR | Under 15 minutes |
| Bundle deliverable regeneration median | Under 5 minutes per document |
Tracked in the Open-Questions-Ledger.
Related docs: Aleph-Product-Spec, Generated-App-Standard, Tool-Registry, Data-Model, Tenant-Model, Observability-Spec.