Policy and Compliance
Your rules, enforced — not your team chasing exceptions.
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
A rule engine built for "our situation is different."
Every organisation's travel rules are different, and the difficult ones are not 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
Part of the booking flow, not a separate email thread
Role-based, on any device, with approval state tracked as part of the trip record.
Real-Time Spend
Finance works from the same data as operations
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.
Expense
Booking and expense in one platform, 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
Duty of care: know where your people are when something goes wrong
A single source of truth across all transport modes is the foundation duty of care depends on.
Rationing Mechanisms
Price, authority, or entitlement — something has to say no.
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.
UnityTrip's rule engine executes all three mechanisms in one model. The two channels, the single test that separates them and the two chokepoints that enforce them are set out in full on the category page.
Determinism
Deterministic on purpose — especially in an agentic world.
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 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 AI layer in practice: walkthrough videos with transcripts →
Audit
Reproducibility, not accuracy, is the standard
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
A booking decision is 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
Flagged gaps, human judgment
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 human judgment, such as compassionate grounds or manager discretion, route to a person with the source clause attached.
Common questions
How does UnityTrip enforce a corporate travel policy?
UnityTrip includes a configurable rule engine that enforces travel policy at the point of booking, not after the fact. Approval limits, spend caps, preferred suppliers, booking windows, and complex payout rules are applied automatically — so the team isn't left chasing exceptions.
Does UnityTrip combine booking and expense in one system?
Yes. Booking and expense claims run in one platform with one login. Every booking and claim is an event, so spend is visible in real time and traceable to a cost centre and activity, and custom payout rules are handled in the same engine that governs bookings.
Can an AI agent or LLM approve business travel bookings?
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.
Why does travel-policy enforcement need to be deterministic?
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.
What happens when a policy clause cannot be expressed as a rule?
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, such as compassionate grounds or manager discretion, route to a human approver with the source clause attached. A visible gap is a better failure mode than silent omission or improvisation.