Policy as evaluable rules, approval routing that matches the org chart, spend and compliance reporting that names the broken rule.
A company had a travel policy PDF and a bookings inbox. Policy said class of travel, advance-purchase windows, preferred suppliers, and who must approve above a threshold. Reality was email. We built a platform where a request is checked against rules before it becomes a booking, then routed, then reported. Same “do not invent compliance” habit as the rest of our compliance software — here the artefact is a trip, not a CoA.
Rules are data: fare class by duration, caps by grade, hotel nightly limits by city band, alcohol, personal deviations. A request evaluates to allow, allow-with-exception, or block. Exceptions require a reason code. We did not bury rules in if-else scattered across UI components; the engine returns a structured verdict the UI only displays.
Routing follows cost centre and amount, not “email your manager.” Deputies exist. A request cannot skip a step by editing the payload after submit — the approval snapshot stores the verdict and the rule versions. That is the audit.
Finance sees spend by cost centre and the count of exception codes. Compliance sees which rules fired and which were overridden. A trip that bypassed the engine does not appear as “compliant.” Related pattern: evidence and exceptions in document intelligence.
We will say which rules can be evaluated and which are still human judgement.
→ Book a call