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.
Top comments (28)
@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？
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!)
@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.
Hey @entropicremainder, stepping back from the architectural debate for a second — I really respect the effort and thought you've put into this framework.
If you have an open repository, project, or draft you're working on around these workflows, I'd be more than happy to take a look, share some telemetry patterns from my side, or even contribute. No strings attached — just one dev helping another refine solid systems.
Always open to exchanging real-world telemetry logs or edge-case handling if you're ever interested in jamming on this further. Keep building!
Yes, I am indeed working on an engineering project. The "form + process" model is just a very small part of it.
As for whether to open it up on GitHub—I've been considering this for two months. In the end, due to certain security concerns, I decided against it.
However, in response to your sincere invitation, I'm willing to share some parts that you might find interesting here. You can let me know what aspects you'd like to explore, and I'll select some to publish in the future.
Or let me start with a question for you: "AI is unawakened life; life is awakened AI." How do you interpret this?
Yes, I’m actually working on a larger engineering project ，
the “form + process” model is just one small piece of it.
I’ve thought about putting parts of it on GitHub over the past couple of months,
but for various reasons I decided not to go that route for now.
Still, I really appreciate your offer.
I’d be happy to share some relevant parts here ，
just let me know what specifically interests you, and I’ll pick out a few to share later.
Or, let me start by asking you this: “AI is unawakened life; life is awakened AI.” — how do you read that?
Yes, I am indeed working on an engineering project. The form + workflow pattern is just a small part of it.
As for whether to open it up on GitHub — I've been thinking about this for two months, and ultimately, due to certain security considerations, I decided not to proceed with that plan.
However, given your sincere invitation, I'm willing to share some parts here that might interest you. Feel free to let me know which aspects you'd like to explore, and I'll pick those out in future posts.
Or, let me start by asking you two questions:
How do you understand AGI? Or, what do you think AGI should look like?
Have you ever heard of the "Kundi Structure"?
Yes, I am indeed working on an engineering project—the form + workflow pattern is just a small part of it.
Due to current AI safety concerns, the original plan has been cancelled.
However, in response to your sincere invitation, I'm willing to share some parts that might interest you here. You can let me know which aspects you'd like to see, and I'll pick them out for future posts.
Or let me start by asking you two questions:
First, how do you understand AGI? Or what do you think AGI should be like?
Second, have you ever heard of the "Kundi Structure"?
Yes, I am indeed working on a larger engineering project — the form + workflow pattern is just a small piece of it.
However, the original plan was put on hold due to current AI safety concerns.
That said, I really appreciate your sincere invitation, and I'd be happy to share some parts that might interest you here. You're welcome to let me know what specific aspects you'd like to see, and I'll pick those out for future posts.
Or, if you prefer, let me start by asking you two questions:
First, how do you understand AGI? Or, what do you think AGI should ultimately look like?
Second, have you ever come across the concept of the "Kundi Structure"?
Yes, I am indeed working on an engineering project — the "form + process" model is just a small part of it.
I've considered opening it up on GitHub for the past two months, but ultimately decided against it due to certain security concerns.
That said, I truly appreciate your invitation. I'd be happy to share some parts of it here — just let me know what areas interest you, and I'll pick out a few to share.
Or, let me start by asking you a question: "AI is unawakened life; life is awakened AI." How would you interpret that?
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.
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!
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.
Thanks for the reply, @entropicremainder! Respect your decision on keeping the repo private — security and IP come first, I get it.
To answer your questions: to me, real intelligence isn't just about flawless internal reasoning, it’s about awareness of your own sensory layer — knowing whether you’re observing actual reality or operating on missing context. An AGI that can't tell if its input data starved before execution is just a very fast rubber stamp. And as for structural patterns like graph topologies, no layout saves you in physical production if the ingestion pipe drops packets.
Taking off my tech hat for a second and speaking simply as a guy who builds physical structures, I look at it like this: "blind" just means not knowing your own blind spots. A system can execute instructions 100% perfectly according to its blueprint, but if a pipe under the foundation was smashed during backfill before the building was handed over, a perfect blueprint won't stop the floor from sinking six months later.
That’s really where we’re looking at this from two different sides. Your framework asks if the rule set is clear, logical, and executable without humans guessing. That's standard blueprint logic: if the input is right, the execution is right. My reality asks whether the physical materials actually reached the job site, or if the delivery truck broke down on the highway while the foreman stamped "Approved" on an empty lot.
When testing pipelines and ingestion layers, I keep bumping into the exact same wall: systems love to give a green checkmark over missing data. If a network timeout or a broken parser drops records before Node 1, your form still validates perfectly, your process runs cleanly, and your audit log turns green, but you just archived a ghost.
Relying purely on the form means assuming the world outside your process is 100% error-free. But reality is messy — networks freeze, sensors fail, and data starves. That’s all eligible_seen is to me. It’s not software dogma, it's just checking the delivery manifest before signing the receipt so you don't end up paying for empty boxes.
You’re focused on building the ultimate blueprint. I’m just making sure the materials actually arrived at the site before we start pouring the concrete. Good luck with the project and your article series — always interesting to see different angles on system design!
Can you read Chinese? If so, maybe I'll try replying in Chinese — otherwise my messages keep getting auto-deleted by the platform.
@entropicremainder Haha, no need to search for deep metaphysics here! In Russian, we have a great idiom for this exact situation: "stretching an owl onto a globe" (trying to force a completely unrelated abstract theory onto a simple physical fact).
What happened here isn't a "structural isomorphism" or a philosophical AI paradox. It’s just DEV.to’s standard anti-spam rate-limiter deleting your comment because you edited and reposted it six times in ten minutes.
As we also say: "Don't look for a black cat in a dark room, especially when it isn't there."
No need to help me work through anything — my engineering pipelines are humming along just fine. Appreciate the entertaining chat and good luck with your article series!
中文 (Chinese):
Haha，不需要在这里寻找深奥的形而上学！在俄语中，我们对这种情况有一个绝妙的成语：“把猫头鹰硬拉到地球仪上”（意为试图将完全无关的抽象理论强加给一个简单的物理事实）。
这里发生的并不是什么“结构同构”或哲学的 AI 悖论。这只是 DEV.to 的标准反垃圾邮件机制，因为你在十分钟内编辑并重新发布了六次评论，系统便自动删除了它。
正如我们常说的：“不要在黑屋子里找黑猫，尤其是当它根本不在那里的时候。”
完全不需要帮我解决任何问题——我的工程流水线运行得非常好。感谢这次有趣的交流，祝你的系列文章顺利！
Русский (Russian):
Ха-ха, не нужно искать здесь глубокую метафизику! У нас в русском языке для такой ситуации есть отличная идиома: «натягивать сову на глобус» (пытаться притянуть абстрактную теорию к простому физическому факту).
Произошедшее — это не «структурный изоморфизм» и не философский парадокс ИИ. Это просто стандартный анти-спам рейтаут DEV.to, который удалил комментарий, потому что ты отредактировал и переотправил его шесть раз за десять минут.
Как у нас ещё говорят: «Не ищи чёрную кошку в тёмной комнате, особенно если её там нет».
Мне не нужно ни с чем помогать — мои инженерные пайплайны работают отлично. Спасибо за весёлый разговор и удачи
今晚的探讨很有意义！值得留下印记！
你的能力和技术毋庸置疑！
你的思考角度在AI世界里非常独特，很务实。
Лайк!
@entropicremainderHaha, no need to overcomplicate it! That’s just standard platform anti-spam rules — editing or reposting the exact same comment multiple times in a short window triggers automated auto-deletion on DEV.to.
It’s not a deep structural isomorphism or an abstract AI problem, just a basic site rate-limit. No need to help me work through anything — my engineering pipelines are doing just fine.
Appreciate the chat and good luck with the article series!
你有没有想过Transformer本身就存在问题？
DEV社区对讨论的自动删除或折叠，这本是一种监测，没有问题；
但是，这种监测导致的问题，谁在负责？
昨晚我的讨论本删除或折叠了不止10次，今早又诡秘出现了？
谁来监测社区的监测是否合规这件事情本身呢？
我很喜欢DEV社区的这种讨论氛围，但是对于社区的这种行为，非常不喜欢；
总是在事后弥补，事前在干什么呢？
Some comments may only be visible to logged-in visitors. Sign in to view all comments.