Technical Architecture
This section is for integrators and operators who need to understand where Open EPM verifies identity, accepts work, and records a result. The browser, MCP and SDK reach the same application model. Server-side authorization and fixed execution apply at each entry point. PostgreSQL holds the authoritative application state.
Start with the object model and service topology. Then follow a request through the client entry point, verified identity, and current grants. Read the storage and processing pages together to see what a preview, accepted request, and committed receipt each establish. The Python, observability, and endpoint pages explain their additional boundaries.
Before using a service topology or endpoint description to configure a host, confirm the installed profile in the installation overview. Listener availability depends on that profile and the authorized function catalogue.
In this section
- Platform concepts and object modelIdentify the workspace, application, dimensions, coordinates and scoped records.
- Services and deployment topologySee where browser, identity, worker and database services run for each profile.
- Browser, MCP and SDK request pathsFollow browser, MCP and SDK requests into the fixed execution boundary.
- Identity, permissions and isolationDistinguish verified identity from enrollment, role and dimensional authorization.
- Metadata, facts and authoritative storageSee how PostgreSQL holds metadata, typed facts and revision history.
- Processing, publication and recoveryDistinguish a preview, a durable admission and a committed effect.
- Python authoring and executionTrace isolated builder output through sealing and a separate authorized run, and see the optional notebook boundary.
- Observability and operational boundariesFind the service, request and worker signals available to operators.
- MCP endpoint scopesCompare the five listener scopes and the role of explicit workspace or application IDs.