Modular Architecture

ENGiOS is organized as ten official modules. The taxonomy gives the public site and the authenticated application one shared product vocabulary.

Why modules exist

Engineering operations are broad enough that a single undifferentiated portal becomes vague quickly. Modules keep the system understandable: each module has a purpose, a set of governed capabilities, related operating areas, and explicit non-goals.

Official module taxonomy

The official modules are ENGiOS Core, ENGiOS Commercial, ENGiOS Engineering, ENGiOS Knowledge, ENGiOS Content, ENGiOS Reporting, ENGiOS AI Studio, ENGiOS Portal, ENGiOS Inbox, and ENGiOS Social.

How operational areas map to modules

Commercial areas such as CRM and proposals belong under Commercial. Project, document, PMO, RFI, and lesson workflows belong under Engineering. Library, semantic search, and chat-assisted retrieval belong under Knowledge. Campaigns, publication assets, and editorial governance belong under Content and Social depending on whether the work is asset production or channel coordination.

How modules evolve

Each module can start as public narrative, then gain operator documentation, then connect to authenticated runtime behavior. The documentation should always mark whether a capability is active, planned, or intentionally out of scope.

Integration posture

This foundation does not publish internal runtime detail. It documents product boundaries and keeps future integrations clear: authentication, backend services, data synchronization, AI runtime, and client portal behavior remain controlled implementation surfaces.

Public vs internal detail

Public docs should describe capability, governance, and operating value. Internal docs can carry route inventories, schema details, infrastructure commands, secrets procedures, and test matrices. The public site must not merge those two levels.