Process Discovery
Part of Document-heavy process automation
Separating data extraction from business approval
Keep proposed fields, checked information, approval and execution as distinct states in a document workflow.
Data extraction identifies what a document appears to contain. Business approval decides whether an authorised rule or person permits the case to proceed. Keep those outputs separate: correcting a field can supply better evidence, but it must not silently make the decision.
Extraction asks what a document says; approval asks whether it may proceed
- Data extractionIdentifies what a document appears to contain. Correcting a field supplies better evidence, and nothing more.
- Business approvalDecides whether an authorised rule or person permits the case to proceed.
- Confidence scoreAn estimate of reading accuracy for a field or recognised words. Not a guarantee of correctness and not a business approval; some fields have no score at all.
- The boundary to holdA field correction must not silently make the decision. Checking transcription does not establish that a document is authentic or its claims true.
Record distinct states
For a chosen document type, record three separate events: the proposed value, the value checked against its source, and the business decision. A reviewer might confirm a date was read accurately yet decline a request because the date fails the applicable rule. A value that cannot be checked should remain uncertain, even if the rest of the document looks usable.
The decision handoff should identify the document version, relevant checked fields, unresolved discrepancies, proposed action and applicable rule or authority. The process owner must say which uncertainties can be shown to a decision maker and which must be resolved first. Checking transcription does not independently establish that a submitted document is authentic or its claims are true.
| State | Meaning | Next step |
|---|---|---|
| Extracted | Software has proposed a value | Check it against the document or another authorised source |
| Validated | The value has passed the specified check | Use it as decision input, subject to any remaining evidence checks |
| Approved | An authorised rule or person has permitted a defined action | Perform that action and verify its result |
Four separate events, recorded separately
- ExtractedSoftware has proposed a value. Next step: check it against the document or another authorised source.
- ValidatedThe value has passed the specified check. Use it as decision input, subject to any remaining evidence checks. A value that cannot be checked stays uncertain.
- ApprovedAn authorised rule or person has permitted a defined action. Record the decision, its basis and the document version considered with the case.
- Executed and confirmedRecord the action attempted in the destination system and the result confirmed there. If a write times out, approval stands but execution is unresolved — check the destination before retrying.
What the decision handoff must carry
- The document version under consideration
- The relevant checked fields
- Any unresolved discrepancies
- The proposed action
- The applicable rule or the authority for the decision
- Confirmed by the process ownerwhich uncertainties may be shown to a decision maker, and which must be resolved first
Use confidence to select review
Some document tools return estimated confidence for fields and recognised words; some fields have no score. A high score is not a guarantee of correctness or a business approval. Set review rules using representative documents and the consequence of a wrong value. An illegible source or conflicting values need investigation, not acceptance of the highest-scoring output.
For a hypothetical licence application, an extractor might read an expiry date correctly. The applicable business rule must still determine whether that date is acceptable. This example asserts no particular licensing requirement.
Make the decision actionable
Name who may approve, return, decline or escalate the case. Show what remains blocked while approval is pending. If a replacement page arrives, repeat the checks and reconsider any decision that depended on the earlier version. Keep the decision, its basis and the document version considered with the case.
After approval, record the action attempted in the destination system and the result confirmed there. If a write times out, approval remains on record but execution is unresolved. Check the destination before retrying.
Before release, trace a correctly read but ineligible document, a misread field, a missing page and an approved case through the proposed route. Check that each stops or proceeds at the intended boundary.
Pre-release trace: does each case stop or proceed at the intended boundary?
- A document read correctly but ineligible under the rule
- A misread field
- A missing page
- An approved case, traced through to the confirmed result in the destination system
- A replacement page arriving after a decisionchecks repeated, and any decision that depended on the earlier version reconsidered
