From Probabilistic Guesswork to Deterministic Execution: A Financial Approval Process as a Design Pattern

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:

1. Controllability — Every path is predefined, no surprises
2. Coverage — Every application is routed somewhere, nothing is dropped
3. 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.

---

Tags

productivity #discuss #ai #workflow #automation #designpatterns #deterministic #verification

Comments

[Mikhail]

I'm @mansio — I wrote the OWP comment you cited at the bottom of the article.

One push on Takeaway 5: "you don't need a population_manifest — this diagram IS the manifest."

The diagram is the manifest for the process. It is not the manifest for the inputs that feed it.

Your Node 4 routes correctly on Counts[5000,10000]. But what if Counts came from a collector that returned 0 rows out of 400 eligible for 4 days — with no errors reported? Routing deterministic. Conditions fire correctly. Node 8 archives with a clean log.

Real production case from that thread: 1106 matched / 193 delivered. Worst case: 39 matched / 0 delivered. Perfect process. Starved input. Clean audit trail. Nobody knew until someone counted the gap between matched and delivered.

eligible_seen belongs one layer before Node 1 — not inside the process, but feeding it. Without that number, a deterministic process over an empty population produces a perfect audit trail of wrong decisions.

Two questions, not one:
"Did the process run correctly?" — your diagram answers this.
"Did the right population reach the process at all?" — that needs the manifest.

[EntropicRemainder]

A form + a process = a complete input-to-output cycle.
I got a bit lazy with the English translation since it was too long, so I split my answer into three parts.
Hope this form gives you some new food for thought!

[Mikhail]

Nice form, but it misses the point.

Your table has 3 expenses (2,000 RMB). Your fields validate those 3 expenses perfectly.
Now answer the actual question: What if the user had 5 eligible expenses for that trip, but 2 were dropped before reaching this form?

Your form is valid. Your process is clean. Your audit log is green. And 2 expenses are silently lost. That is why a form + a process still equals zero visibility without eligible_seen at the ingestion layer.

[EntropicRemainder]

@mansio that’s exactly the distinction I was trying to get at with the form. What you’re calling eligible_seen at the ingestion layer — I’m calling it ‘what the user defined as eligible.’ The form isn’t the validator. The user is. The form just carries what they decided should be there. So the question isn’t ‘did the form validate what arrived?’ — it’s ‘did the user define what should arrive in the first place?’ That’s the layer I think your eligible_seen is pointing at, just from a different angle. Curious if that framing lands differently.

Maybe my replies look too much like AI-generated text, so they get flagged and removed？

[Mikhail]

Appreciate the thoughtful breakdown, EntropicRemainder!

There is a subtle but critical distinction here between declared intent and runtime observation:

What the user defines as eligible is a policy (intent). What eligible_seen measures is runtime reality (telemetry).

If a user defines 5 expenses as eligible, but a broken collector drops 2 before Node 01, the user's intent alone can't save the execution. The machine receives 3, validates 3, and archives 3 cleanly.

If the intake layer doesn't independently track eligible_seen against that expectation, the system fails silently. Relying on human memory to spot missing rows isn't deterministic execution—it’s just a green stamp over invisible data loss.

Intent and intake telemetry have to work together.

(And don't worry about the DEV.to filters—automod on tech sites has been super aggressive lately!)

[EntropicRemainder]

@mansio I think it's necessary here to draw a clear distinction between two fundamentally different entities—user and AI—when it comes to the issue of real-time monitoring:

"User real-time monitoring" is a valid phrase, because the subject is the user—a human individual.
But what about AI? How does AI understand "real-time monitoring"? Have you ever thought about that?
So let me give a definitive definition here:

AI does not need real-time monitoring. AI has only one action: execution.

In the form + process framework, the design specifications of the form, the required fields, the approval basis at each node, and the trajectory of the process flow—these are the AI's real-time correction and detection during execution.

What the user needs to do is think, before NODE 01, about how to design the form, fields, process, and specifications—and then wait at the exit for the result.

If the user can clearly express their intent and design a form, fields, and process that meet the specifications, all that's left is to sit back and wait for the result.

If the user cannot clearly express their intent, then it is the user who needs to be examined—not the AI. Isn't that right?

The real-time monitoring you emphasized earlier belongs to the working model of traditional software engineering. Now, with AI, everything has changed.

The above is a descriptive response, not an interpretive one.

A descriptive expression might come across as a bit rough in tone, and perhaps not humble enough—so I want to make that clear upfront.

There's an old saying in China: "Huà cāo lǐ bù cāo" — roughly meaning, "Rough words often carry the clearest truth." In other words, the coarser the language, the clearer the principle.