HEPO separates platform operation, organisational records, definitions, audit and analytical work in its data architecture. The server framework also has its own system tables. These concerns have different ownership and lifecycle requirements.
A database schema is a logical namespace. Its presence does not by itself establish physical separation, tenant isolation or an independently scaled workload. Those properties depend on how the deployment and operations are configured.
Six schema responsibilities
| Concern | What it holds | Responsibility to establish |
|---|---|---|
| Platform | Platform configuration and operating data | Administrative ownership and allowed operations |
| Tenant/business data | The organisation's working records | Correct organisation context and record access |
| Definitions | Shared or organisation-scoped vocabularies and process definitions | Ownership, scope, change approval and available history |
| Audit | Recorded activity and execution/accountability information | Coverage, writer permissions, review access and retention |
| Analytics | Reporting and analytical definitions or results | Source bindings, refresh, access and workload management |
| Framework/public | Framework-owned runtime/system records | Framework lifecycle and separation from business ownership |
The implementation names these schemas platform, tenant_dev, definitions, audit, analytics and public in the current development arrangement. The public schema is reserved for framework concerns. Do not interpret tenant_dev as proof that general multi-tenant routing is already available.
Establish the organisation boundary
For a dedicated deployment, identify the database, file storage, accounts and operating access that belong to the organisation. For a proposed shared arrangement, verify routing and isolation across records, reporting, files, background work and integration.
The architecture's separation of concerns supports this design, but actual enforcement requires the appropriate credentials, query paths and operational controls. A schema is not a separate physical machine, and merely giving schemas different names does not prove isolation.
Keep identifiers appropriate to the interface
Internal relational records use big-integer primary keys. Public application and integration contracts use business slugs for entity identity, with server-side resolution to internal keys. This keeps internal storage identifiers out of the intended application contract.
An implementer should verify the relevant requests and responses for an extension. Using a slug does not confer access to the referenced record; authority still needs to be checked.
Preserve meaning as data changes
A definition supplies meaning to an observation or report. A change in that definition can affect later comparisons, so establish its scope, ownership and available version context. An updated reading should identify the basis available for its interpretation.
An integration similarly needs stable identifiers, source ownership and reconciliation rules. Delivery records and execution context help a reviewer follow what was obtained or changed. Inspect the coverage needed for the actual workflow rather than assuming every possible event has a complete trace.
Review audit and reporting separately
The audit design supports an append-oriented account of activity. Review the implemented write paths, permissions, privileged access, retention and recovery arrangements before making an immutability claim.
Analytical work has distinct definitions and purposes. Separate schemas do not guarantee that reporting never competes with operational workloads; evaluate queries, refresh arrangements and capacity under representative demand.
Data, kept apart gives the business-facing explanation. Security model and Data Integration develop access and exchange responsibilities.