---
title: 'Boldsea-Engine: Executable Ontology Workflow'
url: https://www.emergentmind.com/topics/boldsea-engine-cfb1ef93-628c-4da6-a97c-fbba0055b55e
type: topic
---

# Boldsea-Engine: Executable Ontology Workflow

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.18040v1', 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.09775v1', 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 [2510.18040] [2509.09775].

## 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 [2510.18040] [2509.09775].

| 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 [2510.18040].

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 [2510.18040].

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` [2510.18040].

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` [2509.09775].

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 [2510.18040].

A representative simplified BSL guard is:

```text
guard CheckLimit {
  when Exists(type='payment')
       ∧ ExistsMax(type='limit', actor=Risk, key=(limit,client))
       ∧ (payload.amount ≤ payload.dailyLimit)
  emit Event {
    type  = 'limit_ok';
    actor = 'System';
    context.client = payload.client;
  }
}
```

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 [2510.18040].

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:

```text
function auto_chain_predecessor(e_new, H):
  let Prev = { e∈H | actor(e)=a ∧ key(e)=k }
  if Prev ≠ ∅:
    let e_max = unique hb-maximal in Prev
    return { e_max }
  else
    return ∅
```

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` [2510.18040].

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 [2509.09775].

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 [2510.18040].

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:

```text
( $$.offer.confirmation=="Yes" ? "process" :
  $$.offer.confirmation=="No" || $$.offer.solution=="Reject" ? "closed" :
  undefined )
```

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 [2509.09775].

## 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 [2509.09775].

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 [2510.18040].

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” [2509.09775].

Source: https://www.emergentmind.com/topics/boldsea-engine-cfb1ef93-628c-4da6-a97c-fbba0055b55e