Expense reports, governed
A deliberately ordinary example. The same pattern applies to purchase orders, claims, access requests or any process with rules and approvals.
The model

The rules
| Rule | Severity | What happens |
|---|---|---|
| Receipt required over 25.00 | BLOCK | The line cannot be submitted without a receipt |
| Meal over the daily cap | WARN | Submission proceeds, flagged for the approver with a reason |
| Approver is the submitter | BLOCK | Approval is refused and routed to someone else |
| Cost centre is inactive | BLOCK | The charge cannot be posted |
Walkthrough
An agent drafts a report
It reads the employee, trip and receipts, and builds line items through the harness.
Dry run
The harness shows what would change and which rules would fire. Nothing is written yet.
Checks
A taxi line of 38.00 has no receipt. BLOCK. The agent is told what is missing and attaches it.
Approval and execute
A meal over the cap goes through with a WARN. The approver sees it, approves, and the report posts.

Changing a rule is a data edit
Finance moves the receipt threshold from 25.00 to 50.00. A steward edits the rule with an effective date and a reason, and a second person approves. The new version applies from that date. The old version stays on record, so a report from last month is judged against what was true last month.
What the auditor sees
For any report: who or what created it, each dry run, every rule that fired, the approver, the exact rule versions in force and the final write, in a hash-linked chain.
Put a boundary around what your agents can do
We are onboarding a small group of early access teams. Tell us what you want to ground, automate or audit.
Request early access