> > > PhilosophyPhilosophyConstitution

SOTER Constitution

Status: Load-bearing. Stable. Changes require an ADR in 02_spec/adr/ (see ArchitectureDecisions.md for the index of existing decisions).

Audience: Anyone - human or AI - joining the project. This is the first document to read after the origin story told in the Problem section below.

Thesis

SOTER - Symbiotic Ontology Transformer Enterprise Runtime - is an analytical, operational and evolutionary platform for organisations. Its job is to create, deterministically synchronise, enforce and evolve a shared model of an organisation's reality. Fully adopted, SOTER becomes a Single Source of Operational Truth.

SOTER is a contingent engineering response to a recurring organisational condition: the fragmentation of operational reality across diagrams, procedures, dashboards, tickets, spreadsheets, reports, API specifications and system records - artefacts that, taken together, still cannot reliably answer what is actually happening, which model says what should happen, or where reality diverged from the model.

This document states the axioms, foundational ontology and amendment rules that are load-bearing for SOTER. Violating an axiom means building a different system, not a tweaked one.

Problem

SOTER exists because organisations often lose shared operational truth.

They produce diagrams, procedures, dashboards, tickets, spreadsheets, reports, API specifications and system records, yet still cannot reliably answer:

What is actually happening?
Which model says what should happen?
Which facts prove what happened?
Where did reality diverge from the model?
Who is responsible for the meaning of this state, object or action?
How should the organisation adapt without erasing history?

SOTER is a response to this condition.

The name SOTER is intentionally symbolic. It points to salvation, but the analogy has limits. SOTER is not a metaphysical saviour. It is not necessary, eternal or universal. It is a contingent engineering response to a recurring organisational problem: the fragmentation of operational reality.

The pain did not create SOTER.

The pain revealed the absence of shared operational truth.

SOTER is an attempt to answer that absence with a text-first, deterministic, auditable and adaptive model of organisational reality.

Argument

Identity

SOTER - Symbiotic Ontology Transformer Enterprise Runtime.

SOTER is an analytical, operational and evolutionary platform for organisations. Its job is to create, deterministically synchronise, enforce and evolve a shared model of an organisation's reality. Fully adopted, SOTER becomes a Single Source of Operational Truth.

SOTER is not merely a diagram generator. It is a closed-loop semantic transformation system for adaptive organisations.

Its premise is isomorphic to the mechanism that gave the human species its edge: creating, sharing and cumulatively refining abstract models of reality across large groups. SOTER is the Company OS - kernel (Providence), file system (the bitemporal ledger .fact), drivers (.model ontology), window manager (Incarnation - server-driven UI), and an "external ecosystem" of specialised programs (FK, HR, MES) running on top and talking through a membrane (.api).

SOTER's central formula is:

declarative transformation + operational mindfulness = adaptive organisation

Axioms

These are load-bearing commitments. Violating one means we have a different system, not a tweaked one. Changing one requires an ADR.

Text-First, Deterministic Projections. The textual .model is the single source of semantic truth. Every diagram, table, UI - every visible artefact - is a projection derived from text via deterministic rules. GUI is never source.
Declarative Transformation. SOTER models organisations as systems of semantic transformations. An Action declares what transformation means: performer, inputs, outputs, constraints, evidence and expected state change. It does not prescribe the internal procedure unless explicitly delegated to an external artefact. Logos models the meaning of action, not the mechanics of execution.
Save-First, Then Interpret. The Ledger accepts every syntactically valid event without judgement. Semantic verification is asynchronous and produces explicit Ontological Dissonance (unresolved_gap) rather than rejecting reality.
Immutability with Correction. The Ledger is append-only and cryptographically chained (hash chain). Errors are not deleted; they are corrected by new facts that reference the wrong one (corrects: [ID]). History is preserved in full.
Bitemporality. Every fact carries both occurred_at (when it happened in the world) and recorded_at (when SOTER learned about it). Their difference (friction) is itself a system metric.
CQRS of Reality. The five file kinds - .model (Ontology / Physics), .view (Read), .interaction (Write), .fact (Ledger), .api (M2M membrane) - are strictly separated. Dependency rules are formalised in the dependency matrix.
Two Modalities of Reality. SOTER runs in two disjoint realities with different rigour:
Analytic (Sandbox / Epiphany Local, Django) - for modelling, prototyping, war-gaming. Ledger may be reset.
Operational (Gateway / Portal, Django) - for actual operational execution. Hash chain is permanent. See 03_philosophy/Research.md#reality-modalities.
Fractal Ontology, Atomic Action. Process is not a separate Logos node type - it is a Macro-Action: an Action grouping its own subgraph of triads. Action itself is atomic and has no sub-elements. Today's working convention: 1 .model file = 1 Process (see ADR-005).
Thermodynamic Honesty. Every Action must close its mass/energy balance (Zero-Sum / MES). When the balance does not match, the gap is materialised as an unresolved_gap rather than hidden.
Operational Mindfulness. SOTER does not only record actions. It observes their consequences, compares them with the expected model, materialises divergences and preserves the evidence needed for adaptation. The system must make organisational learning explicit, auditable and reversible by governance - never hidden inside a black-box optimiser.
Human-Governed Evolution. Sophia or any future adaptive/predictive layer may propose changes to .model, policies, procedures, interactions or projections. Such proposals are not automatically truth. Accepted evolution of the organisational genotype must pass through explicit review, provenance and amendment rules.
Single Universal Keyword. The Logos DSL has exactly one construct for declaring graph nodes: element. Semantics come from class: (in .model) and type: (everywhere). No implicit types, no syntactic sugar. See 02_spec/LogosGrammar.md.
Bilingual Origin, English Source-of-Truth. Conceptual prose was born in Polish; from 2026-05-17, all new artefacts (docs, code, commits, CLI output) are English, with multilingual hooks where feasible. The Web UI (Epiphany) is fully bilingual EN/PL. The CLI is English-only.

Foundational Ontology

These are the only primitives. Every .model is built from them.

SVO Triad - the only node classes in `.model`

Subject - Sovereign actor or system. Has autonomy: true|false (Blackbox/Pool vs transparent/Lane). Cannot compose other Subjects - inter-Subject structure goes through Relationship.
Object - Passive carrier of matter, energy or information. May compose other Objects via parent: when they form one physical/logical whole.
Action - Atomic transformation vector. Exactly one performer: (a Subject). No sub-elements. Explicit control flow via next: / previous:. Branching via decision: alternative | option | all (XOR / OR / AND gateways).
Relationship - N-ary association (hyperedge) binding sovereign entities. Static - does not consume time or energy.

Action as semantic contract

An Action is not a workflow fragment.

An Action is not a procedure.

An Action is not a screen.

An Action is a semantic transformation contract:

performer + input + constraints + context + state
    -> output + state_delta + evidence + possible feedback

The internal method may be manual, procedural, automated, delegated to an external system or implemented by a workflow engine. Logos does not require this internal complexity to be embedded inside the Action.

Where a detailed method exists, it should be referenced as an external artefact or governing Object, not expanded into procedural noise inside the semantic core.

Recommended distinction:

in: - Objects transformed, consumed or required by the Action.
out: - Objects produced or materially changed by the Action.
performer: - the Subject responsible for executing the Action.
governed_by: - procedure, policy, rule, contract or standard constraining the Action.
evidence: - fact, document, status, measurement or trace proving that the Action occurred.

Activity hierarchy - super-category, not a Logos keyword

Action - atomic semantic transformation.
Macro-Action - an Action interpreted at a higher level of abstraction, grouping its own subgraph of triads.
Process - a domain-scoped Macro-Action grouping Actions by shared resources, purpose or transformation chain. Not a declared element in Logos v1; convention is 1 file = 1 Process.
Task - reserved for future Action + Object pairs.

This preserves fractality without introducing a fourth ontological primitive.

Process vs Procedure

SOTER strictly separates process from procedure.

Process - a real or modelled organisational transformation observed at a chosen level of abstraction; in SOTER, a Macro-Action.
Procedure - a method, recipe, checklist, instruction or operational rule for performing an Action or Process.
Workflow / runtime - one possible technical implementation of a procedure or fragment of a procedure.

Therefore:

process != procedure != workflow != execution graph

A procedure may govern an Action.

A workflow may implement a procedure.

Neither procedure nor workflow is the semantic source of truth.

State vs Status

State - immanent, intrinsic properties (mass, serial number). Changing state requires an Action.
Status - observer-relative phenomenon, a label attached by an authorised Subject in the Ledger. Objects have undetermined status until an Action materialises one.

Detail and worked examples are maintained in the architecture and language 02_spec/LogosGrammar.md and 02_spec/Architecture.md#language-and-architectural-assumptions.

The Providence Loop

The core loop is:

Observer -> Ledger -> Verifier -> Reconciler -> Observer

The Verifier audits facts against .model (business physics). The Reconciler materialises any gap as a new Ledger entry (Ontological Dissonance), closing the loop without erasing history.

This loop creates operational mindfulness.

The Evolution Loop

The higher adaptive loop is:

.model -> action -> .fact -> verification -> gap -> reconciliation
       -> hypothesis -> simulation -> amendment -> evolved .model

This loop is not automatic self-modification.

It is governed evolution.

Sophia or any future adaptive/predictive layer may detect patterns, formulate hypotheses and propose amendments, but accepted model evolution must remain explicit, reviewable and traceable.

The system may learn.

The system must not silently rewrite reality.

Implications for SOTER

The axioms and ontology above are binding on every other part of the system, not descriptive background:

The Logos DSL (LogosLanguageSpec.md) is constrained by the Single Universal Keyword axiom and the SVO Triad: it may not add node types or syntactic sugar beyond element + class:/type:.
The Ledger and its technical architecture (TechnicalArchitectureSpec.md) must implement Save-First/Then-Interpret, Immutability with Correction, and Bitemporality exactly as stated - these are not tunable configuration.
The dependency matrix and module boundaries between .model, .view, .interaction, .fact and .api (CQRS of Reality) are formalised in the ADR index; any architectural change that would blur this separation requires a new ADR under the amendment rules below.
The Providence Loop and Evolution Loop are the two loops every runtime component (Verifier, Reconciler, Sophia or any future adaptive layer) must implement or respect; no component may bypass them to "fix" data directly.
Any adaptive or predictive layer (Sophia and successors) is scoped by the Human-Governed Evolution axiom: it may propose, never silently commit, changes to .model, policy or procedure.

Boundaries

What SOTER is not:

Not a monolithic ERP. External specialised systems (FK, HR, MES) run as Subjects on top of SOTER, integrated through the .api membrane.
Not an accounting system. SOTER tracks material/energetic flows (mass, cost basis); legal/fiscal interpretation (KPiR, VAT, payroll) belongs to external programs that consume SOTER's evidence.
Not a workflow engine in the BPMN-procedural sense. Order of Actions emerges from the topology of input/output Objects, not from imperative sequencing. There are no sequence, parallel, fork, join keywords.
Not a procedure repository. Procedures may be referenced, versioned and used as governing artefacts, but Logos does not collapse organisational reality into procedural instructions.
Not a diagramming tool. Diagrams are projections of models and views. They are never the semantic source of truth.
Not a free-form modelling tool. Linter rejects implicit types, syntactic sugar and any attempt to define UI styling inside .view.
Not a passive logger. The Ledger is hash-chained; tampering breaks the chain. Anomalies are materialised, not silenced.
Not a black-box AI optimiser. Adaptive and predictive layers may assist interpretation and propose changes, but they must not obscure evidence, provenance, responsibility or amendment governance.
Not an autonomous psyche. SOTER is deliberately stopped before self-governing agency. Its components may observe, remember, interpret, verify, simulate, and propose changes, but they do not own goals, establish organisational truth, or silently rewrite the organisational genotype. SOTER is an external metacognitive instrument of the organisation, not an autonomous subject.

Operational Consequences

This document is supposed to be boring. Things rarely change here. The following amendment rules translate that stability requirement into concrete, checkable procedure:

Trivial edits (typos, formatting, link fixes): direct commit, no ADR.
Wording of an existing axiom or boundary: PR with a one-paragraph justification.
Adding/removing an axiom, changing an ontology primitive, redrawing a boundary: requires a new ADR file in the docs/protected/02_spec/adr/ folder, registered in the docs/02_spec/ArchitectureDecisions.md index, and a link from this file back to the new ADR.
Promotion from 03_philosophy/incubator/ into here: allowed but rare - only once a concept has stabilised across multiple Logos models and at least one operational deployment level.
Promotion into the Evolution Loop: requires evidence from at least one simulated scenario and one reviewed model-amendment example.

Open Questions

This document intentionally carries no open conceptual questions of its own: by design, it only states what has already stabilised. Candidate concepts that are not yet settled belong in 03_philosophy/incubator/ and may only enter this Constitution through the promotion path defined in Operational Consequences above. Whether a given concept has stabilised enough to promote is itself tracked through that ADR/incubator process, not listed here.