Resume

Home / Case studies / Glounix Factory

Flagship engineering initiative · Internal platform

Glounix Factory

AI helps design. Engineering systems compile, validate, and build. Factory explores how structured models, explicit contracts, and deterministic tooling can make enterprise software production more reproducible than repeated free-form code generation alone.

Role: Founder / Platform ArchitectSnapshot: 22 October 2026Evidence: pinned repository and acceptance reports
Current status: implemented, but not ready to claim universal or end-to-end deliveryThe repository contains model, persistence, studio, compiler, and build workflows. The current contract-verification verdict is FAIL for universal contract verification: 63/68 contract tests passed; mandatory quality gates can be bypassed by a generation route; 19/21 studios were reported outside the canonical repository; isolated Simorgh runtime installation remains unproven. This case study treats those findings as engineering work, not as fine print.

Origin and engineering thesis

Modern code assistants can accelerate local implementation, but enterprise systems must preserve consistency across domains, permissions, tenancy, integrations, process orchestration, reporting, and change history. A working screen or generated module does not establish that a complete solution is secure, coherent, repeatable, or installable.

Factory’s central design hypothesis is to separate probabilistic assistance from deterministic execution. AI can help interpret requirements, explore a model, and prepare proposals. People retain decision authority. Structured metadata, revisions, contracts, compiler transforms, quality checks, and registered artifacts provide the accountable path from design to build.

This is a research and engineering direction, not a claim that arbitrary business software can already be generated automatically.

Architecture and production path

Factory source-derived pipeline from requirements and typed models through revisions, compiler, quality gates, and build registration; unresolved validation and runtime states are labeled.
Conceptual view reconciled with repository architecture and the 22 October 2026 contract-verification report. Quality-gate enforcement and runtime installation remain limitations.

Repository architecture includes requirement and product studios, a Knowledge Graph project model, typed metadata, builder interfaces, persistence adapters, generation targets, a pipeline/build layer, and quality and testing areas. The intended flow is a versioned design snapshot into compilation and a registered build artifact. Some stores and studio flows have PostgreSQL persistence and revision support; canonical ownership is not yet consistent across all studios.

Responsibility boundaries

  • AI assistance: requirement interpretation, design proposals, model analysis, and engineering support.
  • Human governance: review, approval, change decisions, and ownership of accepted models.
  • Deterministic tooling: schema/contract processing, compilation, build creation, registration, and executable checks where the path invokes them.

Engineering decisions and problems

Persistence

Acceptance reports document PostgreSQL-backed Knowledge Graph persistence, durable artifact history, real transaction rollback, and idempotent build registration in tested flows. They also record remaining divergent stores and partial tenant-scope assurance.

Revisions

Design revisions and optimistic concurrency are part of the architecture; coverage varies by studio and the existence of a mechanism is not proof of consistent adoption.

Compilation

Snapshot-to-compiler-to-build registration paths are implemented and tested in bounded cases. The current report found a generation entry point that writes packages without running all required Q01–Q12 checks.

Cross-studio contracts

Typed domain and builder work is real, but current ownership and relation vocabulary have mismatches. Workflow relations can fail quality gates; other end-to-end chains are not executed.

Enterprise integration

Factory targets generated solutions, but isolated Simorgh install and full runtime acceptance are not established by the current verdict.

Evidence governance

Historical acceptance reports are preserved as dated evidence, not promoted to current claims without revalidation against the snapshot.

Validation and evidence

The 22 October 2026 report inventories 288 contracts and records 63/68 executable contract tests passing. It verifies selected quality gates and a narrow traceability chain, while marking multiple integration chains unexecuted. It also identifies quality-gate bypass, split canonical persistence ownership, duplicate-ID import behavior, and workflow relation rejection.

Prior reports document bounded persistence acceptance, browser-based studio screenshots, typed builder checks, and build registration tests. Their original test counts are not presented as current whole-system acceptance. Full Factory-to-generated-application browser acceptance and complete Simorgh runtime installation are not demonstrated in the current verdict.

Security and governance

Tenant/workspace/project scoping, explicit revisions, durable artifacts, and quality gates are intended governance controls. The latest evidence rates tenant isolation and canonical ownership as partial in areas; it is not a completed security assessment. Credentials, customer records, and internal deployment details are intentionally excluded from this public explanation.

Current limitations

  • Generation can bypass mandatory quality checks in at least one verified route.
  • Most studios do not yet share canonical repository ownership, per the current audit.
  • Several cross-studio data, workflow, entitlement, and integration chains remain unexecuted or partial.
  • Simorgh runtime installation and full generated-solution acceptance are unproven.
  • Jalali presentation/effective-dating behavior and import rollback cases are not fully verified.

Next engineering milestones

Enforce the quality-gate runner at the generation choke point; reconcile canonical metadata ownership; reject malformed imports before mutation; align workflow relation contracts; then validate a complete, isolated solution from approved model revision through generated build, installation, and browser acceptance. Publish new status only after those gates pass on a pinned revision.

Personal role

I define the platform’s engineering thesis, architecture boundaries, product direction, and validation priorities. The implementation is team and repository work; this page does not attribute every subsystem to one person.

Discuss Factory architecture