Choose One Document Family and System Boundary

What you will complete

Complete the scope, responsibility, prerequisites, exclusions, baseline, and go, repair, or stop decision for one document family.

Start with the business handoff

A document-processing system receives a file, prepares information for a decision, and hands an approved result to another person or system. That description is still too broad for implementation. A usable boundary names the start event, supported family, required result, accountable reviewer, controlled destination, and actions that remain outside.

Use this pattern: “We receive [document family] through [channel], prepare [fields or status] for [reviewer], and create [non-final destination] only after [decision].” A boundary such as “automate documents with AI” cannot be tested. “Receive domestic supplier invoices in one inbox and create one accounting draft after approval” can.

Watch someone process several recent examples before freezing the scope. Record where the original lives, what values are copied, what lookups occur, why work stops, who resolves exceptions, and what proves the handoff completed. If nobody owns approval or the destination object is unknown, repair that process before automating it.

Decide whether this is an extraction problem

Low volume, one stable layout, or an ownership bottleneck may need a parser, tracker, or clearer procedure rather than intelligent document processing. Mixed types, changing layouts, typed fields, confidence routing, and repeated review can justify a document-understanding layer. The course does not force that choice. “Keep the manual process” is valid when the proposed system adds cost without resolving the constraint.

Separate processing from storage. A document-management system can preserve files, versions, permissions, and retention. Processing uses information inside the file to move work. Agree where originals and approved records live before joining those responsibilities.

Worked example: Cedar & Quay invoice intake

Fictional example: Cedar & Quay Fabrication Ltd is a fictional Toronto manufacturer. It receives domestic CAD supplier invoices in one shared inbox. An accounts-payable reviewer checks exceptions and approves a draft accounting record. Contracts, credit notes, supplier creation, bank-detail changes, final posting, payment, refunds, and multi-entity accounting remain outside the first release.

The continuing invoice is fictional INV-TP-2401 from Ridgemont Industrial Supply Co. It shows a CAD 400.00 subtotal, CAD 52.00 tax, and CAD 452.00 total. These values teach arithmetic and control behavior. They are not customer data, tax advice, or a measured Flowgrammer result.

Cedar & Quay records its current monthly volume, active handling minutes, elapsed approval time, common stop reasons, and failed handoffs before implementation. Those observations establish a baseline. They do not become a savings promise.

Complete Workbook Section 1

1. Name one document family and intake channel.
2. Write the boundary sentence with reviewer, decision, and non-final destination.
3. List prerequisites, supported variants, exclusions, and forbidden actions.
4. Record current volume and handling measures using a stated period and source.
5. Choose go, repair the process first, narrow, or stop, and give the reason.

Download the Document Automation Requirements and Test Pack or open its resource instructions.

Common scope failures

• Combining invoices, contracts, forms, and receipts because all arrive as PDFs.
• Choosing a platform before defining the destination and review decision.
• Including payment or another hard-to-reverse action in the first release.
• Assuming slow approval is an extraction problem.
• Using a fictional capacity calculation as a business outcome.

A narrow boundary creates a system you can test. Module 2 turns that boundary into a schema that preserves what the system saw and what it still does not know.

Check your application