Boldsea-Engine: Executable Ontology Workflow

• The engine directly interprets semantic models as executable algorithms, allowing runtime modifications without the need for compilation.
• It employs a snapshot→batch→fixpoint dataflow with explicit causal dependencies, ensuring deterministic execution and full traceability.
• The system uses model-based validation and auto-chaining of events to maintain an append-only, acyclic event graph for distributed applications.

Searching arXiv for the specified papers and closely related work on boldsea-engine. [ArxivSearchResult(title='Subject-Event Ontology Without Global Time: Foundations and Execution Semantics', authors=['Vladimir Boldachev'], summary='This paper proposes a formalization of a subject-event ontology for modeling complex dynamic systems without reliance on global time. The approach addresses the challenge of describing processual and causally connected reality in distributed, asynchronous, and multiperspective environments, where external temporal synchronization is absent or optional. The proposed ontology is grounded in several key principles: event as an act of fixation -- a subject discerns and fixes changes according to models (conceptual templates) available to them; causal order via happens-before -- the order of events is defined by explicit dependencies, not timestamps; making the ontology executable via a declarative dataflow mechanism, ensuring determinism; models as epistemic filters -- a subject can only fix what falls under its known concepts and properties; presumption of truth -- the declarative content of an event is available for computation from the moment of fixation, without external verification. A formalization is given through nine axioms (A1-A9) covering event inclusion, causality, correction, multiperspectivity, Last-Write-Wins semantics, partitioning by key, and model-based generation, together with three invariants (I1-I3) ensuring the correctness of executable ontologies: monotonicity of history, acyclicity of causality, and traceability. Special attention is paid to the model-based approach (A9): event validation via schemas, actor authorization, and automatic construction of causal chains (W3) without global time. The practical applicability of the theory is demonstrated on the boldsea system - a workflow engine for executable ontologies, where the theoretical constructs are implemented in BSL (Boldsea Semantic Language). The proposed formalization is applicable to distributed systems, microservice architectures, DLT platforms, and scenarios with conflicting facts from different subjects.', entry_id='http://arxiv.org/abs/([2510.18040](/papers/2510.18040))v1', published='2025-10-20T14:21:15Z', updated='2025-10-20T14:21:15Z'), ArxivSearchResult(title='Executable Ontologies: Synthesizing Event Semantics with Dataflow Architecture', authors=['Vladimir Boldachev'], summary='This paper presents boldsea, Boldachev's semantic-event approach -- an architecture for modeling complex dynamic systems using executable ontologies -- semantic models that act as dynamic structures, directly controlling process execution. We demonstrate that integrating event semantics with a dataflow architecture addresses the limitations of traditional Business Process Management (BPM) systems and object-oriented semantic technologies. The paper presents the formal BSL (boldsea Semantic Language), including its BNF grammar, and outlines the boldsea-engine's architecture, which directly interprets semantic models as executable algorithms without compilation. It enables the modification of event models at runtime, ensures temporal transparency, and seamlessly merges data and business logic within a unified semantic framework.', entry_id='http://arxiv.org/abs/([2509.09775](/papers/2509.09775))v1', published='2025-09-11T09:32:39Z', updated='2025-09-11T09:32:39Z')] boldsea-engine is the workflow engine of the boldsea semantic-event approach: an implementation of “executable ontologies” in which semantic models are interpreted directly as executable algorithms in BSL (Boldsea Semantic Language), without compilation. In this framework, semantic models are not passive descriptions but active dataflow programs; model events are operators, reification events are tokens, and execution proceeds without reliance on global time, using explicit causal dependencies in an immutable event graph. The engine is presented as a practical realization of a subject-event ontology, with formal execution semantics, model-based validation, runtime model modification, and applicability to distributed systems, microservice architectures, DLT platforms, and multiperspectivity scenarios (Boldachev, 20 Oct 2025, Boldachev, 11 Sep 2025).

1. Architectural organization and execution kernel

The boldsea-engine implements the snapshot→batch→fixpoint dataflow execution. Its core runtime is described through six main components: History Store, Model Registry, Guard Evaluator, Event Constructor (“emit”), Reference Builder, and Admission Checker. In the complementary architectural presentation, the engine is also characterized as a reactive, subscription-based interpreter of BSL models, with Semantic Store, Validator, UI Controller & UI Validator, Execution Controller, and System Controller as the principal subsystems. These descriptions are not contradictory; they emphasize different slices of the same runtime: the event-graph kernel, the model registry and validation path, and the surrounding UI and lifecycle control machinery (Boldachev, 20 Oct 2025, Boldachev, 11 Sep 2025).

Component	Function
History Store / Semantic Store	Holds the append-only event graph H and the ever-growing temporal graph of reification events
Model Registry	Holds the set Models of epistemic filters, each with schema, permissions, guards
Guard Evaluator / Execution Controller	Watches the graph, evaluates G_Y, and fires model events when Condition(M) becomes true
Event Constructor (“emit”)	Runs emit_Y(H) to produce new event(s)
Reference Builder	Computes refs_explicit, refs_auto_chain, and refs_base
Admission Checker / Validator	Checks admit_incoming(e) and model restricting properties
UI Controller & UI Validator	Automatically generate and validate input forms based on the active model events
System Controller	Processes internal SetDo directives such as CreateIndividual and EditIndividual

The History Store is an append-only event graph H; each event record contains id, actor, role, key, payload, refs. The Model Registry holds the set Models of epistemic filters, each with schema, permissions, and guards. The Guard Evaluator evaluates BSL guards G_Y on the current snapshot H using the matches(·) function and composite literals Exists, Count, ExistsMax, and Order. The Event Constructor executes emit_Y(H) for each active guard. The Reference Builder computes refs_explicit from model Conditions, refs_auto_chain, and refs_base. The Admission Checker performs a two-stage check: admit_incoming(e) tests A9 constraints, and admit_Y(H) tests G_Y and admit_incoming on emitted events (Boldachev, 20 Oct 2025).

At the level of control flow, the engine repeatedly evaluates the current snapshot, collects the set of guards whose conditions are satisfied and admissible, emits a batch B, enriches each emitted event with explicit, automatic, and base references, and extends H until B = ∅. This is the operational meaning of the labeled transition:

$$F(H)=H\cup B(H), \qquad B(H)=\bigcup_{Y\in\mathcal{Y}_0}\mathrm{emit}_Y(H), \qquad \mathcal{Y}_0=\{Y\mid [[G_Y]]_H=true \wedge \mathrm{admit}_Y(H)\}.$$

A defining architectural property is that there is no central scheduler or clock; all coordination is via the happens-before graph

$hb := tc(refs).$

2. Ontological commitments and causal semantics

The subject-event ontology formalized for boldsea-engine is organized around nine axioms, A1–A9. The paper defines an event as “an act of discernment and fixation by a subject … containing who (actor), what (payload), about what (base), model_id and refs.” Causal order is not derived from timestamps but from explicit references: A2 states, “The happens-before relation is defined exclusively through explicit references: hb := tc(refs).” A3 excludes hidden causes: all causes of an event are either explicitly listed in refs or absent. A4 introduces multiperspectivity: different actors can fix conflicting events about the same entity, and the ontology permits the coexistence of alternative facts without global contradiction resolution. A5, the presumption-of-truth principle, makes the declarative content of an event available for computation from the moment of inclusion in H. A6 enforces correction-as-event: refutations, corrections, or cancellations are expressed as new events, and history grows monotonically. A7 defines Last-Write-Wins via hb, per actor and per key. A8 states that the classifying function key induces a partition of history, H = \bigcup_k H_k, ensuring modularity and independent processing. A9 requires model-based generation: an event is permissible only if some model authorizes the actor, validates the payload, and ensures the required witness references for existential conditions (Boldachev, 20 Oct 2025).

The formal clause for A9(iv) is:

$$\forall (\mathrm{Exists}(ϕ)\in \mathrm{Condition}(M)): [[\mathrm{Exists}(ϕ)]]_H = \mathrm{true} \;\implies\; \exists\, e′\in H:\; \mathrm{matches}(e′,ϕ)\;\wedge\;e′\in \mathrm{refs}(e).$$

The invariants I1–I3 establish the correctness envelope of execution. I1 is monotonicity of history: events are not deleted from H, and reactions that have already fired are not annulled. I2 is acyclicity of hb, ensured by prohibition of forward references and acyclicity of refs. I3 is traceability: for any event e∈H, its causal cone is finite and reconstructible by traversing the refs graph. The same presentation states that these axioms and invariants jointly guarantee determinism via W3 and append-only guard evaluation, monotonicity because history never shrinks, and acyclicity by forbidding forward references and cycles in refs (Boldachev, 20 Oct 2025).

A plausible implication is that boldsea-engine treats causality as a graph-theoretic property of explicit dependencies rather than as an artifact of synchronized clocks. This is why global time is optional rather than semantically foundational.

3. BSL as the executable specification layer

BSL is the formal language in which the engine’s executable ontologies are stated. The engine “directly interprets semantic models as executable algorithms without compilation,” and the BSL model is the program: the engine merely interprets it continuously. The language is specified by a formal BNF grammar whose representative fragment includes ModelDef, ModelBody, PropertyList, and property types Attribute, Relation, Role, and SetDo; restriction types include Condition, SetValue, and Permission. Expressions inside Condition or SetValue use a JavaScript-like syntax plus special graph-query prefixes "$"` and `"$"`, and support comparison operators `\$EQ, \$LT, \$GT, … and logical combinators \$OR, \$AND (Boldachev, 11 Sep 2025).

The operational side of BSL in the ontology-without-global-time formulation is given by the mini-grammar

$$\phi ::= atom \mid \phi \wedge \phi \mid \phi \vee \phi \mid \neg atom$$

with

$$atom ::= type = t \mid field(p) = v \mid has(p) \mid Exists(\phi) \mid Count(\phi) \ge k \mid ExistsMax(\phi,a,k) \mid Order(\phi_1\ \mathrm{BEFORE}\ \phi_2).$$

The semantics are defined through matches(e,ϕ) and the interpretation [[·]]_H for composite literals. Negation is stratified to ensure a least fixed point. In practical terms, this means that guards are declarative predicates over the current event history, and the engine computes consequences by repeated fixed-point expansion rather than by imperative sequencing (Boldachev, 20 Oct 2025).

A representative simplified BSL guard is:

$hb := tc(refs).$0

The language thereby merges event recognition, data constraints, permissions, and event emission in a single specification layer.

4. Validation, admission, and automatic causal chaining

Model-based validation is the central admission discipline of boldsea-engine. A9 requires that every incoming event satisfy:

$$\mathrm{admit\_incoming}(e)=\exists M\in Models:\; \mathrm{model\_id}(e)=id(M)\wedge \mathrm{authorized}(\mathrm{actor}(e),M)\wedge \mathrm{valid}(\mathrm{payload}(e),M)\wedge \mathrm{refs\_ok}(e,M).$$

The models carry id, type, schema (data constraints), permissions (roles + conditions), and guards (for reactive events). This places schema validation, actor authorization, and witness traceability in a single admissibility test rather than distributing them across separate subsystems (Boldachev, 20 Oct 2025).

The construction of causal chains is partly automatic. The Reference Builder computes three components for each new event: refs_explicit, refs_auto_chain, and refs_base. refs_explicit is derived from witnesses for each Exists() in Condition(M). refs_base points to the creation-event of context(e). refs_auto_chain implements W3, “Actor-serial per key,” which demands that for each (actor a, key k), events form a total chain under hb. The auto-chain rule is:

$hb := tc(refs).$1

The stated inductive proof shows that adding the auto_chain predecessor preserves W3 and hence the uniqueness of ExistsMax. This is the mechanism behind the paper’s claim that the uniqueness of maxima is ensured by requirement W3 and its implementation through auto_chain (Boldachev, 20 Oct 2025).

The validation path is therefore not only a type check. It is also a causal-accounting discipline: the engine requires admissible payloads, admissible actors, and admissible references, and it augments references so that the hb relation remains sufficient for LWW semantics, traceability, and deterministic evaluation.

5. Runtime modification and representative execution traces

A distinguishing property of boldsea-engine is runtime model modification. The description states that at any moment an analyst, or an LLM assistant, can add, modify, or remove a model event M, including its Condition or SetValue. The engine responds by updating the semantic store, notifying the Execution Controller, reconciling subscriptions, leaving all past reification events intact, and re-evaluating the updated Condition(M) immediately against the current event graph. If the condition is true, it backfills by generating the missing events in causal order, preserving acyclicity and timestamp order. Model edits do not rewind history; new or changed logic applies to future and yet-to-be-fired model activations (Boldachev, 11 Sep 2025).

A canonical example in the ontology-without-global-time presentation is a simple payment workflow:

• e₁: payment(amount=950,client=A) (root)
• guard Y₁ (CheckLimit) fires ⇒ e₂: limit_ok(client=A) with refs={e₁}
• guard Y₂ (ExecutePayment) fires ⇒ e₃: executed(client=A) with refs={e₂}∪auto_chain(e₁)

The execution reaches fixpoint in 2 batches, and the causal graph is fully traceable under I3 (Boldachev, 20 Oct 2025).

A second representative example is the “ProcessingRequest” model, in which the same BSL artifact defines Relation : subject, Attribute : offer, Attribute : solution, Attribute : confirmation, and Attribute : status, together with Permission, Condition, and SetValue. The given SetValue for status computes:

$hb := tc(refs).$2

The sample execution trace is:

1. E₁ (RequestCreated, subject=Product_A123, actor=Customer, …)
2. E₂ (OfferAssigned, offer=Standard, actor=Employee, cause=E₁)
3. E₃ (SolutionSet, solution="Accept", actor=Manager, cause=E₂)
4. E₄ (ConfirmationSet, confirmation="Yes", actor=Customer, cause=E₃)
5. E₅ (StatusUpdated, status="process", system=Engine, cause={E₁,E₂,E₃,E₄})

The engine fires E₅ automatically as soon as its prerequisites are present; no external scheduler or orchestrator is involved, and the behavior is described as pure dataflow driven by declarative BSL (Boldachev, 11 Sep 2025).

6. Relation to BPM, semantic systems, and distributed deployment

The boldsea formulation is explicitly positioned against two gaps in enterprise architecture: the semantic-process gap and the structural-execution gap. Traditional BPM, exemplified by BPMN in the description, “relies on imperative, sequence-driven control flow,” “cannot be altered at runtime without redeployment,” and “decouples process logic from the semantics of underlying data.” Object-oriented semantic systems, summarized as “RDF/OWL + rule engines,” “store static graphs of facts,” “execute rules in an external engine,” and “do not natively model or execute temporal, causal activity.” By contrast, boldsea-engine replaces imperative steps with a pure event-based dataflow in which model events are operators and reification events are tokens (Boldachev, 11 Sep 2025).

The deployment-oriented applicability claims are equally specific. Partitioning by key, A8, “maps naturally to service-level sharding.” “Immutable, cryptographically hashed event ids” fit DLT ledgers. Multiperspectivity, A4, allows conflicting views per subject without central consensus. Optional ts_sys is retained for UI/audit only, not for core causality. Formal arguments stated in the source include: the W3 invariant proven inductively ensures unique “last” events per actor/key and therefore deterministic LWW; a fixed-point theorem sketch with monotonic F, finite guards, and stratified negation guarantees termination; and invariants I1–I3 guarantee monotonicity, acyclicity, and traceability in fully asynchronous deployments (Boldachev, 20 Oct 2025).

A plausible implication is that boldsea-engine is best understood not as a workflow engine layered on top of an ontology, but as an executable ontology system in which ontology, process logic, data, and UI definitions are co-located in a single event graph. That implication matches the explicit formulation that the system “seamlessly merges data and business logic within a unified semantic framework” and that “ontologies, process logic, data, and UI definitions all live as events in one graph” (Boldachev, 11 Sep 2025).