Customers · engagement model
How do you engage with KYE Protocol™ — pilot, partner, or working-group seat?
KYE Protocol™ is Apache 2.0. You don't pay to read the spec, run the SDKs, or pass the conformance fixtures. Engagement is for organisations that want a structured pilot, partner integration, or working-group seat. The page below explains how that's shaped and how to start a conversation.
Customers, point by point
Demo dataYou learn: The page's points, one at a time. You can: Step through them.
-
Step 1 of 5
KYE Protocol™
Written agreement first
Engagement begins with a written agreement before any non-public artefacts are shared. SLA template + procurement pack on request via /engage .
-
Step 2 of 5
KYE Protocol™
KYE™ Reference Gateway™ in dev / pilot environment
The open-source reference Gateway runs alongside the Customer’s existing stack — not in front of a production payment rail or audit ledger.
-
Step 3 of 5
KYE Protocol™
Profile subset in scope
Engagement uses the relevant Connector Profile™ for the sector (Payment, Open Finance, Health, Pension, Legal, Sovereign AI), plus the Core profile.
-
Step 4 of 5
KYE Protocol™
Conformance pinned
The conformance suite version, the profile subset, the deployment topology, the drill cadence, and the v1.1 roadmap items in scope are all pinned in writing.
-
Step 5 of 5
KYE Protocol™
Signed evidence on every action
Each authorisation produces a Decision Map™ + evidence pack that the Customer’s auditor or supervisor can verify offline using the published JWKS.
How this widget is built
- Demonstrates
- KYE Protocol™
- Components
- The points this page makes
- Flow
- Each point in order, as the page sets it out. Architecture diagram
- Used on
- /customers/: On this page, after its opening.
Engagement shape
How an enterprise engagement is structured.
- Written agreement first. Engagement begins with a written agreement before any non-public artefacts are shared. SLA template + procurement pack on request via /engage.
- KYE™ Reference Gateway™ in dev / pilot environment. The open-source reference Gateway runs alongside the Customer’s existing stack — not in front of a production payment rail or audit ledger.
- Profile subset in scope. Engagement uses the relevant Connector Profile™ for the sector (Payment, Open Finance, Health, Pension, Legal, Sovereign AI), plus the Core profile.
- Conformance pinned. The conformance suite version, the profile subset, the deployment topology, the drill cadence, and the v1.1 roadmap items in scope are all pinned in writing.
- Signed evidence on every action. Each authorisation produces a Decision Map™ + evidence pack that the Customer’s auditor or supervisor can verify offline using the published JWKS.
Customer references
What a published reference contains.
A Customer reference lands here when each Customer publishes their own, signed off by their own communications team. The minimum content for a reference:
- Named Customer. Real organisation name and a public quote attributable to a named individual.
- Scoped problem. A specific problem the Customer faced — not a generic vertical positioning.
- Specific artefacts in scope. The KYE™ profiles, schemas, fixtures, and apps that were used — with version numbers.
- Measured outcome. A measurable result the Customer is willing to attribute publicly — latency, audit-cycle reduction, reduced incident frequency, etc.
- Evidence link. Where possible, a link to the Customer’s own blog post, talk recording, or case study.
Ways in
Three pathways.
Ready to see your AI agents flagged?
Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.
Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™.