The Platform Thesis

The interface is a projection of the model.

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

Customisation is configuration of the model — not changes to the software.

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. The distinction matters more than it sounds: customisation as code changes builds a moat that becomes a trap — installations so bespoke they can no longer be upgraded or moved. Customisation as configuration keeps the moat and loses the trap.

The distinction has a supply chain on each side. Traditional customisation turns a requirement into bespoke code — developers, testing, deployment, and maintenance for as long as the client lives. UnityTrip turns the same requirement into policy and configuration executed by the deterministic engine. The first destroys scalability; the second builds scalability out of complexity. So when a prospect says "our operation is unusual — nobody does travel like us", a conventional vendor hears an expensive implementation. This platform was built to hear an advantage: the unusual rules are exactly the ones generic products leave offline, and here they are expressed in the model rather than in code. Tell us how your company actually works. We'll turn it into 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.

Why Travel First

The hardest coordination problem was the point.

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:

Discipline

The architecture generalises. The company is travel-first.

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. UnityTrip is the software layer that turns the way an organisation moves people into executable, auditable operations. Workforce aviation logistics is the beachhead — the hardest case, deliberately chosen.

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.

The Economics

Why the wrong model compounds.

Corporate travel software is not broken because its screens are dated. It is broken because the underlying model is wrong — and a wrong model makes the cost of every transaction compound as requirements grow and change.

When a platform built on city pairs and fares tries to express a leased aircraft, a chartered vessel, or a camp transfer, it does not fail loudly. It fails silently: the complexity is pushed into middleware, spreadsheets, and manual reconciliation. The cost never appears on the travel ledger — it accumulates in the integration layer, the exception queues, and the billable hours spent keeping the glue alive.

In a fare-based system, the transaction cost is a booking fee. In workforce logistics, the real transaction cost is the cost per exception: a policy exception, a mode change, a cost-centre reallocation, a no-show that should have triggered a standby traveller. Each one requires human intervention when the model cannot express the rule. Because UnityTrip's policy engine executes the tenant's model deterministically, the marginal cost of policy enforcement falls toward zero — and stays there as the business changes, because change is configuration of the model, not a new integration project.

That is what event sourcing and a canonical model buy: not elegance for its own sake, but a cost per transaction that survives change. The architecture page shows the machinery; the spend diagnostic measures what the silent failure is currently costing.

Delivery Modes

One model, two ways to run it.

The canonical model does not dictate how it is operated. UnityTrip delivers it in two modes, and the right one is set by the operating environment — not by size or ambition.

These are stages on one path, not competing products: the idea is to take an operation from fire-fighting to calm. Both modes speak the same canonical model — the same concepts of priority, quotas, claims, and travel groups — so an operation can start service-led while conditions are unstable and, when there are sound reasons for the change, graduate to governed platform delivery as a planned migration. The policy and operating rules carry across; the move is a scoped project, not a rewrite, and the conversation never starts over. Consulting and configuration services accompany both.

Common Questions

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.