Meta Description: HONO's engineering team built the same seven-stage AI pipeline for three different problems: timesheet processing, payslip explanations and support tickets. Here is the architecture, what stays fixed, and what changes per domain.
Key Takeaways
- How HONO found the pattern: Three separate engineering squads, working on different problems, independently arrived at the same seven-stage architecture. A client request finally put a name on what already existed.
- The seven stages: Every domain runs through Ingest, Classify, Secure, Extract, Validate, Route, and Audit. The stages are fixed. What each stage does inside a given domain is configuration.
- Three domains, one shape: Contractor timesheets, payslip explanations, and a support helpdesk in development all use the same pipeline. The comparison table in this article shows exactly what changes between them.
- Five configuration axes: Human placement, auto-execute action, classifier vocabulary, validation engine, and the shape of the knowledge the validate stage relies on. These change per domain without touching the pipeline itself.
- What HONO got wrong: The first build was a custom project, not a framework. The second and third domains forced a stage-by-stage rework, including retrofitting model routing and elevating human-in-the-loop from an operational detail to a first-class design principle.
- Why it pays off: New domains ship faster, safety is uniform across all domains, and engineers can move between domains without re-learning the system.
- What is next: Invoice processing and contractor onboarding are the fourth and fifth domains, both client-requested. The article also names the honest boundary of what this pipeline shape cannot do.
What Is This Pipeline?
HONO runs one seven-stage AI pipeline underneath three separate HR and payroll systems: contractor timesheet automation, payslip anomaly explanation, and a support helpdesk currently in development. The seven stages are Ingest, Classify, Secure, Extract, Validate, Route, and Audit. What stays the same across all three is the shape of those stages and the safety rules that govern them. What changes is what each stage does inside a given domain, the vocabulary the classifier uses, what "auto-execute" means in practice, and where a human sits in the review process. Building a new domain on this pipeline costs roughly as much as writing its extraction logic and validation rules, not as much as building a new system from scratch.
How HONO Found the Pattern?
Nobody on the team planned this. Three separate squads, working in different quarters, on different problems, kept arriving at the same architecture. It took a client to name it.
A global energy and engineering workforce firm had received HONO's contractor timesheet pipeline. That build covered 45-plus countries and handled timesheets arriving as email attachments in every format a client's back office could invent. When that client came back asking for the same approach on invoice processing and contractor onboarding, they were not asking for the timesheet product specifically. They were asking for the shape underneath it.
That request made the team look back at the three systems already running or in development at HONO: contractor timesheets, payslip explanations, and the support helpdesk. Nobody had decreed a standard. Three teams had independently arrived at the same seven stages. The pattern had won on its own.
The Seven Stages, Explained
Each stage has a fixed role. What it does inside that role changes by domain.
Ingest
Work enters on four channels: email with attachments, SFTP document drops from third-party systems, webhook triggers from integrated platforms, and scheduled API pulls for sources that only answer when polled. The pipeline is not email-first. Third-party systems drop files on their own schedules, and any pipeline built around one input channel breaks the day a client's system changes its behaviour.
Classify
The pipeline identifies what arrived, what type it is, and which part of the system should handle it. This is the trigger decision for everything that follows.
Secure
Attachment validity and safety checks run before anything else opens the payload. This is a stage in its own right, not a detail buried inside ingestion. Nothing downstream touches a file the security gate has not cleared.
Extract
The AI reads the content and pulls out the fields the domain needs: hours and rates from a timesheet, pay-head movements from a payroll run, the actual question inside a support ticket. The extraction logic is specific to the domain. The machinery around it is not.
Validate and Confidence
Correctness is checked, and a confidence score is attached to every claim the pipeline makes. The question at this stage is: is this safe for AI to act on?
Route
High confidence goes to auto-execution. Failed validation returns a templated response to the sender. Anything in between goes to a human. The pipeline has no "probably fine" path.
Audit
Every decision is logged, with PII scrubbed at write time. This is a stage, not a log line at the end of a run. The audit trail is what makes a stream of model decisions something an enterprise can trust.
For a deeper look at how these stages work in the timesheet context, see Seven AI Agents, One Timesheet.
The Same Pipeline, Three Domains
The stages stay the same. Their meaning changes.
| Contractor Timesheets | Payslip Explanations | Support Helpdesk | |
|---|---|---|---|
| Status | Production | Production | In development |
| Classify means | Which client, which country format, which timesheet type | Which pay heads moved outside the employee's baseline | Ticket category, urgency, which knowledge base owns the answer |
| Auto-execute means | Approve and post the timesheet | Publish the explanation on the payslip | Send the drafted reply |
| Where the human sits | Exception review: only what confidence routing flags | Async: the employee acknowledges, nobody approves before it ships | Review every: mandatory agent sign-off until trust is earned |
The stages are invariant. The classifier vocabulary, the validation engine, what auto-execute does, and where the human sits are all configuration per domain.
Inside Each Domain: What the Pipeline Actually Does?
Contractor Timesheets
The timesheet build was the first of the three. Contractor timesheets for a workforce firm operating across 45-plus countries arrive as email attachments in every format a client's back office can produce.
Classify decides which client, which country format, and which timesheet type is in front of the pipeline. Extract uses OCR with rotation correction, followed by structured parsing of hours and rates. Validation is deterministic where possible. Contractor resolution is a database lookup, not a model guess. It is rule-based elsewhere, with a confidence score attached at each step.
Route is three-way: auto-approve, manual review, or reject with a templated reply to the sender. The human sits at exception review. They only see what confidence routing flags. The projected annual saving of over one million dollars comes directly from how much never needs human attention.
Payslip Explanations
The payslip layer inside Zero Touch Payroll answers a different question. Not "is this document valid?" but "why did this number change?"
Anomaly detection runs against per-employee statistical baselines. When a pay head moves outside its normal band, the pipeline generates an explanation of the variance and publishes it directly on the payslip.
The seven stages are the same, but their meaning shifts. Ingest is continuous payroll input, not documents arriving in an inbox. Classify picks out which pay heads moved. Extract and reasoning work against a time-series baseline rather than an image. The human-in-the-loop is asymmetric: the explanation appears on the payslip, the employee acknowledges it, and nobody approves it before it goes out.
This is a deliberately different safety position from the timesheet domain. A wrong payslip explanation is embarrassing and correctable. A wrong timesheet approval moves money.
Support Helpdesk (In Development)
The helpdesk is the third domain and the fastest to stand up so far. It inherited ingestion, security, confidence routing, and audit as configuration rather than engineering work.
Tickets and support emails arrive, classify assigns category and urgency, extract isolates the actual question and the entities it involves, and validation scores the drafted answer against a vector-similarity knowledge base. The route stage sends the draft to a support agent who must sign off before any reply goes out.
This is the most conservative human placement in the three domains: review every reply, mandatory, until the audit trail earns the system enough trust to move toward exception-only. The dial exists to be turned later. It has not been turned yet.
What Never Changes: Five Invariants
Across all three domains, five things have survived every transfer without modification.
Confidence attaches to every claim, not just the pipeline run.
The question "is this okay to be actioned by AI?" is asked explicitly, per item, every time. It applies to each extracted field, each validation result, and each drafted action.
Ambiguity defaults to a human, with no "probably fine" path.
If confidence does not clear the bar at the route stage, a person decides. This is true in every domain and at whatever position the human holds in that domain.
The security gate sits before extraction, in every domain.
Attachments are validated and safety-checked before anything downstream opens them. This stage has not been relaxed for any domain, including those where the sources are internal systems.
Queue-based orchestration, replayable at every stage.
Every stage reads from a queue and writes to one. A failed extraction retries without re-running ingestion. A corrected validation replays without re-extracting. Debugging the pipeline means reading its queues.
Audit is a stage in its own right, not a log line.
Every decision is recorded with PII scrubbed at write time, in the same trail shape across all domains. One security review covers all of them. One auditor who has read one trail has read them all.
What Changes: Five Configuration Axes
Everything else varies across domains. The discipline is that it varies as configuration, not as forked code.
Where the human sits.
Review every reply (helpdesk today). Exception-only (timesheets). Async acknowledge (payslips). The same dial, three positions, adjusted per domain as trust is established.
What auto-execute means.
Approve and post. Publish an explanation. Send a reply. The action changes. The confidence gate in front of it does not.
The classifier vocabulary.
Client and format for timesheets. Pay-head movement for payroll. Category and urgency for support. Categories belong to the domain. The classify stage does not.
The validation engine.
Business rules and rate codes for timesheets. Statistical baselines for payroll. Policy checks against a vector knowledge base for the helpdesk. Three different engines, all behind the same contract: return a verdict and a confidence score.
The shape of the knowledge the validate stage relies on.
Relational lookups for timesheets. Per-employee time-series for payroll. Vector similarity for the helpdesk. The pipeline does not care what the knowledge looks like. It only needs the validate stage to be able to lean on it.
What HONO Got Wrong the First Time?
The timesheet build started with what the team asked for. Requirements came from the people processing timesheets and the pipeline was built to match those requirements exactly. It shipped, it worked, and the users were satisfied. It was also, as the team later acknowledged, a custom project that happened to look like a platform. Nobody had built it as a framework, because nobody had asked for a framework.
Then two things arrived at the same time. Invoice automation conversations started with the same client, a completely different document type. And new countries came onto the timesheet pipeline with formats the original build had never encountered. Neither fit. Not because the architecture was wrong, but because it had never been designed to be an architecture.
The fix was not a rewrite. It was a stage-by-stage review: for each step, either make it configurable, extend it to cover the new cases, or rebuild it as a configurable component. Two concepts that are now central to the framework were added in this pass rather than designed in from the start. Model configuration and model routing became explicit steps, retrofitted.
Human-in-the-loop was the bigger shift. It had been an operational detail in the timesheet build, a review queue the system happened to have. Invoice processing forced a harder look: when the payload involves money, the model does not get to assume what action to take. A wrong field on a timesheet gets caught by a reviewer. A wrong interpretation of what an invoice means compounds through every downstream system. The human stopped being a queue and became an architectural position that every domain must choose deliberately.
The lesson: the pattern was not designed. It was extracted from a bespoke system, under pressure from the second and third domains, one configurable stage at a time. The framework is what remains after you remove the domain-specific parts. You only find out what remains when the next domain arrives.
Why This Approach Pays Off?
New domains ship faster. The helpdesk was the fastest of the three to stand up. It inherited ingestion, security, confidence routing, and audit as configuration. The cost of a new domain is converging toward the cost of writing its extraction logic and validation rules, which is where the domain actually lives.
Safety is uniform across every domain. One security gate implementation, one audit trail shape, one confidence contract. A security review of the pattern covers every domain running on it. A compliance auditor who has read one audit trail has, in effect, read them all.
Engineers move between domains without re-learning the system. The vocabulary is shared: ingest, classify, secure, extract, validate, route, audit. Only the domain meaning changes. An engineer who has shipped work in the timesheet domain can pick up the helpdesk domain with the same mental model.
What Is Next?
The fourth and fifth domains are both client-requested. The same firm that received the original timesheet pipeline has asked for the same shape on invoice processing and contractor onboarding. They are not asking for the timesheet product. They are asking for the pattern underneath it.
Onboarding stretches the pipeline in a new direction. It involves long-running, multi-document, compliance-heavy journeys where the pipeline runs for days per case rather than seconds per document. That is a different operational shape from the existing three domains.
There is also an honest boundary: this pipeline is built for document-and-event-driven work. Things that arrive, get understood, and get actioned. Conversational interfaces like Zero UI are a different problem with different routing requirements. Forcing interactive work into this pipeline shape would be the same mistake as the original custom build, made in the opposite direction.
