DocTriage is a document-processing and decision-support system that automates the intake and eligibility checking of loan applications for a community no-interest lending program — NILS, the Australian not-for-profit microfinance model. A caseworker opens a structured, cited result instead of a folder of raw PDFs.
The Problem
Caseworkers manually review a large document pack per applicant — identity documents, income statements, bank statements, rent ledgers, utility bills, credit reports, and a supplier quote for the item being financed — against a detailed eligibility handbook. The work is slow, repetitive, and error-prone, and it is the bottleneck between an application arriving and a decision being made. Every hour spent re-reading a PDF is an hour not spent with the applicant.
Architecture & Technical Design
The pipeline is a set of containerised services chained by an n8n orchestrator:
- Native-text PDF extractor: digit-perfect text extraction from PDFs that carry a real text layer. No GPU required, and no OCR error introduced where none is needed.
- Vision-OCR service: a GPU-backed vision model for images, screenshots, and scanned PDFs with no text layer. The orchestrator routes per file type and checks the service is warm before starting a batch.
- Document classification: each file in the pack is identified by type, then handed to the field extractor matched to that type.
- Rules & triage API: extracted fields are evaluated against the program's eligibility criteria, encoded as versioned decision tables. Each rule cites its source in the lending handbook, so any outcome can be traced back to the policy that produced it.
- Confidence grounding: every extracted value is verified against the document's own text. Anything the system cannot ground is flagged for human confirmation rather than trusted silently.
- Review console: the caseworker sees the triage outcome, the per-category findings, the extracted values beside their source documents, and an explicit list of what still needs a human.
- Evaluation store: system decisions are compared against the human reviewer's decisions, so accuracy is measured rather than assumed.
Key Design Decisions
- It never auto-approves. The system produces a recommendation and the evidence behind it. The lending decision belongs to a person, and the interface says so on every case: “Automated recommendation only — the final decision is yours.”
- Rules live in decision tables, not in prompts. Eligibility criteria are versioned data, not model behaviour. They can be reviewed, diffed, and audited by the people who own the policy — and changing a rule does not mean re-engineering a prompt.
- Grounding over trust. An extracted value that cannot be matched back to text in the source document is surfaced as low-confidence rather than passed downstream. The failure mode is “ask a human”, not “guess confidently”.
- Privacy is architectural, not procedural. Inference runs locally; real applicant data never leaves the environment. Development and testing run entirely on synthetic applicants, and only de-identified evaluation data is persisted. Structured identifiers are masked by default in the console and revealed only on an explicit click.
- Serial by design. The parser holds a single GPU model slot, so applicants and documents are processed one at a time. Running them in parallel only queues work and risks timeouts — throughput came from removing redundant OCR, not from fan-out.
- Failures degrade, they don't abort. A document that cannot be read produces an explicit “unknown” entry and routes to human review. One bad file never takes down the whole applicant's run.
What the Caseworker Gets
A triage outcome — proceed, request documents, decline, or waitlist — with human-readable reasons, a per-category breakdown of what passed and what needs checking, and a “needs human review” list. Each finding links to the document and the extracted value behind it, so verifying the system is faster than redoing its work.
Status
Validation phase. The pipeline runs end to end on synthetic applicants while the decision tables are tuned against real human-reviewer outcomes held in the evaluation store.
How it works — animated explainer
