Delivery & Architecture · decision, implementation, operation
In every regulated transformation one decision sits between the parties: which process runs across which systems, which layer holds which decision, at which point the evidence arises. The strategy consultancy ends at the target picture, the implementation partner starts at the tool, quality assurance examines the result. Significon takes that decision — and stays until the process runs and holds in operation.
The problem
None of the three is doing anything wrong. Each works within their remit. The gap sits exactly where the remits meet — and it only shows once the process is live, or once an inspector asks who decided.
The decision in the middle is not an intermediate task. It determines whether the process can later be examined, whether a tool change stays a system question, and whether a change in operation can be assessed. Four patterns follow from it, and they sit in almost every landscape that has grown over years.
01
Standard software is introduced from the function side: a system process is derived from the transactions that happen to exist. The business process across system boundaries is then modelled in executable form nowhere. It lives in presentations, in work instructions and in people’s heads — just not at the place where it is executed and examined.
02
Integration middleware quietly takes on routing and conditions — because that is the fastest place to put them. It thereby becomes a second actor in the process whose decisions appear in no model. In an audit what matters is not whether the result is correct, but what shows who decided it.
03
Annex 11 requires that a quality-relevant decision in a computerised system remains traceable. That presupposes a specified flow. If the flow is only looked at after go-live, the documentation has to chase the system instead of determining it — and every gap between the two is a question in the next audit.
04
The project ends at release, the landscape carries on. Every change, every incident, every configuration adjustment decides afresh whether the validated state holds. Anyone who leaves the project the moment it goes live leaves the same gap a second time — now in operation.
Three situations
All three arrive years after the project. That is why the decision is so rarely taken: it costs time at the start and pays off at a point when nobody asks about it any more.
The inspector does not ask whether the approval step happened, but what shows that it had to happen. If that condition sits in a script in the integration layer rather than in the process model, the answer is a code reading: it takes days, it needs the two people who know the script, and it convinces nobody. An executable model answers with a diagram and a log.
A vendor retires a module, a contract expires, two sites consolidate their systems. If the flow sits inside the systems rather than above them, a tool change turns into a process project with a new specification and new validation. Those costs appear in no licence comparison — they arise from an architecture decision that was not taken years ago.
Two years after go-live a field is to be added. Whether that requires revalidation depends on what the field does in the process: which decision it influences, which record it carries. If the answer is not in a model, it is estimated. And in case of doubt it is estimated wide — the scope grows because the basis for limiting it is missing.
The approach
We take it along two cuts: the process across domain boundaries and the landscape it runs in — both set out as their own cards further down. Both belong before tool selection, because otherwise every tool pulls a part of the decision to itself.
The order is not negotiable: process before system before AI. Reverse it and the tool determines the process, leaving the evidence to be constructed afterwards. This is not a matter of taste — it is the difference between a model you show in an audit and a script you read aloud in one.
AI appears in these flows only as a framed step: a defined input set, technically enforced human approval, an audit trail. The binding frame for it today is Annex 11. The Annex 22 draft of 7 July 2025 indicates a direction; no final version exists.
The flow across system boundaries runs as an executable process model in an orchestration layer. That layer holds the lifecycle and the approval gates. Whatever is not modelled there is not decided — it merely happens.
It calls systems and returns results. Branches and conditions belong one layer up, where they are visible in the model. That is a construction obligation, not an implementation detail.
ERP, MES, eQMS, LIMS and the model behind an AI step can be replaced without rethinking the process. The assignment of authority cannot be replaced without losing the evidence.
The architecture picture
The picture below is the decision, written down. On the left, which cut touches which layer; on the right, the answer that matters: which layer decides and which does not.
The AI step does not sit next to the flow but inside it: with a defined input set before it and an approval gate behind it that cannot be bypassed. The dashed rectangle around it is the point of the architecture — the risk of the non-deterministic step is bounded by the frame before building, not by an examination afterwards.
Cut 1
Which steps belong to the flow, where a decision falls, who approves, which data cross the system boundary. The result is a model that can be executed — and from which the requirement on every system involved can be read.
End-to-end architecture
Cut 2
Which layer holds decision authority, which one carries data, which one is interchangeable. The result is an assignment of authority in which every branch sits somewhere it can be shown in an audit.
Enterprise architecture
Cut 3
An AI function sits at one bounded step: a defined input set before it, a human approval after it that is technically enforced rather than agreed. The step does not carry the process onward while the approval is missing.
AI as a step, not as a layer
The evidence
The first kind is a presentation. The second is a running system in which the principle either holds or shows its cracks. Significon is building the second: a showcase on process-centric orchestration across system boundaries in a GxP context — Camunda 8 as the orchestration layer holding decision authority, n8n as the integration layer without decision logic of its own, AI steps each followed by an approval gate. We build it ourselves, in house, and it is under construction.
That is weaker evidence than a reference and stronger than a promise: it can be checked. Anyone who wants to see it sees it in the state it is in, including the parts still being worked on.
What the showcase shows
The solution
The decision alone changes nothing. It counts once it is carried through implementation and maintained in operation. That is why our work does not stop at the point where an architecture is usually handed over.
Decision
We take the decision that sits between the target picture and the tool: the flow across domain boundaries and the assignment of authority in the landscape it runs in. It starts with a bounded step on a real process, not with a programme across the whole landscape.
Implementation
An architecture decision that nobody carries through implementation stays a recommendation. We lead the project in the regulated environment: with the specialist methods that hang on it, and with the handover that stands at the end.
Operation
Release to productive operation ends the project, not the condition. The validated state only holds as long as every change, every incident and every configuration adjustment runs through a process that recognises GxP relevance.
Tools and frameworks the processes run in
The tools are the ones the processes run in — not the deliverable. Which one is used in a given case follows from the landscape, not from our portfolio. The detail on operation sits on the Enterprise Service Management page.
Why Significon
A target picture that nobody carries through implementation and operation costs time and changes nothing. We take on the architecture decision, lead the project that implements it, and stay in the operation where it has to hold.
We do not sell software. Which systems sit below the orchestration layer is a question about your landscape, not about our portfolio. In a selection we sit on your side of the table — and the question we ask is not which tool can do more, but which decision it pulls to itself.
What we say about this architecture we build ourselves, in house — the orchestration showcase, under construction and open to inspection in the state it is in. And what falls outside we say in the first conversation: a request that does not fit is cheaper for both sides than a proposal that has been made to fit.
Who decides in your organisation how process, system and compliance fit together?
A conversation in which we walk one flow through once — not a proposal.