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.
Data Integrity: definitions, validation, and data boundaries
Keep source records, definitions, audit, and analysis distinguishable, with validation and ownership established for each data path.
Keep source records, definitions, audit, and analysis distinguishable, with validation and ownership established for each data path.
Data Integrity is the set of practices and platform mechanisms that keep HEPO's records meaningful and usable. It concerns validation, ownership, identifiers, relationships, and the separation of operational records from definitions, audit information, and analytical results.
Administrators and implementers use these mechanisms to establish what enters the platform and how it is handled. Validation can check a record against a rule; it cannot establish that every supplied statement is true.
Follow an incoming record
An external source supplies a record. A configured mapping translates its fields and identifies the relevant subject. Validation checks the supported format and business constraints before the intended operation accepts the result. Errors need an explicit handling path, with enough context for the responsible person to correct or investigate them.
A person entering a form also receives validation feedback. Client checks help the interaction; server checks protect the authoritative operation. The review needs to include the actual import or write path, not only the form shown in a demonstration.
Keep different concerns distinguishable
| Data concern | Why it has its own responsibility |
|---|---|
| Platform | Administrative and service information needed to operate HEPO |
| Tenant or organisation | The business records belonging to the intended operating context |
| Definitions | Types, configuration, and vocabulary used to interpret or operate on records |
| Audit | The account of relevant activity and change |
| Analytics | Derived measures and results that must remain distinguishable from their inputs |
These five business concerns are a conceptual map, not a claim about the exact number of technical stores. Separation helps define ownership and access. Its effectiveness depends on the deployment's routing, permissions, storage, and maintenance practices.
Establish the organisation boundary
The intended deployment must make clear which organisation's data an operation can access. For a shared deployment, routing and isolation need explicit implementation and testing across records, files, background work, and reporting. A schema name or a tenant field alone is not evidence of that complete boundary.
The Security Model addresses access. The Deployment page addresses the infrastructure arrangement. Together they establish what the data boundary means in the environment being evaluated.
Preserve source and meaning
An imported record needs its source and mapping context. A report needs the definitions and inputs that give its result meaning. An authored definition needs a deliberate change process so comparisons do not silently mix different interpretations.
The integration layer owns connector configuration and delivery context. An incoming read and a supported outbound write have separate authority and ownership decisions. HEPO's own records can coexist with an ERP that remains authoritative for its domain.
Verify representative success and failure
Data owners agree the rules and source responsibilities. Implementers demonstrate a valid record, a rejected input, an incorrect relationship reference, and the relevant boundary checks. Review how corrections, duplicate handling, and changed definitions affect downstream work.
The practical result is a record whose origin and intended meaning can be examined, with a defined response when those expectations are not met.