The difference between a toy and a tool isn't how smart the AI is — it's whether the output is controllable, predictable, and reusable. This article shows what that looks like in practice.
1. Introduction: What This Article Is About
This article presents a complete financial approval process design — from application submission to final archiving — as a concrete example of how to move from probabilistic guesswork to deterministic execution.
The core idea is simple:
When you predefine every node, every routing path, and every condition in a process, execution no longer requires guessing. Input an application, and the output is a deterministic result.
This isn't just about finance approvals. It's a design pattern that can be applied to engineering reviews, project initiations, task assignments, procurement, reimbursement — any structured workflow that requires predictable outcomes.
Throughout this article, I'll walk through the full process design, explain every node and condition, and show how this structure addresses three critical concerns:
- Controllability — Every path is predefined, no surprises
- Coverage — Every application is routed somewhere, nothing is dropped
- Verifiability — Verification is embedded in every node, not added at the end
2. Design Philosophy
2.1 The Core Problem It Solves
Traditional workflows often rely on human judgment at every step — which is unpredictable, inconsistent, and unscalable. AI-assisted workflows add another layer of uncertainty: if the AI has to "guess" what to do next, the output is probabilistic, not deterministic.
This design solves that problem by predefining the entire execution path.
2.2 Design Principles
| Principle | Description |
|---|---|
| Top-down logic | Process flows hierarchically, from application to final approval |
| Complete coverage | Every possible condition leads to a defined next step — no dead ends |
| Precise conditions | Every routing decision is triggered by explicit, measurable criteria |
| Bidirectional flow | Supports both approval (forward) and rejection (backward) |
| Reusable template | The same logic applies to any structured approval workflow |
| Embedded verification | Every node is a verification point — verification is the process itself |
2.3 Key Symbols Used
| Symbol | Meaning |
|---|---|
Dept |
Department field |
Roles |
Roles field |
Counts |
Amount/quantity field |
== |
Equals |
<> |
Does not equal |
[BC] |
Belongs to department set |
[bc] |
Belongs to role set |
& |
And (both conditions must be satisfied) |
Yes |
Approval granted |
No |
Approval rejected |
[5000,10000] |
Amount ≥ 5000 and ≤ 10000 |
3. The Complete Process Flow
Process Overview
This process contains 8 nodes that represent every stage from submission to closure. Each node has:
- A name and assignee (who acts at this stage)
- Routing paths (where the application can go next)
- Condition settings (what triggers each path)
Node 1: Submit Application
| Attribute | Value |
|---|---|
| Node Name | Submit Application |
| Assignee | All personnel |
| Routing Path | → Node 2 (Supervisor Approval), Node 3 (Department Head) |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
1→2 |
Dept == A |
Department equals A → go to Supervisor Approval |
1→3 |
Dept <> A |
Department does not equal A → go to Department Head |
Explanation:
The applicant submits a request. The system automatically determines the first routing destination based on the department. This ensures different departments enter the appropriate approval channel from the start.
Node 2: Supervisor Approval
| Attribute | Value |
|---|---|
| Node Name | Supervisor Approval |
| Assignee | Applicant's immediate supervisor |
| Routing Path | → Node 3, Node 4, Node 5, or Node 1 (return) |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
2→3 |
Dept == A |
Department A → Department Head |
2→4 |
Dept[BC] & Roles[bc] |
Dept ∈ BC set AND Role ∈ bc set → Finance Approval |
2→5 |
Dept[DE] & Roles[de] |
Dept ∈ DE set AND Role ∈ de set → General Manager |
2→1 |
No |
Supervisor rejects → return to applicant |
Explanation:
The supervisor reviews and routes based on department + role combination:
- Department A follows the standard path
- BC Department + bc Role bypasses Department Head, goes directly to Finance
- DE Department + de Role goes directly to General Manager
- Rejection returns the application to the submitter
Node 3: Department Head Approval
| Attribute | Value |
|---|---|
| Node Name | Department Head |
| Assignee | Department head |
| Routing Path | → Node 4, Node 5, or Node 1 (return) |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
3→4 |
Dept[FG] & Roles[fg] |
Dept ∈ FG set AND Role ∈ fg set → Finance Approval |
3→5 |
Dept[KP] & Roles[kp] |
Dept ∈ KP set AND Role ∈ kp set → General Manager |
3→1 |
No |
Department Head rejects → return to applicant |
Explanation:
The department head reviews and routes based on department + role combination:
- FG Department + fg Role → Finance Approval
- KP Department + kp Role → General Manager
- Rejection → return to applicant
Node 4: Finance Approval
| Attribute | Value |
|---|---|
| Node Name | Finance Approval |
| Assignee | Deputy General Manager |
| Routing Path | → Node 5, Node 6, or Node 1 (return) |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
4→5 |
Yes & Counts[5000,10000] |
Approved AND amount ∈ [5000, 10000] → General Manager |
4→6 |
Yes & Counts[0,5000] |
Approved AND amount ∈ [0, 5000] → Chairman |
4→1 |
No |
Finance rejects → return to applicant |
Explanation:
Finance is the key amount-based decision node:
- Amounts between 5000–10000 → General Manager Approval
- Amounts between 0–5000 → Chairman Approval (skips General Manager)
- Rejection → return to applicant
This ensures different spending levels follow different approval channels.
Node 5: General Manager Approval
| Attribute | Value |
|---|---|
| Node Name | General Manager Approval |
| Assignee | General Manager |
| Routing Path | → Node 6 or Node 1 (return) |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
5→6 |
Yes |
Approved → Chairman |
5→1 |
No |
Rejected → return to applicant |
Explanation:
The General Manager makes the highest management-level decision. Approval moves to the Chairman for final confirmation; rejection returns to the applicant.
Node 6: Chairman Approval
| Attribute | Value |
|---|---|
| Node Name | Chairman Approval |
| Assignee | Chairman |
| Routing Path | → Node 7 |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
6→7 |
Default | Approved → Cashier Payment |
Explanation:
The Chairman provides the final executive confirmation. Once approved, the application moves to the execution phase (payment). This ensures top-level sign-off on all approved requests.
Node 7: Cashier Payment
| Attribute | Value |
|---|---|
| Node Name | Cashier Payment |
| Assignee | Cashier |
| Routing Path | → Node 8 |
Conditions:
| Route | Condition | Meaning |
|---|---|---|
7→8 |
Default | Payment executed → Archive & Close |
Explanation:
The cashier executes the actual payment. This node transitions the application from "approved" status to "executed" status.
Node 8: Archive & Close
| Attribute | Value |
|---|---|
| Node Name | Archive & Close |
| Assignee | AI (system auto-executed) |
| Routing Path | Terminal node (end of process) |
Explanation:
The process endpoint. All approval records, payment confirmations, and condition logs are automatically archived. Notably, the assignee here is AI — archiving is fully automated, requiring no manual intervention.
The process is now complete.
4. Complete Path Overview
Based on different combinations of department, role, and amount, applications follow one of these paths:
| Path | Route | Scenario |
|---|---|---|
| A (Standard) | 1→2→3→4→5→6→7→8 | Department A, standard routing |
| B (BC Dept + bc Role) | 1→2→4→6→7→8 | BC dept + bc role, skips Dept Head |
| C (DE Dept + de Role) | 1→2→5→6→7→8 | DE dept + de role, skips Dept Head & Finance |
| D (FG Dept + fg Role) | 1→2→3→4→5→6→7→8 | FG dept + fg role, full standard path |
| E (KP Dept + kp Role) | 1→2→3→5→6→7→8 | KP dept + kp role, skips Finance |
| F (Rejection) | Varies → returns to 1 | Any node where approval is denied |
5. Why This Design Matters
5.1 It Answers the "Coverage" Question
One of the hardest questions in any automated workflow is:
"How do you know your system actually examined everything it was supposed to?"
This design answers that question directly:
| Concept | In This Process |
|---|---|
population_size |
All applications that enter the process |
eligible_seen |
Applications that reached each specific node |
| Coverage proof | Every node's entry/exit conditions create a complete audit trail |
This flowchart itself is the coverage anchor.
You don't need to add a separate verification step at the end — verification is embedded in every node's conditions.
5.2 It Embeds Verification in the Process, Not at the Boundary
In many systems, verification is treated as a separate step — a check added at the end to catch errors.
This design takes a different approach:
| In this design | Not this |
|---|---|
| Verification is in every node condition | Verification is a single final check |
| The process itself is the verification | Verification is added after the process |
| No need for a separate "verification step" | A separate step that itself needs verification |
Verification is not an action. It's the whole process.
5.3 It Bridges to AI Discussions
This design has direct relevance to ongoing conversations about AI reliability:
| AI Concern | How This Design Responds |
|---|---|
| "Semantic blindness" | The process is deterministic — no semantic interpretation required |
| "Probabilistic outputs" | Every path is pre-defined — no probability involved |
| "Coverage uncertainty" | Every node logs what it processed — coverage is transparent |
| "Who verifies the verifier?" | No separate verifier exists — verification is the structure itself |
6. Key Takeaways
| Takeaway | Statement |
|---|---|
| 1 | This flowchart itself is the coverage anchor. |
| 2 | Verification is not at the boundary — it's in every node's conditions. |
| 3 | Forms define the spec, conditions define the coverage, logs record the verification. |
| 4 | Every step is verification. Every step is deterministic judgment. |
| 5 | You don't need to add a population_manifest at the end — this diagram IS the manifest. |
| 6 | The difference between a toy and a tool: is the output controllable, predictable, and reusable? |
| 7 | Verification isn't an action — it's the whole process. |
7. Conclusion
This financial approval process is more than just a workflow diagram. It's a design pattern for building deterministic, verifiable, and reusable systems.
The principles here apply far beyond finance:
| Domain | Application |
|---|---|
| Engineering reviews | Code review routing based on file paths, author roles, and severity |
| Project initiations | Project approval based on scope, budget, and department ownership |
| Task assignments | Task routing based on skills, availability, and priority |
| Procurement | Purchase approvals based on amount, vendor, and department |
| Reimbursement | Expense approvals based on amount, category, and policy rules |
When you predefine the nodes, paths, and conditions, the process stops being probabilistic and starts being deterministic. The "guessing" disappears. The "coverage anxiety" disappears. The "verification overhead" disappears.
Verification is not an action. It's the whole process.
And when verification is the process itself, fixing it isn't an engineering project — it's a celebration.
Built from a conversation with @heinrichneb on veto heartbeats, @james_anderson_h on semantic blindness, and the OWP team on coverage anchors. This is what "verification as process" looks like in practice.
