The Platform Thesis
UnityTrip maintains one canonical model of workforce movement — across commercial, leased, and chartered aircraft, vessels, ground transport, and accommodation, with entitlements, quotas, booking events, approval chains, and cost attribution as first-class concepts. Every screen a user touches is a projection of that model; every booking is an event in its record; every decision is the model executed deterministically.
That makes UnityTrip a different kind of company than the travel vocabulary suggests: an ontology-driven, event-sourced coordination platform whose first and deliberate vertical is workforce travel. This page states the thesis plainly — what the model is, why each tenant gets its own, and why travel came first.
One Codebase, Many Ontologies
Each tenant runs its own configured ontology: its transport modes and assets, its priority matrix, its quotas and booking windows, its organisational units and approval chains, its cost-attribution rules. Two tenants can look like two different products — different modes, different rules, different structures — while running the same continuously improved codebase, because what differs between them is the model, not the software.
This is also why screenshots carry so little information here. A screen capture of one tenant tells you almost nothing about another; the artefacts that do carry the information are the ones we publish — the API and ontology reference, the policy JSON Schema, and the architecture that executes them.
And it is why onboarding is measured in weeks: bringing a new operation onto the platform means configuring its model, not commissioning a software project. The Policy Builder is that idea made public — an operation's rules assembled into one pre-deconflicted, machine-precise document.
Agentic AI, Governed
AI agents are clients of the ontology, not owners of it. An agent can converse with a traveller, assemble a request, and propose a booking — but the decision is made by the deterministic policy engine executing the tenant's configured model, the same way for an agent as for a human at a browser. That is a governance model, not a feature: agentic convenience at the edge, auditable determinism at the core, and no AI guessing at booking time.
See deterministic on purpose and the walkthrough videos of an agentic booking governed by the engine.
Why Travel First
Workforce travel on owned and leased transport is a stress test with five properties that break conventional software — and prove a coordination model that survives them:
A seat on a leased aircraft is non-fungible and perishable — flown empty, it is money burned, and it cannot be inventoried for tomorrow. The model has to allocate under genuine scarcity, which is why policy, not price, rations demand.
GDS content, ERP postings, fleet schedules, accommodation, payments — each with its own data model. Coordination across them is the product, which is why integration is the architecture rather than an add-on.
Priority matrices, quotas, booking windows, penalty points, safety and compliance requirements — no two operations share them. Rules this varied either become a per-client software fork or a configured model. We chose the model.
A schedule change or crew rotation generates 10–1000x normal load in minutes. Event-sourced, queue-and-stream architecture absorbs what batch systems cannot — and the surge day is the day that decides renewals.
Utilisation, no-show rates, onboarding time — hard numbers, published: ~40% to around 90% seat utilisation, no-shows cut by roughly half, onboarding in about six weeks. A coordination thesis that cannot be measured is a slide; this one is a record.
Discipline
A canonical model of movement, executed deterministically over an event-sourced record, is not inherently a travel idea — and readers of the architecture page sometimes notice that before we say it. We are saying it here so nobody has to infer it: yes, the platform is built to outlast its first vertical.
The discipline is the other half of the thesis. UnityTrip is deliberately a workforce travel company: own the hardest coordination problem first, prove the ontology under production load at enterprise scale, and earn each measured outcome before widening the aperture. What an operator buys today is that focus — and what the model learns serving it.
Common Questions
No. UnityTrip is an ontology-driven, event-sourced coordination platform whose first and deliberate vertical is workforce travel. The travel vocabulary — bookings, PNRs, seats — describes the current projection of a more general capability: a canonical model of workforce movement across commercial, leased, and chartered transport, configured per tenant and executed deterministically. Travel is the beachhead because it is one of the hardest coordination problems an enterprise runs, with measurable outcomes.
UnityTrip serves enterprises whose contracts include strict confidentiality provisions, so we publish measured capability figures without attribution rather than named case studies. The evidence takes a different form: published outcome figures, a documented API and operational ontology, a public policy JSON Schema, a live status page, and an architecture described in enough depth to be checked.
The product is not a set of screens with settings. UnityTrip maintains a canonical operational model — transport modes, entitlements, quotas, booking events, approval chains, cost attribution — and every surface a user touches is generated from that model. Two tenants can run different transport modes, different priority rules, and different organisational structures on the same codebase, because what differs between them is the configured ontology, not the software.
Yes — that is the design centre. Each tenant runs its own configured ontology: its transport modes and assets, its priority matrix, quotas and booking windows, its organisational units and approval chains, its cost-attribution rules. Because customisation is configuration of the model rather than changes to the software, onboarding is measured in weeks, and every tenant stays on one continuously improved codebase.
As clients of the ontology. An agent can converse, propose bookings, and assemble requests, but every decision is made by the deterministic policy engine executing the tenant's configured model — agents propose; the engine decides. That is a governance model: agentic convenience at the edge, auditable determinism at the core.
See the Model
The thesis is checkable: the ontology is documented, the policy schema is published, and the platform is in production at enterprise scale.