Business Modelling Paradigms and SOTER's Cybernetic Theory

Thesis

Business reality should be modelled declaratively, as states, transformations, and invariants, rather than procedurally, as a fixed sequence of steps. SOTER grounds this choice in Aristotelian hylomorphism: a model is a form that continuously governs and is checked against the matter of recorded facts.

Problem

Traditional business process modelling (e.g. in BPMN) is based on the procedural paradigm: a sequence of steps, conditional instructions, and loops is defined (e.g. "first do A, then if X, do B"). This approach is error-prone because business reality is rarely perfectly linear. Every unhandled exception in a diagram causes the process to fail or spawns informal workarounds outside the system.

Argument

Declarative modelling over procedural sequencing

SOTER proposes declarative modelling. Instead of describing exactly how a process must unfold, Logos defines initial states, transformations (actions), and invariants of reality (e.g. "goods cannot be issued if they are not in stock"). The system does not impose a rigid sequence of steps — it permits any behaviour as long as it does not violate the defined physical laws and business rules of the organisation.

Hylomorphism and the organisational digital twin

The philosophical foundation of SOTER is Aristotelian hylomorphism — the concept that every entity consists of matter (substance) and form (shape/structure). In SOTER, the form is the genotype encoded in .model files (the abstract structure of classes, relations, and permitted transformations), while the matter (phenotype) consists of the facts recorded in .fact ledger entries (empirical events that occur in time).

The organisational digital twin emerges through continuous comparison of form with matter. If a recorded fact violates the defined form, the system reports an ontological dissonance. This dissonance is not a technical error — it is a signal that either reality has malfunctioned (e.g. a resource has been stolen) or the model is outdated and needs to be refactored in Git.

Implications for SOTER

Logos must be able to express states, transformations, and invariants directly, rather than encoding fixed control flow. The runtime must compare every incoming fact against the current form and surface mismatches as ontological dissonance rather than silently accepting or rejecting them.

Boundaries

This argument does not claim that procedural diagrams are useless for communication — only that they are unsuitable as the enforced source of operational truth. It also does not claim that every organisation's rules can be captured; it claims that whatever is captured must be declarative.

Operational Consequences

• Model authors express rules as invariants and permitted transformations, not as scripted step sequences.
• An ontological dissonance must always be routed to a human decision: fix reality, or refactor the model in Git.

Open Questions

• How should recurring, expected exceptions be distinguished from genuine ontological dissonance at the tooling level?

Related Documents

• DocumentationStyleGuide.md - writing profile and document-type rules.
• PhilosophyEssayTemplate.md - philosophy document template.
• PhilosophyOverview.md - philosophical documentation entry point.
• GovernanceOverview.md - governance and lifecycle entry point.
• AkashaLedgerOverview.md - ledger and fact-recording context.