Governance Authority Playbook
How to sell Kaphera Cloud into the governance authority archetype: consortia, public institutions, regulators, and large enterprises that operate or define a dataspace. The MDS reference and the steward-ownership / source-availability story do most of the closing; the managed governance interface is what they actually use.
Jobs to be done
- When I need to operate a dataspace for my consortium or supply chain, help me manage the full lifecycle, profiles, identity, onboarding, credentials, discoverability, from a single interface, so I don’t assemble it from parts.
- When participants need to join my dataspace, help me make onboarding self-service and fast, so growth doesn’t require proportional growth in my team.
- When regulators or auditors review our operations, help me produce auditable records of every identity decision, credential issuance, and participant action, so I can answer their questions without qualification.
- When I evaluate infrastructure providers, help me inspect every component managing my dataspace, so I don’t depend on a vendor’s goodwill to understand what my infrastructure is doing.
Signal → Product map
When you hear the signal, sell the product. The justification tells you why that product and not another.
| What you hear | What to sell | Why this product, not another |
|---|---|---|
| ”We’re building / operating a dataspace” | kaphera-cloud-managed-server • kaphera-cloud-managed-console | The governance interface is a managed-only capability. Profile registration, identity rules, onboarding management, credential issuance, discoverability, all in one surface. Not the base server, it lacks the governance layer. |
| ”We need to audit what manages our infrastructure” | kaphera-cloud-server (Source-available — Elastic) | The source-available Elastic licence means they can read and audit every component. No other managed provider offers this. If they also need managed ops, sell the Managed Server and point to source-availability as the audit guarantee. |
| ”Participant onboarding is too manual and slow” | kaphera-cloud-managed-server • kaphera-cloud-managed-console | Self-service join flow with real-time progress tracking. The authority defines the rules; the platform enforces them automatically. Not a consulting engagement, a product that scales onboarding without scaling the team. |
| ”We need Catena-X-compliant registry infrastructure” | kaphera-digital-twin-registry | Multi-tenant, AAS Part 2-compliant. Replaces per-participant registry instances, dramatically reducing cost. GPL ensures it stays open and interoperable. The only multi-tenant DTR in the ecosystem. |
| ”We cannot depend on a provider that could be acquired” | Steward-ownership + source-available licensing | Not a product, a structural argument. Kaphera cannot be acquired by a hyperscaler. The source-available licensing means they can operate independently if the relationship changes. This closes deals that features alone cannot. |
| ”The interface needs to work without engineering expertise” | kaphera-cloud-managed-console | The managed console’s governance interface is designed for non-technical operators. Profile management, onboarding rules, audit logs, no CLI, no configuration files. Not the base console, the governance views are managed-only. |
Upgrade signals
- Growing participant count → per-participant pricing scales with adoption. Each new participant they onboard is recurring revenue for Kaphera.
- Need for custom credential specifications → enterprise engagement with engineering support.
- Asking about running across multiple regions → dedicated tier + multi-region deployment.
- Operating additional dataspaces → each dataspace is a new profile, additional revenue.
- Asking about supply chain visibility beyond connectors → add kaphera-digital-twin-registry for product-level digital twin metadata.
Objections & responses
| Objection | Response |
|---|---|
| ”We’ve assembled this from components before" | "And you know the cost: every integration is custom, onboarding is manual, auditing means tracing failures across systems that weren’t designed to work together. Kaphera replaces the assembly with a single operational surface." |
| "Your MDS track record is mobility-specific" | "The MDS deployment validates the operational model, 150+ connectors, identity management, credential lifecycle, profile stability. The platform is dataspace-agnostic; the profiles are what make it domain-specific." |
| "How do we know you’ll still be here in 5 years?" | "Steward-ownership means we cannot be acquired. Source-available means you can operate independently. The governance structure and the licensing together give you a credible long-term answer that no VC-backed competitor can match.” |
What closes the deal
The MDS reference. 150+ connectors in production, operated by Kaphera. Not a demo, a production deployment they can call and verify.
For sophie-renard: the production track record + the source-available audit guarantee. She has been burned by a proprietary provider before. Show her the code, then show her the MDS numbers.
For isabelle-dufour: the governance console demo + the pricing. She needs to see herself completing the workflow and needs a price that fits an innovation budget, not an enterprise contract.
Related
- governance-authority, the archetype this playbook serves.
- sophie-renard, isabelle-dufour, the two named scenarios under this archetype (mobility consortium ops and corporate-responsibility-driven governance).
- kaphera-cloud-managed-server, where the governance layer lives; the only product that exposes profile / identity / onboarding / credentials in one surface.
- kaphera-cloud-managed-console, the operator-facing UI for non-technical governance staff.
- kaphera-digital-twin-registry, the multi-tenant DTR that supplements governance for product-level data exchange (Catena-X).