SOTER Platform — Genesis and Business Rationale

Thesis

SOTER exists to eliminate the gap between what organisations document, what their systems enforce, and what actually happens. It does this by binding process models directly to the execution environment and to a ledger of real-world facts.

Problem

The SOTER project did not emerge as a theoretical product idea. It was born from a recurring, frustrating experience working with modern organisations: companies produce enormous volumes of documents, diagrams, procedures, reports, and system records, yet they lose the ability to precisely determine what is actually happening within their structures. There exists a systems truth, a user truth, a management truth, and a spreadsheet truth — but there is no single, authoritative source of operational truth.

In traditional enterprises, business process documentation dies the moment it is approved. Analysts draw diagrams in Visio or Sparx EA, which end up as PDF files on SharePoint. Meanwhile, developers implement operational systems according to their own interpretation, and employees modify processes via emails and Excel to work around software limitations. A massive gap opens up — documentation drift.

Argument

Binding the model to execution

The primary goal of SOTER is to create a mechanism that eliminates this inconsistency by binding process models directly to the execution environment and the ledger of real-world facts.

SOTER eliminates documentation drift by making the process model executable. The Logos language describes the structure and permitted transformations. The runtime validates every operational event against this model. If a process changes, the model must be updated in Git — otherwise the system will report a dissonance. Changing a procedure requires changing the model code, which guarantees that documentation is permanently up to date.

An immutable ledger as the basis for auditability

For operational truth to be indisputable, SOTER relies on a bitemporal event ledger (Akasha). Every business event is recorded as an immutable fact in a chronological chain that is cryptographically linked (hash chain). Traditional CRUD databases allow historical records to be modified using UPDATE statements, which makes reliable auditing impossible and encourages abuse.

In SOTER, history is sacred: facts cannot be modified or deleted. Any corrections require the introduction of new facts (e.g. a corrective invoice), which enables full reconstruction of the organisational state at any point on both the historical timeline and the event registration timeline (bitemporality).

Implications for SOTER

The platform must keep the model executable rather than descriptive, and must treat the ledger as append-only. Both properties follow directly from the diagnosed problem: documentation drift and unauditable history.

Boundaries

This does not claim that every organisational truth can be reduced to a model and a ledger of facts — only that the operational truth SOTER governs must be. Informal, non-operational communication is out of scope.

Operational Consequences

• Process changes must land as model changes in Git; no side-channel documentation is authoritative.
• Corrections to recorded history are always additive (new facts), never destructive edits.

Open Questions

• How much of an organisation's informal truth is safe to leave outside the model without recreating the original documentation drift at a smaller scale?

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.