The three questions

The original Car Evolution proposition opens with three questions put directly to the reader.

• Could access to different vehicles, shared journeys and chauffeur-like mobility cost less than maintaining an underused private car?
• Would you like an Uber- or Cabify-style chauffeur for all your journeys, business or leisure, at a total price below that of a lease?
• Would you like to stop paying fuel, insurance and depreciation on your current car in exchange for picking up a passenger along the way?

Operational product evidence

A mobility and logistics operating system tested as an MVP at operational scale.

This was not a narrow routing experiment. It operated as a full mobility and logistics operating system, coordinating public, private, contracted and third-party vehicles through one planning and execution environment. It supported vehicle and passenger preferences, permitted and restricted access zones, time windows, CO₂ policies, service-level commitments, hard and semi-flexible rules, dynamic optimisation, incident response and continuous route reconfiguration.

The product therefore entered its European phase with substantially more evidence than an untested concept or first prototype. Its core orchestration capability has already been built and used in real operations. The current opportunity is to commercialise that capability in Europe as-is where the existing configuration fits, while adapting and extending it where local customers, regulation and integrations make this commercially advantageous.

Beyond ordinary workshop and driver management, xSeil is distinguished by the artificial-intelligence algorithms that plan routes while respecting constraints and preferences:

• which travellers may travel with which others;
• vehicle types and their usage preferences;
• the zones each vehicle type may enter, and at which hours;
• CO₂ policies;
• maximum mileage and maximum number of stops per route;
• service-level agreements and maximum tolerable delay;
• traffic congestion.

From these it builds an optimal route plan for each vehicle and revises it as events occur through the day.

Before selecting xSeil, the client studied the systems available on the market and consulted competing suppliers, concluding that xSeil fitted these particular flexibility requirements better.

Evidence from the operating product

The following images form part of the documentary evidence of the product in operation. A more detailed technical and operational case study is available in Experiencias Xcaret xSeil — Pre-Agentic Logistic Intelligence Before AI Mainstream.

The opportunity

Three structural barriers that existing carpooling models have not solved.

Private vehicles remain unused for much of the day while their owners continue paying financing or leasing, insurance, depreciation, fuel or electricity, parking and maintenance. At the same time, other users pay separately for taxis, ride-hailing, rentals, public transport or vehicle subscriptions.

High user effort

Users must normally publish each journey, negotiate stops, select passengers and agree on payment. In BlaBlaCar, for example, every trip has to be published and negotiated with each interested party, deciding stops and amounts each time. This makes carpooling suitable for occasional journeys, but difficult to use as a dependable daily mobility system.

Insufficient network availability

A shared journey may be available for a regular commute but not for an exceptional or unplanned trip. This uncertainty encourages users to retain their own vehicle even when it is underused.

Scaling complexity — and why this is the hard part

Suppose the previous barrier were solved and a large user network existed, with journeys running in every direction. The system would then have to manage thousands of concurrent routes, which could saturate the system itself.

Current logistics systems do one of two things. They plan rigid routes and timetables, like scheduled lines. Or they close transport slots on demand — Uber with passengers, Amazon with parcel delivery. If no units are available, the job is scheduled for the following day, and the model relies on self-employed drivers making an extra effort at demand peaks.

Semi-rigid policies

It becomes harder still when policies are semi-rigid — almost human considerations of the form electric cars are preferable, but… or a short travel time is preferable, but if a longer route means arriving earlier, then…

This is precisely the class of decision for which xSeil and the Car Evolution algorithms were designed.

The product and the user experience

Coordinated mobility plans, not isolated bookings.

Car Evolution is an AI-assisted mobility orchestration platform that coordinates private vehicles, shared fleets, subscription vehicles and external mobility services around the schedules and preferences of their users. A user can act as a driver, a passenger, or both, depending on the day, time or journey.

The platform analyses recurring and exceptional travel needs, user calendars, willingness to drive, acceptable detours, preferred passengers or compatibility rules, vehicle availability and characteristics, waiting-time limits, service expectations, environmental preferences, and the wider supply and demand across the network. It then generates coordinated mobility plans rather than treating each journey as an isolated booking.

For a driver

A vehicle owner can define when the vehicle is available, when they are willing to drive, maximum extra travel time, acceptable number of stops, passenger preferences, and the amount of vehicle cost they wish to recover. The driver receives a proposed departure time, route, pickup points, expected additional travel time, passenger information and estimated cost contribution.

For a passenger

A passenger defines destination, required arrival time, preferred pickup area, acceptable waiting time, recurring or one-off journeys, accessibility requirements and service preferences. For a user who prefers a chauffeur service — definable for particular hours or days — the application behaves like Uber or Cabify but with automated travel plans: the assistant indicates where to wait, which vehicle will stop, the driver’s name.

Cost allocation and settlement are handled through an integrated payment service according to the accepted mobility plan.

Dynamic orchestration

A live mobility plan, not a route calculated once before departure.

Possible events include traffic congestion, a delayed passenger, an agenda change, a vehicle becoming unavailable, a driver cancelling, a new urgent journey, weather or access restrictions, or demand exceeding available capacity.

When this happens the platform reassesses the affected journey network. It can reassign passengers, change pickup points, alter departure times, combine or separate routes, allocate another available vehicle, modify the order of stops, or activate an external fallback service.

Product architecture

Six layers, coordinating existing mobility resources rather than owning vehicles.

Control centre and policy layer

A B2B and institutional product in addition to the end-user application.

Car Evolution can provide an operational dashboard for employers, universities, municipalities, mobility operators, industrial parks, residential communities or tourism destinations.

The organisation can define priorities such as reducing emissions, reducing peak-hour congestion, maximising vehicle occupancy, prioritising electric vehicles, guaranteeing service to selected areas, minimising passenger delay, or limiting total mobility cost. The platform presents alternative scenarios and their operational consequences before a policy is activated — for example, comparing the least-polluting plan against the most punctual and the fastest.

European deployment and adaptation

A proven MVP entering its next commercial and product stage.

Car Evolution does not require a new first prototype to establish that the core product works. The product has already been tested as an MVP at operational scale and can be offered commercially as-is for defined B2B use cases, especially bus and passenger-transport orchestration.

The appropriate next step is a first European deployment inside a bounded mobility ecosystem with recurring journeys and an identifiable user community: a university or research campus, a large employer, an industrial or technology park, a residential development, a municipality with defined commuter corridors, a tourism destination, or a corporate fleet and employee-mobility programme.

This deployment can use the existing orchestration product while adding the adaptations that are commercially convenient for the selected European customer: local regulation, data interfaces, identity and payment services, privacy and security requirements, user-experience localisation, mobility-provider integration and additional capabilities. Autonomous vehicles are not required.

Business model

Recurring revenue without owning vehicles.

Scalability

Connected, bounded networks rather than immediate city-wide adoption.

Each new deployment adds users, vehicles, mobility patterns, integration partners and reusable configuration knowledge. The platform can later connect several independently operated mobility communities while allowing each one to maintain its own policies, users, data governance, service priorities and commercial arrangements.

Success metrics

European deployments should validate market fit, transferability and commercial repeatability.

Product, legal and regulatory boundary

A coordination layer, not a replacement for existing mobility services.

Car Evolution is not intended to replace all existing mobility services. It acts as the coordination layer between private vehicles, shared fleets, subscription vehicles, corporate mobility, public-transport interfaces, taxis and ride-hailing providers.

Where a journey has been committed to a passenger and an unresolvable incident occurs, Car Evolution may arrange a taxi, Uber or Cabify, with the cost prorated across all users. This collaborates with those services and provides a guarantee to users. It is a growth-phase function, to be studied and developed rather than assumed.

The model is aligned with Spain’s sustainable mobility law, which is oriented toward encouraging services of this kind in order to reduce overall transport costs and CO₂ emissions. A collaborating public entity can be given a control screen to set policies, with pre-planning showing alternative scenarios for comparison. User documentation and information are stored encrypted, for privacy and for security.

Market conditions

CO₂ reduction commitments and shifting policy leave people uncertain about which new car to buy, and increase the pressure for an effective and efficient answer.

The potential market is large. The approach here is different, the algorithm is already validated in operation, and the team has worked together on developments of this type.

Mobility Operating System: policy-driven control already demonstrated

The control centre did not merely display routes. It governed the operational rules, priorities and trade-offs under which the entire mobility network was planned, executed and reconfigured.

The description Mobility Operating System is not a new marketing label applied retrospectively to a conventional route optimiser. The xSeil architecture combined a web-based command-and-control core, mobile field execution, data integration and cleansing, operational master data, planning and optimisation, real-time monitoring, dynamic coordination, and managerial intelligence across the full passenger-transport lifecycle.

In operational terms, the control centre acted as the policy and decision layer between management objectives and field execution. It converted organisational rules, service commitments, fleet conditions and live network pressure into executable vehicle, passenger and route decisions.

Dynamic access, zone and route policies

The operating model already supported policies defining which types of vehicles could be assigned to particular hotels, services, zones, routes or destinations, and under which time or operating conditions. The underlying operational model included vehicle categories, hotel and park routes, service types, zones, transfer points, geofences, pickup windows, slow-transit periods, saturation conditions and special service rules.

These elements were not treated as passive reference data. They participated directly in feasibility and assignment decisions. A vehicle could be operationally suitable in one part of the network and unsuitable in another because of its type, role, capacity, service configuration, access policy, maintenance status, timing or the current route regime. When the state of the operation or an authorised policy value changed, the planning and coordination layers could reassess the affected assignments and route structures.

Preferences and policy values that change with the operating state

The platform distinguished between hard constraints, which could not be violated, and soft or semi-flexible policies, whose relative importance depended on the current situation. Capacity, feasibility and committed service could operate as prohibitive boundaries. Other goals — such as reducing fuel consumption, limiting stops, using a preferred vehicle type, avoiding transfers or protecting a particular punctuality measure — could become more or less important as pressure moved through the network.

This dynamic valuation is essential to the Mobility Operating System concept. Management did not have to pretend that every policy was equally important at every moment. The platform could interpret the current regime, compare the marginal operational cost of competing objectives and select an executable balance while preserving non-negotiable commitments.

A pool of simultaneous operational objectives

xSeil was designed to manage a pool of interacting objectives, not to optimise a single metric in isolation. Depending on the service and operating context, the active objective set could include:

The purpose was not to achieve a theoretical optimum for one indicator. It was to keep the complete system feasible, balanced, explainable and operationally acceptable under continuous change. Hard constraints invalidated unacceptable solutions; semi-flexible objectives were balanced according to their current operational value.

Closed-loop command, execution and reconfiguration

The control centre connected planning with actual field execution. It could compare planned routes, assigned vehicles and promised pickup times with real vehicle positions, actual boarding, observed punctuality and operational incidents. Deviations could then trigger route-sheet updates, passenger redistribution, transfer coordination, vehicle or personnel reassignment and revised execution instructions.

This closed loop is what distinguishes an operating system from a static planning application. The platform did not stop after producing a route. It maintained a shared operational state, applied policies to that state, observed execution and changed the plan when the real network diverged from expectations.

Why this matters for Car Evolution

Car Evolution carries this control-centre logic into a wider shared, corporate, urban and multimodal mobility environment. The product proposition is therefore not limited to passenger–driver matching. Its deeper capability is to allow an organisation to express mobility policies and objectives, evaluate alternative network configurations, execute the selected plan and adapt it as demand, vehicles, incidents and priorities change.

Technical basis: JUBAP.Net © xSeil Whitepaper — Experiencias Xcaret Logistics.

From underused vehicles to one adaptive network