Inbound email
Unstructured input
Process lab · Demonstration 01
Useful automation starts where structure ends.
In production, most inquiries should be captured by a structured form and never reach a pipeline at all. The first design question is what structure can be captured upstream. Email is where that is not possible — and where the method has to earn its place.
DisplayAlertAssistAutomate
A human still approves the output.
One email · several independent paths
Watch the work split into checkable steps.
✦ Reading & judgment
◆ Written rule
● Human decision
↳
“Other” is evidence: repeated hits show which subtype to add next, instead of asking people to imagine every case up front.
| Ask | 01Account | 02Split | 03Type | 04Subtype | 05Requirements | 06Extract | 07Complete? | 08Draft | 09Grounding | 10Weigh |
|---|
Scroll to follow the paths →
The important artifact
People write the rules. The system follows them.
These are the complete tables used by the demonstration. Boundaries, requirements and routes are visible, reviewable and changeable without retraining anything.
01
Types & subtype boundaries
Only the relevant type’s list enters each classification step.
| Type | Subtype | Boundary injected |
|---|
02
Requirements, sources & actions
A lookup decides what happens next. No model chooses its own tools.
| Subtype | Required fields | Source | Weigh? | Action |
|---|
The only answer material
Four short, named sources.
The reply step sees one relevant snippet — never the whole knowledge base.
The operating principle
“Use judgment only where judgment is needed. Everything else should be a rule someone can inspect.”
01 Small steps
02 Minimal context
03 Visible evidence
04 Human approval