Factory/Simorgh reports document rich HCM architecture artifacts and UI acceptance snapshots. Full lifecycle and cross-system acceptance still require a pinned, complete run.
Enterprise platform · Product architecture
Simorgh Business Solutions
A modular business management suite intended to connect shared platform services with enterprise applications. NEXA is a product identity associated with this work, not an unrelated platform. The development and production repositories are distinct snapshots and must not be conflated.
Status: broad platform implementation; overall freeze readiness blockedRecent development reports show many engine-level scoped suites passing, but a mandatory full regression and browser E2E freeze remain blocked by environment limits. Production is at a separate commit and has uncommitted data artifacts. No certification, complete security posture, or full production equivalence is claimed.
Executive overview
Simorgh addresses a familiar enterprise problem: operational data and processes spread across departments, systems, and spreadsheets. The platform direction is a shared foundation for identity, organizational structure, permissions, workflow, configuration, application engines, and solution-specific domains. The intended customer-facing experience is a Business Management Suite rather than a single ERP module.
Development and production evidence must be read independently. Development HEAD 92b87f4 includes concurrent uncommitted work; production HEAD 8799a67 contains its own current state. The public case study does not copy internal network topology, user records, or customer data.
Platform architecture
Repository layout and reports show Django-based platform engines, solution modules, API services, a React frontend, registration/installation flows, and shared authorization/configuration facilities. The architecture includes builder and workflow capabilities, module manifests, and engine-level integration contracts. The public website presents NEXA as a modular business-management product, but marketing statements are not treated as implementation proof.
Organization and access model
The platform direction includes tenant and workspace scoping, organizational relationships, identity, role-based access, and shared services. Detailed claims about parent/subsidiary authorization, on-premises parity, APQC implementation, or uniform isolation require additional source review and acceptance evidence; no formal standards certification is claimed.
Product relationship
NEXA is presented as a business-facing offering associated with Simorgh’s platform work. The precise boundary between platform engines, solution packages, and product packaging varies by repository state and should be verified against the release manifest before making module-level delivery claims.
Enterprise domains
Current repositories include finance, HR/HCM, project, inventory, procurement, manufacturing, engineering, and platform capabilities at different levels of implementation. Presence of source code, a route, or a catalog entry does not establish end-to-end product readiness. MES, PLM, and strategy capabilities are not advertised as complete without specific current acceptance evidence.
Development reports identify concurrent Finance solution changes and pending full acceptance. They are not treated as frozen or production-ready functionality.
Engine-level workflow suites have recorded passing bounded tests. Cross-solution workflow and enterprise process acceptance is not equivalent to a full platform regression.
Form, grid, detail, dashboard, and related engines are present; reports document scoped fixes and outstanding integration/test debt.
Validation and engineering evidence
On 12 October, the development readiness report marked freeze BLOCKED because the full 9,107-test regression and browser E2E could not complete within the available environment. It reported targeted engine/Factory suites passing and frontend typecheck/build succeeding, while recording known defects and unexecuted gates. A later MME freeze report documented 23/23 full-stack gates and three browser lifecycle tests passing for the module-management workflow specifically; that bounded result does not clear the entire platform freeze.
The production repository snapshot is later, on 22 October, and should be treated as a distinct codebase state. No new tests were run for this portfolio audit; repositories were read-only.
Security, tenancy, and governance
Tenant and role scoping, module lifecycle controls, API permissions, and audit-related engines are part of the implementation surface. Reports include security regression tests and tenant-scoping work, but the available evidence does not establish complete security assessment, certification, or uniform isolation across all modules. The portfolio deliberately avoids publishing sensitive organization records or internal service details.
Current limitations
- Development and production snapshots differ; active uncommitted changes exist in both worktrees.
- The full development freeze remains blocked on broad regression and browser E2E evidence.
- Solution modules have different maturity; catalog presence is not delivery evidence.
- Full organizational hierarchy/access behavior and SaaS/on-premises parity need focused acceptance verification.
- APQC alignment or any formal compliance should not be implied without documented mapping and assessment.
My role and lessons
As founder and product architect, I have shaped product direction, platform boundaries, domain priorities, and delivery trade-offs. The current engineering record reinforces a core enterprise lesson: platform breadth is not the same as integrated readiness. Release confidence depends on explicit ownership, pinned revisions, tenant-aware test data, and a complete cross-domain acceptance path.
Discuss enterprise platform architecture