What you'll learn: how to run the seven-step design drill on a document-processing brief: why arithmetic and matching belong in code, how a review queue sets the automation level, and how a scored answer looks.
At a glance
Figure 1. The drill: seven outputs in 30 minutes
How to read this: the same four timed boxes as the blank-page defense.
- The model reads the document; code checks the numbers and matches the order.
- Text inside a document is data, even if it says "pay this account".
- A claims intake has the same shape: a claim form instead of an invoice.
Scenario
Composite scenario, not a real company. Quillfield Distribution has 9 accounts-payable clerks and about 6,000 supplier invoices a month (illustrative), arriving as PDFs by email. About 20 percent are scans, and about 400 suppliers use different layouts.
Clerks key the supplier, invoice number, date, purchase-order (PO) number, lines, tax and total into the ERP system (enterprise resource planning software) and match each invoice to its PO. Month-end creates a backlog; wrong amounts and duplicate payments have occurred. The finance director wants less keying and earlier detection of mismatches, with nothing above a set limit posted unreviewed.
What you will be able to do
- Run the seven-step drill on a document brief.
- Separate what the model extracts from what code verifies.
- Set automation from measured accuracy.
Prerequisites
- The blank-page design defense, for the timed flow and the rubric.
- The pattern catalog: understand (extraction), answer (pipeline), act (batch, review queue).
Core ideas
The seven-step checklist for documents
| Step | What is hard here | Usually fits |
|---|---|---|
| 1. Frame | The error rate today is unknown; some suppliers may send structured files, needing no model | Measure first; ask which suppliers can send data |
| 2. Requirements | Scans, 400 layouts, month-end peak, audit trail, bank details | Batch processing with a per-document status |
| 3. Patterns | Extraction is probabilistic, checks are not | Document-processing pipeline; structured extraction; review queue; batch |
| 4. Architecture | A posted payment cannot be recalled | Post only after checks pass or a clerk fixes the invoice, with an idempotency key; approval above the limit |
| 5. Evaluation | Field accuracy differs by field and by supplier | Field-level labels; error rate of the auto-accepted set |
| 6. Threats | Text in an invoice can address the model; changed bank details can redirect payment | Schema-only output; bank changes never taken from extraction |
| 7. MVP (smallest first release) | Posting is the risky step | Extraction and review first, posting later |
In the interview: "How do you decide what is automatic?" Good: measure per-field accuracy, pick the threshold where the accepted set's error rate meets the business limit, keep sampling.
Worked example
Attempt the drill first, then open the answer.
Open after your attempt: the model answer and its score
Frame. Outcome: share of invoices posted without keying, and wrong-amount postings (target zero). Collect today's error and duplicate rates first; suppliers that can send structured files skip the model.
Requirements. About 270 invoices a working day (illustrative). Users: 9 clerks, a finance approver. Data: PDFs, PO table, supplier master. Out of scope: payment runs.
Patterns. Document-processing pipeline: schema-bound extraction, code checks, a review queue, asynchronous batches. Discarded: one model call that reads and posts (no check before paying) and manual keying (no saving).