Policy & Compliance
The hardest part of corporate travel isn't booking. It's making thousands of bookings follow policy, stay in budget, and produce data finance can trust.
UnityTrip's rule engine executes an operational ontology — a structured, machine-readable model of your operation that is the contract between natural-language policy and executable logic.
Rule Engine
Every organisation's travel rules are different, and the genuinely difficult ones are never in an off-the-shelf product. UnityTrip's rule engine absorbs whatever yours are — from standard policy and approval limits to the unusual: a warm-clothing subscription for crews heading to cold sites, spectacles for staff and their families claimed as travel, payouts tied to your own rotation cycles. If you can describe the rule, it goes in the engine, configured per organisation and applied at the point of booking. When it changes, it deploys without downtime. And once an operation's rules are in the platform, they stop being unusual: they become configuration, policy, and data, executed as reliably as anyone else's.
Approvals
Pre-trip approvals are part of the booking flow, not a separate email thread; role-based, on any device; approval state tracked as part of the trip record.
Real-Time Spend
Every booking and claim is an event, so spend is visible in real time and traceable to a cost centre and activity — not reconstructed from spreadsheets. Finance works from the same data as operations.
Expense
Booking and expense claims run in one platform with one login; the reasons travellers claim reimbursement are captured at source; custom payout rules are handled in the same engine that governs bookings.
Duty of Care
When you know where your people are and how they're travelling, you can act when something goes wrong. A single source of truth across all transport modes is the foundation duty-of-care depends on.
Rationing Mechanisms
When demand exceeds seats, every travel channel needs a mechanism that says no. There are three. Commercial travel rations by price: the fare is the gatekeeper. Business travel rations by authority: an approver holding delegated financial authority says yes or no to each request. Entitlement travel — leased aircraft, vessels, and vehicles carrying private and subsidised journeys — rations by quota: the rules grant the seat, sanctions protect the rules, and there is no approval step at all.
The channel names an organisation uses are arbitrary; the mechanism is what matters. A subsidised booking with no approval step behaves as entitlement travel whichever budget funds it — a channel is what it does. This is why priority replaces price is a theorem rather than a slogan: when price cannot ration, something else must, and the policy has to say precisely what.
Inside a workforce operation, price drops out of the picture entirely: there are two governed channels, and the axis between them is one question — approved, or not. Commercial content, whatever booking tool or provider it comes from, is not a channel; it is content that lands in one of the two. The fare prices the seat; it does not govern the seat. And "not approved" never means denied: the entitlement channel is auto-approved, in the precise sense that no approver intervenes — quota, entitlement, or the traveller's own payment says yes, deterministically. Which reasons require an authority is itself configuration: one operation runs medical travel auto-approved with unlimited quota so nothing impedes organising a medevac; another could route it through approval. The test is universal; the mapping is per-tenant policy. The consequence buyers ask about first: friction is derived rather than imposed — medical travel is frictionless because safety outranks process, private travel is frictionless because no company money moves, and business travel carries the full claim machinery because company money does. The platform adds exactly as much process as your money and your safety already require, and none elsewhere. Modelling this correctly — channels defined by mechanism, content source kept orthogonal — is the understanding the platform is built on.
Most corporate travel software models price and a thin layer of authority. UnityTrip's rule engine executes all three mechanisms in one model — approval chains for the business channel; priority matrices, quotas, and sanctions for the entitlement channel — which is what lets one platform govern a workforce operation's whole travel program rather than only its commercial slice. The glossary entry defines the mechanisms; the Policy Builder writes the entitlement rules.
Determinism
AI is changing how travel gets booked — agents will shop, compare, and request on a traveller's behalf. It does not change what a booking decision is: live state and exact arithmetic under rules that must hold up to audit. UnityTrip's doctrine is frontier AI at build time, determinism at run time. AI amplifies the consultancy that designs and configures the policy; the engine that decides bookings stays deterministic; an agent is just another client of it. The engine's service surface — validation, quotas, penalties, segment release — is documented in the API and ontology reference.
See the knowledge layer in practice: corporate travel's AI shift →
Audit
Auditors, insurers, and regulators rarely ask how accurate a system is. They ask whether you can reproduce and explain a specific decision from a year ago. A compiled, versioned ruleset answers permanently — this booking was approved because this rule of this policy version applied. A model interpreting documents at booking time cannot: change the model or the document, and the past decision is gone.
State and Arithmetic
An approval is live state and exact maths: eleven of twelve annual quota used, day 34 of a 35-day booking window, whether this traveller is currently banned. Language models are unreliable at counting and date arithmetic — a model deciding at booking time would still need a deterministic state layer underneath, adding an unexplainable layer on top of the engine rather than replacing it.
Visible Gaps
When a policy clause cannot be expressed as a rule, UnityTrip flags it rather than silently dropping it — the gap is a visible artifact the organisation signs off, not an omission or a model's improvisation. Clauses that are genuinely human judgment, such as compassionate grounds or manager discretion, route to a person with the source clause attached — because no engine should be computing them.
Common Questions
Not reliably, and not auditably. An approval decision needs live state and exact arithmetic — quota counters, booking windows, ban status — which language models are unreliable at, and it needs to be reproducible a year later, which a model interpreting mutable documents cannot offer. The workable pattern is different: AI helps author and configure the policy, agents request bookings as clients of the platform, and a deterministic engine decides — identically every time, with the rule that decided it attached.
Because the questions that matter afterwards are audit questions, and the costly errors are the tail cases — two key personnel on the same aircraft, a banned traveller boarded. A versioned, deterministic ruleset reproduces any past decision with the exact rule and policy version that applied. A system that is usually right but cannot explain itself is not an answer an audit accepts.
It is flagged, not dropped. Clauses the engine cannot express are reported at configuration time, so the organisation sees exactly what is and is not enforced — and clauses that are inherently human judgment route to a human approver with the source clause attached. A visible gap is a better failure mode than silent omission or improvisation.