> > > SpecBpmnExecutableVsNonExecutableAnalysis

BPMN Executable vs Non-Executable Analysis

Question

What is the correct relationship between BPMN (in both its executable and non-executable forms) and SOTER's model-first architecture, given BPMN's structural ambiguity between diagram, execution specification, and audit artifact?

Context

The analysis originates from the OMG document "BPMN 2.0 by Example," which describes non-executable BPMN models represented both as diagrams and as machine-readable XML. The important distinction is not "diagram versus XML." The same BPMN model can have a visual representation and an XML representation.

The distinction that matters is:

business process model != executable procedure

SOTER exists partly because this distinction is often collapsed in BPMN-centric systems, and this note fixes SOTER's position before any BPMN-oriented tooling or projection work proceeds.

Sources

OMG, "BPMN 2.0 by Example"
Internal architecture discussion on Camunda-style execution semantics

Findings

BPMN tries to serve several audiences at once: business analysts, process owners, integration designers, workflow automation teams, and execution engines such as Camunda-like runtimes. A model useful for business understanding is not necessarily a safe executable specification.
BPMN diagrams and BPMN XML are two representations of the same BPMN model. The XML is not automatically executable; it can encode non-executable process models, executable process definitions, collaboration diagrams, choreography diagrams, and diagram interchange metadata.
Therefore: visual BPMN != non-executable by definition, and BPMN XML != executable by definition. Executability depends on conformance class, engine-specific attributes, implementation bindings, and runtime context.
An executable workflow contains implementation concerns — retries, technical tasks, service calls, compensation paths, engine-specific semantics — that can obscure business meaning when mixed into the same artifact as the business model.
BPMN-centric systems typically follow the pattern BPMN model -> engine -> runtime truth, where the runtime engine becomes the authoritative definition of organizational reality.

Interpretation

The main risk for SOTER is importing BPMN's ambiguity wholesale. SOTER must not let one artifact become an ontology, a process description, a procedure, a runtime script, a visualization, an integration contract, and an execution log all at once. This collapse is exactly what makes many BPMN-centric systems hard to reason about.

SOTER inverts the Camunda-centric pattern. Instead of BPMN model -> engine -> runtime truth, SOTER uses:

Logos model -> facts -> verification -> projections -> optional execution adapters

BPMN becomes one projection, not the source of truth. Execution is an optimization layer: the runtime may perform work, orchestrate systems, or guide users, but it must not become the authoritative definition of organizational reality. The authoritative layers are .model (possible reality), .fact (what occurred), .view (human-readable projections), and .interaction (controlled write paths). Workflow execution may use these layers, but it must not replace them.

This motivates a process vs. procedure distinction. A process is a semantic structure of transformation (inputs -> action -> outputs) that explains what changes and why. A procedure is an operational implementation (step 1 -> call service -> wait -> retry -> compensate -> notify) that explains how a specific runtime carries out work. SOTER should model processes in Logos; procedures can exist as adapters, playbooks, workflows, scripts, or engine-specific definitions that reference the model.

SOTER's core is declarative transformation. An Action is a semantic contract, not merely a workflow box: Action(x) -> y, where in organizational reality x and y are structured behavioral and material states (Input state + subject + constraints -> output state). This makes Logos closer to an ontology of possible transformations than to a procedural flowchart. At the Logos level, an action may remain a black box, defining required inputs, produced outputs, allowed performer, constraints, expected evidence, and possible states — the internal procedure can be modeled separately if needed. This protects SOTER from prematurely encoding every operational detail into the semantic model.

The same pattern scales: a larger process can be understood as a macro-action (OrganizationStateBefore -> Process -> OrganizationStateAfter), allowing SOTER to move from individual actions to whole organizational capabilities while keeping one semantic pattern.

SOTER's "kill feature" is operational mindfulness: the ability to compare declared models with observed facts and detect where the organization has drifted from its own declared reality. This requires a layered model: ontology (what can exist and transform), facts (what occurred), interpretation (what facts mean relative to the model), adaptation (what should change), and prediction (what may happen next). BPMN usually stops around process description or execution. SOTER continues into interpretation, adaptation, and model correction.

This is why SOTER exists: documentation becomes false, diagrams die after meetings, dashboards show numbers without truth, analysts translate between incompatible worlds, BPMN flattens organizational reality into workflow, developers receive tasks without semantic context, and responsibility matrices do not expose real coverage. SOTER answers with a structured separation of model, fact, view, and interaction.

One of the central definitions follows directly:

.model = space of possible reality
.fact  = occurrence within that space
ledger = recorded trajectory through that space
memory = adaptive interpretation of that trajectory

The model does not record what happened; it defines what can happen. Facts do not mutate the model — they record that a model-defined possibility occurred. Runtime actions move instances through the model's possibility space; they do not change the possibility space itself.

This also constrains how user interaction is allowed to reach the model. User interaction must not directly mutate the model. The correct chain is user interaction -> command -> fact -> projection update -> optional status change. If a user drags a card between lanes, that visual gesture must become a semantic command; the command generates a fact; the fact may change the projected status of a domain object if the model permits that transition. Drag and drop is not a visual operation — it is a semantic command expressed visually. A workflow card is neither the model nor necessarily the domain object; it is typically a representation of an action occurrence (ActionDefinition -> ActionOccurrence -> Fact -> StatusProjection). Moving the card may directly change the action occurrence and indirectly affect domain object status through declared transition effects.

SOTER also distinguishes ledger memory from organizational memory. The ledger records occurrences, preserves order, serves as evidence, and does not generalize or decide what is useful. Organizational memory abstracts, interprets, forgets selectively, supports survival and decisions, and adapts through learning. Short formula: the ledger testifies; organizational memory adapts.

Finally, SOTER can model IT when IT is part of operational reality — bounded contexts, integrations, API contracts, event sourcing, system topology, operational capabilities, cross-system responsibility — but it should not replace source code modeling, class diagrams, framework internals, or line-by-line implementation design. Its role is semantic coverage, not code generation by default.

BPMN becomes dangerous when one diagram is expected to be business truth, technical implementation, runtime script, and audit object at once. SOTER avoids this by separating ontology, facts, views, interactions, and execution adapters. The result is not "better BPMN." It is a model-first organizational runtime where BPMN is only one controlled projection of a deeper semantic truth.

Impact on SOTER

This analysis fixes constitution-level rules that constrain architecture and philosophy going forward:

BPMN is a projection, not source truth.
Execution is an optimization layer.
Runtime must not own ontology.
User actions generate facts, not model mutations.
Status change is not model change.
Model change requires an explicit amendment process.
Process and procedure must remain separate.
A procedure may reference a process, but must not redefine it silently.

These rules bound how any future BPMN projection, execution adapter, or workflow UI may be designed.

Confidence

High. The distinction between model and execution is already load-bearing across SOTER's architecture (.model / .fact / .view / .interaction separation) and is treated as settled rather than open for debate.

Follow-up

Promote the constitution-level rules into a formal governance document or ADR if they are not already captured there.
Use this note as the reference position when designing any BPMN export or execution-adapter projection (see TextToBpmnToolingAnalysis.md).