> > > SpecAdr001ModelVsProceduralNotation

ADR-001: Transformational Change Model vs. Procedural Notation

Status

Accepted

Context

Standard process modeling, including BPMN 2.0, is procedural and descriptive. It focuses on activities to be executed and treats the organization as a graph of tasks.

That model is useful for communication, but it drifts quickly from the actual state of execution. A diagram can remain visually correct while the operational truth has already changed.

Decision

SOTER adopts a transformational paradigm.

Each Activity or Action in Logos is modeled as a function that transforms input objects into output objects under the responsibility of a subject.

The canonical modeling unit is:

Subject -> Action -> Object

SOTER models state changes and responsibility, not merely activity boxes.

Rationale

The transformational model gives SOTER a stronger basis for verification than a purely procedural diagram. If an action claims to transform organizational matter, cost, information, or responsibility, the model can be checked for missing actors, missing inputs, missing outputs, and inconsistent flows.

Consequences

Positive

SOTER can reason about process state rather than only process shape.
Diagrams become projections of a model, not the model itself.
The model can support later reconciliation against observed facts.

Negative

Analysts must model transformations rigorously.
Informal exceptions must be represented as facts or explicit model variants.
Entry cost is higher than drawing a simple diagram.

Neutral or Operational

BPMN remains useful as an output notation.
SOTER must preserve a clear boundary between transformation semantics and visual process notation.

Alternatives Considered

Procedural BPMN as the Primary Model

Rejected because BPMN diagrams are too easy to desynchronize from operational truth and do not provide enough semantic structure for SOTER's verification goals.

Migration or Adoption

Existing process descriptions should be translated into Logos by identifying subjects, actions, input objects, output objects, and responsibility boundaries.