Policy & 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 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.

Approvals

Part of the booking flow, not a separate email thread

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

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. Finance works from the same data as operations.

Expense

Booking and expense in one platform, one login

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

Duty of care: know where your people are when something goes wrong

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.

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 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

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 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

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 route to a human approver with the source clause attached. A visible gap is a better failure mode than silent omission or improvisation.