Business Process Integration
For Both Executive and Technical ReadersProcess Diagramming specifies who does what and when. It has almost nothing to say about why a decision is reached inside a gateway. Here is a way to integrate the two.
01 The Gap
Every process has a gateway labelled “Approve?” But no instructions.
A typical enterprise process is a diagram with a gateway labelled “Approve?” What happens inside that diamond is left entirely unspecified. Most implementations fill it with hard-coded rules, which cannot handle uncertainty or explain themselves, or with human judgment, which is not auditable and does not scale. Neither produces a record that can be shown to a regulator.
The gateway is a placeholder. Process diagrams specify that a decision is made. They say nothing about how. This is not a flaw in the approach, it was designed that way, leaving the decision itself to whatever system the gateway invokes. The question is what that system is.
02 The component
The gateway invokes a Decision Service. It gets a traceable answer back.
Business Process Integration is the pattern by which every gateway that requires expertise, credit assessment, clinical triage, fraud detection, underwriting, security escalation, becomes a call to a Decision Service. The process diagram does not contain the logic. It invokes a service, receives a DecisionCertificate, and branches on the result.
The process engine sees only the service call and the returned certificate. The gateway branches on the decision field; the certificate carries everything a regulator needs to inspect.

A clinical pathway for suspected acute appendicitis. Two gateways contain decisions the diagram records but does not specify: the diagnosis decision, and the dismissal criterion.
This pathway has a gateway that carries the entire clinical argument: Acute appendicitis diagnosed? The ER evaluation produces a clinical picture in 10–25 minutes, physical examination, lab results, imaging. What emerges is a judgment call. The diamond in the diagram records that a decision was made. It says nothing about which findings drove it, how confident the clinician was, or what would change the call.
The second decision is quieter but equally consequential. The dismissal gateway requires the patient to have been fever-free for at least 24 hours and not more than 36. That sounds like a simple rule. But fever-free in a post-surgical patient on antibiotics is not a single temperature reading, it is a pattern across time, against a background of treatment response and individual variation. The antibiotic protocol itself branches: 3–5 days or 5–9 days. That branch is a judgment about how severe the infection was and how well the patient is responding.
The Decision Service fills both diamonds with a traceable answer. For the diagnosis gateway: the causal model takes the clinical findings, RLQ pain score, rebound tenderness, WBC count, CRP, CT findings, Alvarado score, and returns the probability of acute appendicitis, which findings drove it most, and how much of that signal is causal vs. correlational. The gateway receives a certified answer and routes accordingly. If the probability is in the uncertain range, the certificate names the single finding most likely to change the call, and routes to Additional Clinical Assessment with that request attached.
For the dismissal gateway: the causal model takes the patient’s temperature record after surgery and returns the probability that the fever-free window has been met safely. Both gateways now carry a decision that can be shown to a review board.
03 How it works
The gateway calls the Decision Service. It gets a certificate back, not a string.
The gateway becomes an invocation. The task preceding the gateway calls the Decision Service, passing the case identifier and available evidence. The service runs the full reasoning pipeline and returns a result.
The Decision Service returns a DecisionCertificate. The certificate carries the probability estimate, the reasoning behind it, a robustness check, an explanation of which evidence drove the result, and a full audit record. It does not return a string.
The gateway branches on the certificate. “Approved” routes to the approval path. “Referred” routes to a human reviewer, with the certificate specifying exactly what additional information would most change the decision. “Declined” routes to the decline path with an explanation attached. No logic lives inside the diamond.
The referral path is not a black box. It is a specific request: the certificate names the finding most likely to change the outcome, and the reviewer is asked for that finding specifically.
04 The Brains
The causal model is what fills the diamond.
The Decision Service is powered by a causal model built from clinical knowledge. There is plenty of medical data, so it is trained on that. Then cause-and-effect relationships from domain experts are added. The result is a model that can be opened, inspected, and if needed, corrected. The certificate it produces is traceable to every assumption inside it.
The DecisionCertificate is the governance artifact: inspectable, contestable, and submissible to a regulator or a review board.
The model across four states
05 What the model can answer
This one simple model can answer seventeen distinct questions.
This is a primitive model for illustrative purposes. A more sophisticated and realistic model could be almost indistinguishable from a clinician, but probably not entirely: a clinician produces varying results.
Rung 1, Observational
- Given these clinical findings, what is the posterior probability of acute appendicitis?
- Given high WBC, how does CRP co-vary? (cousin relationship through InflammationLoad)
- Given high RLQ pain, how does ReboundTenderness co-vary? (cousin through PainSensitivity)
- Given this appendicitis severity, what PostOpFeverDuration and InfectionSeverityScore should we expect?
- Which evidence items most raised the appendicitis posterior from prior? (pattern analysis)
- Which unobserved finding would most change the diagnosis? (value of information)
Rung 2, Interventional
- If we surgically intervene (treat appendicitis as confirmed regardless of uncertainty), what are the expected post-operative outcomes?
- If we suppress inflammation pharmacologically (do(InflammationLoad=−1)), what happens to WBC, CRP, and the appendicitis posterior?
- What is the pure diagnostic signal of WBC=14 stripped of its back-door confounding through InflammationLoad?
- What is the causal effect of each clinical input on the appendicitis diagnosis, separated from shared confounder contributions?
Rung 3, Counterfactual
- Given this patient’s observed findings, had their WBC been normal, what would the appendicitis posterior have been?
- Had their pain sensitivity been lower, would the clinical presentation still have met the diagnostic threshold?
- Given that PostOpFeverDuration was 45h, had InflammationLoad been lower at presentation, would they have met the safe-dismissal criterion?
- Had AlvaradoScore been 5 instead of 7 (different composite presentation), what would the diagnosis have been for this specific patient?
What it cannot answer
- Time-series questions (no dynamic Bayesian network)
- Questions about specific lab values below the threshold (CRP and WBC are continuous but priors may not cover edge cases well without recalibration)
- Diagnosis of conditions other than appendicitis, the model is single-target
- Population-level causal effects without aggregation across U-node draws
06 Converse in plain English
Let’s Ask EARA.
A conversation: the operator types, the LLM listens, the model thinks, the LLM speaks. That is the Enterprise AI Reasoning Architecture.
The audit trail is the AuditRecord. The process is auditable because the certificate exists.
07 Where it sits
The last component in the stack. Where reasoning meets governance.
Business Process Integration is the final component in the core EARA stack. It is the point where certified reasoning outputs leave the architecture and enter the enterprise process. Every component upstream produces inputs to the DecisionCertificate; Business Process Integration assembles and delivers it.
Upstream: the AuditRecord (from 01 Pipeline), the RobustnessReport (from 06 Robustness), the PatternExplanation (from 08 Pattern Analysis), and the InquiryResult (from 05 Inquiry, when the decision is “referred”). Downstream: the enterprise process, the regulator, and the customer. The TrustAlert from 11 Monitoring can suspend the Decision Service until re-elicitation is complete.