Code Factory: generate module artifacts from definitions
Author module and capability definitions, preview supported generation, and review the resulting artifacts before integration and release.
System Layer — Shared Services Behind HEPO
Understand HEPO's shared security, data, integration, local AI, workspace, and extension services, and how to evaluate them in your deployment.
Understand HEPO's shared security, data, integration, local AI, workspace, and extension services, and how to evaluate them in your deployment.
The System Layer is the technical foundation used across HEPO's modules. It provides the common services for identity and permissions, data handling, process execution, interfaces, integration, and local AI. Implementers configure these services for the organisation; technical evaluators examine how they behave in the intended deployment.
These services support all three offerings: People & Culture Orchestration, Process Orchestration, and Simulation & Gamification. The Operational Core supplies shared business records. The System Layer supplies the mechanisms through which modules present, use, and govern those records.
Follow one request through the platform
A project owner opens a work item and requests an action. The interface presents the available controls, the request carries its context to the server, and the configured process validates and authorises the operation. Execution produces a result that the application can present, with the relevant execution and audit information available for review.
If the action needs information from another system, a configured connector supplies it. If it uses AI interpretation, the inference service runs within the deployment boundary. If a human approval is required, that decision remains a separate step. These responsibilities work together; each still needs to be configured and verified for the actual path.
Governance, connections, and operation
| Subject | What the page explains |
|---|---|
| Security | Identity, roles, permissions, enforcement, and audit review |
| Data Integrity | Validation, data ownership, separation of concerns, and tenant context |
| Deployment | The organisation's infrastructure boundary, storage, operation, and handover |
| Data Integration | Connectors, mappings, schedules, delivery records, and direction of exchange |
| Interoperability | How data connections and tool invocation fit the wider environment |
| Local AI | Inference within the deployment and its use by evaluation, retrieval, and the assistant |
Adapt the workspace and extend the platform
| Capability | What changes |
|---|---|
| Common Canvas | The arrangement of supported views and panes around a task |
| Shared Module | Configured list, form, and detail surfaces for supported record structures |
| Code Factory | Module and capability artifacts produced from definitions through supported generation paths |
| Process-driven UI | The registered interfaces that a process or assistant can address |
| Scalability | How extension and operational capacity are planned and evaluated |
The first three preserve the existing progression: compose views, configure data surfaces, generate module artifacts. They address different kinds of change. A new layout does not create new business logic; a generated artifact still needs integration and validation before release.
The coordinated responsibilities beneath the modules
The architecture describes sixteen coordinated systems. This map is useful for understanding responsibilities after the operating experience is clear; it is not a list of additional products or a guarantee of universal behaviour on every path.
| Responsibility | Purpose |
|---|---|
| Coordination | Initialise services and coordinate multi-step work, including defined failure handling |
| Communication gate | Route exchanges among registered components |
| Action execution | Supply common patterns for invoking and handling actions |
| Validation | Apply format and business checks at the relevant boundaries |
| Persistence | Store and retrieve data, including supported cache behaviour |
| Transformation | Convert between defined representations |
| State distribution | Distribute changes to participating application components |
| Device signals | Translate supported device input into application signals |
| Visual presentation | Render the operator's working surfaces |
| File processing | Handle supported uploads, downloads, and document flows |
| Identity lifecycle | Manage identities, credentials, sessions, and their states |
| Entity relationships | Maintain named connections among records |
| Security framework | Express and enforce configured access rules |
| UI framework | Provide reusable interface patterns for modules |
| External interface | Connect the platform to agreed external capabilities |
| Application identity | Hold the deployment's administrative identity and configuration |
Shared definitions and typed contracts help keep the application and server aligned. Generation reduces repeated contract work, but deployed versions and custom extensions still need compatibility checks. Coordinated services also need a defined response to failure; database rollback and reversal of an external action are different operations.
Evaluate the deployment through a real case
Use a representative workflow and two roles. Examine an allowed action, a denied action, a validation failure, the resulting records, and any external delivery. Follow an AI request to its configured inference endpoint. Review the storage, backup, update, and recovery arrangements with the people who will operate them.
The Architecture & Security reference brings those questions together for technical evaluation. The organisation owns its access and operating requirements; implementers configure and test them; the delivery partner coordinates demonstration and handover.
People & Culture Orchestration · Process Orchestration · Simulation & Gamification · Platform overview