Arquitectura Modular

ENGiOS está organizado en diez módulos oficiales. La taxonomía da al sitio público y a la aplicación autenticada un vocabulario único de producto.

Por qué existen módulos

Las operaciones de ingeniería son lo suficientemente amplias como para que un portal indiferenciado se vuelva vago rápidamente. Los módulos mantienen el sistema comprensible: cada módulo tiene propósito, capacidades gobernadas, áreas operacionales relacionadas y no objetivos explícitos.

Taxonomía oficial de módulos

Los módulos oficiales son ENGiOS Core, ENGiOS Commercial, ENGiOS Engineering, ENGiOS Knowledge, ENGiOS Content, ENGiOS Reporting, ENGiOS AI Studio, ENGiOS Portal, ENGiOS Inbox y ENGiOS Social.

Cómo las áreas operacionales se asignan a módulos

Áreas comerciales como CRM y propuestas pertenecen a Commercial. Proyectos, documentos, PMO, RFIs y lecciones pertenecen a Engineering. Biblioteca, búsqueda semántica y recuperación asistida por chat pertenecen a Knowledge. Campañas, activos de publicación y gobernanza editorial pertenecen a Content y Social según el trabajo sea producción de activos o coordinación de canales.

Cómo evolucionan los módulos

Cada módulo puede comenzar como narrativa pública, ganar documentación operacional y luego conectarse al comportamiento autenticado. La documentación debe marcar siempre si una capacidad está activa, planificada o intencionalmente fuera del alcance.

Postura de integración

Esta fundación no publica detalle interno de runtime. Documenta fronteras de producto y mantiene integraciones futuras claras: autenticación, servicios backend, sincronización de datos, runtime de IA y portal del cliente siguen como superficies controladas de implementación.

Detalle público vs interno

Docs públicas deben describir capacidad, gobernanza y valor operacional. Docs internas pueden llevar inventarios de rutas, detalles de schema, comandos de infraestructura, procedimientos de secretos y matrices de prueba. El sitio público no debe mezclar esos niveles.