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.
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.
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
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
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.
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.
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.
Factory targets generated solutions, but isolated Simorgh install and full runtime acceptance are not established by the current verdict.
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