THE DESIGN QUESTION
Rule checks and human decisions.
In a review workflow, a fast answer is not enough. The reviewer needs to know which source rule applies, what evidence is present, what is missing, and who made the final decision. This exercise explores that separation of responsibilities.
FICTIONAL DISCOVERY BRIEF
Define the reviewer decision.
This is a constructed scenario, not a record of client interviews. The exercise assumes a reviewer needs faster evidence triage, a policy owner needs consistent rule handling, and a risk lead needs to see where human judgment enters.
What needs another look?
Surface missing evidence and applicable rules so the reviewer can request more information, escalate, or make a documented decision.
Three fictional records.
Three fictional records, three deterministic rules, and no model call, client data, automated approval, or durable storage.
Observable behavior.
Each record produces its expected rule result; every result identifies the rule; even an all-pass record requires a reasoned human decision.
A real pilot would also need agreement on policy ownership, reviewer roles, data retention, accessibility, and evaluation before connecting to any live system.
THE SYSTEM
Record to reviewer decision.
Amount, receipt, approval, and purpose.
Three inspectable policy checks.
Pass or gap, each tied to a rule ID.
Action and written rationale, held until page reload.
The rule-based assistant can surface gaps; it cannot approve or deny. The reviewer can approve, request evidence, or escalate, and must write a reason.
ARCHITECTURE DECISIONS
Rules and reviewer control.
Show rule IDs and evidence.
Deterministic checks expose the rule ID and gap. They are easy to test, but they cannot interpret ambiguous documents or establish real-world policy accuracy.
Keep approval with the reviewer.
The tool reports evidence status; a person selects an action and writes a rationale. The prototype has no identity, authorization, or durable audit trail.
Use repeatable fictional cases.
Three invented records avoid client data and make expected outcomes repeatable. They are acceptance examples, not a representative evaluation dataset.
POC ACCEPTANCE CHECKS
Three acceptance examples.
Each fictional record has an expected result. These checks exercise the rule engine without pretending to measure review quality or business impact.
- 01 / EX-1042P-02 gap
High amount, no manager approval
The $318 record has a receipt and purpose, but lacks approval.
- 02 / EX-1043P-01 gap
Missing receipt
The $74 record has approval and purpose, but no receipt.
- 03 / EX-1044Human review
Evidence present
All three checks pass. A person still makes and explains the decision.
Unit tests also check the exact $50 receipt boundary, an amount just above the $250 approval boundary, and a blank business purpose. They test deterministic rules only—not accessibility, security, model quality, or production readiness.
WHAT THE ARTIFACT PROVES
What the demo demonstrates.
You can switch cases, inspect each policy result, and record a decision with a reason. The demo does not prove production suitability, reduced review time, model quality, or client outcomes. It is an independently authored portfolio exercise, developed with AI assistance rather than a prior engagement.
Try the working demoIF THIS BECAME A REAL PRODUCT
Requirements for a real pilot.
A next iteration would need authenticated reviewers, durable decision history, versioned policy, test fixtures, accessibility review, and a measured evaluation plan. Model-assisted document extraction could then be introduced upstream, with source citations and human confirmation before any decision.