Glounix Factory

Overview

Glounix Factory is Simorgh's flagship engineering initiative: a software production platform built around a simple thesis. Probabilistic AI assistance should not be the authority that decides whether a system is consistent, secure, installable, or complete. Those decisions require explicit models, contracts, deterministic transforms, and evidence.

Factory is best understood as engineering infrastructure rather than a code-generation tool. It connects requirement and product studios, a Knowledge Graph project model, typed metadata, builder interfaces, persistence adapters, generation targets, a pipeline and build layer, and quality and testing areas.

Origin and motivation

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 coherent or repeatable.

Factory began from that gap: how to separate probabilistic design assistance from deterministic execution, while keeping human decision authority explicit.

The problem

Free-form generation produces artifacts without a durable account of what was decided, why it changed, which contracts were satisfied, and whether the resulting build can be installed and validated as a system.

The harder problem is not producing more code. It is preserving intent and accountability as a system grows across studios, domains, revisions, and deployment targets.

Who it is for

Engineering leaders, platform teams, and enterprises that manage long-lived systems where consistency, change history, and validation matter more than raw generation speed.

Vision and objectives

An approved design revision becomes a registered build through a traceable path: model, contract, compile, validate, build, and evidence. The goal is reproducible engineering, not a claim that arbitrary business software can already be produced automatically.

Key capabilities

• Requirement and product studios for structured design work
• A Knowledge Graph project model with typed metadata and revisions
• Builder interfaces and persistence adapters across studio workflows
• Generation targets, pipeline orchestration, and build registration
• Quality gates, contract checks, and testing areas
• A conceptual path from design snapshot to registered build artifact

Engineering and architecture

Repository architecture is Python-based on the engine side, with separate studio and web application surfaces. The public Factory website is a Next.js and Django application and is intentionally decoupled from the engine.

The current public evidence is deliberately bounded. Acceptance reports document PostgreSQL-backed persistence, durable artifact history, transaction rollback, and idempotent build registration in tested flows. They also record divergent stores, partial tenant-scope assurance, and quality-gate bypasses that remain engineering work.

Difficult problems and solutions

Current status

Factory is implemented but not ready to claim universal or end-to-end delivery. The pinned contract-verification report records 63 of 68 contract tests passing, mandatory quality gates that can be bypassed by a generation route, and 19 of 21 studios outside the canonical repository.

Those findings are treated as engineering work, not fine print. The next milestones are to enforce the quality-gate runner at the generation choke point, reconcile canonical metadata ownership, reject malformed imports before mutation, align workflow contracts, and validate a complete solution from approved model revision through generated build, installation, and browser acceptance.