Could You Hand a Regulator One Record of What Happened — or Would You Stitch Five Logs?

In the prevailing integration model, a business process is not a thing that exists. It is an emergent effect of calls choreographed between systems of record. A recipe or flow fires. The gateway records which API was invoked, by which identity, under which policy. The automation engine keeps a job history with its own run identifiers. And each endpoint — the ERP, the CRM, the ledger, the case system — keeps its own internal record of what it was told to do. Five participants, five clocks, five schemas, five notions of "who."

So when a regulator asks about one business event, someone has to become a forensic investigator inside their own company. They pull a gateway access log, match it to a recipe run ID, join that to three systems' internal audit tables, reconcile timestamps that were never synchronized, and infer the identity chain across handoffs that were never designed to line up. The evidence exists — scattered — but the correlation is a reconstruction performed under deadline, and every join is a place where the story can quietly diverge from what actually happened. The cost of that reassembly is a tax you pay every quarter, every audit, every incident. Worse, it is a tax with no guaranteed ceiling: the harder the question, the more systems you have to stitch, the more likely the seams show.

Give the category its due, because the strengths are real. Prebuilt connector breadth and API-led connectivity genuinely accelerate integration and let teams reuse governed interfaces instead of rebuilding them. Design-time and runtime API governance — one control plane, rulesets applied across the API estate — is valuable and hard-won. Low-code recipes really do let business teams automate without waiting on engineering. And the newest agent control planes genuinely discover services, mint delegated identities, and apply policy to which API or agent may be called, logged at the gateway. That is advanced work, and pretending otherwise fools no expert reader.

But notice precisely what all of that governs and records: the connection, the API, the recipe job, and the agent's call — with identity and policy enforced at the gateway. The tells are in the vendors' own language. One enterprise-automation platform promises "immutable audit logs for all AI actions" — auditing actions, because there is no process object to audit. A data-activation platform concedes its audit trail is "implicit," distributed across the endpoints it activates. A mass-market automation platform's compliance guidance amounts to "log everything — every input, output, and error." Read those honestly and they are all saying the same thing: the record is a downstream artifact you are responsible for collecting and correlating, not a native property of the process. It could not be otherwise — the business process never ran in the platform. It ran in the endpoints the platform glued together. Auditing the tool call is not auditing the process.

The gap matters because evidentiary questions are per-instance and per-action — not per-connection. Look at what the frameworks actually demand:

• SOX. Who was authorized to initiate this entry, who approved it, was segregation of duties preserved, and was the control operating on the date in question? These are questions about authority and state at a specific step, not about which API answered.
• HIPAA. Which identity touched which protected record, was access limited to the minimum necessary, and where is the per-access record? A gateway can tell you a call happened; it struggles to tell you the business justification the process was operating under when it happened.
• The EU AI Act. Was there meaningful human oversight over this automated decision, and can you explain and reproduce it? "Log everything" produces volume. It does not produce an explanation of why this instance decided as it did, or a faithful replay of the run.

Compress all of it into the sentence an examiner will actually say: "Show me who approved step 4, on whose authority, and replay it." A stitched reconstruction can approximate that answer. What it cannot do is guarantee it — because the keys that would bind the approval, the authority, the data, and the effect into one provable chain live in different systems that each recorded only their own slice. You are not producing evidence. You are defending a correlation.

The fix is architectural, not procedural. Stop treating the audit trail as something you harvest, and make it a property of a process that actually exists as a runtime object. That is the design premise of a composable process fabric. The business process runs as a first-class object with durable, governed state on one runtime. Governance is inline — the deterministic workflow enforces authority and sequence at the moment of the action, not as a design-time ruleset a call may or may not have respected. Human approval is a first-class step, not a side conversation logged elsewhere. And Connectors are the only primitive that touches external systems: a governed, typed, audited I/O edge — the thin, recorded boundary, not the place the business logic lives.

Because every state transition, every decision, every approval, and every external effect happens on the same runtime, the record is not collected — it is emitted. One immutable, per-action audit belongs to the process instance itself. This is an architectural property of making the process the governed object, and it is worth stating plainly what it does not claim: this is not zero integration. The fabric still runs over your existing estate through those governed Connectors. The difference is not whether you connect to systems of record. The difference is where the business actually runs and, therefore, where the record natively lives.

Now replay the regulator's question against each model. In the choreographed world, "who approved step 4, on whose authority, replay it" launches a forensic project: locate the recipe run, find the gateway entry for the approval call, correlate it to the approver's identity in a third system, and hope the reconstructed sequence is faithful. In the process-as-object world, step 4 is a row in this instance's ledger. The approver, the authority they held, the state the decision saw, and the external effect it produced are one linked chain, and the run is replayable because the runtime is the source, not the endpoints. That is the entire "+1": the evidentiary record is a native property of the process, so explainability is by construction rather than by reconstruction.

For a CFO or CRO, the change is not cosmetic. It moves the audit conversation from "can we reassemble what happened, and how confident are we?" to "here is the instance, with its authority and its replay." It collapses the standing cost of evidence production and, more importantly, removes the category of risk where the evidence exists but the correlation is contestable. You are no longer defending a hypothesis. You are handing over a fact.