The Platform Thesis

The interface is a projection of the model.

UnityTrip maintains one canonical model of workforce movement: 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. What workforce aviation logistics is, and is not, is defined on the category page.

Engagements are expertise first: a review reads the record you already hold, read access only, people who have run workforce aviation diagnose it, and the treatment executes in the platform, the system that holds the record. That is the end of the Enterprise AI loop where credibility is decided, because it needs a system that holds the authoritative record and a person who ran the operation to say no to the confident wrong recommendation, not the crowded end that only diagnoses. How a review runs · How this differs from process intelligence

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 and where its budgets attach. Two tenants can look like two different products while running the same continuously improved codebase, because what differs between them is the model, not the software. Customisation as code 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. Why configuration survives the moves that break code is set out in The second shift.

When a prospect says its operation is unusual, a conventional vendor hears an expensive implementation. The unusual rules are exactly the ones generic products leave offline, and here they are expressed in the model, not in code; why that is the advantage is set out on the investors page. Tell us how your company works and we will turn it into configuration.

This is why screenshots carry so little information here: a screen capture of one tenant tells you almost nothing about another. The artefacts that carry the information are the ones we publish: the API and ontology reference, the policy JSON Schema and the architecture that executes them.

It is also 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 has 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; the platform is built to outlast its first vertical. UnityTrip is nonetheless deliberately a workforce travel company: own the hardest coordination problem first, prove the ontology under production load, and earn each measured outcome before widening the aperture. Workforce aviation logistics is the beachhead, the hardest case, deliberately chosen. What an operator buys today is that focus.

Scope

The traveller-touch test: what belongs inside, and what does not.

Three sets of systems run an operation that moves people: workflow and operations, finance, and regulation. UnityTrip joins the first two and interfaces to the third. The test for what belongs inside the platform is whether it touches a traveller: directly, like a seat on a leased aircraft; indirectly, like a bed in a guesthouse; or through the systems that carry the traveller's record, the ERP and the GDS. What passes the test is modelled as one record: a single traveller truth, from request to booking to claim to posting.

What fails it stays in the silo built for it, and UnityTrip interfaces rather than absorbs: aircraft maintenance, airworthiness regulation, flight-and-duty limits and fatigue management. Even finance is seen through workflow eyes: UnityTrip carries its own travel ledger, which either holds the authoritative books or shadows the accounting system's through daily balances, and it keeps booking when that system is down, because a booking cannot wait for the ERP. Where the customer runs a ledger of record such as SAP, it stays the master ledger. Which case a client is in, and where its budgets attach, is set out in UnityTrip and SAP: a single source of truth. UnityTrip's own record is immutable by construction, so the platform cannot control the ledger, but it can always prove what the ledger said and what it was sent.

See the systems UnityTrip connects to and how it works with SAP S/4HANA.

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 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. The operational consequences, from the pace of change to what happens when an upstream system fails, are answered in questions from operations teams.

Service-led delivery is the earlier stage on the path to platform delivery. For an operation whose requirements arrive daily as line items, UnityTrip runs the platform for the client, with the capacity to surge when the operation needs it: forty production changes have shipped in a single week. What is structurally a project is named as one, and both stages run the same canonical model, so the policy and operating rules carry across as a planned migration. Consulting and configuration services accompany both stages.

That is what event sourcing and a canonical model buy: a cost per transaction that survives change. Why that measure has become the deciding one is the subject of The second shift.

Revenue management and revenue accounting

Yield and money for the same seats, in one record.

A fleet without fares still has yield to manage and money to account for. Seat allocation by entitlement is revenue management without price: priority, quotas, booking windows and go-shows decide who flies and keep the aircraft full. Value lines frozen at booking, liability held until flown, penalties earned, refunds per passenger per segment, cost reversals to the ledger of record: that is revenue accounting for the same seats. In UnityTrip both run on one data repository, and airline revenue-management and revenue-accounting experience sits on the team that reviews it. The allocation model is set out in the seat allocation guide; the accounting model in the cancellations and refunds guide.

Common Questions

See the Model

The thesis is checkable: the ontology is documented, the policy schema is published, and the platform is in production.