Architecture & reliability
Systems designed for the days when things go wrong.
A flow that works in a demonstration is not a production system. Here are the architecture principles we apply so that an automation stays reliable, understandable and transferable.
- Who it is for
- IT managers, operations and technical leadership.
- Principle
- Each component does one job and can be replaced.
- Reversibility
- Your rules and data remain documented and exportable.
Reference architecture
Separate, readable and testable responsibilities.
Each project is tailored, but the structure stays the same. A simple flow uses only the layers it needs.
- 01InputsE-mail, files, forms, APIs, webhooks, scheduled tasks. The raw input is kept so that processing can be replayed.
- 02ApprovalFormat, required fields, duplicates. Attachments are isolated before anything is read.
- 03OrchestrationQueues, states, retries and timeouts. An interrupted process resumes where it stopped.
- 04Business rulesPrices, thresholds, routing, checks: everything that must be exact is written in readable, tested code.
- 05AI, if useful AIClassification, extraction, document search. Outputs checked against a schema, with a confidence level for each result.
- 06Human control HumanApproval before any binding action, and for every case below the confidence threshold.
- 07ActionsWriting to the ERP, CRM, e-mail or a database, with minimal permissions.
Reliability principles
What we apply by default.
These principles are not extras billed on top: they are part of how we build.
Input validation
Incoming data is checked (format, required fields, consistency) before any processing. Invalid input goes to a human queue instead of propagating.
Idempotency
Each operation carries a unique key: replaying it has no additional effect. No duplicate invoices, orders or messages.
Controlled retries
A temporary failure is retried automatically, at increasing intervals and with a maximum number of attempts, then reported.
Timeouts and fallbacks
Every external call has a maximum time limit. Beyond it, a planned behaviour applies: putting on hold, handing over to a person, alert.
Uncertain outcome
When it is unclear whether an action succeeded, for example after a network outage, it is marked as uncertain and checked, never blindly retried.
Audit log
Who, what, when, on which data, with what result. The log is append-only: entries are never modified or deleted.
Least privilege
Each component receives only the permissions it needs. Secrets stay on the server side, never in a browser or in the source code.
Isolation
Risky processing, such as analysing received files, runs in an isolated environment, with no network access and no access to the rest of the system.
Separate environments
Development, test and production are separate. No testing on your production data without your consent.
Observation mode
A new flow can first run without sending anything: it prepares each action for review while its real behaviour is validated.
Emergency stop
Each flow can be paused without losing pending items, then resumed cleanly.
Technologies
Chosen for the problem, never imposed.
We favour proven, documented and replaceable technologies.
- Orchestration
- Node.js or Python code, n8n where appropriate, queues and scheduled tasks.
- Data
- PostgreSQL, SQLite or your existing databases; encrypted backups.
- AI
- Models from established providers or open models installed locally; vector search for documents.
- Hosting
- Linux servers, containers, private cloud or your infrastructure.
- Observability
- Structured logs, metrics, alerts by e-mail or messaging.
Reversibility
Your asset is your rules and your data, not the tool.
Business rules, interfaces and data remain documented and exportable. An AI model or a component can be replaced without rebuilding the process, and the system can be taken over by another team.
Architecture
Start simple, add only what is missing.
Let’s talk about your process and the level of reliability it really requires.