HENQThe application defines
What the product does.
Its data models, relationships, workflows and user experience. It proposes policies and names the operations its users need.
Platform architecture · CTO / SVP briefing
How applications
run on HENQ.
HENQ is an open-source software platform for building and operating applications. It manages their data, permissions, AI execution and shared services on infrastructure your organization controls.
The institutional proposition
Establish a common reference foundation and require projects to build on it or demonstrate conformity. Institutions retain control of adoption, conformance requirements and procurement, while suppliers compete on the systems they build.
HENQ provides the software, published architecture and repeatable tests to put that foundation into practice.
HENQ provides versioned requirements for identity, data protection, AI authority and audit evidence. Institutions adopt that baseline and add their own obligations. Published interfaces and repeatable tests support procurement, system acceptance and upgrades.
01 / The platform and its applications
What you operate.
What your teams build.
- What do we operate?
- The HENQ platform and its supporting infrastructure. HENQ manages application data, identity and permissions, AI and workflows, files, information exchange and decision records. Your organization controls where it runs and which service providers it uses.
- What does an application team supply?
- A versioned application definition: data models, relationships, constraints, proposed policies and named business operations. The team also builds the user interface and application-specific workflows. A permit, a patient referral and a financial review remain application concepts, not built-in HENQ types.
- How do applications connect?
- Through documented service interfaces. Applications call installed operations to read or change information, start approved work and receive authorized updates. The same governing rules apply whether the caller is local or connected over a network.
HENQ’s core services are called the kernel. They enforce the rules that applications rely on. HENQ operates the authoritative application databases; institutions retain ownership of their data. Applications do not need a second authoritative database or administrator access to the kernel’s stores.
HENQ takes responsibility
How it is allowed to act.
HENQ stores the data, verifies identity and permissions, and governs transactions, information protection and external work. It records decisions and manages recovery.
- At installation
- The application submits a versioned package. HENQ validates its definitions and the installer's authority, then installs the approved version.
- During use
- The application calls named commands, queries and subscriptions. HENQ checks current permissions, performs the authorized work and returns the permitted result.
Behind the kernel HENQ connects to databases, file stores, workflow engines, model providers and delivery services through private interfaces. Applications use HENQ services, not administrator credentials for those systems.
The same permission and operation rules apply to local and remote applications. A network connection changes latency and failure handling; it does not give callers more authority or make remote work part of one atomic transaction.
Permissions are enforced where data is stored.
If an application omits an access filter, the data layer must still refuse unauthorized records. These checks also apply to files, saved results and background work.
02 / How applications define themselves
Define your application.
HENQ enforces the rules.
An application supplies a versioned package with a deterministic definition of its models, relationships, constraints, policies and named operations. HENQ checks the exact package, its language and the installer’s authority before managing installation and upgrades.
- Define.Identify the package, version, resources and required capabilities. Each application defines its own business terms; those terms do not become built-in kernel types.
- Validate.Check the definition, permissions, dependencies, isolation and compatibility. Valid syntax alone does not permit installation.
- Install.HENQ manages approved schema and policy changes. Applications do not run raw migrations with administrator credentials.
- Invoke.Typed clients call installed commands and queries with validated inputs and explicit limits. They cannot submit arbitrary SQL, graph queries or general-purpose transaction callbacks.
Local extensions can participate in a transaction only within their authorized resources and versions. They cannot run unrestricted application code inside the kernel. Remote clients call the same named operations through an approved transport interface.
Portable application contracts
Application definitions express domain meaning independently of the underlying storage and transport. Versioned contracts and compatibility checks preserve that meaning when infrastructure changes.
03 / Authorization and transactions
Verify the caller.
Check the action.
The kernel establishes the caller’s identity, then checks the operation, tenant, workspace, subject, resource and versions against current permissions. Supplying an identifier does not prove permission to use it.
- Authenticate
Who is asking? - Authorize
Is this action permitted? - Commit
What was recorded? - Deliver & confirm
Did external work finish?
One governing transaction
Application changes, decision records and the authorization of follow-up work commit together. Approval of an old version cannot authorize a changed one. Permission checks must remain valid through commit, including when policies change at the same time.
Track external work separately
Recording an outbound work item does not complete a model call, transfer or notification. Dispatch rechecks the required permissions and records the actual outcome. Idempotency keys and receipts help identify repeat requests; they do not by themselves guarantee exactly-once delivery.
When the outcome is uncertain
If a connection fails during commit, the caller checks the recorded outcome within defined time and resource limits before retrying. A lost response does not prove the operation failed. Unresolved outcomes stay marked as unknown. Looking up a receipt requires permission, even after a workspace is retired.
04 / Information protection
Permissions govern action.
Handling rules govern information.
Institutions define protection profiles for sensitivity, compartments and handling restrictions. These rules apply in addition to ordinary access permissions. They can express different classification systems; applications cannot assign themselves new privileges.
Restrictions follow derived information
Queries, summaries, model inputs, events, receipts and exports retain the relevant restrictions of their sources. Combining protected information or using it in a decision does not erase those restrictions.
Release has separate authority
Changing a classification or releasing information under less restrictive rules requires separate authorization. An administrator subject to a stricter institutional policy cannot simply disable it.
Protection down to the field.
The protection model covers whole records, documents and individual fields. Field-level classification supports authorized partial results. Field identities, schema and content versions keep rules tied to the right information as it changes. Derived results and historical views retain the relevant restrictions.
Protection also covers disclosure through metadata, errors and dependencies. Institutional profiles specify access, handling, retention and release requirements. If a required profile is not supported, access is refused.
05 / AI, workflows and real-time updates
Give AI a task.
Keep control of the decision.
Governed execution separates permission to prepare a proposal, permission to run a model, permission to approve a result and permission to publish or act. Each is scoped to its purpose, sources and destination.
- Durable orchestration
- Long-running workflows manage retries, waiting and recovery. Tasks remain subject to their governing rules, and outcomes are recorded across interruptions.
- Agent and model execution
- Agents and models run through interfaces that restrict what they can access and do. Providers can be replaced. A prompt, model response or tool request cannot grant permission.
- Human decisions
- A reviewer approves the exact saved proposal and source versions. That approval and the authorized application change commit in the same transaction.
- Events and subscriptions
- Events have stable identities and can be replayed subject to current access checks. An open connection does not grant permanent access. If permissions change, the service may require a refresh or refuse to replay restricted history.
Notifications, WebSockets and machine subscriptions follow the same access rules. Sensitive operational information and analytics remain separate. Any permitted disclosure must satisfy the information-protection rules.
06 / Files and governed information exchange
A file store holds bytes.
HENQ governs their use.
Documents, attachments and evidence have stable identities, versions, integrity checks and protection metadata. HENQ manages their access and lifecycle. Storage credentials stay private; knowing an object key or storage URL does not grant access.
One lifecycle across records and bytes
Upload, integrity verification, resource admission and availability must survive partial failures. The lifecycle accounts for staged or orphaned bytes, retry, retention, erasure and recovery. Coordination with a separate object store is explicit; it cannot be assumed atomic with a database commit.
What an exchange agreement specifies
Every exchange identifies the information, the recipient and the conditions of release:
- Which information?
- Exact versions and permitted fields or files, with their origin and protection requirements.
- For whom, and why?
- Verified destination, approved trust relationship, permitted use and separate release authority.
- Time and access limits
- Expiry, revocation and what counts as an access, including concurrent requests and retries.
- Under which rules?
- Supported handling policies, how combined restrictions apply, and refusal of requirements the recipient cannot meet.
- With what evidence?
- What a receipt proves, how partial or unknown outcomes are checked, and the time and resource limits on those checks.
HENQ to HENQ
Independent installations establish recipient trust and compatible handling profiles. Source permission to release is not destination permission to disclose. Receiving governance must not silently drop source restrictions.
Exchange between independent authorities remains distinct from clustering or a shared transaction. Receipts record the facts actually observed at each boundary.
HENQ to conventional systems
Documented, versioned interfaces let partners use familiar client tooling and established transfer methods. Credentials are narrowly scoped to the admitted exchange.
Each interface enforces the same grant, expiry and handling requirements. Recipient authentication and trust remain separate from possession of a download link or token.
Define exactly what an access limit counts.
The exchange policy specifies how concurrent requests, partial delivery, retries and caching consume an allowance. It also defines how to handle expiry, revocation and interrupted transfers.
HENQ cannot recall delivered bytes or count a recipient’s offline reading. Requirements after delivery depend on recipient trust, agreements and evidence of compliance.
Object and file storage sit behind a replaceable infrastructure boundary. Identity, permission, retention and exchange remain platform responsibilities regardless of where the bytes are held.
07 / Operating model and extensibility
Operate with control.
Plan for change.
Two routes to the same requirements
Applications can use HENQ’s shared services directly. Systems built on other foundations can be assessed against the institution’s adopted requirements. Assessment covers the complete application and its governing rules, not just the infrastructure it uses.
Conformance is demonstrated through observable behavior: permitted work succeeds, unauthorized work is refused, and concurrent operations and recovery preserve the same governing rules.
08 / Design notes and primary references
Established standards.
Shared requirements.
Open architecture means inspectable code, documented interfaces and requirements institutions can reuse. HENQ uses the Apache 2.0 license.
These references inform HENQ’s approach to access control, credentials and the exchange of handling rules. They address different responsibilities within the platform.
- Attribute-based access control
Policy decisions combine attributes of the actor, information, operation and environment.
- OAuth resource indicators · RFC 8707
Resource targeting scopes credentials to an intended service. Application authorization and access budgets remain additional duties.
- Sender-constrained tokens · RFC 9449
Proof of possession binds token use to a key, strengthening the connection between a credential and its legitimate holder.
- Rights-policy representation · ODRL 2.2
A common vocabulary for permissions, prohibitions and duties. Policy exchange and evidence of enforcement remain distinct.