The problem
GxP processes regularly cross system boundaries. The problem does not arise at the crossing — it arises in the way systems and integration are typically introduced.
01
Standard software is typically introduced from the function side: a system process is derived from the available transactions. The continuous cross-system business process fades into the background — it is not modelled in executable form anywhere and therefore not auditable.
02
Classical integration middleware gradually absorbs routing and decision logic. It becomes a second, unmodelled agent in the process — one whose decisions are neither visible in the BPMN model nor traceable in the audit trail. This is precisely what is unacceptable in a regulated environment.
03
AI tools are layered onto existing system landscapes — as a layer that produces results without the process frame before and after being deterministic. The result is a non-deterministic step without a defined input set, without enforced human sign-off, without an auditable lifecycle.
Regulatory consequence
Annex 11 requires that every quality-relevant decision is traceable — who decided what and on what basis. The Annex 22 draft draws a line for AI systems: Generative AI and Large Language Models should not be used in critical GMP applications, and the draft excludes them from its scope. We therefore keep non-deterministic steps out of quality-determining decisions — or we design their framework so that decision responsibility demonstrably rests with the human.
The classical middleware model does not systematically fulfil any of these requirements: it produces handoffs without a decision model, integration without a lifecycle, and AI results without a deterministic frame. The problem is not the use of middleware or AI — it is the absence of authority by a single, auditable instance over the entire process.
If middleware routes and the routing logic is not in the process model, the decision is not auditable — even if the result is correct.
A BPMN process model without an executable engine is documentation, not a control instrument. What is executed then follows the system flow — not the model.
AI steps in an unmodelled flow produce results without a traceable decision basis. The gap originates in the process design — long before an audit finds it.
The audit trail does not start at the system output. It must cover the entire lifecycle: which input, which processing, which human approval, which result.
The core principle
The solution to the middleware problem is not new middleware. It is an architecture in which each layer has a clearly defined authority — and in which the orchestration layer does not surrender decision authority over the overall process.
Layer 1 · Orchestration
The BPMN engine executes the entire E2E flow as an executable model. It holds the lifecycle, controls the approval gates, and is the leading audit bracket — visible, modelled, verifiable.
Camunda 8
Layer 2 · Integration
Calls target systems and returns results — without its own decision logic. Branches and conditions belong in the orchestration layer, not here. This is a structural requirement, not a detail.
n8n
Layer 3 · AI
AI functions sit at clearly defined steps. Before: a deterministic knowledge base defines the input set. After: an enforced human approval gate. The model decides nothing that carries the process forward uncontrolled.
LLM + HITL-Gate
"The safety of AI comes from the framework — not as an add-on to it."
This is the architectural proof of value: the risk of the non-deterministic step is constrained by design before building — not validated retrospectively.
Use case example
Change management typically touches ERP, MES, and eQMS simultaneously — with different approval levels, responsibilities, and documentation requirements. Without an executable process model, coordination becomes a source of compliance gaps.
The example is shown as a normal change (full approval path). Different change types differ exclusively in the process flow — not in the system architecture. That different governance can be represented purely through the process model, without new code, is an independent proof of the architecture thesis.
Why Significon
We come from the GxP environment — validation, qualification, regulatory requirements are not an add-on to the project, but the starting point. The showcase on this page we build ourselves, in house: Camunda, n8n, system integration. It is under construction and not finished; what stands here came out of building it, not out of a slide.
We run a PoC through the same phases as a regular undertaking: scoping, design, build, deploy. This is consistent with the core thesis — structure carries conformity. The PoC demonstrates the principle it proves. It is a bounded first step on a real process; what follows is decided by its outcome, not by this offer.
The system components below the orchestration layer are interchangeable — ERP, MES, LLM model. The architectural element that cannot be swapped is the discipline: decision authority remains in the orchestration layer. This applies to any concrete system landscape.
Is process-centric orchestration the right approach for your system landscape?
We'll clarify that in the first conversation — no sales pitch.