Governance Authority

The customer-segment archetype for organisations that operate or define a dataspace, industry consortia, public institutions, regulators, and large enterprises governing shared data exchange networks. They need a single integrated governance interface for profile registration, identity, onboarding, and credentials, with the source-availability and certifications procurement and audit demand.

Who is the customer?

The Governance Authority is the organisation responsible for operating or defining a dataspace, the entity that sets its rules, establishes the identity model, and controls who can participate. In practice this is an industry consortium, a public institution, a regulatory body, or a large enterprise acting as the governing centre of a shared data exchange network. The Mobility Data Space and Catena-X are the most prominent examples in Kaphera’s initial market, but private organisations governing internal dataspaces, a consumer electronics manufacturer managing supply chain transparency across its tier network, for instance, follow the same pattern.

The people involved in this decision are not typically individual engineers making a tooling choice. They are executives, programme directors, and technical leads accountable to a consortium board, a regulatory mandate, or a board-level digital transformation commitment. Their decisions are deliberate and slow-moving. They operate under scrutiny. A governance authority that makes an infrastructure choice that disrupts participant onboarding or creates a compliance exposure will hear about it at the next consortium meeting. Stability, auditability, and compliance posture are their primary concerns, not deployment speed or developer experience.

What is their problem?

Standing up and operating a dataspace requires a set of capabilities that no single off-the-shelf platform has historically provided in an integrated form. The governance authority must register and publish dataspace profiles, define and enforce the identity model participants must satisfy, manage credential issuance, control which organisations can discover and join the dataspace, and maintain all of this as specifications evolve and participant counts grow. They must do this in a way that is auditable, both to their own consortium members and to any external regulatory body with an interest in the dataspace’s operation.

Historically, governance authorities have assembled this capability from components: identity management tooling bolted to access control systems bolted to participant registries, each integration custom-built and owned by whoever was available at the time. This creates operational fragility and makes it difficult to onboard new participants consistently, because each step of the process may touch a different system with a different interface. It also makes auditing difficult, when something goes wrong, tracing the failure across a patchwork of integrated components is slow and error-prone.

The governance authority also faces a discoverability problem. If the dataspace is not visible to potential participants in a standardised way, onboarding depends on direct outreach and manual coordination rather than a self-service flow. This limits the dataspace’s growth rate and concentrates operational burden on the governance team rather than distributing it through the platform.

What is the most important customer benefit?

A complete, integrated governance interface that is purpose-built for the role. The governance authority can register dataspace profiles, configure the identity and onboarding rules that participants must satisfy, manage credential issuance, and control discoverability, whether the profile is visible to all organisations on the platform or restricted to a specified group, from a single, consistent operational surface. They do not need to assemble this from parts.

For compliance-sensitive governance authorities, the source-available licensing of the Kaphera Cloud operator and platform server is also material. Being able to inspect and audit every component of the infrastructure managing their dataspace is not a nice-to-have; for some organisations it is a procurement requirement. Kaphera is the only managed connector platform that offers this, no other provider’s operational stack is auditable by the organisations depending on it.

The steward-ownership governance structure adds a further dimension for public institutions and consortia that care about the long-term independence of their infrastructure provider. A governance authority choosing Kaphera is choosing a platform that cannot be acquired by a hyperscaler and repurposed. For organisations whose mandate includes ensuring that data sovereignty infrastructure remains under European control, that structural commitment carries weight that no feature comparison can replicate.

How does the company know what the customer wants or needs?

Kaphera’s knowledge of the governance authority persona is grounded in operating one. Think-it operated the Mobility Data Space connector infrastructure before Kaphera, and Kaphera now formally owns and operates the MDS deployment, serving over 150 active connectors. The operational demands of running a production dataspace, managing participant onboarding at scale, handling credential lifecycle, maintaining profile stability while the underlying EDC specification evolves, are not hypothetical requirements derived from interviews. They are the operational reality the team has been managing.

The MDS relationship also provides ongoing signal on what governance authorities encounter when the platform is under operational stress: what breaks, what is difficult to audit, where participants get stuck in onboarding, and what changes to the governance interface would have prevented those failures. This feedback loop is direct and continuous, not periodic.

What is the customer journey?

The governance authority’s journey with Kaphera typically begins with an infrastructure decision that is already being forced by external circumstances, a consortium agreement, a regulatory timeline, or an industry initiative that requires a dataspace to exist and operate by a specific date. By the time they are evaluating platforms, they have usually already attempted to assemble the capability themselves or contracted a previous provider, and have encountered either the cost, the complexity, or the compliance gap that brought them back to market.

The evaluation process is thorough and slow. The governance authority will want to understand the compliance posture (TISAX, ISO 27001, CX-0018 where applicable), the licensing model (particularly the source-available terms that allow them to audit the platform), the infrastructure sovereignty story (EU cloud providers, no hyperscaler dependency), and the production track record. The MDS reference, 150-plus live connectors, operated since mid-2026, is the credibility anchor that makes these conversations move faster than they otherwise would.

Onboarding begins with registering a dataspace profile: defining the identity model, setting the onboarding rules that participants must satisfy, and configuring discoverability. The platform handles the operational layer, credential issuance, participant provisioning, profile lifecycle, so that the governance authority’s team focuses on policy and compliance rather than infrastructure operations. As the dataspace grows, the governance authority’s interaction with Kaphera shifts from setup to monitoring: tracking participant status, reviewing audit logs, managing profile updates as specifications evolve.

The renewal and expansion dynamic for a governance authority is different from any other persona. Once a dataspace is operating on the platform and participants are onboarded, the cost of switching infrastructure is extremely high, for the governance authority and for every participant that depends on it. The relationship is long-term by design, which means the initial trust built during evaluation and onboarding is the foundation the entire relationship rests on.

Governance interface surface

flowchart LR
  GA["Governance Authority"]
  PR["Profile registration"]
  IM["Identity model"]
  OR["Onboarding rules"]
  CI["Credential issuance"]
  DI["Discoverability"]
  GA --> PR
  GA --> IM
  GA --> OR
  GA --> CI
  GA --> DI
  PR -.heavy use.-> SR["sophie-renard<br/>(consortium)"]
  IM -.heavy use.-> SR
  OR -.heavy use.-> ID["isabelle-dufour<br/>(supply chain)"]
  CI -.heavy use.-> ID
  DI -.shared.-> SR
  DI -.shared.-> ID