Mobility Maturity & Trust Framework 2026
An evidence framework developed by HopHop B Mobility to separate public mobility claims by actual maturity. The framework is not a certification or regulatory standard; it is a published methodology for more precise communication, due diligence and programme governance.
1. Why maturity language matters
Mobility projects often combine software, regulated transport, infrastructure, vehicles, operators and public authorities. Those layers do not mature at the same speed. A route can be mapped without being approved; an API can exist without being integrated; a partnership discussion can exist without an activated service. Treating those states as equivalent creates false confidence and weakens institutional trust.
This framework therefore classifies the specific claim being made, not the ambition of the overall project. A programme can legitimately be R5 in one function and R1 or R2 in another.
2. Six maturity states
A question, hypothesis or technology field is being investigated. No product or service availability is implied.
A use case, architecture, route model or operating concept has been defined, but material implementation dependencies remain unresolved.
Regulatory requirements, operating areas, permits, safety responsibilities or authority pathways are being prepared, discussed or applied for. An application is not an approval.
Technical, commercial or operational integrations are being implemented or validated. Integration work is not equivalent to customer availability.
A bounded deployment or test operates under explicit scope, conditions, oversight and evidence collection. Pilot status must not be presented as general operational availability.
The service can be obtained by its intended users within a defined market and scope, supported by the required legal, technical and operational conditions. Availability may still be subject to individual confirmation.
3. Evidence dimensions
A single maturity label is insufficient if the underlying evidence is uneven. HopHop therefore separates six dimensions and applies the wording appropriate to the claim being assessed.
Authority decisions, applicable permits, approved operating areas, vehicle permissions, legally required roles and conditions.
Production configuration, integration tests, monitored interfaces, failure handling and verified system boundaries.
Named responsibilities, provider/fleet readiness, support and recovery processes, real service execution and incident handling.
Signed scope, activated partner/customer relationship, published offer or otherwise verifiable ability to transact. Outreach or discussion alone is not a partnership.
Source provenance, timestamps, verification status, audit trail and separation between target/illustrative values and observed data.
The wording visible to users must not exceed the weakest material evidence dimension needed for that specific claim.
4. Public-claim rules
Use only when an intended user can actually request or obtain the service within the stated scope.
Use for a confirmed relationship with appropriate evidence. Outreach, meetings, applications and evaluation are not by themselves a public partnership.
Use only for the scope covered by a competent authority or other issuer. Submitted, under review and supported are different states.
State the pilot boundary: geography, users, duration, vehicles, oversight or other material constraints where relevant.
Use only when the described production data or function is genuinely current and connected. A dashboard label or planned integration is not sufficient.
Use only for the function or service that is genuinely usable in production. A built UI, database entity or internal workflow does not by itself prove operational service.
Use only where the certification, assessment scope or legal basis is identifiable. Avoid blanket self-certification.
5. Evidence hierarchy
A · Primary authority / issuer
Official laws, regulator decisions, permits, registers and records published by the competent issuer.
B · Counterparty evidence
Signed scope, official partner/customer page, formal contract evidence or other independently attributable confirmation.
C · Operational evidence
Production logs, completed transactions, monitored service records, incident and audit evidence.
D · Company statement
A company’s own website, press release, social post or presentation. Useful, but not independent verification.
E · Secondary reporting
Credible media, databases and research sources. Quality depends on provenance and recency.
F · Unverified / illustrative
Plans, targets, mock-ups, seed data, simulations or unsupported claims. These must never be presented as observed reality.
6. Regulatory example: autonomous road mobility in Germany
Germany’s AFGBV illustrates why “route mapped”, “application”, “approved operating area” and “operational service” must remain distinct. The regulation requires autonomous vehicles on public roads to operate within a defined and approved operating area; the approval of that operating area is a separate legal step, and vehicle authorisation and other conditions remain relevant. A project can therefore have substantial route and application work without yet having an operational autonomous passenger service.
7. European mobility context
The European Commission frames cooperative, connected and automated mobility as an integration challenge spanning vehicles, infrastructure, connectivity and the wider multimodal transport system. That system-level view supports a maturity model that evaluates more than vehicle technology alone.
European Commission — Cooperative, connected and automated mobility (CCAM)8. HopHop self-application
HopHop applies the same framework to its own public product language. As of 30 August 2026, the public website distinguishes:
Premium Chauffeur
Available today — provider, vehicle and price availability confirmed per enquiry.
Railway Mobility
Integration / build-up — premium rail journeys on enquiry, partner/API integration in progress.
Autonomous Mobility
Development and regulatory preparation — no autonomous passenger service currently offered.
AI Robotics
Research and integration roadmap — no operational robotics service currently offered.
This self-classification is a company statement, not independent certification. It should be checked against the underlying evidence and updated when material facts change.
Method notes
- • No composite numerical score is used. False precision can hide a weak material dependency.
- • The framework classifies claims and capabilities, not companies as a whole.
- • Evidence must be dated; material changes can move a claim both forward and backward.
- • Regulatory status is jurisdiction- and use-case-specific.
- • Version history begins with v1.0 dated 30 August 2026.