HAT Microserver

The most up to date stable version of HAT core is HAT 2.0

Components of the HAT Microserver

1. Web server and APIs

Each HAT Microserver has its own API. These APIs are configurable i.e. it can be for a namespace, a few data attributes within a namespace or a combination of data attributes across namespaces. Data Debit capacity (making an API available) is written into each API.

2. Database

Each PDA owner owns a database and own the rights to the contents of the database.

Data is placed in a folder, or ‘namespace’ within the database. These are separated and ordered according to data sources, so that (for example) Spotify and Facebook data is placed into individual Spotify and Facebook namespaces inside the database.

Each database contains a data schema, allowing for the storing of an individual’s data from any source without losing the structure specific to the source, while at the same time enabling the individual to relate their data to a context, providing a common semantic structure for third parties to use such data.

3. File Storage

Unless rendered into text based data, files cannot be stored in the HAT Database. These files are held in the S3 storage system offered by AWS and managed by Dataswift.

4. Computation / PDA Functions

Private serverless computations are called PDA Functions and enable private analytics and “AI” for the personal data stored. New data points can be created and stored locally but the PDA function can not call out or to any other data sources other than what is available in the PDA.

A critical use case is to generated insights from data in one namespace and made available for acquisition via Data Debit process. e.g learn from Spotify data and share it securely.

PDAs also support a notion of custom data "combinators", with the key feature being data transformation. It allows for remapping, combining, ordering, and filtering to harmonise output of datasets with varying provenance.

General Architecture

In the current architecture we use cloudformation to manage all customer PDAs and their databases running as separate, isolated Docker containers across a number of Elastic Compute Cloud EC2 instances. Each PDA communicates with the outside world via APIs and can be accessed by the owner and authorised applications from the outside world, including the Rumpel interface. PDA data is persisted in encrypted Elastic Block Store EBS units and backed up using EBS Snapshots, to make sure individuals' data is not lost even in the case of outages.

Currently available Data Plugs are run using a separate set of cloud resources, managed by https://dataswift.io using the same orchestration tools and similar infrastructure. Further Data Plugs, developed by third-parties can be hosted separately and talk to individual PDAs via the provided APIs.

Each database contains a data schema, which allows the storage of any individual's data from any source without loosing the structure specific to the source, at the same time allowing the individual to relate their data to the context of their personal life and provide a common semantic structure for third parties to use such data.


HAT APIs were developed to exercise user managed control of your personal data. REST APIs for the HAT schema can be used by web, mobile and other clients to interact with the PDA, allowing the user to control their data and applications benefit from it. API documentation can be found in the API Reference section.

We also provide convenience wrappers Hat Client Scala Play around HAT HTTP APIs and contains the most up-to-date set of typesafe HAT Data Models and Play-JSON based serializers and deserializers for them.

For those who would like to build an app to interact with PDAs, it is a matter of calling HAT APIs for data I/O. A Developers' Portal is available for tools, documentations, zero-touch onboarding PDAs, Apps, and other services in a sandbox environment.

The access to data in any PDA is via Data Offers. Once a Data Offer is agreed, specified data points from a PDA will be prepared for the Data Buyer as Data Debit (all data is within one bundle of a Data Debit), and retrievable through an API endpoint on that PDA that has accepted the offer. A contract of the exchange is then logged by DEX.

A development free option for organisations who don’t want to commit to any development but still want to interact with customers via PDAs is available through partner services such as DataTrader.