From English Policies to Executable Rules
Key Concept
Policies written in English are suggestions. Policies written as rules are how your systems learn to behave.
Dual-Language Policy: The same rule expressed in two forms—one for humans to understand the reasoning, one for machines to enforce automatically.
Figures (Full Resolution)
Figure 4.1: Invoice Approval Dashboard
The manager’s view of Invoice #4847 in the approval queue. Three policy findings flagged: missing business purpose, amount exceeds auto-approval threshold, and documentation deadline approaching.
Figure 4.2: n8n Automation Workflow
The automation workflow that syncs invoices from QuickBooks, evaluates them against policies, and routes exceptions for human review.
Figure 4.3: OPA Policy Evaluation
How the policy engine (Open Policy Agent) evaluates an invoice against your rules and returns findings.
Figure 4.4: Dual-Language Architecture
The architecture of dual-language policies: English policies translate to executable rules that the policy engine evaluates automatically.
Figure 4.5: Invoice Approval Queue Flow
How Invoice #4847 flows through the approval queue—from entry to policy evaluation to manager review to final approval.
Downloadable Resources
Policy Templates
- Policy-to-Rule Translation Cheatsheet (PDF) – Convert your English policies to executable rules
- Sample Dual-Language Policy Document (PDF) – Complete example with both human and machine versions
Implementation Guides
- Invoice Approval Policy Template – Ready-to-customize approval thresholds
- Documentation Requirements Policy – What documentation is required and when
Understanding the Invoice #4847 Example
Throughout this chapter, we follow Invoice #4847 from ABC Office Solutions. Here’s what the policy evaluation found:
| Finding | English Policy | Executable Rule | Status |
|---|---|---|---|
| Missing business purpose | “All expenses must have documented business purpose” | IF invoice.business_purpose IS NULL THEN flag |
Flagged |
| Exceeds threshold | “Invoices over $2,000 require manager approval” | IF invoice.amount > 2000 THEN require_approval("manager") |
Routed |
| Documentation deadline | “Documentation required within 10 days” | IF days_since(invoice.date) > 7 AND NOT documented THEN warn |
Warning |
What the Manager Sees
When Invoice #4847 lands in the approval queue, the manager sees: – Invoice details: Vendor, amount, date, line items – Policy findings: Specific issues requiring attention – Action options: Approve, reject, request more info – Context: Why this invoice was flagged (not just “needs approval”)
This is the power of dual-language policies: the manager has context, not just a list of invoices to rubber-stamp.
The 10-Day Documentation Window
One of the most powerful executable rules is the documentation deadline:
English Policy:
"Business purpose and supporting documentation must be
provided within 10 business days of the transaction date."
Executable Rule:
IF transaction.date + 10_business_days < today
AND transaction.documentation_status != "complete"
THEN alert_owner AND flag_for_reviewWhy 10 Days?
| Timeframe | Memory Accuracy | Documentation Quality |
|---|---|---|
| Same day | 95%+ | Excellent |
| Within 3 days | 85-90% | Good |
| Within 10 days | 70-80% | Acceptable |
| 30+ days | 40-50% | Poor |
| Year-end | 10-20% | Guessing |
The 10-day window catches documentation while memory is fresh—not at year-end when you’re reconstructing from credit card statements.
Don’t Worry About the Code
Important: You don’t need to write code to benefit from dual-language policies.
The code examples in this chapter show what’s possible—they’re the “machine” side of dual-language policies. Your job is:
- Define the English policies – What rules should govern your business?
- Work with an implementer – They translate to executable rules
- Review the results – Are policies being enforced correctly?
Think of it like hiring an electrician: you decide where you want outlets, they handle the wiring.
Real Results: Case Study
Client: Regional professional services firm, 45 employees
Before Dual-Language Policies: – 23% of invoices missing business purpose at year-end – Average 47 days between transaction and documentation – 180+ hours of year-end cleanup
After Implementation: – 3% of invoices missing business purpose (caught within 10 days) – Average 4 days between transaction and documentation – 12 hours of year-end cleanup
Key Change: The 10-day documentation window caught issues while memory was fresh. Problems surfaced in days, not months.
Key Takeaways
- Policies that sit in binders don’t work – They depend on human memory
- Dual-language bridges the gap – Same rule, two expressions
- Machines enforce, humans decide – Automation catches issues, people make judgments
- The 10-day window is powerful – Catch documentation gaps while memory is fresh
- You don’t need to code – Define the policies, let implementers handle the rules
Your Next Step
Take one policy you already have (even if unwritten) and try expressing it as an executable rule:
Example: – English: “Large purchases need owner approval” – Executable: IF purchase.amount > [threshold] THEN require_approval("owner")
What’s your threshold? $500? $1,000? $5,000? Defining this is the first step.
Want help translating your policies? Apply for a complimentary Tax Ready Assessment